# [Re-opened] WiFi not working



## natharran (Sep 15, 2014)

Hi guys,

I need your help with connecting my laptop to my home WiFi. I read the handbook section and I believe I set everything correctly but for some mysterious reason it still doesn't work.

Steps I took:

Configured my device in /etc/rc.conf

```
wlans_ath0="wlan0"
ifconfig_wlan0="WPA inet 192.168.1.6 netmask 255.255.255.0 ssid daidalos"
wpa_supplicant_enable="YES"
```
Restarted netif and checked that wlan0 exists with correct parameters:


```
wlan0: flags=8c43<UP,BROADCAST,RUNNING,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu 1500
	ether 24:0a:64:94:cf:7f
	inet6 fe80::260a:64ff:fe94:cf7f%wlan0 prefixlen 64 scopeid 0x4 
	inet 192.168.1.6 netmask 0xffffff00 broadcast 192.168.1.255 
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
	media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
	status: no carrier
	ssid daidalos channel 14 (2484 MHz 11b)
	regdomain 96 indoor ecm authmode WPA1+WPA2/802.11i privacy MIXED
	deftxkey UNDEF txpower 20 bmiss 7 scanvalid 60 wme burst
	roaming MANUAL
```

Loaded if_wi with `kldload` (the rest of the drivers listed in the handbook is part of my kernel so `kldload` fails with "file exists" - if_ath, wlan_wep, ... )

Created /etc/wpa_supplicant.conf manually. When it didn't work I tried two utilities to do this for me - first I tried wpa_gui but that didn't even recognize the wlan0 and it didn't load anything from the .conf file, so I tried wifimgr. That did, indeed, find the "daidalos" network with strong enough signal. So I deleted the wpa_supplicant.conf file and created a new one via wifimgr. It crashes every time I want to change the settings with 
	
	



```
cannot reset interface wlan0 - exit status 1
```
 but at least it creates the .conf file:

```
# /etc/wpa_supplicant.conf written by wifimgr(8)
network={
	ssid="daidalos"
	bssid=cc:5d:4e:4d:0a:f8
	key_mgmt=WPA-PSK
	proto=RSN
	psk="mypassword"
}
```
which is basically the same that I created manually (the only new line is the "bssid").

Started new wpa_supplicant instance via `wpa_supplicant -s -B -i wlan0 -c /etc/wpa_supplicant.conf` (which is exactly what wpa_supplicant_enable="YES" does).

Deleted current default route (because it stated my ethernet interface) and set a new one: `route add default 192.168.1.1 -ifp wlan0` so the `netstat -r` reads:

```
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            192.168.1.1        UGS         0      460    wlan0
localhost          link#3             UH          0        4    lo0
192.168.1.0        link#2             U           0     5367    re0
192.168.1.3        link#2             UHS         0       29    lo0
192.168.1.6        link#4             UHS         0        0    lo0

Internet6:
Destination        Gateway            Flags      Netif Expire
::                 localhost          UGRS        lo0
localhost          link#3             UH          lo0
::ffff:0.0.0.0     localhost          UGRS        lo0
fe80::             localhost          UGRS        lo0
fe80::%re0         link#2             U           re0
fe80::da50:e6ff:fe link#2             UHS         lo0
fe80::%lo0         link#3             U           lo0
fe80::1%lo0        link#3             UHS         lo0
fe80::%wlan0       link#4             U         wlan0
fe80::260a:64ff:fe link#4             UHS         lo0
ff01::%re0         fe80::da50:e6ff:fe U           re0
ff01::%lo0         localhost          U           lo0
ff01::%wlan0       fe80::260a:64ff:fe U         wlan0
ff02::             localhost          UGRS        lo0
ff02::%re0         fe80::da50:e6ff:fe U           re0
ff02::%lo0         localhost          U           lo0
ff02::%wlan0       fe80::260a:64ff:fe U         wlan0
```

The result - no connections whatsoever (they are enabled in ipfw by the way). Searching the web didn't help. Some time back I managed to make this WiFi work but I don't remember how I did it (it contained all the aforementioned steps but apparently something else, too).

I'll appreciate any advice guys, thanks a lot.


----------



## wblock@ (Sep 15, 2014)

*Re: WiFi not working*

if_wi() is a driver for old wireless hardware, not relevant to anything shown.

Mixing the static configuration with wpa_supplicant() might be a problem.  Does the access point supply DHCP?  If so, make this all a lot easier:

/etc/rc.conf

```
wlans_ath0="wlan0"
ifconfig_wlan0="WPA SYNCDHCP"
```

/etc/wpa_supplicant.conf

```
network={
   ssid="daidalos"
   psk="mypassword"
}
```


----------



## natharran (Sep 15, 2014)

*Re: WiFi not working*



			
				wblock@ said:
			
		

> if_wi() is a driver for old wireless hardware, not relevant to anything shown.
> 
> Mixing the static configuration with wpa_supplicant() might be a problem.  Does the access point supply DHCP?  If so, make this all a lot easier:



Thank you for answering. The access point doesn't supply DHCP (I wouldn't try to configure a static address if it did). However, I don't think this is the problem because I managed to make this work some time ago (meaning having a static configuration + wpa_supplicant). I just can't recall what exactly the catch was.


----------



## wblock@ (Sep 15, 2014)

*Re: WiFi not working*

In that case, don't specify the SSID in /etc/rc.conf, let that come from /etc/wpa_supplicant.conf.

Make sure the radio is not disabled with an external switch, keyboard function key, or in the BIOS.  `# ifconfig wlan0 up list scan` should show at least your wireless network, and probably others also.


----------



## natharran (Sep 17, 2014)

*Re: WiFi not working*



			
				wblock@ said:
			
		

> In that case, don't specify the SSID in /etc/rc.conf, let that come from /etc/wpa_supplicant.conf.



Thanks again for your patience . But I just found out it doesn't matter whether the SSID is or isn't in rc.conf. What does matter is whether the SSID is or isn't hidden. It seems that something (I'm guessing it's either wpa_supplicant() or ifconfig()) has trouble handling hidden SSIDs. I tried what you suggested and the connection worked for a few minutes but then it died. So I set my SSID to be visible and now it works for both cases (SSID un/defined in rc.conf).

Although I now probably should mark this thread as solved I would like to know more about this issue - specifically if it is a known bug. Or should I report it?

Thanks again.


----------



## ljboiler (Sep 17, 2014)

*Re: WiFi not working*

According to wpa_supplicant.conf(), you need to add 





> scan_ssid=1


 to your network definition if your access point is hidden.


----------



## natharran (Sep 17, 2014)

*Re: WiFi not working*



			
				ljboiler said:
			
		

> scan_ssid=1



Thank you. It seems this was the problem. The connection to the hidden network is now working fine. I wondered why wifimgr didn't add this line automatically so after a few tries I found out that if the SSID is specified in rc.conf() the wifimgr sees the network as if it wasn't hidden at all. Therefore, it doesn't add the critical line to the wpa_supplicant.conf(). When I added the network as hidden the line was there. Of course, had I read the man page well enough this wouldn't have happened.

So it's solved and thank you very much for your advices guys.


----------



## wblock@ (Sep 17, 2014)

*Re: [SOLVED] WiFi not working*

"Hidden" SSIDs are an ongoing problem.  Generally, they do not do what people want for security, and only make connecting more difficult for honest users.  I actually thought about mentioning that, but you did not say you were using such a setup.


----------



## kpa (Sep 17, 2014)

*Re: [SOLVED] WiFi not working*



			
				wblock@ said:
			
		

> "Hidden" SSIDs are an ongoing problem.  Generally, they do not do what people want for security, and only make connecting more difficult for honest users.  I actually thought about mentioning that, but you did not say you were using such a setup.



Yeah, there's nothing hidden about "hidden SSIDs", the SSIDs are broadcast in cleartext everytime traffic gets transmitted between the client and the supposedly hidden access point.


----------



## natharran (Sep 17, 2014)

*Re: WiFi not working*



			
				kpa said:
			
		

> Yeah, there's nothing hidden about "hidden SSIDs", the SSIDs are broadcast in cleartext everytime traffic gets transmitted between the client and the supposedly hidden access point.


Ok, thank you, I expected the hidden SSID to be transmitted encrypted after the AP is asked for a connection but apparently this is not the case.

However, the reason I reopened this thread is that issues about wifi continue. It's incredibly slow (ping response from the internet 20 times longer than via ethernet device) and it keeps dying every other minute no matter whether the SSID is or isn't hidden. I also have two other operating systems at this laptop and none of them has this issue so it must either be something about my setup or I don't know.

Any ideas?
Thank you.


----------



## ondra_knezour (Sep 17, 2014)

Regarding the ath(4) device, following page on the wiki may be of some interest 
https://wiki.freebsd.org/dev/ath%284%29/Debugging


----------



## natharran (Sep 18, 2014)

ondra_knezour said:
			
		

> https://wiki.freebsd.org/dev/ath%284%29/Debugging


Thank you, I'll read it when the time allows it (probably tomorrow) and I'll past anything that might be of importance here.


----------



## natharran (Sep 18, 2014)

Hi again,
I followed this guide and I set some of the parameters suggested there and it seems it helped. At least the pings no longer take 20 times more time and it SEEMS to be stable so far. Here are some parameters from my sysctl.conf() if you're interested:

```
net.inet.ip.redirect=0
kern.random.sys.harvest.ethernet=0
kern.random.sys.harvest.point_to_point=0
kern.random.sys.harvest.interrupt=0
net.inet.raw.maxdgram=16384
net.inet.raw.recvspace=16384
net.route.netisr_maxqlen=2048
```
I'm not sure which of them is THE ONE (or if more of them are needed). I'll keep testing it for a while and if it proves reliable enough I'll mark this thread solved (again ).


----------



## natharran (Sep 18, 2014)

Ok, it is stable (I hope) - meaning it doesn't die for no obvious reason. But the performance gets really bad if I get "too far" from the AP. But next room shouldn't be "too far". Pings vary from 5 to 200 ms. When I'm "near" or I use ethernet interface they vary from 5 to 10 ms (mostly 5). I'm guessing it could be caused by wifi transmitting performance settings but I didn't find any way to increase it. I ran `sysctl -a | grep ath` but I wasn't able to determine the correct parameter. Since there is no such issue in my Slackware Linux installation (the same laptop) I expect it is caused by some default limitation in FreeBSD.
Could you please tell me how I can test this?
Thanks.


----------



## ondra_knezour (Sep 18, 2014)

The `ifconfig wlan0` output in "working" and "less working" conditions may help in debugging.

Try `ifconfig wlan0 regdomain etsi country cz txpower 30`. Almost every settings to the interfaces (except some driver debugging tools and HW initialization during driver loading) are done using the ifconfig(8) command. Check its manual page, its worth that time.


----------



## natharran (Sep 19, 2014)

Hi and thank you for replying,
the `ifconfig wlan0` output for both working and "less working" cases is the same (checked with diff()):

```
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	ether 24:0a:64:94:cf:7f
	inet 192.168.1.5 netmask 0xffffff00 broadcast 192.168.1.255 
	inet6 fe80::260a:64ff:fe94:cf7f%wlan0 prefixlen 64 scopeid 0x4 
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
	media: IEEE 802.11 Wireless Ethernet MCS mode 11ng
	status: associated
	ssid daidalos channel 1 (2412 MHz 11g ht/40+) bssid cc:5d:4e:4d:0a:f8
	regdomain ETSI country CZ indoor ecm authmode WPA2/802.11i privacy ON
	deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 7 scanvalid 60
	protmode CTS ampdulimit 64k ampdudensity 4 shortgi wme burst
	roaming MANUAL
```
That's after running `ifconfig wlan0 regdomain etsi country cz txpower 30`. I also tried to set higher txpower but it remains at 30 so that appears to be the maximum possible power.
However, the result is still the same - pings go astronomical just in a next room.
I don't know if it is of any relevance here but these are outputs from my Linux installation:
`ifconfig wlan0`:

```
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.4  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::260a:64ff:fe94:cf7f  prefixlen 64  scopeid 0x20<link>
        ether 24:0a:64:94:cf:7f  txqueuelen 1000  (Ethernet)
        RX packets 9  bytes 1537 (1.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9  bytes 1119 (1.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
```
`iwconfig wlan0`:

```
wlan0     IEEE 802.11bgn  ESSID:"daidalos"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: CC:5D:4E:4D:0A:F8   
          Bit Rate=1 Mb/s   Tx-Power=15 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=70/70  Signal level=-30 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:1  Invalid misc:1   Missed beacon:0
```
So the transmitting power is the same but this issue doesn't occur in Linux. But what else could be the cause?


----------



## ondra_knezour (Sep 19, 2014)

Either I am getting blind or I don't see RSSI value, what about `ifconfig ath0`?

You are connected on 1 Mbps on Linux, which may be either power down because of really small data transfers (typically only couple of pings) or high level of interferences from other sources. However, received signal level -30 dBm is pretty strong, I would considering lowering TX power would it be longer point to point link with directional antenaes, because such power level can easily over-excitate input amplifier, which leads to signal distortion.

So, what would I do next - try to scan for another networks, select some channel with lowest count and weakest signal (bear in mind that 2,4 GHz channel overlaps, 3 is safe distance, so if you have interference on channel 1, closest one which can be considered clean is channel 4), move your AP little, even 10 - 20 cm may make difference, especially if placed at the corner of the room, try to decrease TX power on both sides and try to force low connection mode/speed to test if round trip value would get better.

Sorry for only general advices, but I don't have any FreeBSD installation with wireless hardware handy.


----------



## natharran (Sep 25, 2014)

Hi,
sorry for a long delay, I didn't get to this until now.
There isn't any RSII value for `ifconfig ath0` either:

```
ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 2290
	ether 24:0a:64:94:cf:7f
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
	media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng
	status: associated
```
I tried changing channels but for some reason after typing `ifconfig wlan0 channel <anychannel from 1 to 13>` it always stays on channel 1. Not even specifying the channel in rc.conf helps. I also tried changing 11b/g/n modes via rc.conf() to no avail (the mode changes but it doesn't help).
I did some more research and found some very old thread (2007) (not here) where someone was describing the very same problem with Atheros wifi on FreeBSD (6 I think) but there wasn't any solution there. Other than that I didn't find anything.

EDIT: I don't know if it is of any importance but here is the `dmesg -a | grep ath`:

```
ath0: <Atheros AR9485> mem 0xf7a00000-0xf7a7ffff irq 18 at device 0.0 on pci3
ath0: RX status length: 48
ath0: RX buffer size: 4096
ath0: TX descriptor length: 128
ath0: TX status length: 36
ath0: TX buffers per descriptor: 4
ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries
ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries
ath0: [HT] enabling HT modes
ath0: [HT] enabling short-GI in 20MHz mode
ath0: [HT] 1 stream STBC receive enabled
ath0: [HT] 1 RX streams; 1 TX streams
ath0: AR9485 mac 576.1 RF5110 phy 1153.4
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000
ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/dovecot /usr/local/lib/ffmpeg0 /usr/local/lib/mysql /usr/local/lib/nss /usr/local/lib/qt4 /usr/local/llvm33/lib
32-bit compatibility ldconfig path: /usr/lib32
ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping
ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping
ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping
ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping
ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping
ath0: ath_reset_grablock: didn't finish after 10 iterations
ath0: ath_reset_grablock: warning, recursive reset path!
ath0: ath_reset: concurrent reset! Danger!
ath0: ath_reset_grablock: didn't finish after 10 iterations
ath0: ath_reset_grablock: warning, recursive reset path!
ath0: ath_reset: concurrent reset! Danger!
ath0: ath_reset_grablock: didn't finish after 10 iterations
ath0: ath_reset_grablock: warning, recursive reset path!
ath0: ath_reset: concurrent reset! Danger!
ath0: ath_raw_xmit: sc_inreset_cnt > 0; bailing
ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping
ath0: ath_raw_xmit: sc_inreset_cnt > 0; bailing
ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping
ath0: ath_reset_grablock: didn't finish after 10 iterations
ath0: ath_reset_grablock: warning, recursive reset path!
ath0: ath_reset: concurrent reset! Danger!
ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping
ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping
ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping
```


----------



## natharran (Sep 29, 2014)

Ok, since it seems nobody has the answer for this I'll have to rely on my Linux installation if I need wireless.

Thanks for your advices guys.


----------



## ondra_knezour (Sep 30, 2014)

Try to ask at the FreeBSD wireless mailing list, there are developers hanging around, including Adrian Chadd, who did many work on the Atheros wireless support in last years and who is usually very supportive.

https://lists.freebsd.org/mailman/listi ... d-wireless


----------



## natharran (Oct 3, 2014)

Thanks, I'll do it.


----------



## adrian@ (Oct 17, 2014)

Hi!

Erm, you should file a bug. https://bugs.freebsd.org/submit/

I've started addressing some of the kinks in the AR9485 support on some chipsets - apparently there's some, erm, "options" that the driver didn't know about. They're in FreeBSD-HEAD, so I'd appreciate it if you can try out the latest FreeBSD-HEAD and provide me with feedback.

Thanks!


-adrian
(WiFi / ath maintainer)


----------

