Udp packet with datagram length less than actual length is not discarded in linux kernel version 3.10.61.
Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Udp packet with datagram length less than actual length is not discarded in linux kernel version 3.10.61.
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?
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.
Last edited by sundialsvcs; 03-29-2017 at 08:13 AM.
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.
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.
the udp packet is discarded by the stack but in linux kernel it is accepted.
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.
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]
Last edited by kavitha reddy; 03-29-2017 at 08:48 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.