This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

1500 bytes over wan link of 1492 MTU. Is that possible?

0

Hi i have ppoe which allows 1492 bytes to pass through. This makes the mss go to 1452. I examined the packet and the IP header is 20 bytes the TCP header is 32 bytes and the data is 1448 which makes it in total 1500 bytes. Ive noticed that the tcp header is 32 beacause of a additonal 12 byte option value. Can someone just explain how all that can pass through a PPOE link of 1492 MTU? Thanks

asked 20 Aug '12, 06:45

TechKid's gravatar image

TechKid
1113
accept rate: 0%


3 Answers:

1

The packets in your Cloudshark trace aren't going over a PPPoE interface, they are going straight over Ethernet. There are no PPPoE headers in the packet, just the Ethernet, IPv4, and TCP headers. From the MAC addresses in the packets, I assume the first frame in that capture is going between a Dell PC and a Fortinet firewall. If the firewall is on your local network, then there's no PPPoE involved, and therefore no 1492-byte MTU involved.

answered 20 Aug '12, 13:56

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

It has to Transit a PPPOE modem in order to reach the internet. It first goes to the firewall which then goes to the modem.Doesnt it use the smallest MTU between the two devices? I dont expect a 1500 byte to come in from the internet through my modem which is 1492 and reach my desktop? BTW Thanks

(20 Aug '12, 13:58) TechKid

OK guys i think i figured it out. Im assuming that the firewall is acting as a proxy between and that is the reason why Im seeing these large packets from a internet facing connection. Please let me know if this is possible

(20 Aug '12, 14:52) TechKid

Which two devices? The smallest MTU between the PC and the firewall is 1500 bytes, as they're on the same Ethernet segment. If the firewall is directly sending Ethernet packets to the mode, the smallest MTU between them is also 1500 bytes. If PPPoE is involved, it's probably being hidden from you inside the ADSL modem.

If you're using DSL, and it's using PPPoE - rather, than, say, PPPoA, my guess is that the "E" in PPPoE is bridged Ethernet over ATM...

(20 Aug '12, 14:58) Guy Harris ♦♦
1

...and if the hardware on the other end of the DSL connection is terminating the PPPoE session on that end, there might not be any real Ethernet involved, so that the "Ethernet" could be given an MTU bigger than 1500. Who makes your DSL modem? Perhaps they document a feature such as that.

(20 Aug '12, 15:00) Guy Harris ♦♦

THanks you are right

(20 Aug '12, 15:30) TechKid

0

Ususally this would require fragmentation by the router, but TCP should have the "Don't Fragment" bit set. In that case you should see an ICMP message saying "Fragmentation needed but don't fragment bit set" coming back to your system, after which it should resend the data in smaller segments. The stack will remember the MTU of 1492 for a while and then try again sending with MTU 1500, doing the same procedure over and over again.

answered 20 Aug '12, 06:57

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

"1497","6.121084","xxx.xxx.xxx.xxx","192.168.0.xxx","TCP","1514","[TCP segment of a reassembled PDU]"

there it is. In total the frame is 1514 including the ethernet headers. Im puzzled as to how 1500 bytes is received when the mtu on the dsl interface is 1492.

It has something to do with the TCP option timestamp value. The tcp options adds 12 bytes to the 20 byte TCP header making it 32 bytes total.

(20 Aug '12, 07:57) TechKid

0

Im puzzled as to how 1500 bytes is received when the mtu on the dsl interface is 1492.

So, you are receiving larger packtes than the MTU size (Max Transmission Unit) of your DSL interface? Well, that's possible, as long as you (presumably) don't know the MTU size on the other side of the DSL connection (your ISP) as well.

If you try to send packets larger 1492 bytes through your DSL interface, your packets should be fragemented (unless the don't fragment flag is set).

See also here:

http://ask.wireshark.org/questions/11232/does-mtu-size-on-capture-nic-limit-the-size-of-packets-you-can-capture

Regards
Kurt

answered 20 Aug '12, 09:03

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

Thanks. I noticed that both sides negotiated a mss of 1460

(20 Aug '12, 09:06) TechKid

The following message suggests, that wireshark re-assembled fragmented frames.

[TCP segment of a reassembled PDU

Please disable IPv4 de-fragmentation and check the packet size again.

Edit -> Preferences -> IPv4 -> Reassemble fragmented IPv4 datagrams

If that does not solve your problem, can you please post the 3-way handshake and some large frames on cloudshark.org?

HINT: As you cannot delete an anonymously uploaded file on cloudshark.org, you better don't post any private data. Post just those packets in a capture file, that are required to analyze the problem.

(20 Aug '12, 09:09) Kurt Knochner ♦

I think its something to do with tcp timestamp

(20 Aug '12, 10:02) TechKid
(20 Aug '12, 10:22) TechKid