Trying to configure wifi AP (with VPN)

[iOS_Neil]

Morning!

At work now but can try tonight. One thing I noticed straight off - your uname - shows:

Code: Select all

root@raspberrypi:~# uname -a
Linux raspberrypi -->4.4.11-v7+ #888<-- SMP Mon May 23 20:10:33 BST 2016 armv7l GNU/Linux

Mine shows:

Code: Select all

pi@raspberrypi:~ $ uname -a
Linux raspberrypi -->4.4.9+ #884<-- Fri May 6 17:25:37 BST 2016 armv6l GNU/Linux

Is this due to the differences between my RPi 1 & your 2?

[epoch1970]

Somehow, operation 11 in the 1st part of the install, apt-get update && apt-get upgrade, did not yield the same for you as it did for me.
That is an interesting hint, because on my Pi 3s (the only model I've been using lately) I noticed improved wifi operation after upgrade. Different platform, and perhaps different versions of Raspbian. But nevertheless, a difference in kernel version is not really something we want for a 100% working recipe involving wifi...
BTW, until you fix that with the Pi 2, I think you don't need bother installing my own hostapd-rtl package: it will not run on 4.4.9, having being built for 4.4.11.

EDIT: In this message you posted the uname command output, I should have paid attention. Sorry I missed that!

[iOS_Neil]

Looking back, I think I missed the sudo apt-get upgrade I'll check when home and get it done...

[epoch1970]

Damn, you're in the middle of a storm, and you've put your trust in a guide that's blind
I'm going to review *your* posts more carefully until next time...

[iOS_Neil]

Ha ha, I just need to concentrate a bit more....I can only imagine how frustrating it must be for you that you've done everything right and I'm struggling because I can't follow instruction. Thanks for sticking with it

[epoch1970]

No worries. I like puzzle games (well not really but with computers I do.)
If we finally manage to fly that kite, it'll be an amazing moment

[epoch1970]

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!

[iOS_Neil]

Hello!

Thanks for the long and detailed desciprtion! I've gone through everything that I can see again, checked all the things you've listed...And still not working It MUST be something I've done (or not done) clearly. When I got to the end and did "showmacs br0" the Pi returned

Code: Select all

pi@raspberrypi:~ $ showmacs br0
-bash: showmacs: command not found

?
I'm also wondering - if we get this running on the Pi2, would it then run on the Pi1? Ultimately I'll have to give the 2 back

[epoch1970]

That's "brctl showmacs br0"
I would suppose it would work on Pi same as Pi2, but I don't really know.
There is something that I've left out until now, that would be to change the SSID name, and perhaps channel. I know your file works on my machine; but I remember your files had control characters perhaps it's better to get rid of them.
If you "cat -v some-text-file" it should print the otherwise non printable characters.

Another possibility is that your usb card is not exactly the same as mine. I think I got mine end of last year. Perhaps there is an internal design change that makes a difference. You could remove the 8192cu.conf file, reboot and see if the card works with stock options. Before we swap cards by mail

Actually, you've seen the card work on another machine, right?
EDIT: be sure to recompute the wpa_psk string if you change the SSID name.

[iOS_Neil]

That's "brctl showmacs br0"
I would suppose it would work on Pi same as Pi2, but I don't really know.
There is something that I've left out until now, that would be to change the SSID name, and perhaps channel. I know your file works on my machine; but I remember your files had control characters perhaps it's better to get rid of them.
If you "cat -v some-text-file" it should print the otherwise non printable characters.

Another possibility is that your usb card is not exactly the same as mine. I think I got mine end of last year. Perhaps there is an internal design change that makes a difference. You could remove the 8192cu.conf file, reboot and see if the card works with stock options. Before we swap cards by mail

Actually, you've seen the card work on another machine, right?
EDIT: be sure to recompute the wpa_psk string if you change the SSID name.

Hi,

ok, tried everything above and still the same...Only thing I didn't do was to remove the 8291.conf file as wasn't sure where it is? Failing that, I think first thing I'm going to do is reformat the card and start right from the top - but I'll create a word doc or something that has everything I need to do from the top to the bottom and work my way down, crossing off as I go...That would have to be next week though

Thanks,
Neil.

[iOS_Neil]

I had a thought...Don't know if it's feasible but what if you img'd your card, uploaded, I downloaded & wrote to my card? Is that an idea?

[epoch1970]

Excellent idea!
I have to shrink (16gb -> 8gb) before I take the image. What file size will Dropbox allow? Even compressed it will be over 2GB I think.

[iOS_Neil]

Google says Dropbox allows up to 20gb?

[epoch1970]

Hi, there!
I have now uploaded the accesspoint_of_aargh.img.gz image file to my Dropbox.

After downloading, you want to:

1. "gzip -d accesspoint_of_aargh.img.gz": this will expand the file from ~2 GB to ~16 GB. I did not truncate the dd transfer; as far as you are concerned, everything past the 1st 5 GBs in this file is garbage or zeros.
2. Verify the MD5 sum of the file to see if it was corrupted during transfers. On linux: "md5sum accesspoint_of_aargh.img", OSX: "md5 accesspoint_of_aargh.img", Win: dunno. This will take some time! You must see this signature: "bd8c0fc94f688a3dd65388390292bbe8"
3. Transfer "accesspoint_of_aargh.img" to your SD with (I suppose) the dd command as you'd do for a raspbian install image. I think dd will complain it has run short of space on the destination SD, that's no problem.
4. Install the SD and boot the Pi. You should see AP "worky". Try connecting.

Now let's imagine we have touch-down To make this system really yours:

1. To login use "pi" (no quotes) as password for user pi. Change it.
2. If you look at the system you'll see the root partition uses 3.8 GB out of 5 GB. You can run raspi-config and expand the root partition to max available size.
3. You should run raspi-config and change wifi country from FR to yours.

I have used the image file to burn a new 16 GB SD. The process above should work as is and yield a bootable image.

When you've verified you have a good download, drop me a line and I will remove the image file. No need to distribute soon-to-be-obsolete, untrusted binary images to the entire world.

Good luck!

[iOS_Neil]

Downloaded and perfect match on the checksum!

Will try to get the card written tonight and will let you know asap

[iOS_Neil]

Hmmm...Unzipped the file, it came out at around 15gb. When I try to write it I get an error that my card isn't big enough. I'll buy another card tomorrow

Edit: Can examine the img file and currently extracting the 5gb

[epoch1970]

Sorry I did not truncate the file. I thought dd would surf over the short write issue, didn't try to simulate that condition, and obviously I was wrong.
I took a copy of the image, renamed it to "accesspoint_of_aargh_6GB.img", then ran the following command from the directory where the file was located:

Code: Select all

sudo dd if=/dev/null of=./accesspoint_of_aargh_6GB.img seek=1 bs=6442450944

It runs very fast, and truncates the file to 6GB (a good safety margin since the FS is ~5GB).
Then I wrote this image to my 16GB SD and got a running system. This is what "sudo cfdisk /dev/mmcblk0" shows on the running Pi:

Code: Select all

                                              Disk: /dev/mmcblk0                                              
                             Size: 14.9 GiB, 15931539456 bytes, 31116288 sectors                              
                                      Label: dos, identifier: 0x05b8256f                                      
                                                                                                              
    Device              Boot              Start          End      Sectors      Size     Id Type               
>>  Free space                             2048         8191         6144        3M                           
    /dev/mmcblk0p1                         8192       137215       129024       63M      c W95 FAT32 (LBA)    
    /dev/mmcblk0p2                       137216     10881700     10744485      5.1G     83 Linux              
    Free space                         10883072     31116287     20233216      9.7G

(as you see, massive free space block at the end, since my block device is 16GB)

Try doing the same or simply download accesspoint_of_aargh_6GB.img.gz before buying a 16GB SD: there is no guarantee your 16GB will be exactly the same as mine, so you might still encounter a short write error for just a few bytes.

Code: Select all

$ md5 accesspoint_of_aargh_6GB.img 
MD5 (accesspoint_of_aargh_6GB.img) = dea62d39a5debbbb9f0e83e63039bf2b

[iOS_Neil]

!!!!!!!!!
Guess who's connected to 'worky' and posting this reply whilst connected?!!

It's alive, ALIVE!

Thank you SO much for sticking with me to get it working. I'm so pleased right now (and the wife is off my back )

Now...To look at VPNs

[epoch1970]

Well done!! Whoohooo!!!

(What are your expectations w.r.t. VPN? E.i. Doing what from where to where?)

[iOS_Neil]

Regards VPN, all I'd like to be able to do is connect my iPhone / Firestick to avoid geoip restrictions...I'm happy to use a paid solution rather than free but currently have a free trial with one that uses OpenVPN...

EDIT: I should have said...Its working on my Pi B which is fantastic!

[epoch1970]

EDIT: And now the Pi B... I never doubted you

OpenVPN is a valuable piece of software, it's been there for a while and works well.
Circumventing geoip restrictions mean going through the tunnel and at the other end, go to the Internet. Which means:
- You are not supposed to do this (I guess you know that),
- You need good throughput on your end (your ISP connection), otherwise everything will be slow as molasses,
- Unless you have an uncle in America (or whatever) you'll need to go with a for-pay service that provides an endpoint in the area of your choice,
- This third party will "see" everything you do (same as your ISP does without the VPN) since you're using his network.

You've not described the role of the Pi, but from the title of the thread, I imagine you'd like the Pi to connect, and have the iOS or Amazon clients use that tunnel connection. It's difficult to say exactly what the VPN provider will accept (and personally I don't use VPNs to hide my *ss).
If its ToS allow to connect a subnet, then the Pi could work as a gateway (changing br0 to use a static configuration, defining NAT from br0 to the VPN-created interface, changing the default route pointing to your router to one pointing to the VPN-created interface --in case the VPN software did not handle that.) OpenVPN runs well on the Pi.
If the VPN provider allows only a single client at a time, then trying to work around this would be a) in breach of their ToS, b) extremely tedious.

All in all, I think this looks like a routed VPN configuration. This is the most common kind, I believe you could find some how-to's (including on this forum). The only twist in your case is that when you read "eth0", you should read "br0" instead.

However. If you could run the VPN software on the iOS and Firestick clients you wouldn't need to care about all that. Your clients would tunnel as they want, and the Pi would transport as it does now (only this time: an encrypted payload destined to the internet address of the VPN provider). I've never used the OpenVPN client on iOS (it does only routed VPNs, not bridged VPNs --an iOS limitation); I don't own a single Android device, let alone an Amazon set-top box.

HTH

[iOS_Neil]

Thanks for all the info, it definitely helps and gives me some interesting reading ahead

I do run a VPN on my iPhone when needed, but the FireStick has no option to run through a VPN - hence the reason I want to use the Pi. I'll post back and let you know how I get on.

Again, I'm indebted to you for all your help - I wouldn't be anywhere near the point I'm at now without it

Neil.