Re: [RFC] SIP conntrack handler and TCP fragmentation

[Ulrich Weber <uweber.linux@gmail.com>]

On 12.10.2016 13:41, Florian Westphal wrote:
> Ulrich Weber <uweber.linux@gmail.com> wrote:
>> From reading the code this fixed the problem when Content-Length
>> points to one of the next TCP fragments.
> 
> Right.
> 
>> In our case Content-Length is always 0 with a couple of SUBSCRIBE calls.
>> E.g. a TCP packet starting with this will break the SIP connection tracking:
>>
>> INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE
>> Content-Length: 0
> 
> Ugh.
> 
> I guess it makes sense to detect this and then accept for this case too.
> 
>> The previous TCP packet was accepted by SIP connection tracking
>> because it had no Content-Length field.
> 
> Perhaps we should treat Content-length of 0 like "no Conent-Length
> field".
> 
Ahh, I found the root of the problem ;)

Since the payload doesnt start with SIP/2.0, its interpreted as
a response. Starting with INVITE its interpreted as an INVITE
request. Since there is no CSeq header found, its dropped then as invalid.

Possible proper solutions would be either
a) add trailing space to sip_handlers commands
b) check for trailing SIP/2.0 in request line

Do you think a or b would break existing setups?