I have uploaded a new copy of the socks dissector that will fix this
problem.
Originally I planned to replace either the pinfo dst or src addresss with
the
socks destination address before the recursion. However this didn't work in
this situation because to first socks tunnel was trying to create a second
socks tunnel to the same server. Therefore the tunnels would look the same
to
the conversation code even if I replaced the pinfo address.
Instead I added a flag (in_socks_dissector_flag). Now the dissector will
just exit when this flag is set.
Jerome,
You really have a unusual case here. The first socks tunnel is creating
a second socks tunnel to the same server. If you can supply another capture
with the second socks tunnel going to another server I will look at
enhancing
the dissector to handle that case.
Jeff Foster
jfoste@xxxxxxxxxxxx
From: Jerome Delamarche
Sent: Wednesday, September 17, 2003 2:27 AM
> Here is the a capture that make (t)ethereal crashes when it decodes the
> "CONNECT TO Port 1080" request from the client using the SOCKS4 protocol.
> Also crashes with SOCKS5.
>
> The problem comes from a infinite recursive loop that occurs when the
SOCKS
> dissector tries to analyze the encapsulated protocol....which is still
SOCKS
> here... Seems, packet offsets are not well handled thus the analysis still
> restarts from the beginning of the packet....
***
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.
****