RE: Bigger packet after mangling queued packets

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

I think I have run into this issue in the past. Check if you have loaded the module nf_defrag_ipv4. If that is the case, most likely the OS is taking part of the reassembly and you won't be able to see the fragments of the packet. You can try as well disabling the checksum offloading calculation with ethtool.
If machine A and B are virtual hosts connected via veth pairs, disable the offload in both ends :)

Best,
Jesus

-----Original Message-----
From: netfilter-owner@xxxxxxxxxxxxxxx [mailto:netfilter-owner@xxxxxxxxxxxxxxx] On Behalf Of Anton Danilov
Sent: 29 August 2016 23:18
To: Pierre-Antoine BRAMERET <pa.brameret@xxxxxxxxx>
Cc: netfilter@xxxxxxxxxxxxxxx
Subject: Re: Bigger packet after mangling queued packets

Hi.

Check the outgoing traffic with tcpdump on machine A, and check the offloads on machine B.

2016-08-29 19:12 GMT+03:00 Pierre-Antoine BRAMERET <pa.brameret@xxxxxxxxx>:
> Hi,
>
>
> I recently discovered netfilter_queue, and have a question about 
> changing the packet size before accepting it. What happens when the 
> accepted packet is now too large and would require splitting?
>
> I have tested the following situation. Computer A filters outgoing UDP 
> packets toward a given port and multiple by 10 their payload before 
> accepting them. An app sends a packet from A to computer B, which is 
> reachable through a LAN. The MTU of the corresponding ethernet devices 
> is 1500. I sent a packet with an initial payload of 200 bytes, which 
> is correctly multiplied by 10 by my filter callback, and gives a 
> single IP packet of more than 2000 bytes. On computer B, I see through 
> tcpdump that a single packet arrives, with an erroneous IP header 
> (total length is 1500, packet is marked as fragmented), but a correct 
> UDP header (length is 2008 bytes). The 2000 bytes of UDP payload are 
> correctly received by the socket on computer B. How would that happen?
>
> I have seen the discussion about what may happen to a packet that is 
> larger (http://marc.info/?l=netfilter&m=133494380818412), is this the 
> case here?
>
>
> Many thanks,
> --
> BRAMERET Pierre-Antoine
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" 
> in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo 
> info at  http://vger.kernel.org/majordomo-info.html



--
Anton.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at  http://vger.kernel.org/majordomo-info.html
��.n��������+%������w��{.n����z��׫�)��jg��������ݢj����G�������j:+v���w�m������w�������h�����٥




[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux