First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
Ask Your Question
0

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

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?

ChestyP's avatar
1
ChestyP
asked 2018-02-02 13:42:29 +0000
edit flag offensive 0 remove flag close merge delete

Comments

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's avatar ChestyP (2018-02-02 14:57:26 +0000) edit
more
  • delete

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's avatar Jim Aragon (2018-02-02 22:27:24 +0000) edit
more
  • delete
add a comment see more comments

1 Answer

0

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.

sindy's avatar
6.2k
sindy
answered 2018-02-02 20:00:34 +0000, updated 2018-02-03 14:35:12 +0000
edit flag offensive 0 remove flag delete link
more

Comments

add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer