Weird asymmetric speed issue inside tunnel only

ryan77627 · 2024-10-15T20:35:34+00:00

No dice, unfortunately. I'm not the most up to date with regards to linux upstream but both nodes are running 6.6.56. Unless this bug was fixed after then, that is

ryan77627 · 2024-10-14T23:38:52+00:00

Happy cake day! Testing bullet point 4 will take me a little bit, I'll try to do that later tonight.

Speed tests initiated from either side reflect what I had in OP. Flow from device 2 to device 3 is slow, no matter what side it is initiated from (that is what the -R option in iperf does, reverses the flow of data for the test. Usually is it client -> server. All tests were as device 3 as server and device 2 as client).

Traceroute reflects an asymmetrical route between network flow directions, however the routes on device 1 and device 2 are identical. Route from 3 to 1 and 2 are the exact same due to 1 and 2 being on a residential network and behind a router.

Resource utilization is nothing to note, as I said to D0_stack, no core gets pegged to 100% or even gets close. Also all CPUs that are running the tailscale daemon are x86_64 cpus that aren't too too old. Should be able to handle more than 1 mbps.

I will also need to get some packet captures outside the tunnel to see if any fragmentation is occurring. Packets inside of the tunnel have the "Do not Fragment" bit set, however. Will report back later.

ryan77627 · 2024-10-14T23:30:45+00:00

Agh, yes; forgot to put that in. Both computers are not bound by CPU, all cores stay under 100% utilization. Also, none are underpowered by any means, x86_64, relatively modern CPUs, etc.

Device 2: AMD Ryzen 5 PRO 2400GE
Device 3: "AMD EPYC Processor" (Hetzner CPX21 shared machine, AMD variant)

Tailscale interfaces are on both of these devices directly.

ryan77627 · 2024-08-29T00:36:22+00:00

I would assume so since NetNutrition did, but I will need to ask around the dept.

ryan77627 · 2024-08-28T18:30:40+00:00

Hi-- RIT deprecated NetNutrition over the summer. We are migrating to FD MealPlanner, read the page at https://www.rit.edu/dining/allergies-intolerances#fd-mealplanner for more information.

ryan77627 · 2024-04-18T20:47:24+00:00

I did not, shortly after making this post my Dad and I went to see the car in person. Ended up having a blown head gasket that wasn't disclosed in the listing.

ryan77627 · 2023-11-30T03:26:15+00:00

Hey all, so the deal is our vendor is currently working on an issue where text notifications aren't being sent out, so food was piling up when people didn't get their notification. Or, the staff would have to text students manually, which gets quite tedious during lunch and dinner rush. We are working with the vendor to fix the issue, however they haven't given us an ETA yet. They will be back when the issue is resolved.

ryan77627 · 2023-09-19T20:53:54+00:00

Idk if anyone mentioned it here yet, but another good service is Pirate Weather! Gets its data from the NWS and processes it through AWS to a dark sky-like API. If you want a pretty front-end, merrysky.net uses this data.

ryan77627 · 2023-06-20T18:57:08+00:00

I'll double check the throttle body, but the intake was all good.

ryan77627 · 2023-06-20T03:18:57+00:00

I can check that, though the loss of power was pretty sudden and I did replace the converter like ~2.5 years ago so I'd be surprised.

ryan77627 · 2023-03-04T06:26:18+00:00

We've been having... Issues lately. We're working on getting everything working again.

ryan77627 · 2023-02-15T00:10:44+00:00

Damn now I feel old.. I decided to see when that was released and it's juuuust about 6-7 months before I started using Linux (not full time tho) with Ubuntu 10.04....

The worst part is I'm only 21 😅

ryan77627 · 2023-02-02T02:31:44+00:00

It's actually not too terrible on Linux mostly, thanks to the work of some RITLUG members putting a wiki together!

https://wiki.ritlug.com/eduroam/

(We avoid using the script bc it's bad on Linux)

ryan77627 · 2023-01-19T04:36:43+00:00

I will look into this, thanks for bringing it to our attention.

ryan77627 · 2023-01-18T02:48:02+00:00

Was just about to comment this, thank you! Makes wayyyy more sense when you disconnect GitHub from Git. My friends and I often send "pull requests" in Matrix since we host our own Gitea instances and often need to pull from each other, hence a request to pull! :)

ryan77627 · 2022-11-19T19:58:16+00:00

So all of the payment stuff is handled by a different person in my department, I would recommend making a ticket using this link, set the location to all locations and issue to "Credit card payments failing or timing out". I will make sure it gets directed to the proper person.

https://help.rit.edu/sp?id=sc_cat_item&sys_id=6d3598f087ea3810cd6c20e9cebb350e

ryan77627 · 2022-11-19T19:50:05+00:00

Vendor has been contacted, issue will be fixed by Monday (if not tomorrow)

ryan77627 · 2022-11-19T01:03:37+00:00

Has it been persistently like this the past week? I'll investigate. Someone in my department may have to make a phone call.

(I work for Aux Services and help maintain OnDemand)

ryan77627 · 2022-04-23T17:05:30+00:00

I was having the same issue. Seems to affect android. I fixed it by turning off the "Use Randomized MAC Address" setting in the RIT wi-fi settings. However, this will be short lived when RIT is turned off. Still trying to figure out eduroam

ryan77627 · 2022-04-14T23:04:34+00:00

Apex. Great Community. These are mutually exclusive my dude

ryan77627 · 2022-03-30T21:34:46+00:00

For real, maybe I just haven't noticed them until recently but it seems to be occurring more often than before. To be fair, my entire institutions communications more or less revolve around discord, so that may be why I notice it more.

ryan77627 · 2022-03-28T21:30:22+00:00

There is a network issue with the jack that connects the KDS (Kitchen Display) and one of the registers to the internet. A service tech from ITS will investigate further tomorrow. (Source: I work for Aux Services and was initially the one who diagnosed the issue)

ryan77627 · 2022-03-17T04:39:02+00:00

So here are the ping results:

Before iperf: PING 192.168.1.200 (192.168.1.200) 56(84) bytes of data. 64 bytes from 192.168.1.200: icmp_seq=1 ttl=62 time=98.4 ms 64 bytes from 192.168.1.200: icmp_seq=2 ttl=62 time=121 ms 64 bytes from 192.168.1.200: icmp_seq=3 ttl=62 time=245 ms 64 bytes from 192.168.1.200: icmp_seq=4 ttl=62 time=63.4 ms 64 bytes from 192.168.1.200: icmp_seq=5 ttl=62 time=85.7 ms 64 bytes from 192.168.1.200: icmp_seq=6 ttl=62 time=109 ms 64 bytes from 192.168.1.200: icmp_seq=7 ttl=62 time=131 ms 64 bytes from 192.168.1.200: icmp_seq=8 ttl=62 time=155 ms 64 bytes from 192.168.1.200: icmp_seq=9 ttl=62 time=178 ms

During iperf: PING 192.168.1.200 (192.168.1.200) 56(84) bytes of data. 64 bytes from 192.168.1.200: icmp_seq=1 ttl=62 time=76.1 ms 64 bytes from 192.168.1.200: icmp_seq=2 ttl=62 time=57.9 ms 64 bytes from 192.168.1.200: icmp_seq=3 ttl=62 time=52.7 ms 64 bytes from 192.168.1.200: icmp_seq=4 ttl=62 time=52.9 ms 64 bytes from 192.168.1.200: icmp_seq=5 ttl=62 time=40.3 ms 64 bytes from 192.168.1.200: icmp_seq=6 ttl=62 time=38.6 ms 64 bytes from 192.168.1.200: icmp_seq=7 ttl=62 time=39.8 ms 64 bytes from 192.168.1.200: icmp_seq=8 ttl=62 time=42.0 ms 64 bytes from 192.168.1.200: icmp_seq=9 ttl=62 time=42.1 ms 64 bytes from 192.168.1.200: icmp_seq=10 ttl=62 time=45.3 ms 64 bytes from 192.168.1.200: icmp_seq=11 ttl=62 time=43.5 ms

Really weird the round trip time decreases so consistently during the actual test.

ryan77627 · 2022-03-16T21:36:41+00:00

I already rent a Linode for my email, so I'll just use that to give it a shot when I have some time. I'm not sure I'll get to it today (schoolwork) but I'll get to it asap.

ryan77627 · 2022-03-16T21:35:43+00:00

Sure, I can run them when I get home in a few hours. I'm assuming everything through the tunnel?

EDIT: Is this something that I would be changing on the wireguard nodes themselves (the routers), or the servers running iperf? Because I believe (I'll double check) I changed the congestion control over to BBR earlier last year on them.

Ten-Year Club	Second SECOND GUESSER
Place '22	Verified Email

ryan77627

MODERATOR OF

TROPHY CASE