Ask Your Question
0

Help finding "ERR_CONNECTION_RESET" cause

asked 2024-07-24 23:03:15 +0000

AVCGABoyd gravatar image

updated 2024-07-25 01:34:15 +0000

Hello, my volunteer Coast Guard unit is having an issues with our access to some websites. We use chrome to access Met information and routinely we encounter "ERR_CONNECTION_RESET" which causes us to have to restart the PC to regain access. I have a wireshark capture that was taken during one of these events and I'd really like some assistance in analysis if at all possible.

The IP of the problem PC in the capture is 192.168.1.184 and the web sites involved are https://reg.bom.gov.au/qld/forecasts/... and http://www.bom.gov.au/qld/forecasts/s...

The issue arose towards the end of the capture and ANY help would be greatly appreciated.

Hopfully this link to the capture works https://drive.google.com/file/d/1Yw-_...

edit retag flag offensive close merge delete

Comments

in the capture


If you would like to share a capture file, place it on a public file share then update the question with a link to it.

Chuckc gravatar imageChuckc ( 2024-07-25 01:07:37 +0000 )edit

Can you make the link public (open access) ?

Chuckc gravatar imageChuckc ( 2024-07-25 01:26:05 +0000 )edit

A very big thank you for your help.

AVCGABoyd gravatar imageAVCGABoyd ( 2024-08-02 01:58:10 +0000 )edit
add a comment

1 Answer

Sort by » oldest newest most voted
1

answered 2024-07-25 05:45:11 +0000

SYN-bit gravatar image

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)?

edit flag offensive delete link more

Comments

Thank you for the info - greatly appreciated.

I have looked at the Orbi and attempted to set the MTU to 1508 but it advises the range allowable is 616 to 1500 so I have set it to 1500. I'll monitor the situation and advise what happens.

I sorry if I missed advising that the connection is Orbi to VR2800 ( Bridged mode) to Telstra DSL.

AVCGABoyd gravatar imageAVCGABoyd ( 2024-07-25 21:42:26 +0000 )edit

If you say you have set it to 1500, which value was configured before you set it to 1500?

So if I understand you correctly, the ADSL line (with PPPoA) is bridged to Ethernet (with PPPoE) on the VR2800 and the Orbi is configured with the PPPoE username and password. And the IP address of the Orbi is 192.168.1.1?

SYN-bit gravatar imageSYN-bit ( 2024-07-26 08:38:05 +0000 )edit

Sorry for the delay in responding (overwhelming homefront!) The change to MTU 1500 has made a significant difference and that most if not all the errors have not reoccurred. I fount reference to MTU 1500 in some Telstra docs noted at the end of this comment AND it is a setting in the Telstra 7610 Gateway device that I missed/glossed over.

I admit to not noting exactly the value before the change to 1500 : it was 14nn.

Your statement/question about the ADSL line and PPPoA and ethernet with PPPoE has made me go back and look at the settings of all the devices.

VR2800 (nominally set to 192.168.1.2) and operating in Bridge Mode: Connected to NBN via DSL port Connected to Orbi WAN port via Lan4/WAN port DSL Settings DSL Modulation type: Auto Sync-up Annex type: Annex A/L Bit Swap: enable (but greyed ...(more)

AVCGABoyd gravatar imageAVCGABoyd ( 2024-08-01 09:42:00 +0000 )edit

part 2 comment

xDSL Settings Transfer Mode: PTM

The docs I can find on the Telstra settings advise: Settings for all connection types

These settings are required regardless of the type of nbn connection you have: Internet Connection Type/Protocol: IPoE/DHCP/Automatic VLAN ID/Tagging: Blank/No/0 IP Configuration: Dynamic/obtain IP address automatically No Username or password

Settings for FTTN/B These settings are required for fibre to the node and fibre to the basement connections. Seamless Rate Adaption (SRA): Enabled VDSL2 Profile: 17a G.Vector: Enabled Non-standard G.Vector: disabled G.INP: Enabled

If you’re using your own router: • Your router must support WAN on an Ethernet port. If not, you could consider purchasing a business router from Telstra • Use Ethernet full duplex with auto-negotiation on. This ensures it signals to UNI-D that it’s full duplex capable, to avoid duplex mismatch • Be operating as ...(more)

AVCGABoyd gravatar imageAVCGABoyd ( 2024-08-01 09:42:52 +0000 )edit

Glad to hear the problems are gone. Looking at the old config and Telstra docs, there is no PPPoE involved, so the MTU of 1492 which was visible in the ICMP packets (so I assume this was the value that was configured for MTU size on the WAN interface of the Orbi) was probably a leftover from a time where there still was a PPPoE connection and now it got in the way.

All is well, that ends well :-)

SYN-bit gravatar imageSYN-bit ( 2024-08-01 17:42:28 +0000 )edit
add a comment

Your Answer

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

Add Answer

Question Tools

subscribe to rss feed

Stats

Asked: 2024-07-24 23:03:15 +0000

Seen: 222 times

Last updated: Jul 25