Hi


I was sending the udp packet with datagram length less than actual length(in header length field is set to ((8+data length)-1)) but that packet is not discarded by linux kernel version 3.10.61. what could be the reason for it?

Hi and welcome to LQ.

There can be a variety of reasons. Please share how you have generated this packet exactly. Did you write code to do this or have you generated the packet as an Ethernet or UDP frame and given it to the network stack somehow?

Note that if you wrote code and passed data to the driver, but gave it a longer length than the buffer data you provided, the driver may have assumed the buffer was of sufficient length and just copied data over matching the length anyways, regardless of overflowing the buffer.

As far as I am aware, the kernel does not take it upon itself to decide ... "gee, the program which sent this packet must have a bug in it, so I'm going to just take it upon myself to drop the packet instead of delivering it."

Nope, the kernel's just gonna do what the kernel's gotta do: "the packet will arrive." Buggy or not.

Edit: After being received, other layers of the network software stack might detect a problem and take appropriate action, but the packet will not be initially turned away.

In the end, it's up to the receiving application to check the packet for plausible content, and, if necessary, to spew " WTF?! " into some log-file somewhere, so that "the bug in the other application" can be found and fixed.

HI mistler

i am using one tool to send the packet and it is sending as a ethernet packet.so through the tool i am sending to one linux device which is having my application running on it to receive the packets sent from the tool.i used simple socket programming for receving it. below is the line i used for receive.

recvdLength_lt = recvfrom(lt,(char*)&app_eth_packet.packet_buffer[0],sizeof(app_eth_packet),0,(struct sockaddr*)&from_ptr,&addrLen))

packet_buffer size is 1522 bytes.

i am not corrupting the udp data and corrupting the udp header length field. so i was expecting it should fail at checksum calculation or it should check the udp length field with actual data length received at socket.so that it will discard the packet.

The intension is to do the compliance testing on one proprietary stack. the udp packet is discarded by the stack but in linux kernel it is accepted.

i also tested two more scenarios on linux stack

1)sending the udp packet with greater than actual length
i am setting the udp header length field to ((8+datalength(16))+1)

2)sending udp packet with invalid checksum in checksum field of udp header

that packets got discarded by the kernel.i attached the wireshark capture for both scenarios and also the reported issue.

Attached Thumbnails

     

If it was carried by a valid Ethernet header, the driver would allow the frame to be accepted into the network stack and then it would allow the UDP stack to evaluate whether or not to accept the packet. You say it was discarded by the stack. Note that this was deemed to be a valid Ethernet frame, a valid IP datagram, and the UDP encapsulation was finally detected in error. This is why the OSI layers exist, I believe it was the Transport layer which finally detected this error, however it also was a problem introduced solely within the Transport layer. The Network and Data Link layers, or any other lower layers, are not supposed to catch this type of problem.

1 members found this post helpful.

Hi mistler


if i am not wrong the udp packet discarded with in Transport layer,but in case of stack i was not able to receive the data to my application.

In the linux kernel case i was able to receive the data to my application.


is it depends on what are the checksum offloading flags enabled ?

below is the output of the ethtool

rx-checksumming: on [fixed]
tx-checksumming: on
tx-checksum-ipv4: on
tx-checksum-ip-generic: off
tx-checksum-ipv6: on
tx-checksum-fcoe-crc: off
tx-checksum-sctp: off
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: off
tx-tcp6-segmentation: on
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: off [fixed]
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: on
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: on [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off
tx-gre-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
fcoe-mtu: off
tx-nocache-copy: off [requested on]
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]

"Anything goes" for a mal-formed packet . . .