The guide is not only blind, he also drinks on Fridays
While you're preparing for a constructive evening, I'm out killing neurons and growing fat. So I've prepared this post in advance.
My goal is that we have the same config. What works here should work there. Now you're using a Pi 2 so that's perfect. I also believe your issue comes from one single diff, so I would try to verify/close each possible difference, reboot and try hostapd each time.
So let's try prioritize and limit the number of reboots towards a working AP. This is what I suggest:
- Use a potentially working hostapd.conf and interfaces file.
- Run up to date kernel and wifi module (I re-did an update + upgrade around 13:00 today, all is fine.)
- Run an hostapd binary that is built for that new kernel
- A normal network environment (in case your router doesn't like something and rejects your Pi)
1 - Hostapd.conf and interfaces file:
I am running the hostapd.conf file you copy-pasted to the board when we started debugging the thing. Last line of the file reads "ht_capab=[SHORT-GI-20][SHORT-GI-40][HT40+][DSSS_CCK-40][MAX-AMSDU-7935]" without carriage return (which is *not* right, but it works for me anyway.)
It's straight off your post, it still reads country=GB.
Interfaces, I am using the /etc/network/interfaces file specified
in this post, step 3. Note it relies on dhcp, hence on your router.
I guess you're there already, so no need to reboot and try a connect.
2 - Kernel update. Yes something is amiss here, as we said earlier try to re-execute Step 11 in
this post.
After a reboot, you should see this (note 8192cu module size has changed):
Code: Select all
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 4.4.11-v7+ #888 SMP Mon May 23 20:10:33 BST 2016 armv7l GNU/Linux
pi@raspberrypi:~ $ lsmod | grep 8192
8192cu 519156 0
3 - A working hostapd. Since you built hostapd-rtl on 4.4.9, I think there is a good chance it won't be running after updating the kernel.
Each running process has its own number, "init" is process 1, and in this trace, hostapd was process #947. I voluntarily killed it to show you what pidof would report is hostapd had died: it would return empty.
Code: Select all
pi@raspberrypi:~ $ pidof hostapd
947
pi@raspberrypi:~ $ sudo kill -9 947
pi@raspberrypi:~ $ pidof hostapd
pi@raspberrypi:~ $
If you have a PID# returned by pidof, you can try your AP. If it fails then download mine (next paragraph).
If "pidof hostapd" returns empty, download my hostapd-rtl binary;
Link is in this post, install it instead of yours, and reboot.
If you're now running my binary and the AP doesn't work or the hostapd-rtl process doesn't run... Uninstall hostapd-rtl, put your hostapd.conf aside, locate to the adequate directory with "cd /usr/src" and reexecute
this post from step 3 to compile your own. It's not going to look exactly the same since you've built recently. But in the end, "ls -la /usr/src" should show a current date for hostapd-rtl files, esp. "hostapd-rtl_2.4-4_armhf.deb". Install it, put back your hostapd.conf file in place, reboot, try the AP.
In the end, you're running your own hostapd-rtl, recompiled for this kernel, the process runs but the AP still doesn't work ok... Let's check networking, then.
3 - Checking network status
Above we've verified the network conf files are ok. Now perhaps something is doesn't click within your network. It might pertain to your router configuration, or to devices attached to the Pi. Here is what a working condition looks like (edited, comments below):
Code: Select all
pi@raspberrypi:~ $ ifconfig
br0 Link encap:Ethernet HWaddr 74:da:38:xx:xx:xx
inet addr:172.17.255.96 Bcast:172.17.255.255 Mask:255.255.0.0
inet6 addr: fe80::xxxxxxxxxxxxxxx/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:596 errors:0 dropped:0 overruns:0 frame:0
TX packets:124 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:126387 (123.4 KiB) TX bytes:17328 (16.9 KiB)
eth0 Link encap:Ethernet HWaddr b8:27:eb:xx:xx:xx
inet addr:169.254.94.218 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:813 errors:0 dropped:0 overruns:0 frame:0
TX packets:148 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:154932 (151.3 KiB) TX bytes:23826 (23.2 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:280 errors:0 dropped:0 overruns:0 frame:0
TX packets:280 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:22976 (22.4 KiB) TX bytes:22976 (22.4 KiB)
wlan0 Link encap:Ethernet HWaddr 74:da:38:xx:xx:xx
inet addr:169.254.208.132 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:416 errors:0 dropped:0 overruns:0 frame:0
TX packets:175 errors:0 dropped:2 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:19648 (19.1 KiB)
pi@raspberrypi:~ $ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.17.0.1 0.0.0.0 UG 204 0 0 br0
169.254.0.0 0.0.0.0 255.255.0.0 U 202 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 303 0 0 wlan0
172.17.0.0 0.0.0.0 255.255.0.0 U 204 0 0 br0
pi@raspberrypi:~ $ brctl show
bridge name bridge id STP enabled interfaces
br0 8000.74da38xxxxxx yes eth0
wlan0
pi@raspberrypi:~ $ brctl showmacs br0
port no mac addr is local? ageing timer
...
1 00:04:20:xx:xx:xx no 14.14 <- some wired device on my LAN (local no)
2 74:da:38:xx:xx:xx yes 0.00 <- the Edimax adapter (local yes, port 2)
1 b8:27:eb:xx:xx:xx no 0.20 <- another Pi on my LAN :)
1 b8:27:eb:xx:xx:xx yes 0.00 <- the ethernet adapter (local yes, port 1)
...
pi@raspberrypi:~ $
- Your IPs will differ, I use 172.17.0.0/16 here, you're using another network probably 192.168.1.0/24 or something like that.
- You can disregard 169.254.x.x addresses. The OS is giving APIPA (aka auto-IPv4-local link, aka zeroconf) addresses to each interface so that the machine can be reachable even in absence of a DHCP service.
- In the output to route, you must see the default route 0.0.0.0 belonging to br0 and going through your router IP (Gateway could read something like 192.168.1.1). From the Pi you must be able to access the Internet.
- The bridge must show both local networking cards wlan0 and eth0 "inserted".
- Asking "showmacs br0" will list all networking cards the bridge knows about. There are our 2 local interfaces, and the MAC addresses of all the devices present on your network (do *not* post that on this forum!). The list should be surprisingly long. If you do not see non-local devices, something is amiss with the bridge.
If you don't get something like this environment, perhaps look at your router, check network cables, check (again) /etc/network/interfaces... If you've fixed something, reboot and try the AP.
If it still doesn't work, we could examine wpa_supplicant stuff and hardware differences for the Edimax wifi thingy and the Pi itself. But I'm afraid that would be looking for an explanation, not for a solution...
Good luck!
I'll check when home and get it done...
