Guy Harris wrote:
> On Oct 6, 2008, at 8:09 AM, Cosmin Craciunescu wrote:
>
>> One problem is in order to dissect IP protocol 0x69 (SCPS)
>
> SCPS compressed TCP, that is (according to the SCPS-NS specification).
>
Yes, that's the one.
>> I need to
>> have access to information from the TCP packet with the SYN flag for
>> this connection (it's a convoluted protocol).
>
> I.e., the connection starts out using TCP (protocol 6) and then
> switches to compressed-header TCP (protocol 105)?
>
Correct again. The TCP packet that opens the connection has a SCPS
option which shows willingness to enable compression, and a connection
id. The endpoints that communicate through the SCPS compressed TCP
protocol are supposed to remember the TCP ports (and other things) for
each connection id, in order to reduce redundant data being sent over
the wire.
> Does the initial SYN always have SCPS options? If so,
> dissect_tcpopt_scps() in the TCP dissector could attach the relevant
> information to the conversation for the TCP connection, and the SCPS
> dissector could look for the TCP conversation and use that
> information. If not, the TCP dissector might have to have an option
> to create a conversation and attach the relevant data (if it already
> does so, it probably needs to have that controlled by an option, so
> that a TCP capture with a SYN flood doesn't cause a lot of
> conversations to be allocated - that was an issue with tcpdump, which
> allocates a conversation data structure by default).
Thank you for this, it's given me an avenue to look at. I didn't know
about conversations, and I'll take a look at them. Since the SCPS
option should always be set if SCPS compressed TCP is to be used, I'll
look at dissect_tcpopt_scps() to see what can be done.