Date: Fri, 4 Jun 2004 09:55:12 -0700
From: Guy Harris <gharris@xxxxxxxxx>
On Tue, Jun 01, 2004 at 09:58:25PM +0200, Olivier Biot wrote:
> Given your input I can live with the patch. Guy, what's your view?
> Maybe we can check it in and see if it breaks something (which it
> shouldn't).
...but it did.
I have an FTP capture where the client sends
Unfortunately, as the connection comes *from* the server to the
*client*, the official port number for FTP data (port 20) is the port
from which the initial SYN *comes*, not the port to which it *goes*, and
the new port matching scheme doesn't work, and the FTP data connection
isn't dissected as such.
Hi Guy, Olivier, list,
Indeed the patch breaks the FTP DATA.
The patch assumes that the well known port number is used to receive
connections.
It does not work when the client chooses a well known port number for its
ougoing connections.
This is because the table "tcp.port" does not contain this information.
There should be two tables :
- "tcp.port" when the well known port number is used to receive connections.
- "tcp.cport" when the well known port number is used by the client to
initiate a connection.
All dissectors (FTP, ...) that use a well known port number to initiate a
connection should be modified.
If the SYN was seen in the conversation, the TCP dissector should call
dissector_try_port() twice :
- Once for the "tcp.port" table.
- If the first call failed to find a match, a second time for the
"tcp.cport" table.
Which other protocols do use this well known port number for client flow
(the IANA list does not mention that either)
What do you think ?
See you,
metatech
