Slow upload on Android devices (edit: all devices)
All the Android devices in the house are having problems with the upload speed when I'm using pfsense.
I'm using N66U with Tomato (also tried stock with the same problem) as an access point. DHCP is disabled.
My internet connection is 50/50 mbit. I get those speeds on laptops, iPads, desktops but not the Android devices connected. They get around 30/0,01 mbit when using Speedtest.
Nexus 7 2012
Samsung Galaxy S3 (x2)
Samsung Galaxy S2 (x2)
Does anybody have any idea what the problem can be?
Are you using the Speedtest.net app or website? Perhaps the app doesn't use the same test servers. Perhaps client that the website uploads doesn't run well on Android.
Have you experienced this not happening without pfSense?
Same version of Android on each?
Are you using any traffic shaping?
Looks like the problem isn't just on Android devices. Today I used my laptop on some other Wi-Fi networks and when I am home now the internet is terrible on it too but I am getting 50 down, 25 up and 5 ms ping but when I am loading any websiste it takes around 10 seconds.
I am not doing any traffic shaping.
I am not having slow speeds when accessing websites and files on local network.
Not sure quite what you meant there.
So there are problems with all wifi connected devices? But not all the same symptoms?
There are no problems with ethernet connected devices?
I'm not really sure what the symptoms are. But for example Facebook Messenger is working perfectly, but web browsing and loading Facebook is extremely slow.
Problem is only on wifi.
Edit: I forgot to mention that everything is running in Esxi if that helps. Realised it was a little bit stupid to not mention that…
Hmm, so something in the path of the wifi traffic. The access point, cabling, switch, physical NIC in the ESXi host, the virtual NIC setup in esxi.
Has this just started?
It might be that I got the problem after restarting the pfsense VM a week ago but all the devices didn't get the problem at the same time. The devices that always are at home are not having problems at all but after they are being used on other Wi-Fi networks it becomes terrible when they are on the home network.
Thank you for your time :)
Hmm, OK. So no change in the Network hardware.
Do you use, say, a VPN to protect wifi access in public places that has become the default route for those devices?
Are all the devices using the same DNS servers?
More 'out there' suggestion: some of your devices have malware redirecting all their traffic via some other location?
I'm going to subscribe to this thread. All our Android devices and a Windows phone are very slow through our network.
pfSense 2.1 amd64
Squid 3.3.10 in transparent mode
wpad (but most (all?) devices point straight to squid anyway)
Firewall rule logs show nothing blocked and all http traffic going straight to squid with no problem. But my Android very very frequently shows "no connection - retry". Refresh a connection a few times and eventually it works.
This is a common Android complaint so I wasn't sure if it was pfSense or Android's fault but a Windows phone apparently suffers similar symptoms. "The internet is slow" is the complaint I hear.
I occasionally look for a problem in pfSense but there is nothing in squid or system logs to indicate anything is wrong. Speedtest.net indicates good upload and download speeds. It's just random connections that timeout or are very slow.
No hardware changes for me but I've changed the firewall config a bunch of times in learning pfSense so I couldn't isolate what's causing it, and I don't remember if it was ever significantly better or worse.
I should add, the sole computer attached via ethernet has no such connectivity problems.
connected to pfSense through a VLAN interface on a Cisco SG-200
I just ran speedtest on the computer and it gave me ~15Mbps down / 0.79Mbps up, which is comparable to what the Android devices give (~12-13Mbps down / ~2.5Mbps up), both with ~1-200ms ping time. Not sure why the slow upload speed on the PC. Android can give me these speedtest results while before/after still experiencing connectivity in gmail and chrome. Frustrating.
Well start off by investigating your wifi setup. Though since you're seeing the full bandwidth it's probably OK. Check your DNS settings, if your android devices are using some external, and slow, dns server that could explain it.
I use DHCP on my devices, with DNS forwarding enabled in pfsense. My DNS servers in the pfsense general setup page are my isp's two DNS servers and then 220.127.116.11 and 18.104.22.168.
I do not have " Do not use the DNS Forwarder as a DNS server for the firewall" checked on the general page. I'm not sure if I should or not.
I don't have an entry in my wifi interface's DHCP server page under "DNS servers".
Nothing filled in under "Dynamic DNS" either.
You have a separate wifi access point that is running dhcp?
One thing that might be relevant here is that the Chrome browser is notorious for hanging onto its cache. It could be that you have gone to some other wifi network and chrome/android had cached something that isn't valid on your home network, page data, routing info, DNS etc.
My pfsense box has an Atheros AR9280 (AR5BXB92) card and a 20cm external antenna for an internal wifi interface. The dhcp is pfsense's built in server.
This device is a new Nexus 10 that's only been used on my pfsense network. I used to use a Nexus 7 that had been on a bunch of networks and clearing all cache data worked for about 5 minutes at a time.
And the problem manifests itself on other devices. Windows phone and some Apple things too.
I'll try clearing the android caches again though.
Since you're using a card in ap mode the first check the system log and wireless log.
When it happens, the only significant thing in the firewall logs is significant numbers of TCP:PA entries.
The wireless logs look like this:
although to be honest I never look at them and haven't while connections are timing out. I will next time.
The system logs don't indicate anything unusual.
Are those all the same wireless device? All those entries within the same second?
At the very least you may want to increase the re-keying interval. I have Key Rotation at 3600 and Master Key Regeneration at 7200, though I originally set that because earlier pfSense versions did not separate the wireless logs and it was spamming the system log. It didn't actually affect wifi performance at all.
In my logs I see, for example, this when a device first comes out of standby and connects:
Mar 16 15:21:41 hostapd: ath0_wlan0: STA 10:bf:48:**:**:** WPA: pairwise key handshake completed (RSN) Mar 16 15:21:41 hostapd: ath0_wlan0: STA 10:bf:48:**:**:** RADIUS: starting accounting session 52BEED1F-0000035D Mar 16 15:21:41 hostapd: ath0_wlan0: STA 10:bf:48:**:**:** IEEE 802.1X: authorizing port Mar 16 15:21:41 hostapd: ath0_wlan0: STA 10:bf:48:**:**:** WPA: received EAPOL-Key frame (4/4 Pairwise) Mar 16 15:21:41 hostapd: ath0_wlan0: STA 10:bf:48:**:**:** WPA: sending 3/4 msg of 4-Way Handshake Mar 16 15:21:41 hostapd: ath0_wlan0: STA 10:bf:48:**:**:** WPA: received EAPOL-Key frame (2/4 Pairwise) Mar 16 15:21:41 hostapd: ath0_wlan0: STA 10:bf:48:**:**:** WPA: sending 1/4 msg of 4-Way Handshake Mar 16 15:21:41 hostapd: ath0_wlan0: STA 10:bf:48:**:**:** IEEE 802.1X: unauthorizing port Mar 16 15:21:41 hostapd: ath0_wlan0: STA 10:bf:48:**:**:** WPA: start authentication Mar 16 15:21:41 hostapd: ath0_wlan0: STA 10:bf:48:**:**:** WPA: event 1 notification Mar 16 15:21:41 hostapd: ath0_wlan0: STA 10:bf:48:**:**:** IEEE 802.11: associated
Then nothing until it times out sometime later, usually having gone back into standby. The only other thing that appears is the WPA rekeying at 3600s (1h) intervals.
Your logs show a lot of handshake failing.
That would have been several devices.
I changed the Key Rotation and Master Key Regeneration this morning. I got similar handshake messages to you, once per device, after I looked after changing the key values.
But still it's slow. Like dialup slow or slower for the initial connection. And e.g. it's even slow to connect to pfSense GUI, to the point of timing out frequently. Just viewing system log pages and firewall aliases, not doing any config changes etc. My pfSense is via https, but not on port 443.
Sometimes it's better, like last night it behaved like a "normal" broadband connection should. And then this morning, timing out and slow connections but reasonable, not great download speeds once a connection is made.
I had to leave but will continue to investigate when it goes bad.
You have good signal strength? Multiple antennas? Did you set the antenna connector numbers correctly?
Single TP-Link ANT2408C antenna. It's a big one. Good signal strength, devices mostly used in the same room as the antenna. I will check the connector numbers but like I say, signal strength is good and the problem persists.
Ah, well definitely check the antenna selection then. I belive the default setting is to use one connector for Tx and the other for Rx. If you have only the Tx antenna connected you may well see great signal strength at the wireless device end but almost nothing being received back. Not sure how that would affect usage. It usually ramps down the connection speed until it sees consistent traffic but if it's seing a huge signal coming in perhaps it keeps trying to move back to a faster rate.
I only have one antenna and setting the Tx and Rx to use the correct connector (and diversity disabled) gave a huge improvement.
Maybe that's it- I thought it was a choice of 1 antenna connected to either jack or 2 if you wanted a 1x1 vs. 2x2 and the Atheros card would auto-config.
So I should connect a second cable and antenna? Easily doable for about $30. I avoided a second cable because it would mean drilling holes in my case, which is short on space anyway. No big deal though.
The antenna is giving me about 46-53dBm on channel 1 (both tx and rx) and 60dBm on channel 2 according to a wifi analyser app.
Diversity is gone from 2.1? I couldn't find it.
I have an older Atheros wifi card but it's there in the settings for 2.1 on my home box.
![wifi settings.jpg](/public/imported_attachments/1/wifi settings.jpg)
![wifi settings.jpg_thumb](/public/imported_attachments/1/wifi settings.jpg_thumb)
Hmm, it's not there in my GUI. 2.1-RELEASE amd64 build.
Hmm, interesting. I'm running 32bit Nano but I wouldn't expect that to make any odds. Perhaps your card doesn't support that setting so the screen doesn't show it. As long as you have tx and rx set the same I can't imagine it makes much difference. Clearly from your test it's important to choose the correct antenna.
One thing I found interesting - despite WEP being disabled, the android wifi analyser app that I installed detects and reports my regular WPA2 network but also detects an unnamed WEP network from the same MAC. I wonder why/how that is being broadcast.
I also wonder what the point is of checking the hide SSSID option when all these wifi analyser tools can see it anyway.
Do you have the sysctls:
[2.1-RELEASE][firstname.lastname@example.org]/root(3): sysctl -a|grep antenna dev.ath.0.txantenna: 1 dev.ath.0.rxantenna: 1 [2.1-RELEASE][email@example.com]/root(4): sysctl -a | grep diver dev.ath.0.diversity: 0
I guess that means I need to change my rx antenna. I presume that the 0-offset sysctl numbers map to the 1-offset pfSense GUI …
In case it differs between configs (like the missing 'Diversity' setting), my pfSense antenna options for both tx and rx are:
Quick google pointed me to this. A skim read indicates that I should look further into why my pfSense gui values differ from the sysctl values before I go setting things. There are also other values I have that differ from some of the values in that thread, so I will look into those too.
I had a look at man ath4 debugging and it pointed me towards an installed pfSense tool athstats. My output is:
I'm not sure what I should expect, but it seems like an awfully high rate of failures for various statistics.
This page might offer some suggestions. I'm wondering why as I mentioned earlier, the wifi sniffer app I installed finds an anonymous WEP access point broadcasting from my wifi card. I have WEP disabled in pfSense. I'm using channel 9. No other networks nearby are close. I think 6 and 12 are the closest channels and they are in the next houses. But the network rx graphs show an overlay of my named WPA2 network on channel 9 with the anonymous WEP network on the same channel, essentially mirroring each others' signal strengths. How can I diagnose/find/see/disable this network from pfSense? There is nothing shown by ifconfig. My config.xml files show tags but nothing between.
Here's the output of the wifi sniffer:
The red is my WPA2 network, the blue is the anonymous WEP network the sniffer sees.
I installed four other wifi analyser/sniffer apps. All but one detected the hidden WEP network.
I rebooted my pfSense box, hoping there would be some interface to the AR9280 in the bios where I could disable WEP but nothing.
As I said, there is nothing in pfSense's config.xml.
I wish all the wifi sniffers were wrong, but it would be a convenient explanation to my lost and delayed traffic. As you can see from the graph (and all the other graphs from the other tools) the WEP network signal strength is consistently stronger than my WPA2 network so it makes sense that WEP could be interfering.
I also have this hangover from when I first started messing around with a Nano build of pfSense. In file /etc/loader.conf.local
I suspect none of that is required any more and I doubt it has an effect but you never know.
Ooo, interesting stuff. Here's my output from athstats:
[2.1-RELEASE][firstname.lastname@example.org]/root(1): athstats athstats: ath0: Invalid argument athstats: ath0: Invalid argument 44570515 data frames received 23809533 data frames transmit 157053 tx frames with an alternate rate 17847009 long on-chip tx retries 3848293 tx failed 'cuz too many retries 40 stuck beacon conditions 54M current transmit rate 105752 tx stopped 'cuz no xmit buffer 7489 tx failed 'cuz dma buffer allocation failed 131452 tx frames with no ack marked 18653355 tx frames with short preamble 2453819 rx failed 'cuz of bad CRC 1 rx failed 'cuz decryption 18237535 rx failed 'cuz frame too short 118055 rx failed 'cuz of PHY err 2752 transmit override receive 11756 OFDM restart 103547 CCK restart 67353936 beacons transmitted 229918 periodic calibrations -0/+0 TDMA slot adjust (usecs, smoothed) 33 rssi of last ack 20 avg recv rssi -96 rx noise floor 5024844 tx frames through raw api 7489 raw tx failed 'cuz interface/hw down 18 rx failed 'cuz frame too large 51625 cabq frames transmitted 21221 cabq xmit overflowed beacon interval 1 switched default/rx antenna Antenna profile:  tx 19961028 rx 44570515
Also loads of failures but that's over some time (~80 days) and quite a lot of data. I also see errors in Status: Interfaces:
WIFI1 interface (ath0) Status up MAC address 00:11:f5:**:**:** IPv4 address 192.168.10.1 Subnet mask IPv4 255.255.255.0 IPv6 Link Local fe80::211:f5ff:fe**:****%ath0_wlan0 Media autoselect mode 11g <hostap> Channel 8 SSID ******** BSSID b8:3e:**:**:**:** Rate 54M RSSI 15.0 In/out packets 11078538/18599609 (1.24 GB/21.94 GB) In/out packets (pass) 11078538/18599609 (1.24 GB/21.94 GB) In/out packets (block) 41613/1 (7.23 MB/48 bytes) In/out errors 1497/3638 Collisions 0</hostap>
Interesting that my 'antenna profile' lists only  out of what I assume is 0,1 or 2 even though I have connector 0 selected.
Edit: Also interesting is my ratio of Tx_retries vs total transmit frames. It looks like I have a very large number of retries which is probably because I'm in an area with many many other wifi networks.
I'd be interested if a wifi sniffer also indicates a WEP being broadcast from your card.
My antenna profile after rebooting still shows TX on  and RX on , despite my ,  pfSense GUI wifi interface settings.
I emailed Adrian Chadd to ask his opinion. I'm not sure how interested he will be in an 8.3-based OS but he would probably have some insight that's beyond my random guesses.
Using Wifi Analyzer in Andorid, which looks like what you're using, I see no hidden WEP networks.
Adrian is a busy man, he's almost single handedly responsible for all the Atheros code you see in FreeBSD, but he does have a presence here on the forum. No idea how often he checks in.
Looks like your last post got eaten by BB code but I assume your TX antenna profile was not 1?
Ah yeah, I guess```
Adrian replied in like 2 seconds with lots of helpful suggestions … but then checked and basically said (paraphrasing) it's not worth too much bother on 2.1 since he did heaps of fixes for FreeBSD 9.x. So bring on 2.2 I guess. In order to test my phantom WEP issues, the best bet would be to install FreeBSD on a laptop or whatever with an Atheros card and capture packets, but I don't have access to any suitable hardware. I'll ask at work tomorrow or I have an old Netbook somewhere with battery issues that I might be able to disassemble and hook up to power.
The first thing I would do is power up the card without an OS and see if perhaps there is something in cards firmware that's defaulting to a WEP host.
Can you see the MAC address of the WEP AP? Is it definitely the same card? Perhaps some other device like a phone running a hotspot server?
Adrian replied in like 2 seconds with lots of helpful suggestions …
Well you've gone straight to the source of knowledge there so anything I say is totally obsolete! ;) A man I already held in high esteem has just risen further. You've got to love open source software when things like that happen. :)
How can I power up the card without an OS? It's a half mini-PCIe card on my Jetway motherboard. There's absolutely no interface to it, as far as I'm aware.
Yeah, the MAC address is the same. I had a quick browse through lots of the /var/log logs and nothing to do with WEP at all. In fact, I suspect pfSense has no awareness of it and it's coming direct from hardware.
What I might do, since my curiousity is piqued, is buy another Atheros card since they're cheap enough and stick it in the PC and run FreeBSD Live, since I've already got Windows and Ubuntu and I don't need another full OS install, and then try and see what Adrian can tell me from a packet capture run.
One thing Adrian did recommend was to hook up a second antenna. I will do that for sure.