Geekzone: technology news, blogs, forums
Guest
Welcome Guest.
You haven't logged in yet. If you don't have an account you can register now.


terrbear

15 posts

Geek
+1 received by user: 5


#307129 22-Sep-2023 14:54
Send private message

I’ve been trying to get a Chorus tech out here, but haven’t yet had luck because the sporadic packet loss I see isn’t easily reproduced without patience on RSP’s end.

 

The gist is, at various points during the day, I’ll see some packet loss. I ran speedtest from the cli 100 times, and of those, 10 times showed packet loss between 0.5-2%.

 

I’ve been trying to figure this out for a few months now. I thought at first it was my modem. I was on 2degrees and using their FritzBox. I changed to another modem/router (Asus GT-AX11000), same issue. 

 

So I’d thought maybe it was some unluckily routed MTU blackhole. Turned MTUs down everywhere to 1280, no dice.

 

I gave up on 2degrees because their hold times were really long, and had the hope that maybe having a different route out of NZ would be helpful. Switched to OneNZ. Same issue.

 

I can hook a laptop directly to the ONT and run mtr to the gateway, and still see 50% packet loss. I realize that some ICMP will get dropped, but it’s so consistent and I think a corresponding symptom to the other packet drops I see during the day.

 

I have a static IP, and if I run a mtr from outside to my IP, I see 0% packet loss until the last hop, which is my house :)

 

So, I’ve tried 2 ISPs and 3 modems (FritzBox, Asus, Macbook), and no luck. I told One I’d be happy to pay the no-fault fee for Chorus, so they scheduled a tech, but warned that because they didn’t see any problems Chorus would likely not show up. It seems that is true; nobody’s shown up.

 

At the ONT, I see the sleeve for the fibre cable is damaged (I can see all the inside cables). I’m told that’s not a problem because traffic is passing.

 

What would be the best way to get a Chorus tech out here? It’s entirely possible I’m being dumb. I’m happy to throw money at this problem, but I really need reliable TCP connections.

 

I made a mistake early on and told the support team that if I run traffic through Wireguard, the problem is mitigated. I think that’s because WG UDP retransmits a lot more aggressively than a normal TCP connection. But I’m not running my traffic through Wireguard normally.

 

Oh, the traffic in question is mostly SSH/HTTPS. Like, doing git things with Github and doing API calls to AWS. The rest of the family notices this problem when pages don’t load or buttons don’t seem to click the first time and they resubmit. 

 

Thanks in advance, smarter people here :)


View this topic in a long page with up to 500 replies per page Create new topic

This is a filtered page: currently showing replies marked as answers. Click here to see full discussion.

Cxf

Cxf
72 posts

Master Geek
+1 received by user: 52

2degrees

  #3144216 8-Oct-2023 09:32
Send private message

Chorus Assurance restarted the POLT that homed both of these ONT.

Glad to hear it's all fixed, their equipment was dropping specific sizes frames in multiples of 16.

Cisco cli let's you run a sweeping ping with incrementing size


RT1#ping
Protocol [ip]:
Target IP address: 121.x.x..x
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: gigabitethernet0/1.4
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]: y
Sweep min size [36]:
Sweep max size [18024]: 1501
Sweep interval [1]:

Type escape sequence to abort. Sending 1466, [36..1501]-byte ICMP Echos to 121.x.x.x, timeout is 2 seconds: Packet sent with a source address of 131.203.y.y
Packet sent with the DF bit set !!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!! !!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!.!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!! !!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.! !!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!.!!!!!!! !!!!!!!!.!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!. Success rate is 98 percent (1446/1466), round-trip min/avg/max = 8/12/40 ms

Starting from 36 and ending at 1501 (which should fail)
If you can count from 36 we can see all the sizes that failed. Which was cleared up after the POLT restart.

View this topic in a long page with up to 500 replies per page Create new topic








Geekzone Live »

Try automatic live updates from Geekzone directly in your browser, without refreshing the page, with Geekzone Live now.



Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly to your computer or smartphone by using a feed reader.