LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
Reload this Page Packets larger than MTU of interface
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 04-19-2016, 01:54 AM   #1
psycroptic
Member
 
Registered: Aug 2011
Location: USA
Distribution: ArchLinux - 3.0 kernel
Posts: 349

Rep: Reputation: Disabled
Packets larger than MTU of interface

Quick question; on some Linux computers I have seen, I can do a tcpdump on an ethernet interface and I see packets going out with much larger sizes than the MTU of the configured interface. See below:

Code:
01:53:26.441716 IP 10.172.172.2.48429 > 192.168.251.1.54671: Flags [.], seq 46377:55393, ack 0, win 229, length 9016
01:53:26.441806 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 6441, win 1318, options [nop,nop,sack 2 {10305:11593}{7729:9017}], length 0
01:53:26.441898 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 9017, win 1308, options [nop,nop,sack 1 {10305:11593}], length 0
01:53:26.441982 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 11593, win 1298, length 0
01:53:26.442085 IP 10.172.172.2.48429 > 192.168.251.1.54671: Flags [.], seq 55393:56681, ack 0, win 229, length 1288
01:53:26.447903 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 11593, win 1298, options [nop,nop,sack 1 {12881:14169}], length 0
01:53:26.448013 IP 10.172.172.2.48429 > 192.168.251.1.54671: Flags [.], seq 56681:63121, ack 0, win 229, length 6440
01:53:26.449657 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 11593, win 1298, options [nop,nop,sack 2 {15457:16745}{12881:14169}], length 0
01:53:26.449769 IP 10.172.172.2.48429 > 192.168.251.1.54671: Flags [.], seq 63121:64409, ack 0, win 229, length 1288
01:53:26.449842 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 14169, win 1288, options [nop,nop,sack 1 {15457:16745}], length 0
01:53:26.449932 IP 10.172.172.2.48429 > 192.168.251.1.54671: Flags [.], seq 64409:66985, ack 0, win 229, length 2576
01:53:26.450021 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 16745, win 1277, length 0
01:53:26.450104 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 16745, win 1277, options [nop,nop,sack 1 {18033:19321}], length 0
01:53:26.450202 IP 10.172.172.2.48429 > 192.168.251.1.54671: Flags [.], seq 66985:70849, ack 0, win 229, length 3864
01:53:26.450279 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 16745, win 1277, options [nop,nop,sack 2 {20609:20617}{18033:19321}], length 0
01:53:26.450366 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 19321, win 1267, options [nop,nop,sack 1 {20609:20617}], length 0
01:53:26.450449 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 20617, win 1262, length 0
01:53:26.450527 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 21905, win 1257, options [nop,nop,sack 1 {24481:25769}], length 0
01:53:26.450611 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 23193, win 1252, options [nop,nop,sack 1 {24481:25769}], length 0
01:53:26.450699 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 25769, win 1242, length 0
01:53:26.450790 IP 10.172.172.2.48429 > 192.168.251.1.54671: Flags [.], seq 70849:72137, ack 0, win 229, length 1288
01:53:26.450869 IP 10.172.172.2.48429 > 192.168.251.1.54671: Flags [.], seq 72137:85017, ack 0, win 229, length 12880
01:53:26.450965 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 27057, win 1237, length 0
01:53:26.451044 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 29633, win 1227, length 0
01:53:26.451122 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 32209, win 1217, length 0
01:53:26.479743 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 33497, win 1212, length 0
01:53:26.479852 IP 10.172.172.2.48429 > 192.168.251.1.54671: Flags [.], seq 85017:96609, ack 0, win 229, length 11592
01:53:26.487614 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 36073, win 1202, length 0
01:53:26.489720 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 38649, win 1192, length 0
01:53:26.489829 IP 10.172.172.2.48429 > 192.168.251.1.54671: Flags [.], seq 96609:104337, ack 0, win 229, length 7728
01:53:26.508209 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 41225, win 1182, length 0
01:53:26.508318 IP 10.172.172.2.48429 > 192.168.251.1.54671: Flags [.], seq 104337:108201, ack 0, win 229, length 3864
01:53:26.509224 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 43801, win 1172, length 0
01:53:26.509333 IP 10.172.172.2.48429 > 192.168.251.1.54671: Flags [.], seq 108201:112065, ack 0, win 229, length 3864
01:53:26.509411 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 46377, win 1162, length 0
01:53:26.509514 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 48953, win 1152, length 0
01:53:26.509596 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 51529, win 1142, length 0
01:53:26.509674 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 54105, win 1132, length 0
01:53:26.509750 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 56681, win 1121, length 0
01:53:26.509828 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 59257, win 1111, length 0
01:53:26.515909 IP 192.168.251.1.54671 > 10.172.172.2.48429: Flags [.], ack 61833, win 1101, length 0
In this case, it is an FTP transfer from sending computer 10.172.172.2 to client 192.168.251.1. There are packet sizes up to 12880 bytes! The MTU on this interface is most definitely 1500.

Why would this be? As far as I know, the "jumbo" frame ethernet spec typically only goes up to ~9000 bytes, so why such large packets?
 
Old 04-20-2016, 02:15 AM   #2
linosaurusroot
Member
 
Registered: Oct 2012
Distribution: OpenSuSE,RHEL,Fedora,OpenBSD
Posts: 982
Blog Entries: 2

Rep: Reputation: 244Reputation: 244Reputation: 244
"If the '-e' option is given, the link level header is printed out. On Ethernets, the source and destination \addresses, protocol, and packet length are printed."

Do you find them more reasonable?
 
Old 04-24-2016, 01:26 PM   #3
orgcandman
Member
Contributing Member
 
Registered: May 2002
Location: new hampshire
Distribution: Fedora, RHEL
Posts: 600

Rep: Reputation: 110Reputation: 110
TSO - maybe your nic is actually doing the "on-the-wire" segmentation. Check with ethtool and see if tx segmentation offload is supported.
 
Old 05-02-2016, 03:40 PM   #4
zOSGuy
LQ Newbie
 
Registered: Sep 2010
Location: Central NY, USA
Distribution: Debian
Posts: 27

Rep: Reputation: 0
As far as I know, if the "do not fragment" bit is not set on in the packet TCP will automatically break it into as many fragments as necessary to get it to or below the MTU. The entire outbound packet may be larger than the MTU, but TCP will only transmit a packet that is at or under that value.

... I just looked it up. TCP indeed does this, all under the covers. If the "do-not-fragment" bit is set ON, TCP will return an error code if it gets a packet larger than the MTU of the connection.
Last edited by zOSGuy; 05-02-2016 at 04:36 PM.
 
Old 05-05-2016, 12:19 AM   #5
psycroptic
Member
 
Registered: Aug 2011
Location: USA
Distribution: ArchLinux - 3.0 kernel
Posts: 349

Original Poster
Rep: Reputation: Disabled
OK. The TCP stream above did not have the DF bit set.

so perhaps tcpdump is reporting the segment size, not the packet size?
 
Old 05-05-2016, 03:10 AM   #6
psycroptic
Member
 
Registered: Aug 2011
Location: USA
Distribution: ArchLinux - 3.0 kernel
Posts: 349

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by orgcandman View Post
TSO - maybe your nic is actually doing the "on-the-wire" segmentation. Check with ethtool and see if tx segmentation offload is supported.
Indeed it is, for transmitted TCP:

Code:
user@system:~# ethtool -k eth1
Features for eth1:
rx-checksumming: off [fixed]
tx-checksumming: on
        tx-checksum-ipv4: on
        tx-checksum-ip-generic: off [fixed]
        tx-checksum-ipv6: off [fixed]
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
scatter-gather: on
        tx-scatter-gather: on
        tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
        tx-tcp-segmentation: on
        tx-tcp-ecn-segmentation: off [fixed]
        tx-tcp6-segmentation: off [fixed]
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: off [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-ipip-segmentation: off [fixed]
tx-sit-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
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]
l2-fwd-offload: off [fixed]
busy-poll: off [fixed]
hw-switch-offload: off [fixed]
 
Old 05-05-2016, 07:44 AM   #7
zOSGuy
LQ Newbie
 
Registered: Sep 2010
Location: Central NY, USA
Distribution: Debian
Posts: 27

Rep: Reputation: 0
I believe TCP is reporting the size of the original packet it received for transmission, and anything in the list larger than the MTU was broken up into MTU sized fragments (under the covers).
 
  


Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
a device with small mtu in the path makes tcp socket fail in transmiting larg packets pendrive Linux - Networking 1 12-01-2013 10:00 AM
loopback interface MTU size free2rhyme2k Linux - Networking 6 02-14-2012 07:57 PM
[SOLVED] Assign MTU value for network interface. need help deepclutch Debian 1 05-18-2011 03:52 AM
DHCP server not using 'option interface-mtu'? Moloko Linux - Networking 2 01-09-2010 11:30 AM
Problem of blocking ICMP packets while calculating Path MTU myself_rajat Linux - Networking 3 05-11-2004 12:47 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 02:48 PM.

Contact Us - Advertising Info - Rules - Privacy - LQ Merchandise - Donations - Contributing Member - LQ Sitemap -
Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration