Hi Florian, On 12.10.2016 09:52, Florian Westphal wrote: > Ulrich Weber <ulrich.weber@xxxxxxxxx> 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 <kaber@xxxxxxxxx> > 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: INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE Content-Length: 0 The previous TCP packet was accepted by SIP connection tracking because it had no Content-Length field. Cheers Ulrich -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
