Upload speed is 0 after switching to pfsense, only on linux
-
G'day,
Since installing pfsense on my router, on my desktop pc the upload speed has dropped to essentially zero, only on linux.
The cables are not bad.
It's the same on wifi.
On the same machine on Windows there is no problem.
On all other devices on the network, both wired and wireless, on mac and raspberry pis, there is no problem.
I'm using KDE Neon 5.27.6
I tried a fresh install of Kubuntu, same problemHere's a speedtest-cli result:
Retrieving speedtest.net configuration... Testing from Aussie Broadband (XXX.XXX.XX.XXX)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by TasmaNet Pty Ltd (Melbourne) [0.42 km]: 9.43 ms Testing download speed................................................................................ Download: 26.56 Mbit/s Testing upload speed...................................................................................................... Upload: 0.37 Mbit/sI've googled and found nothing useful. I am sad.
-
You could try providing some useful info. For example, are you getting an IP address? Have you tried some packet captures to see what's happening, etc..
BTW, I'm running Linux here and it's been working fine with pfSense for over 7 years.
-
How are you testing in Windows? Browser based speedtest? Does Linux give the same results if you test the same way?
Check the link settings in Linux and Windows. For example are they both showing the same MTU?
Is the test client connected directly to pfSense? Via a switch? WIFI also goes via the same switch?
Steve
-
@lindseywhittaker just tested from one of my linux vms, running Ubuntu 22.04.2 and not seeing any issues.
Testing download speed................................................................................ Download: 532.43 Mbit/s Testing upload speed...................................................................................................... Upload: 52.45 Mbit/s root@NewUC:/home/user#My connection is 500/50
I really don't see what pfsense would be doing different for some linux client vs any other client - not like pfsense even knows that a client is..
-
Thanks @stephenw10
On linux i've tested via browser and via cli. Browser shows a flat 0.00, cli is 0.37-0.42 every time. On windows it's 27/7 via browseer, on a macbook air via cli it's around 7.8mbps. That is using the same cable as the pc, and also on wifi. I just checked on my phone on speedtest.net in the browser and it's 0.00 there, too.
The PC is wired via a switch. The WiFi is via the same switch. Both linux and windows are set to automatically detect the MTU. Pfsense is set to 1500.
Mac test results:
jake@MacBook-Air-2 ~ % speedtest-cli Retrieving speedtest.net configuration... Testing from Aussie Broadband (XXX.XXX.XX.XXX)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by YLess4U (Fyshwick) [466.41 km]: 35.546 ms Testing download speed................................................................................ Download: 23.84 Mbit/s Testing upload speed...................................................................................................... Upload: 7.79 Mbit/s@JKnott Yes I'm getting an IP address. I'm posting this from the linux pc, and am able to download large files. Uploading, to drive for example, is not functioning. I'm not sure I've done this right (or I'm sure I've not done this right), but here's some tcpdump:
07:47:29.075995 IP (tos 0x0, ttl 56, id 10594, offset 0, flags [DF], proto TCP (6), length 1500) 169-150-207-217.bunnyinfra.net.https > lw-1.43624: Flags [.], cksum 0x8351 (correct), seq 26908184:26909632, ack 421, win 133, options [nop,nop,TS val 341822148 ecr 619037342], length 1448 07:47:29.075997 IP (tos 0x0, ttl 64, id 26910, offset 0, flags [DF], proto TCP (6), length 52) lw-1.43624 > 169-150-207-217.bunnyinfra.net.https: Flags [.], cksum 0x9f1e (incorrect -> 0x1511), ack 26909632, win 24563, options [nop,nop,TS val 619037445 ecr 341822148], length 0 07:47:29.076186 IP (tos 0x0, ttl 56, id 10595, offset 0, flags [DF], proto TCP (6), length 1500) 169-150-207-217.bunnyinfra.net.https > lw-1.43624: Flags [P.], cksum 0xca15 (correct), seq 26909632:26911080, ack 421, win 133, options [nop,nop,TS val 341822148 ecr 619037342], length 1448 07:47:29.076710 IP (tos 0x0, ttl 56, id 10596, offset 0, flags [DF], proto TCP (6), length 1500) 169-150-207-217.bunnyinfra.net.https > lw-1.43624: Flags [.], cksum 0x1682 (correct), seq 26911080:26912528, ack 421, win 133, options [nop,nop,TS val 341822149 ecr 619037343], length 1448 07:47:29.076713 IP (tos 0x0, ttl 64, id 26911, offset 0, flags [DF], proto TCP (6), length 52) lw-1.43624 > 169-150-207-217.bunnyinfra.net.https: Flags [.], cksum 0x9f1e (incorrect -> 0x09c0), ack 26912528, win 24563, options [nop,nop,TS val 619037446 ecr 341822148], length 0 07:47:29.076911 IP (tos 0x0, ttl 56, id 10597, offset 0, flags [DF], proto TCP (6), length 1500) 169-150-207-217.bunnyinfra.net.https > lw-1.43624: Flags [P.], cksum 0xf38a (correct), seq 26912528:26913976, ack 421, win 133, options [nop,nop,TS val 341822149 ecr 619037343], length 1448 07:47:29.077497 IP (tos 0x0, ttl 56, id 10598, offset 0, flags [DF], proto TCP (6), length 1500) 169-150-207-217.bunnyinfra.net.https > lw-1.43624: Flags [.], cksum 0xb6ad (correct), seq 26913976:26915424, ack 421, win 133, options [nop,nop,TS val 341822150 ecr 619037344], length 1448 07:47:29.077501 IP (tos 0x0, ttl 64, id 26912, offset 0, flags [DF], proto TCP (6), length 52) lw-1.43624 > 169-150-207-217.bunnyinfra.net.https: Flags [.], cksum 0x9f1e (incorrect -> 0xfe6e), ack 26915424, win 24563, options [nop,nop,TS val 619037446 ecr 341822149], length 0 07:47:29.078194 IP (tos 0x0, ttl 56, id 10599, offset 0, flags [DF], proto TCP (6), length 1500) 169-150-207-217.bunnyinfra.net.https > lw-1.43624: Flags [P.], cksum 0xc991 (correct), seq 26915424:26916872, ack 421, win 133, options [nop,nop,TS val 341822150 ecr 619037344], length 1448 07:47:29.078385 IP (tos 0x0, ttl 56, id 10600, offset 0, flags [DF], proto TCP (6), length 1500) 169-150-207-217.bunnyinfra.net.https > lw-1.43624: Flags [.], cksum 0x8c24 (correct), seq 26916872:26918320, ack 421, win 133, options [nop,nop,TS val 341822151 ecr 619037344], length 1448 07:47:29.078387 IP (tos 0x0, ttl 64, id 26913, offset 0, flags [DF], proto TCP (6), length 52) lw-1.43624 > 169-150-207-217.bunnyinfra.net.https: Flags [.], cksum 0x9f1e (incorrect -> 0xf31c), ack 26918320, win 24563, options [nop,nop,TS val 619037447 ecr 341822150], length 0 07:47:29.078991 IP (tos 0x0, ttl 56, id 10601, offset 0, flags [DF], proto TCP (6), length 1500) 169-150-207-217.bunnyinfra.net.https > lw-1.43624: Flags [P.], cksum 0xa84a (correct), seq 26918320:26919768, ack 421, win 133, options [nop,nop,TS val 341822151 ecr 619037344], length 1448 07:47:29.079180 IP (tos 0x0, ttl 56, id 10602, offset 0, flags [DF], proto TCP (6), length 1500) 169-150-207-217.bunnyinfra.net.https > lw-1.43624: Flags [.], cksum 0x095b (correct), seq 26919768:26921216, ack 421, win 133, options [nop,nop,TS val 341822152 ecr 619037345], length 1448 07:47:29.079182 IP (tos 0x0, ttl 64, id 26914, offset 0, flags [DF], proto TCP (6), length 52) lw-1.43624 > 169-150-207-217.bunnyinfra.net.https: Flags [.], cksum 0x9f1e (incorrect -> 0xe7ca), ack 26921216, win 24563, options [nop,nop,TS val 619037448 ecr 341822151], length 0 -
@lindseywhittaker the pcap downloaded and say loaded into wireshark is going to be much easier to read..
But see some thing in there that have me wonder. For starters why are you seeing invalid checksums? Also a win of 133 is a really small window size.. and yeah going to be really shitty upload if that is the case..
here just did a upload see the win size..
What would be good test.. Is sniff on pfsense for just your clients IP and do the upload test only..
speedtest-cli --no-download
set your capture to zero so it catches everything vs being limited to specific number of packets.. Then upload that pcap and we can see what is going on.. For the multiple uploads that would be happening..
-
Your speedtests are against different servers. One is much closer than the other. Or is detected as such at least.
