Hi,
> I don't know what I'm talking about, but... :
> Are you sure NFQUEUE gets involved in outgoing tcp fragmentation?
Well, NFQUEUE receives 100 bytes payload, out of which 20 are IP and 20 TCP.
I shrink payload (adding a valid TCP option, 8 NOPs for example), so
TCP is 28 bytes and the payload size is (100-20-28).
These 8 bytes will get retransmitted over and over, breaking the
transmission and coming from the most unlucky packet that started a
SEQ/ACK war.
Same happens when payload gets larger.
>
>> also want to have control over SEQ/ACK numbers assigned to
>> both packets and connection structures.
>
> It'd be the TCP layer's job to fragment outgoing packets, considering
> the appropriate MSS. conntrack defragments, as far as I can see,
> nfqueue doesn't deal with the issue at all.
Of course it is.
But, given example - want to modify packet so it's data size (mean,
data == anything after tcphdr data offset) will change. Wasn't NFQUEUE
oriented at doing any kinds of MITM/encryption stuff, not being used
as a drop-in replacement for pcap thus a base for l7-filter only?
What happens then? Retransmission. What happens if I want to send out
a packet which length is bigger than MTU? Partial fragmentation thus
SEQ/ACK flaw leading to constant retransmission of a first fragment.
More, the same happened when trying to capture packet withing mangle
or raw table, which is nonetheless strange.
>From looking at the code, guess the only possible workaround is to use
nfq_set_verdict(NF_STOLEN, ...) and reinject the modified packet.
But again, that's not enough to deal with whole connection tracking thing.
>> [...] Can anyone point me to correct place in kernel sources to
>> see/attach with SystemTap and track how SEQs are generated and how
>> outgoing packets are planned to be fragmented or even dropped?
>> Deliberately want a good tour. [...]
>
> For plain ipv4, for recent systemtap versions:
>
> probe kernel.function("secure_tcp_sequence_number").return {
> printf ("%s -> %d\n", @entry($$parms), $return)
> }
> probe kernel.function("tcp_fragment") {
> println($$parms, " ", @cast(&$skb->cb[0], "tcp_skb_cb")->seq,
> " ", @cast(&$skb->cb[0], "tcp_skb_cb")->end_seq)
> }
>
> sk=0xffff8805215d4880 skb=0xffff8805125fac00 len=0x500 mss_now=0x5a8 1280 3015968150 3016000006
Answer accepted. So will running a dump_trace() or similar for
anything called after nfq_set_verdict reveal a call to this functions?
cheers,
Igor
--
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
