I traced the problem to the display routines. The version information was
being pulled from the first byte of the tcp data even after the actual
socks startup was done. I have patched my copy of the dissector and will
upload it tomorrow. First I want to check the diff that you sent.
Jeff Foster.
-----Original Message-----
From: Yaniv Kaul [mailto:ykaul@xxxxxxxxxxxx]
Sent: Thursday, February 12, 2004 7:41 AM
Attached please find a fix for packet-socks.c that corrects this,
against CVS 2004-01-20.
Yaniv Kaul wrote:
> Lines 840-844, in packet-socks.c:
> else if ( hash_info->state == AuthReply){ /* V5 User Auth reply */
> hash_info->cmd_reply_row = get_packet_ptr;
> if (check_col(pinfo->cinfo, COL_INFO))
> col_append_str(pinfo->cinfo, COL_INFO, " User
> authentication reply");
> hash_info->state = V5Command;
>
> The code assumes that the response for a an authentication request is
> a V5Command. However, it's usually an authentication response - and
> the authentication subnegotiation has its own version number ('1',
> according to RFC 1929). This causes it not to interpret the command
> properly (as it see the version is '1' and '5', it won't continue to
> dissect the packet).
>
> I've seen servers replying with version '5', but I think it's a faulty
> server - some clients won't be able to connect to it, if they expect
> the version they sent ('1)' and the version they received ('5') to
> match...
>
> Snoops will be available upon request.
>
>
***
The information in this email is confidential and intended solely for the individual or entity to whom it is addressed. If you have received this email in error please notify the sender by return e-mail, delete this email, and refrain from any disclosure or action based on the information.
****