 | 1 | initial version |
In the 3-way-handshake an MSS of 1460 is advertised from the client as well as the server. In the beginning of the capture, the client is segmenting the request data towards the server to 1452 bytes instead of the received MSS of 1460, this means it has somehow learned that is can not send larger segments.
After a while the client starts sending segments of 1460 again, but they get retransmitted. See for instance the session with filter tcp.port == 61968. In that session the request keeps getting retransmitted, but the server comes back with a 408 response code and a TCP ACK value of 1, meaning it never received any data from the client after the 3-way-handshake.
The same happens in the session with filter tcp.port == 62032. But here you can see an IMCP type 3 code 4 packet (Fragmentation needed, but DF bit set). This ICMP error from your router (192.168.1.1) tells the client to use smaller segments, as the next hop has an MTU of 1492 (see the details in the ICMP headers). This corresponds to an MSS of 1452 and matches the packets at the start of the packet capture.
So, TCP segments larger than 1452 bytes can not be forwarded by your router, usually this is because of the addition of PPPoE headers (8 bytes). But as TCP segments of 1460 can be received, it seems the link between your NetGear router and your ISP has an MTU of 1508 or higher.
Please check the correct WAN interface settings for your router with your provider, but my guess is that you are able to configure the MTU size of the WAN interface to 1508 to solve this issue.
Could you try this setting and report back if it solved the issue (or made things worse)?
