Hi Florian,

On 12.10.2016 09:52, Florian Westphal wrote:
> Ulrich Weber <ulrich.we...@gmail.com> wrote:
>> I know the proper solution would be TCP defragmentation
>> in the nf_conntrack_sip kernel module. However I'm not
>> sure if this is worth the effort.
> I think an even better solution would be a SIP proxy that can
> inject expectations to keep datapath in kernel and only deals with
> the signalling traffic.
Yes your right, is there already one capable of doing this?
But then again, I dont want to put a proxy on an embedded box ;)

>> What about just accepting unparsable TCP SIP packets?
> I wonder why this patch did not fix your problem:
> 3a7b21eaf4fb3c971bdb47a98f570550ddfe4471
> Author: Patrick McHardy <ka...@trash.net>
> netfilter: nf_ct_sip: don't drop packets with offsets pointing outside the 
> packet
> It specifically deals with this problem (l7 size larger than packet
> size).
>From reading the code this fixed the problem when Content-Length
points to one of the next TCP fragments.

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:

Content-Length: 0

The previous TCP packet was accepted by SIP connection tracking
because it had no Content-Length field.

To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to