We are a non-profit educational organization using Lubuntu for educational classroom lab clients, coecting to a small Ubuntu battery powered server with built in wireless Access Point. The client laptops are re-furbished HP Stream 11 netbooks [Intel Celeron N2840 dual 2.16GHz, 2GB RAM, 32GB onboard SSD] and some use the Realtek 8723be wireless card and others use Broadcom bcm43142 wireless cards. We had originally been using Lubuntu 14.04 but decided to upgrade for the next set of schools this year.
After initial installation and working around the well-known Broadcom compatibility issues (thanks to these forums), all of the clients can coect to the server AP. However, we found that after coecting, they randomly stop communicating. I can run a series of PINGS and all packets retu in normal 2-3ms range for thousands of attempts, then all of a sudden, a laptop will stop receiving icmp packets (or report tens of thousands of seconds delay), and then timeout with report "Destination Host Unreachable" or in some cases "send msg: no buffer space available". When this happens, other clients configured identically continue to respond with no errors (so that rules out problem at the server AP). The BCM chipsets seem worse than the RTL chipset, but we've seen the exact problem on both versions. Ruing ifconfig and iwconfig when PINGs are unsuccessful still shows the non-responding client is coected to the AP and has same IP address.
A work around is to discoect the wireless coection using graphical network manager icon in lower right, or to toggle the "Airplane" mode key. After recoecting, the client usually communicates with AP normally again (Pings 100% successful) but once in a while only a reboot restores coectivity. Sometimes these droputs happen after 5-10 minutes, and other times it may be hours before a client discoects. I have about 200 laptops to configure for several schools and this problem is critical because the offline math tutoring program we run from the little server is sensitive to discoection. I've searched the Inteet and tried many things, but so far no success. Here is what I've done so far:
1. Fresh install of Lubuntu 16.04 desktop AMD 64bit from Live ISO disc.
2. Fresh install of Lubuntu 16.04 desktop from i386 32bit Live ISO disc.
3. Coect to other wireless networks -different server APs on different chaels, corporate domain AP, different physical location (even went out of city to isolated area with no other wifi signals).
Also compared these same networks while coected with Windows 8 laptops, several Android tablets, and a Dell Latitude 6410 ruing Lubuntu 14.04LTS, and they did not show any dropouts while the new Lu16.04 devices did.
4. Update everything possible [apt-get update], try different drivers [bcmwl-keel-source is supposed to be best match for bcm43142, using rtl8723be for RTL]
5. Edited the WiFi power management config file for Realtek by adding in /etc/modprobe.d/rtl8723be.conf
# Disable chipset power mgmt.
Options rtl8723be fwlps=0 ips=0 {alteatively =N)
6. Perform upgrade ( sudo apt-get dist-upgrade) on netbook originally ruing Lubuntu 14.04LTS and coected to corporate network (with exteal Inteet access). While doing this, it successfully downloaded hundreds of MB of files for the upgrade to Lu16.04 and then started installing/configuring them. Near the end of the process, I noticed the WiFi network dropped out and I had to force recoect. It had been stable up until a certain point in the upgrade to 16.04. After the Upgrade and ruing apt-get update to make sure everything was latest, I compared that netbook to some of the others that I had updated from the ISO disc clean install and found it acted the same.
In all cases, PINGS will cease, html pages "freeze", and often the Network manager will pop up message in upper right saying "network discoected".
Today I ran the "wireless info" scripts by Wild Man, Krytorik, chili555, and others as often mentioned in these forums on this netbook with BCM that was upgraded from LU14.04 to LU16.04. The first report was taken while it was successfully PINGing the server AP [ wireless-info-RA-Ping.txt]. After a couple hours, I caught it failing (Dest host unreachable) and grabbed another capture of the wireless info [ wireless-info-RA-noPing.txt]. Comparing the two report files shows only minor differences in AP signal quality/level, number of packets sent/rcvd, beacon timestamps. The only significant difference I find is that when it was working, it also showed three other neighboring WiFi networks available that didn't show up when it was not successfully PINGing the intended server AP. I am attaching both reports in case anyone can find something else different.
One other thing I will mention is that sometimes under Lu 16.04, I've seen the graphical Network Manager icon in lower right of screen change from the 4-bar signal strength icon to the double-box indicating network discoected, and sometimes clicking it will not show ANY WiFi networks available, even when I may still be successfully PINGing my server AP. At most other times, the 4 bars show signal level, even when it stops responding to PINGS. So this visual notification doesn't seem to correspond to whether or not the client is really coected, and I am treating it as more an aoyance instead of show-stopper right now so can defer resolution of that until later unless the same fix corrects both the dropping out and the status display. Rebooting always restores the proper display of network status.
I am at a loss what to try next. I've been configuring Lubuntu on these netbooks for a year and have leaed my way around CLI, so am not quite a newbie, but I am not a real linux expert yet either. Any suggestions?
برچسب:
نویسنده: استخدام کار