Ask Your Question

How to verify "ICMP Packet Too Big Messages " aren't being returned

asked 2018-02-02 13:42:29 +0000

ChestyP gravatar image

I had a scanner installed and we use these to scan to email using obviously via SMTP. It would not scan an actual scanned document but the the device has an SMTP test that would send a small emails and so it would complete the communication. I was told by the tech that the reason was that the MTU size was an issue. I was also told that the carrier "Wireless 4G LTE" was the root cause of the issue and when using "tunnel path-mtu-discovery" I'm told that " , the carrier isn’t sending the ICMP Packet Too Big Messages back to our router" I have a packet capture during this scanning process, my question is how can I tell that this is the case?

edit retag flag offensive close merge delete


Maybe this is a better way to ask.. in my capture I have colored rules that is showing up in this capture above "(tcp.flags.syn==1) && !(tcp.options.wscale.shift)" So the syn bit is set to 1 .. how does this mean that Windows scaling is not supported? When I took the WS course this was given to me but I don't remember the details

ChestyP gravatar imageChestyP ( 2018-02-02 14:57:26 +0000 )edit

Well, since you got that coloring rule from me:

The coloring rule triggers if either of the TCP peers fails to announce support for Window Scaling in the handshake packets. To use Window Scaling, both systems must support it, so each system must put its Window Scaling shift factor in its first packet, which will be the SYN and the SYN/ACK packets.

The first part: "tcp.flags.syn==1" means that the SYN bit is set, so it is either a SYN or SYN/ACK packet.

The second part "!(tcp.options.wscale.shift)" means that the field that would have the shift factor is not present.

So this is a SYN or SYN/ACK packet and the Window Scaling option is not present.

But as Sindy said in his answer, this wouldn't have anything to do with your situation.

Jim Aragon gravatar imageJim Aragon ( 2018-02-02 22:27:24 +0000 )edit

1 Answer

Sort by » oldest newest most voted

answered 2018-02-02 20:00:34 +0000

sindy gravatar image

updated 2018-02-03 14:35:12 +0000

The window scale factor and the TCP window as a whole have nothing to do with MTU discovery. TCP reception window has to do with memory buffer at the recipient side while MTU has to do with frame size on various network segments on the path between the two endpoints (client and server). E.g., some encapsulations (PPPoE, VPNs) occupy part of the Ethernet frame so a smaller part of it remains available for the payload.

There is no way to see that something (like e.g. the icmp "packet too big" message) is missing in the capture. But you may find that out by symptoms, i.e. that smaller packets do get through (means get acknowledged in case of TCP) while larger don't. If you have some possibility to manipulate the MTU or MSS on sending side, you can reduce it there and if that helps, you can be almost certain that the icmp "packet too large" doesn't pass through somewhere on the network path between your equipment and the remote server. If you have issues with any server, your ISP is most likely the guilty one.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2018-02-02 13:42:29 +0000

Seen: 1,641 times

Last updated: Feb 03 '18