Automatic MAC Cycling Not Functioning
Opened this issue · 3 comments
I've spent a few hours trying to configure PiPass for full functionality, and can consistently receive StreetPass notifications. The issue I have lies in the automatic MAC cycling and the "Advance" feature included in PiPass.
I receive the following error messages according to the PiPass logs:
2015-12-04 23:34:16,105 - main - INFO - PiPass is now running.
2015-12-04 23:34:20,680 - main - INFO - Spoofing as 40:53:50:4F:4F:7A on attwifi ( Extended Mac ) for 5 minute(s).
2015-12-04 23:39:28,420 - main - WARNING - A possible incompatible hostapd WiFi chipset has been detected.
2015-12-04 23:39:28,421 - main - ERROR - Unable to change the MAC address of the WiFi adapter.
2015-12-04 23:39:28,424 - main - INFO - PiPass has been shutdown with an error.
For a little background information, I am using the CanaKit recommended in the hardware section of you documentation:
http://www.amazon.com/gp/product/B008XVAVAWpsc=1&redirect=true&ref_=oh_aui_detailpage_o00_s00
I did a little research on the included dongle, and it appears to be using the Ralink 5370 Chipset according to the CanaKit product description:
http://www.canakit.com/raspberry-pi-wifi.html
I wasn't sure if this is merely a compatibility issue with the CanaKit dongle, or if I neglected to configure something correctly. To reiterate one point, I can absolutely get StreetPass notifications by manually stopping/starting PiPass, I am just unable automate.
I'm sure there's information that I'm failing to include for you, so please let me know if there's anything I can provide.
With the help of a friend, I found a workaround for this specific issue via crontab. This just emulates someone manually stopping\starting PiPass in specified time increments.
For starters, I did this all as root, as permissions were bothering me, though I'm sure sudo could be employed.
You will need to know where "php" is installed, but for me on a fresh image of Raspbian, it was located at /usr/bin/php. You will also need to know where the "assets" folder for PiPass is located, which should be /var/www if you're using the default installation methods listed by Matthew. If the paths differ, you will have to change them instead of using mine as listed in the following instructions.
Once you've located the above mentioned do the following:
- Type "sudo crontab -e"
- You may have to select an editor. I used VIM basic, but just following the onscreen prompt.
- If you're unfamiliar with VIM, and choose to use it, you may need to Google how to use it. it's slightly more involved than a Windows-based text editor.
- At the bottom of the file type the following:
- 0-58/5 * * * * /usr/bin/php /var/www/assets/php/stop.php
- 1-59/5 * * * * /usr/bin/php /var/www/assets/php/start.php
- Make sure to save the file.
The above steps will emulate someone stopping and then starting PiPass in 5 minute increments. Depending on when you make the change, it could 5 minutes before you start seeing any log messages, so give it about 5 minutes or so for testing.
I used the 5 minute increment for testing, but I may switch to 30 minute increments, to do this just use the following in Crontab instead:
- 0-58/30 * * * * /usr/bin/php /var/www/assets/php/stop.php
- 1-59/30 * * * * /usr/bin/php /var/www/assets/php/start.php
Finally, PiPass will still attempt to use whatever you have set for "StreetPass Cycle Time," so make sure you set it for something higher than the increment specified in Crontab. I personally use 60 mintues.
So I had a similar issue going on with my TL-WN722N (ar9271 chipset) on a Raspberry Pi 2 after a fresh manual (a la the autoinstaller script) installation on a fresh Raspbian (Jessie Lite) install. Startup was fine, connection was fine, advancing killed the service. Trying to look over some logs, /var/log/messages was spitting out the following after each attempted advance:
localhost kernel: [61502.241772] device wlan0 left promiscuous mode
localhost kernel: [61502.241946] br0: port 2(wlan0) entered disabled state
localhost kernel: [61503.506205] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Sounded like the device wasn't coming up fast enough?
I tried manually editing/restarting hostapd.conf/hostapd, and apparently if I restarted twice, things would work just fine. The first restart would not take any change in hostapd.conf (as evidenced in ifconfig, but the second sudo service restart hostapd would make it finally take. So, I'm not sure why? Maybe something about ipv6 configuration on the network device is slowing things down?
Regardless, I didn't circumvent this problem with cron like @Novax95 managed to. Instead, throwing a little sleep timer in there, I forced a second restart shortly later. Going into the piPass.py script, I changed the line block at 428–430 to:
# Restart hostapd to ensure NETWORK_CONFIGURATION is used. Restarting hostapd will also ensure that it is running if it is currently off.
# subprocess.call() will wait for the service command to finish before moving on. subprocess.call('sudo service hostapd restart', stdout=open(os.devnull, 'w'), stderr=open(os.devnull, 'w'), shell=True)
time.sleep(5)
subprocess.call('sudo service hostapd restart', stdout=open(os.devnull, 'w'), stderr=open(os.devnull, 'w'), shell=True)
Works like a beaut now. Still throws the error after the first restart. Second one indicates the interfaces are back up again:
localhost kernel: [61502.241772] device wlan0 left promiscuous mode
localhost kernel: [61502.241946] br0: port 2(wlan0) entered disabled state
localhost kernel: [61503.506205] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
localhost kernel: [61508.430425] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
localhost kernel: [61508.432176] device wlan0 entered promiscuous mode
localhost kernel: [61509.156396] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
localhost kernel: [61509.156616] br0: port 2(wlan0) entered forwarding state
localhost kernel: [61509.156676] br0: port 2(wlan0) entered forwarding state
If I get enough spare time, I might try to find out what's mucking up the restart. I'm hoping some of you more savvy Linux'y types can use this to some advantage in potential diagnosis.
You could try my solution at issue #80 here
What it does is make it try several times to restart hostapd as it doesnt seem to always restart the first try. It also will try to rewrite the hostapd.conf file if the MAC address isn't what it is supposed to be as it seems to have a problem there too.
my installation of piPass would run for a few zones then exit out with an error but now it just keeps going and going