duncan_mk wrote:I've been having trouble with the Wlan over some months - covered in a couple of posts esewhere:
post28526.html#p28526
but these concerned 64bit distro's. These have sorted themselves out - 3.8.4-antix.2-amd64-smp x86_64 is now good & trouble free. The only remaining problem is that I cannot connect to the router with any 32bit kernel higher than 3.7.10.
Rusty put me on to this post from Brian Masinick:
post25059.html?hilit=b43%20firmware#p25059
and I have found his suggestion of using the legacy drivers useful. The Dell had a habit of dropping the signal (not a huge problem - I have an 'ifdown' 'ifup' script which usually reconnects without pain) but it's been running for several hours today with out problem
__{{emoticon}}__
Here's some output to show what's happening:
Output of Dell netbook:
Code: Select all
$ inxi -n
Network: Card-1: Broadcom BCM4312 802.11b/g LP-PHY driver: b43-pci-bridge
IF: wlan0 state: up mac: 0c:60:76:3f:54:c6
Card-2: Realtek RTL8101E/RTL8102E PCI Express Fast Ethernet controller driver: r8169
IF: eth0 state: down mac: 00:24:e8:e2:6f:63
Code: Select all
# iwlist wlan0 scan | grep ESSID
ESSID:"NETGEAR-2.4-G"
ESSID:"BTWiFi"
ESSID:"BTWiFi"
ESSID:"BTWiFi-with-FON"
ESSID:"BTHomeHub2-2R42"
ESSID:"Netgear" <====
ESSID:"Powerbook"
Code: Select all
$ su -c"iwlist wlan0 scan | grep ESSID"
Password:
ESSID:"NETGEAR-2.4-G"
ESSID:"BTHomeHub2-2R42"
ESSID:"BTWiFi"
ESSID:"BTWiFi-with-FON"
ESSID:"BTWiFi"
ESSID:"BTOpenzone-B"
ESSID:"BTHub3-KHXG"
Code: Select all
$ inxi -n
Network: Card-1: Realtek RTL8111/8168B PCI Express Gigabit Ethernet controller driver: r8169
IF: eth0 state: down mac: e8:11:32:96:ff:77
Card-2: Broadcom BCM4313 802.11b/g/n Wireless LAN Controller driver: bcma-pci-bridge
IF: wlan0 state: up mac: e0:ca:94:02:70:97
Code: Select all
$ su -c"iwlist wlan0 scan | grep ESSID"
Password:
ESSID:"NETGEAR-2.4-G"
ESSID:"vellasrv1-Wireless"
ESSID:"BTHomeHub2-2R42"
ESSID:"BTWiFi"
ESSID:"BTWiFi-with-FON"
ESSID:"Powerbook"
ESSID:"Netgear" <====
ESSID:"BTWiFi"
ESSID:"BTOpenzone-B"d
As you will note, there are differences - notably the"Netgear" router which is the one I use! Don't know if this is any help - but that's how things are in Suffolk.
dmk
Can you say with certainty that it is always on the 32 bit 3.8.4 kernel in which you miss seeing the Netgear ESSID? Could it be coincidence, or is your Wifi access always consistent with other kernels, yet not with the 32 bit instance of the 3.8.4 kernel?
If it is really problematic with only the 3.8.4 kernel, but not the others, then the solution is clear - assuming that is the only variable: use a different kernel. Why that particular kernel would be problematic is beyond me, but there is a chance that the actual issue is not associated with the kernel specifically, but perhaps with the router or the interaction with the other Wifi access spots.
At one point in time, I was consistently finding that neighboring Wifi access points were attempting to use the same Wifi channel as the one that I was using. The solution for me was to watch the channels being used, and if the other access points were always using the same ones. If they were, I just reprogrammed my wireless router to a different channel and set it to a fixed channel number and that permanently fixed the problem (unless yet another channel came along, in which case, I may have had to repeat this exercise).
Based on these comments, you can see that there is the potential that the real problem could be intermittent Wifi channel access contention, and that is why I posed the question about whether a particular kernel is at fault or not. If it's ALWAYS the kernel, then we can point the finger at the kernel, but if the access points in your area vary from time to time, as they have in the areas where I've lived, then that is a more likely variable - an ever changing one at that, and that is one possible reason why you do not see consistent behavior.
So, there are at least two possibilities, maybe more than that: 1. The 32 bit 3.8.4 kernel isn't as robust as it needs to be for Wifi access; if so, use a kernel that you've known to work. There are plenty of kernels available: antiX kernels of different versions, Debian kernels, and Liquorix kernels, to name three alternate sources; each have several versions available; use what works for you, that's why we keep plenty of options available in order to address various different hardware issues. 2. Diagnose and experiment with Wifi channels. I've seen a lot of channel conflict in the areas I've lived, especially with channels 6 and 7. Belkin and Netgear inexpensive routers tend to contend for those channels unless you explicitly reprogram your router to a different channel. Some ISPs, when they install their Wifi setup for you, will take care of channel contention in dense areas where they install everyone's equipment; if you handle it yourself, you can see what channels have strong signals that could interfere, and you can choose a different channel. 3. Some inexpensive routers just don't work all that well, and seem to benefit from an occasional power cycle reboot, even when you've done all of these things. Belkin and Netgear routers are generally inexpensive and usually fall into this category.
Hope this is useful.