| View previous topic :: View next topic |
| Author |
Message |
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
 Posted: Sun Mar 30, 2014 6:41 am Post subject: Netgear A6200 and ndiswrapper |
 |
|
I recently purchased a Netgear A6200 adapter to match a new Netgear A6300v2 router I got for the house. The adapter works well in Windows 7 but, wouldn't you know it, there's no linux driver. Nothing on the website/installation disk and nothing in the kernel (not yet, at least). I installed ndiswrapper, hoping this might work, and it seems to be able to find the device and identify it just fine. In fact, the wifi module will setup (seemingly) properly, but it won't connect. My wpa_supplicant log is empty and the only messages I'm seeing related to the matter are in dmesg (see below). I've included some current info, but hoped that someone might be able to help me make sense of all this:
| lsusb: | ...
Bus 005 Device 003: ID 0846:9050 NetGear, Inc.
... |
| modprobe: | Module Size Used by
ndiswrapper 250430 0
... |
| /etc/init.d/net.wifi1 start: | * Bringing up interface wifi1
* Starting wpa_supplicant on wifi1 ...
Successfully initialized wpa_supplicant
rfkill: WLAN soft blocked [ ok ]
* Starting wpa_cli on wifi1 ... [ ok ]
* Backgrounding ... ...
* WARNING: net.wifi1 has started, but is inactive |
(note, the WARNING message comes up for my older adapter but which will work fine anyway after a few moments - I never looked into this in great detail, but as it's come up previously and I've still been able to connect I don't think this is at all related)
(also, the 'rfkill: WLAN soft blocked" does NOT come up for my older adapter. I wonder if this could be related, but I have no idea what it means)
| iwconfig wifi1: | wifi1 IEEE 802.11g ESSID:off/any
Mode:Managed Frequency:2.462 GHz Access Point: Not-Associated
Bit Rate:300 Mb/s Tx-Power:0 dBm
RTS thr:2347 B Fragment thr:2346 B
Encryption key:off
Power Management:off
Link Quality:89/100 Signal level:-39 dBm Noise level:-96 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:47 Invalid misc:173 Missed beacon:0 |
(I noticed that the Encyrption key is set to off, but this is apparently also how it is set with the working adapter as well, even though I'm using WPA2 encryption on my network... My guess is that iwconfig doesn't pick up on this type of encryption?)
Now, with my old adapter the network would function fine by this point. Instead I get:
| ping yahoo.com: | | ping: unknown host yahoo.com |
| dmesg: | [ 2601.740154] ndiswrapper version 1.59 loaded (smp=yes, preempt=no)
[ 2601.900168] usb 5-2: reset high-speed USB device number 3 using xhci_hcd
[ 2601.913225] xhci_hcd 0000:06:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801e79d5300
[ 2601.913230] xhci_hcd 0000:06:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801e79d5340
[ 2601.913232] xhci_hcd 0000:06:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801e79d5380
[ 2601.913235] xhci_hcd 0000:06:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff8801e79d53c0
[ 2601.920504] ndiswrapper: driver bcmwlhigh5 (NETGEAR,Inc.,08/01/2012, 6.30.61.21) loaded
[ 2601.926040] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc90009486000, 32000, 8
[ 2601.926045] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc9000948dd00, 32000, 9
[ 2601.926047] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc90009495a00, 32000, 9
[ 2601.926049] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc9000949d700, 32000, 9
[ 2601.926051] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900094a5400, 32000, 9
[ 2601.926053] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900094ad100, 32000, 8
[ 2601.926055] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900094b4e00, 32000, 9
[ 2601.926057] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900094bcb00, 32000, 9
[ 2601.926059] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900094c4800, 32000, 9
[ 2601.926061] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900094cc500, 32000, 9
[ 2601.926063] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900094d4200, 32000, 8
[ 2601.926065] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900094dbf00, 32000, 9
[ 2601.926067] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900094e3c00, 32000, 9
[ 2601.926069] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900094eb900, 32000, 9
[ 2601.926071] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900094f3600, 32000, 9
[ 2601.926073] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900094fb300, 32000, 8
[ 2601.926075] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc90009503000, 32000, 8
[ 2601.926077] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc9000950ad00, 32000, 9
[ 2601.926079] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc90009512a00, 32000, 9
[ 2601.926081] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc9000951a700, 32000, 9
[ 2601.926083] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc90009522400, 32000, 9
[ 2601.926085] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc9000952a100, 32000, 8
[ 2601.926087] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc90009531e00, 32000, 9
[ 2601.926089] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc90009539b00, 32000, 9
[ 2601.926091] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc90009541800, 32000, 9
[ 2601.926093] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc90009549500, 32000, 9
[ 2601.926095] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc90009551200, 32000, 8
[ 2601.926098] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc90009558f00, 32000, 9
[ 2601.926100] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc90009560c00, 32000, 9
[ 2601.926102] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc90009568900, 32000, 9
[ 2601.926104] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc90009570600, 32000, 9
[ 2601.926106] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc90009578300, 32000, 8
[ 2601.926108] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc90009580000, 32000, 8
[ 2601.926110] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc90009587d00, 32000, 9
[ 2601.926112] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc9000958fa00, 32000, 9
[ 2601.926115] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc90009597700, 32000, 9
[ 2601.926117] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc9000959f400, 32000, 9
[ 2601.926119] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900095a7100, 32000, 8
[ 2601.926121] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900095aee00, 32000, 9
[ 2601.926123] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900095b6b00, 32000, 9
[ 2601.926125] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900095be800, 32000, 9
[ 2601.926127] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900095c6500, 32000, 9
[ 2601.926129] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900095ce200, 32000, 8
[ 2601.926131] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900095d5f00, 32000, 9
[ 2601.926133] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900095ddc00, 32000, 9
[ 2601.926135] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900095e5900, 32000, 9
[ 2601.926137] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900095ed600, 32000, 9
[ 2601.926139] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900095f5300, 32000, 8
[ 2601.926141] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc900095fd000, 32000, 8
[ 2601.926143] ndiswrapper (MmBuildMdlForNonPagedPool:1864): ffffc90009604d00, 32000, 9
[ 2601.942195] ndiswrapper (ndis_encode_setting:383): unknown type: 3
[ 2602.190701] wlan0: ethernet device c4:04:15:3c:d8:f2 using NDIS driver: bcmwlhigh5, version: 0x61e3d15, NDIS version: 0x501, vendor: 'NDIS Network Adapter', 0846:9050.F.conf
[ 2602.191851] wlan0: encryption modes supported: WEP; TKIP with WPA, WPA2, WPA2-PSK; AES/CCMP with WPA, WPA2, WPA2-PSK
[ 2602.192200] usbcore: registered new interface driver ndiswrapper
[ 2602.198663] ndiswrapper: interface renamed to 'wifi1'
[ 2602.198682] systemd-udevd[14496]: renamed network interface wlan0 to wifi1
[ 2606.009656] IPv6: ADDRCONF(NETDEV_UP): wifi1: link is not ready
[ 2617.070074] IPv6: ADDRCONF(NETDEV_CHANGE): wifi1: link becomes ready |
Last edited by alienjon on Sat Aug 09, 2014 1:22 am; edited 2 times in total |
|
| Back to top |
|
 |
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
| Posted: Sat Apr 05, 2014 3:09 am Post subject: |
|
|
I toyed around a bit with wpa_gui and discovered that it has a nice log of events going on with wpa_supplicant (the actual log version of which I can't seem to find in the system). In any event, it would seem that - having setup my wpa_supplicant.conf - to accept changes via wpa_gui, this application has taken upon itself to update that configuration file with the following information for my home network:
| relevent section of /etc/wpa_supplicant/wpa_supplicant.conf: | network={
ssid="LJRWireless"
psk="{passcode}"
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP
auth_alg=OPEN
} |
When I enable either the network with the new or old adapter, this is the same information - so I believe it to be correct for this reason. Of course, when I use wpa_gui with the old adapter, it will show that it has connected to the network (and, subsequently, the world wide waste at large) with all the glorious connection details I strive to achieve with the new adapter. HOWEVER: If I try to connect with the new adapter it seems to start off with a message that it is 'scanning', that it finds the network, that it actually connects to a "4 way handshake", but then alternates back to scanning and the whole process repeats ad nauseum.
This is where things get even more interesting as I now checked the log in wpa_gui and found the following message:
| Code: | | 4 way handshake failed - pre-shared key may be incorrect |
I've verified that the connection key is correct, but maybe the type of passcode/specific WPA isn't? My router is setup to use a "WPA2-PSK [AES]" encryption, but I'm not sure how the configuration file should look any different...
As a last thought, the router that I'm using is actually dual band - meaning that I actually have 2 networks that I can connect to (and I have connected to them both on different systems). The 2.4ghz band is the LJRWireless network but there is also a 5ghz band with a different name. My old device does not register the 5ghz band (which it shouldn't as it's b/g technology) but using wpa_gui to 'scan' with the new adapter (which SHOULD be able to read that band) ALSO doesn't come up with anything. That may or may not be related, but I figured it's worth mentioning... |
|
| Back to top |
|
|
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
| Posted: Sat Apr 05, 2014 7:56 pm Post subject: |
|
|
I looked into the rfkill message, wondering if this might be part of the problem. I'm referring to the following from my first post that displays whenever I start the interface (net.wifi1) for the new adapter:
| Code: | | rfkill: WLAN soft blocked |
I did some research into this piece specifically and found a few mentions about rfkill being invoked when there is a driver conflict. One solution (in ubuntu) was to blacklist the modules. It seems that, for me, simply removing the modules (`modprobe -r X`, where X=the modules for my old adapter) and adding the ndiswrapper does the trick to remove the message, but I don't get any change in connection (ie: I still can't connect). Interestingly, rfkill isn't even installed on my system, so I'm not sure why I got the message:
| emerge rfkill -pv: | | [ebuild N ] net-wireless/rfkill-0.5 8 kB |
|
|
| Back to top |
|
|
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
|
| Back to top |
|
|
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
| Posted: Fri Apr 11, 2014 3:52 pm Post subject: |
|
|
| Any takers on this? I still haven't had any luck :-/ |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Fri Apr 11, 2014 8:37 pm Post subject: |
|
|
| alienjon wrote: | | Any takers on this? I still haven't had any luck :-/ |
alienjon ... I have been following but from experience I've developed an aversion to ndiswrapper :)
Anyhow, from that log your DEAUTH is trigged by the 4-way handshake failure ... so authentication. I notice you have 'wps' enabled ... if your AP is expecting the wps PIN then this may be the cause of the authentication failing. I say that with very little experience of using wps with wpa_supplicant (I tend not to buy AP's that have this feature ... I'd disable it on the AP if at all possible) but I can't see anything else that suggests why the failure occurs. So, from the looks of things you have the wps useflag enabled on wpa_supplicant, try disabling it.
The only other possible cause of such a failure would be the psk, and so just to rule this out have you checked it, and/or is it possible the psk you used is at the character limit (effectively, 63 chars)? If so *don't* quote the string in your wpa_supplicant.conf as it'll be truncated with the first quote included and the last char excluded.
Also, I think I may have got this very same card working on an Ubuntu install some months back, it was obviously traumatic as I can hardly remember anything of what I did ... I'll try and contact the friend I was helping and see if they made any notes.
best ... khay |
|
| Back to top |
|
|
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
| Posted: Fri Apr 11, 2014 11:14 pm Post subject: |
|
|
Thanks for the reply! I've not used ndiswrapper before and I read several warnings about it (being deprecated, specifically) so I didn't have the highest of expectations... I tried both disabling WPS from wpa_supplicant as well as connecting via WPS. Disabling didn't seem to make a different (wpa_gui reported the same error messages, at least, but I'll try to get the larger wpa_supplicant log file and have a look through that too). WPS connection tried connecting to every wifi connection in range (mine last, it seemed) with no luck either. In those instances it would display "trying to authenticate" for a few seconds before terminating and going to the next network. I haven't done WPS before, so I may have also done this process wrong - though I did enable connection on the router side as well.
I would MUCH rather use a formal driver for this device, but I haven't been able to find any, unfortunately. I'm not even sure how to get the chipset of the device to see if there's a generic driver (I was guessing that it's new enough that a linux driver may not be available yet). However, if you are aware of one for me to test out, I'd be very interested! |
|
| Back to top |
|
|
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
| Posted: Mon Aug 04, 2014 2:26 am Post subject: |
|
|
Soon after my last post I put this issue down for a bit - hoping that time might bring new ideas. I re-approached the issue earlier today and decided to look into the wpa_supplicant driver. I had been using wext (for both the old and the new adapters) but in reading behind some of the details on the web I found the nl80211 is really what I should be using - if I am able to get it to work (wext is apparently kept as it works with most chipsets, but is slowly being phased out by nl80211 which, from what I gather, should have the same level of compatibility - though please correct me if I'm wrong).
Using this different driver I get a different error:
| wpa_supplicant -Dnl80211 -iwifi1 -c/etc/wpa_supplicant/wpa_supplicant.conf: | Successfully initialized wpa_supplicant
nl80211: Could not configure driver to use managed mode
wifi1: Failed to initialize driver interface
|
With full debugging:
| wpa_supplicant -Dnl80211 -iwifi1 -c/etc/wpa_supplicant/wpa_supplicant.conf -dd: | wpa_supplicant v2.0
random: Trying to read entropy from /dev/random
Successfully initialized wpa_supplicant
Initializing interface 'wifi1' conf '/etc/wpa_supplicant/wpa_supplicant.conf' driver 'nl80211' ctrl_interface 'N/A' bridge 'N/A'
Configuration file '/etc/wpa_supplicant/wpa_supplicant.conf' -> '/etc/wpa_supplicant/wpa_supplicant.conf'
Reading configuration file '/etc/wpa_supplicant/wpa_supplicant.conf'
ctrl_interface='/var/run/wpa_supplicant'
ctrl_interface_group='wheel'
ap_scan=1
update_config=1
Line: 6 - start of a new network block
scan_ssid=1 (0x1)
ssid - hexdump_ascii(len=11):
4c 4a 52 57 69 72 65 6c 65 73 73 LJRWireless
PSK (ASCII passphrase) - hexdump_ascii(len=10): [REMOVED]
key_mgmt: 0x2
PSK (from passphrase) - hexdump(len=32): [REMOVED]
Priority group 0
id=0 ssid='LJRWireless'
Could not open file /sys/class/net/wifi1/phy80211/name: No such file or directory
rfkill: initial event: idx=0 type=2 op=0 soft=0 hard=0
rfkill: initial event: idx=2 type=1 op=0 soft=0 hard=0
nl80211: Set mode ifindex 8 iftype 2 (STATION)
nl80211: Failed to set interface 8 to mode 2: -19 (No such device)
nl80211: Could not configure driver to use managed mode
netlink: Operstate: linkmode=0, operstate=6
nl80211: Set mode ifindex 8 iftype 2 (STATION)
nl80211: Failed to set interface 8 to mode 2: -19 (No such device)
wifi1: Failed to initialize driver interface
Failed to add interface wifi1
wifi1: Cancelling scan request
wifi1: Cancelling authentication timeout |
Might this ring something for anyone? |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Mon Aug 04, 2014 2:58 am Post subject: |
|
|
| alienjon wrote: | | Code: | | Could not open file /sys/class/net/wifi1/phy80211/name: No such file or directory |
|
alienjon ... that particular directory is provided by MAC80211 but ndiswrapper doesn't use this, it uses the windows subsystem. I'm not sure where you read you should be using nl80211 but "NDISwrapper relies on the aging "wireless-extensions" to enable applications to access Wi-Fi" (link).
best ... khay |
|
| Back to top |
|
|
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
| Posted: Tue Aug 05, 2014 1:25 am Post subject: |
|
|
| khayyam wrote: | | I'm not sure where you read you should be using nl80211 |
I, of course, having made this statement, cannot find the link that led me to this belief. I will point out the kernel documentation, though that points out the intention to be replacing wext, though at the same time I was not aware of the NDISWrapper 'limitation' to wext. Again, I was trying something different to see if I could make progress. This seems to be part of why NDISWrapper does not support the newer driver.
I think my search would benefit from some study of WPA authentication and innerworkings of '4 way handshakes'. I'll also study the logs a bit further - and with different options set - to see what I can conclude. I also never responded to the PSK question from your previous post. The password I'm using is very simple (actually short - 10 alphanumeric characters, to be precise) and without anything outside letters and numbers. Unless too simple of a password could be the culprit it must be something else... |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Tue Aug 05, 2014 2:12 am Post subject: |
|
|
| alienjon wrote: | | I also never responded to the PSK question from your previous post. The password I'm using is very simple (actually short - 10 alphanumeric characters, to be precise) and without anything outside letters and numbers. Unless too simple of a password could be the culprit it must be something else... |
alienjon ... that shouldn't be the issue then, I mentioned it as its one possible cause of authentication failure. If you haven't already then I would disable the wps useflag on wpa_supplicant as the client may be sending an empty wps pin and so failing for that reason (I speculate).
You might post your wpa_supplicant.conf (sans psk) and the output of the following:
| Code: | | # awk '{RS="Cell"}/LJRWireless/' <(iwlist wifi1 scan) |
best ... khay |
|
| Back to top |
|
|
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
| Posted: Tue Aug 05, 2014 3:28 am Post subject: |
|
|
| khayyam wrote: | | If you haven't already then I would disable the wps useflag on wpa_supplicant as the client may be sending an empty wps pin |
Naw, as I mentioned before putting this down I got the same -dd output with and without WPS built into wpa_supplicant.
However, I've also made significant progress. I'd built my wpa_supplicant.conf from the example file, and thus included several options as per how I understand my network to be setup. I've since eliminated most of the lines. Here's the current iteration:
| /etc/wpa_supplicant/wpa_supplicant.conf: | ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
update_config=1
network={
ssid="LJRWireless"
psk="123456789"
} |
Now, with this setup I still cannot connect by command line:
wpa_supplicant -Dwext -iwifi1 -c/etc/wpa_supplicant/wpa_supplicant.conf -d -> pastelog output (I checked, but did not see anything really incriminating in the log, please let me know if you see otherwise)
HOWEVER, if I connect via: /etc/init.d/net.wifi1 start
VOILA! And I'll connect. This is now making me wonder the difference between starting the service by hand and via the startup script. I've seen that the last few lines in the command-line output:
| Code: | RX ctrl_iface - hexdump_ascii(len=6):
53 54 41 54 55 53 STATUS
wifi1: Control interface command 'STATUS'
RX ctrl_iface - hexdump_ascii(len=22):
47 45 54 5f 4e 45 54 57 4f 52 4b 20 30 20 64 69 GET_NETWORK 0 di
73 61 62 6c 65 64 sabled |
repeat over and over again every 10 seconds. WPA_GUI reports that I've connected to the router, but no IP is assigned. While keeping wpa_supplicant running in one terminal window, if I open another and run dhcpcd wifi1 up NOW the connection is made. While I'm sure there's more to it in the startup script, this appears to be the only difference in order to get it to run for me (maybe the router isn't dhcp'ing as it should?)
On a few other notes, I see (using the shortened wpa_supplicant.conf) a few interesting points, firstly:
| Code: | wifi1: State: ASSOCIATED -> 4WAY_HANDSHAKE
wifi1: WPA: RX message 1 of 4-Way Handshake from 98:fc:11:b6:6b:c6 (ver=2) |
The 4way handshake is now connecting. Assuming that this is the result of a change in my conf file (the only thing I can think it would have been) was something about setting the encryption type (key_mgmt) or some of the other items in the example conf that I truly believed were needed to identify the appropriate connection (wpa_supplicant seems to autodetect much better, though I may fiddle more to see what I got wrong).
Also, the RFKILL error persists:
| Code: | | rfkill: WLAN soft blocked |
A google search turned up that this is remedied via:
| Code: | rfkill unblock all
# Also, the following can be used to see what (if anything) is being blocked and if it's a soft or hard block
rfkill list
|
That same search indicated that this is likely not even much in the means of an error - as other symptoms led to resolutions of those other problems (As is the case with me). In other words, the connection can work just fine with this error.
As the connection is now working I'm considering this issue solved. khayyam: thanks for all the help and support in this. I really appreciated your input  |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Tue Aug 05, 2014 1:38 pm Post subject: |
|
|
| alienjon wrote: | | However, I've also made significant progress. I'd built my wpa_supplicant.conf from the example file, and thus included several options as per how I understand my network to be setup. I've since eliminated most of the lines. |
alienjon ... as you noted wpa_supplicant will autodetect and select the best/securest method by scanning the AP's capabilities so you can do without providing all the details (though there are cases in which you might want to). The output of 'iwlist' (above) would show exactly what the AP supports and so the wpa_supplicant.conf can be further configured to match. I'm inclined to think that it was 'group' and 'pairwise' that were likely the cause ...
One change to wpa_supplicant.conf I would advise (as the following is the current recommended syntax) ...
| /etc/wpa_supplicant/wpa_supplicant.conf: | ctrl_interface=DIR=/run/wpa_supplicant GROUP=wheel
update_config=1
network={
ssid="LJRWireless"
psk="123456789"
} |
| alienjon wrote: | | Now, with this setup I still cannot connect by command line [...] (I checked, but did not see anything really incriminating in the log, please let me know if you see otherwise) |
The authentication was successful ...
| Code: | | EAPOL authentication completed successfully |
'wpa_cli status' should show the wpa_state as "COMPLETED" ... but as dhcpcd hasn't run you are not provided an ip address, and so no networking.
| alienjon wrote: | | Also, the RFKILL error persists: |
I suspect this may be due to udev and the device being renamed 'wifi1' (is there a udev rule in place for device renaming?). Anyhow, it doesn't seem to cause any issues, but you can unblock by adding a preup() function to /etc/conf.d/net
| Code: | preup() {
rfkill unblock all
return 0
} |
| alienjon wrote: | | As the connection is now working I'm considering this issue solved. khayyam: thanks for all the help and support in this. I really appreciated your input :-) |
You're welcome & best ... khay |
|
| Back to top |
|
|
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
| Posted: Wed Aug 06, 2014 1:01 am Post subject: |
|
|
| khayyam wrote: | | alienjon ... as you noted wpa_supplicant will autodetect and select the best/securest method by scanning the AP's capabilities so you can do without providing all the details (though there are cases in which you might want to). The output of 'iwlist' (above) would show exactly what the AP supports and so the wpa_supplicant.conf can be further configured to match. I'm inclined to think that it was 'group' and 'pairwise' that were likely the cause ... |
I think that you're right, though I'm still not sure what the correct settings should have been (iwlist will likely shed some light, I suppose?). On that same note, I appreciate your pointing out about that iwlist, as it is run from the same adapter, will tell me right then if I'm able to connect or not. The whole reason that I purchased this new adapter was to connect to a new 5ghz router I had bought a few months ago. Seems that I'm not able to connect to that band, but the router is dual band and I can connect at the older 2.4 band as well (and iwlist is able to show that to me quite easily).
One change to wpa_supplicant.conf I would advise (as the following is the current recommended syntax) ...
| khayyam wrote: |
One change to wpa_supplicant.conf I would advise (as the following is the current recommended syntax) ... | /etc/wpa_supplicant/wpa_supplicant.conf: | ctrl_interface=DIR=/run/wpa_supplicant GROUP=wheel
update_config=1
network={
ssid="LJRWireless"
psk="123456789"
} |
|
This is also helpful. I've seen SEVERAL variations in different forums and FAQs about the ctrl_interface option. They all seem to work, but I hadn't seen any specific recommended/preferred setting. I'll update this too. As for the RFKILL it may well be related to udev, as I do have rules defining the names of the devices (the gentoo handbook encourages it these days). Doesn't seem to be an error, though, and more of a warning as I am still able to connect even with this message. As before, thanks again for the help! |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Wed Aug 06, 2014 2:02 pm Post subject: |
|
|
| alienjon wrote: | | The whole reason that I purchased this new adapter was to connect to a new 5ghz router I had bought a few months ago. Seems that I'm not able to connect to that band, but the router is dual band and I can connect at the older 2.4 band as well (and iwlist is able to show that to me quite easily). |
alienjon ... if you post the output of the following I may be able to help ....
| Code: | | # awk '{RS="Cell"}/LJRWireless/' <(iwlist wifi1 scan) |
best ... khay |
|
| Back to top |
|
|
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
| Posted: Thu Aug 07, 2014 12:42 pm Post subject: |
|
|
Sure thing. Here's the output, though the 5ghz band has a different name. If I run the command you gave with that band's ssid I get no output:
| awk '{RS="Cell"}/SpeedyMcRosen/' <(iwlist wifi1 scan): | |
This is the LJRWireless output.
| awk '{RS="Cell"}/LJRWireless/' <(iwlist wifi1 scan): | 01 - Address: 04:A1:51:E9:41:45
ESSID:"LJRWireless"
Protocol:IEEE 802.11g
Mode:Master
Frequency:2.437 GHz (Channel 6)
Quality:96/100 Signal level:-34 dBm Noise level:-96 dBm
Encryption key:on
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
24 Mb/s; 36 Mb/s; 54 Mb/s
Extra:bcn_int=100
Extra:atim=0
IE: Unknown: 000B4C4A52576972656C657373
IE: Unknown: 010882848B962430486C
IE: Unknown: 030106
IE: Unknown: 2A0104
IE: Unknown: 2F0104
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : CCMP
Pairwise Ciphers (1) : CCMP
Authentication Suites (1) : PSK
IE: Unknown: 32040C121860
IE: Unknown: 0B050300130000
IE: Unknown: 2D1AAD1917FFFFFF0000000000000000000000000000000000000000
IE: Unknown: 3D1606081500000000000000000000000000000000000000
IE: Unknown: 4A0E14000A002C01C800140005001900
IE: Unknown: 7F080500080000000040
IE: Unknown: DD810050F204104A0001101044000102103B0001031047001074E3B77243F449A31D2963043CBB3
0D11021000D4E4554474541522C20496E632E102300075236333030763210240007523633303076321042000336373910540008
00060050F20400011011000752363330307632100800022008103C0001031049000600372A000120
IE: Unknown: DD090010180203001C0000
IE: Unknown: DD180050F2020101880003A4000027A4000042435E0062322F00
IE: Unknown: 46057208010000
02 - Address: 98:FC:11:B6:6B:C6
ESSID:"LJRWireless"
Protocol:IEEE 802.11g
Mode:Master
Frequency:2.437 GHz (Channel 6)
Quality:100/100 Signal level:-28 dBm Noise level:-96 dBm
Encryption key:on
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 9 Mb/s
18 Mb/s; 36 Mb/s; 54 Mb/s
Extra:bcn_int=200
Extra:atim=0
IE: Unknown: 000B4C4A52576972656C657373
IE: Unknown: 010882848B961224486C
IE: Unknown: 030106
IE: Unknown: 2A0100
IE: Unknown: 32040C183060
IE: Unknown: 2D1AEC0117FFFF0000000000000000000000000000000C0000000000
IE: Unknown: 3D1606000000000000000000000000000000000000000000
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : CCMP
Pairwise Ciphers (1) : CCMP
Authentication Suites (1) : PSK
IE: Unknown: DD180050F2020101000003A4000027A4000042435E0062322F00
IE: Unknown: 0B05000033127A
IE: Unknown: 7F0101
IE: Unknown: DD07000C4307000000 |
Last edited by alienjon on Fri Aug 08, 2014 12:04 am; edited 1 time in total |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Thu Aug 07, 2014 1:34 pm Post subject: |
|
|
| alienjon wrote: | | Here's the output, though the 5ghz band has a different name. If I run the command you gave with that band's ssid I get no output: |
alienjon ... can you emerge net-wireless/iw and provide the output of 'iw list', thanks.
best ... khay
ps. something (possibly whitespace form cut & paste from the terminal) has caused the right margin to fail to wrap, can you edit your previous post and correct this. |
|
| Back to top |
|
|
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
| Posted: Fri Aug 08, 2014 12:06 am Post subject: |
|
|
| Fixed previous post. I'll post that output when I get home. Before I forget, though, I also wanted to mention that while I am now connecting with the new adapter, I'm apparently not holding the connection for very long. I still have an IP, but I can't seem to connect to anything outside even pinging the router. I haven't tested that yet, though, and will try to get some output for that as well. |
|
| Back to top |
|
|
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
| Posted: Sat Aug 09, 2014 1:22 am Post subject: |
|
|
To elaborate on my last post a bit: I had a good first day or two, but now I'm seeing that I can't stay connected for more than a few minutes before I lose the connection. By lose the connection I still appear to have an IP (currently assigned via the router's DHCP, though I'd eventually like to set it on my computer's side). However, I can't ping any IPs outside of my local LAN, and LAN-internal connections result in a 'Network is unreachable' error. It looks similar to when I needed to run dhcpcd after starting wpa_supplicant, except that I have an IP assigned.
Even more unfortunate than that is that my old adapter (an rt73 based USB adapter) is exceedingly on the fritz... It's an entirely different error that I'll have to look into, but as that was my backup plan for when I needed to connect but the new adapter wouldn't work, and it is now not working as reliably either, if I can't figure it out I may just look into buying a new AC (or at least N) adapter that's supported by the linux kernel...
In any event, I'm going to 'unsolve' this post, as this is clearly still a work in progress 
In the meantime, here's the output you requested. It seems that I can't connect via ndiswrapper to a higher band network (I know it's possible, because it's an AC adapter and can connect to this 5ghz band in Windows:
| iw list: | Wiphy phy0
max # scan SSIDs: 4
max scan IEs length: 2285 bytes
Coverage class: 0 (up to 0m)
Device supports RSN-IBSS.
Supported Ciphers:
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP (00-0f-ac:4)
Available Antennas: TX 0 RX 0
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* WDS
* monitor
Band 1:
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm) (passive scanning, no IBSS)
* 2472 MHz [13] (20.0 dBm) (passive scanning, no IBSS)
* 2484 MHz [14] (20.0 dBm) (passive scanning, no IBSS)
Supported commands:
* new_interface
* set_interface
* new_key
* start_ap
* new_station
* set_bss
* authenticate
* associate
* deauthenticate
* disassociate
* join_ibss
* set_tx_bitrate_mask
* frame
* frame_wait_cancel
* set_wiphy_netns
* set_channel
* set_wds_peer
* probe_client
* set_noack_map
* register_beacons
* start_p2p_device
* Unknown command (92)
* connect
* disconnect
Supported TX frame types:
* IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
Supported RX frame types:
* IBSS: 0x40 0xb0 0xc0 0xd0
* managed: 0x40 0xd0
* AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* mesh point: 0xb0 0xc0 0xd0
* P2P-client: 0x40 0xd0
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* P2P-device: 0x40 0xd0
software interface modes (can always be added):
* AP/VLAN
* monitor
valid interface combinations:
* #{ AP } <= 4,
total <= 4, #channels <= 1
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
Device supports TX status socket option.
Device supports HT-IBSS.
Device supports low priority scan.
Device supports scan flush.
Device supports AP scan. |
|
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Aug 09, 2014 2:52 am Post subject: |
|
|
alienjon ...
looking at the above output the driver (ndiswrapper) doesn't support 5ghz. The supported frequencies are all in the 2.4ghz range. If the driver was capable of using those frequencies they would be listed. Sorry.
As for the other issue, its likely this (instability) is also due to ndiswrapper ... though its difficult to tell without logs, etc.
best ... khay |
|
| Back to top |
|
|
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
| Posted: Sat Aug 09, 2014 4:04 am Post subject: |
|
|
| khayyam wrote: | | looking at the above output the driver (ndiswrapper) doesn't support 5ghz. The supported frequencies are all in the 2.4ghz range. If the driver was capable of using those frequencies they would be listed. Sorry. |
That's how I was reading it too. I imagine that it's still possible to expect ndiswrapper to maintain the connection (I'm not seeing anything really out of the ordinary in the logs, I don't think, but I may post in the next day or two). However, I also am trying to run a reasonably new piece of hardware with software old enough that it's not even maintained any longer... In the several google searches I've made on this topic I don't see anything that encourages me that any linux drivers for this chipset will come out any time soon (possibly indicating that getting a different one would be a better option). Any suggestions? Preferably an AC adapter that could connect to the 5ghz band?
| khayyam wrote: | | As for the other issue, its likely this (instability) is also due to ndiswrapper ... though its difficult to tell without logs, etc. |
If this is in regards to the rt73 adapter, it's definitely not related to ndiswrapper, as there is reasonable (though possibly old) support for this specific chipset. I'm using rt73usb, rt2x00usb, and rt2x00lib modules for this adapter. Typically works well, but I'm increasingly having this issue come up (it's happened on and off since I installed Gentoo most recently on my compute). The error message doesn't say much, though, as a google search will only return results 2+ years old and nothing that seems to be related to what I have for a setup. I enabled additional debugging messages in the kernel for the rt73 modules and I hope that this might add something useful. Something else to do research in, I suppose |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Aug 09, 2014 5:23 am Post subject: |
|
|
| alienjon wrote: | | Any suggestions? Preferably an AC adapter that could connect to the 5ghz band? |
alienjon ... I'd recommend anything with the Atheros chipset. The QCA988x family is 802.11ac and is supported by the ath10k driver (though I'm not aware of any USB devices with this chipset, they seem to be PCIe). Actually, I see this is firmware encumbered so perhaps not such a good idea. Second on the list would be Intel, but again I'm not sure there are 802.11ac USB devices with this chipset (which btw, is also firmware encumbered).
| alienjon wrote: | | If this is in regards to the rt73 adapter, it's definitely not related to ndiswrapper, as there is reasonable (though possibly old) support for this specific chipset. I'm using rt73usb, rt2x00usb, and rt2x00lib modules for this adapter. Typically works well, but I'm increasingly having this issue come up (it's happened on and off since I installed Gentoo most recently on my compute). The error message doesn't say much, though, as a google search will only return results 2+ years old and nothing that seems to be related to what I have for a setup. I enabled additional debugging messages in the kernel for the rt73 modules and I hope that this might add something useful. Something else to do research in, I suppose :-) |
Sorry, I'd read that as the same card/driver ... "on and off" issues tend to be atributable to environment (weather, radio interference, etc, etc) ... post the error and other details (ie, add '-d -f /var/log/wpa_supplicant.log' to wpa_supplicant_wlan0= in /etc/conf.d/net).
best ... khay |
|
| Back to top |
|
|
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
| Posted: Sat Aug 09, 2014 1:53 pm Post subject: |
|
|
I don't necessarily mind using a non USB adapter. What do you mean by 'firmware encumbered', though? Do you mean that it's heavy in resources/slower firmware? I'll have a look around the interwebs and see what I can find.
| khayyam wrote: | | "on and off" issues tend to be atributable to environment (weather, radio interference, etc, etc) ... post the error and other details (ie, add '-d -f /var/log/wpa_supplicant.log' to wpa_supplicant_wlan0= in /etc/conf.d/net). |
I've actually had that line (-dd, actually) added to /etc/conf.d/net since I started this whole process. I've started that adapter and cleared out the log, so that I'll have whatever it's displaying if/when it happens next (it'll be a bit of a waiting game, though, as it doesn't happen all the time and seemingly randomly...)
Lastly, it occurred to me that I've also been making an assumption with everything in this thread - something that you had noted earlier, at one point - the naming of my adapters. I'd followed the instructions in the Gentoo handbook and decided to name my adapters wifi0 (the older, though working from the beginning, adapter using rt73usb) and wifi1 (which is the new AC adapter that is the main focus of this thread). I configured them by MAC address in the udev rules file (the output of which is below). The assumption that I've made is that this is setup appropriately. While I believe this to be the case, could this (or something wrong in this file) be messing up with the adapters?
| cat /etc/udev/rules.d/76-net-name-use-custom.rules: | # Use the ID_NET_NAME_MAC as the ID_NET_NAME_PATH can change (though old ones are provided for reference)
SUBSYSTEM=="net", ACTION=="add", ENV{ID_NET_NAME_MAC}=="wlx00fd0791acad", NAME="wifi0"
SUBSYSTEM=="net", ACTION=="add", ENV{ID_NET_NAME_MAC}=="enxc404153cd8f2", NAME="wifi1"
# I'm preferring the ID_NET_NAME_MAC because the ID_NET_NAME_PATH was changing if I changed the USB plug.
#SUBSYSTEM=="net", ACTION=="add", ENV{ID_NET_NAME_PATH}=="wlp6s0u2", NAME="wifi0"
#SUBSYSTEM=="net", ACTION=="add", ENV{ID_NET_NAME_PATH}=="enp6s0u1", NAME="wifi1" |
|
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Aug 09, 2014 6:20 pm Post subject: |
|
|
| alienjon wrote: | | What do you mean by 'firmware encumbered', though? Do you mean that it's heavy in resources/slower firmware? |
alienjon ... I mean that in order to function it requires firmware. This firmware is provided by the vendor and so (often) closed. ath5k and ath9k both function without firmware, so the driver is responcible for all functionality, if something doesn't work it can be debuged, etc, with firmware this becomes far more difficult.
| alienjon wrote: | | [...] The assumption that I've made is that this is setup appropriately. While I believe this to be the case, could this (or something wrong in this file) be messing up with the adapters? |
I don't use udev, having switched to mdev once udev merged with systemd. If you want to know how udev works then you need only search the forums, its probably the primary subject for support issues.
best ... khay |
|
| Back to top |
|
|
alienjon
Veteran
Joined: 09 Feb 2005
Posts: 1709
|
| Posted: Sun Aug 10, 2014 4:07 pm Post subject: |
|
|
| khayyam wrote: | | alienjon ... I mean that in order to function it requires firmware. This firmware is provided by the vendor and so (often) closed. ath5k and ath9k both function without firmware, so the driver is responcible for all functionality, if something doesn't work it can be debuged, etc, with firmware this becomes far more difficult. |
I see. The way you phrased your other post ("Actually, I see this is firmware encumbered so perhaps not such a good idea") made me think that you were indicating this to be a downside for the atheros cards. But the link you provide notes:
| Quote: | | A major difference from ath9k is that there's now a firmware and that's why we had to implement a new driver. |
So I'm thinking that the ath9k would be a good option without worrying about firmware. I'll need to see if this covers ac technology, though. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
