RaspiPass AP fails to change MACs/SSIDs

[joshbgosh10592]

Hi! Once I reboot the Pi, the AP isn't automatically started, which may be by design, which is fine. I click start AP under Admin tasks. Most of the time, it succeeds. If it doesn't for whatever reason, I just reboot the Pi using the admin tab, and it works. Until the first change. Then my 3DSs cannot connect for a while, and I'll keep connection testing to the attwifi network, and it'll fail (Error code 003-1099, "No AP in range") most of the time and randomly connect again.

I'm also not putting the fact that I'm in an apartment complex with a lot of wireless networks broadcasting... If that is the cause, how often does a 3DS attempt to reach out with a StreetPass relay?

I'm mostly concerned if this part is what's causing the failure:

1521580108.497843: Failed to create interface mon.wlan0: -95 (Operation not supported)
1521580108.507942: wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
1521580108.508492: wlan0: Could not connect to kernel driver

Here's the most recent log, after I let it change MACs the first time:

Probability manually set at 100
Wed Mar 21 08:08:27 AEDT 2018
Starting RaspiPass...
Running random check with 100% chance...
Random check passed - bringing up AP.
Closing any existing hostapd processes...
Using SSID attwifi and MAC address 4E:53:50:4F:4F:40
Changing MAC address...
Bringing up access point...
hostapd output may follow below.
1521580108.496494: Configuration file: /var/raspipass/hostapd.conf
1521580108.497843: Failed to create interface mon.wlan0: -95 (Operation not supported)
1521580108.507942: wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
1521580108.508492: wlan0: Could not connect to kernel driver
1521580108.510575: Using interface wlan0 with hwaddr 4e:53:50:4f:4f:40 and ssid "attwifi"
1521580108.717949: wlan0: interface state COUNTRY_UPDATE->ENABLED
1521580108.717968: wlan0: AP-ENABLED
1521580123.617713: 1521580123.617723: wlan0: STA GALAXY3DS IEEE 802.11: associated
1521580123.618325: wlan0: AP-STA-CONNECTED CLIENT3DS1
1521580123.618359: 1521580123.618363: wlan0: STA GALAXY3DS RADIUS: starting accounting session 5AB1784C-00000000
1521580135.462584: 1521580135.462593: wlan0: STA PIKA3DSIEEE 802.11: associated
1521580135.462880: wlan0: AP-STA-CONNECTED PIKA3DS
1521580135.462913: 1521580135.462918: wlan0: STA 7c:bb:8a:f7:fc:5e RADIUS: starting accounting session 5AB1784C-00000001
1521580151.397053: 1521580151.397064: wlan0: STA PIKA3DS IEEE 802.11: disassociated
1521580151.397166: wlan0: AP-STA-DISCONNECTED PIKA3DS
1521580173.167753: 1521580173.167763: wlan0: STA BLACK3DS IEEE 802.11: associated
1521580173.168069: wlan0: AP-STA-CONNECTED BLACK3DS
1521580173.168101: 1521580173.168105: wlan0: STA BLACK3DS RADIUS: starting accounting session 5AB1784C-00000002
1521580178.068094: 1521580178.068105: wlan0: STA PIKA3DS IEEE 802.11: associated
1521580178.068399: wlan0: AP-STA-CONNECTED PIKA3DS
1521580178.068432: 1521580178.068437: wlan0: STA PIKA3DS RADIUS: starting accounting session 5AB1784C-00000003
1521580184.026636: 1521580184.026648: wlan0: STA PIKA3DS IEEE 802.11: disassociated
1521580184.026750: wlan0: AP-STA-DISCONNECTED PIKA3DS
1521580200.099481: 1521580200.099491: wlan0: STA PIKA3DS IEEE 802.11: associated
1521580200.099794: wlan0: AP-STA-CONNECTED PIKA3DS
1521580200.099826: 1521580200.099830: wlan0: STA PIKA3DS RADIUS: starting accounting session 5AB1784C-00000004
1521580238.868265: 1521580238.868275: wlan0: STA BLACK3DS IEEE 802.11: disassociated
1521580238.868379: wlan0: AP-STA-DISCONNECTED BLACK3DS
1521580325.706423: 1521580325.706434: wlan0: STA GALAXY3DS IEEE 802.11: disassociated
1521580325.706537: wlan0: AP-STA-DISCONNECTED GALAXY3DS
1521580380.545839: wlan0: AP-STA-DISCONNECTED PIKA3DS

[fatmagic]

Getting the same thing here with a new RPi3 and 7.4 image. From my 2 days of testing, I found out that the Nintendo Relay IPs have changed. Pinchie only allows traffic through the RaspiPass that are directed to the Nintendo Relay points (which is a smart move in regards to security, considering it's an open WiFi connection). His IPTables are setup to only allow traffic for those IPs. The Relay IPs have changed since Pinchie's last update, so the current IPTables are not relevant any longer.

To test this, I disabled the firewall on the RaspiPass, and instantly I got streetpasses.

So now, I have to filter my 3DS traffic on my normal WiFi and find out what IPs it's trying to connect to, and then submit those changes to Pinchie. Or we'll just have to add it in manually (or I can try to figure out how to fork this Project and do it myself, new territory for me!).

Will keep you posted on this.

[joshbgosh10592]

I was kind of thinking that once I kept reading about it. I'm wondering if we could just MAC filter what devices connect (only allow 3DS MACs, manually added, and maybe only allow traffic to 52.x.x.x and 192.195.x.x (unless they changed that drastically...)
Unless... Can IPTables be set to only allow certain domains? That would be the easiest way, I could think, and future-proof it.

I'm trying to think of how I could assist... I have an enterprise grade switch which I can see what type of traffic is being sent, and a DD-WRT installed on a Netgear router spoofing NSPOOF connected to said switch, but I'm not sure if I can make it sniff only IP addresses entering/leaving that specific port. I could port mirror and have all traffic sent to that device to another port which I could have Wireshark running on, but I don't have another computer laying around.

[fatmagic]

Hey Josh -

Well shoot, if you could narrow down the traffic that the 3DS is pulling down while it's asleep, that would be most useful. We could then manually update the IPTables and get it working again properly, without having to drop the firewall. Here is a comment where Pinchie originally sifted his traffic for exactly this - not sure it will be helpful, but you can at least see where he was getting his info from to fix this issue a year ago.

And in regards to MAC filtering, Pinchie tried it, but it didn't work on the RPi3 (see this comment). I would imagine it's possible, but I personally don't know how to implement it.

If you can't pull it off, I can probably sift for the traffic via my corporate firewall (which I fully control). I'll just dig through the log files and see what the 3DS is hitting. Let me know if you have any success.

[joshbgosh10592]

If I had my Pi-Hole install working properly, it would be a lot easier... However, looking at the live log file (which gets insane on my network), I found this:
npdl.cdn.nintendowifi.net - 104.88.7.160
nasc.nintendowifi.net 69.25.139.139
nppl.c.app.nintendowifi.net - 52.39.19.157 and 34.208.213.200
conntest.nintendowifi.net - 69.25.139.140
l-npns.app.nintendo.net - 35.167.248.201 and 54.68.136.190

Now, most of these I found are CNAMEs, so they just point to something else, but the IPs I gave are from Pi-Hole, or a DNS lookup (via PING).
I'm not exactly sure what they use for this, but could probably just reference his post you mentioned about him sifting his traffic, and just modify the IPs of them.

[fatmagic]

Josh - I heard from Pinchie, he mentioned we can try this to track it down:

If you're proficient enough, there's a commented line in iptables preventing dropped LAN packets being logged. With that enabled and iptables re-run it should start logging the addresses it was denied to. You have to filter through a lot of garbage traffic, but with 100% probability set on the device you can get the addresses by time.

So with a bit of log watching on the RPi3, we can probably find all the addresses as well.

I also want to try the addresses you provided.

Will continue playing.

[fatmagic]

@joshbgosh10592 Been tinkering around with this more today. Getting further along. Hopefully will have this beat in a day or two.

[joshbgosh10592]

@fatmagic Awesome! I've been too busy with work to really try anything, but may be able to on Monday, if anything is still needed.

Unless @Pinchie has the list of hostnames that were resolving to the list of IPs he provided here. If he does, it would be even easier.

[ztc0611]

@fatmagic how did you disable the firewall? I wouldn't mind doing this, because I just want streetpasses.
You're a legend for coming back and fixing this!

[joshbgosh10592]

Hey @fatmagic Take a look at this.
I think, to honor @Pinchie 's wishes by making it "set it and forget it", there could be a cronjob created to run a script (or multiple scripts, because there are multiple hostnames) to change the entry in iptables.

So, then we're only stuck trying to figure out what hostnames are being used by the 3DS. The rest, we could modify/create the cronjob to run and modify it from there.

[Pinchie]

@the-mudkip You can disable the firewall with:

sudo iptables --flush

Note that the iptables rules are also present in the firewall.rules file in /raspi_secure - that file is automatically re-loaded on reboot (technically when the network interface comes back up from a down/off state)

With regards to the firewall files in the /raspi_secure directory:

• /raspi_secure/iptables.sh is the script I use to dump all the rules into iptables when I'm working on them (I personally hate reading the firewall.rules layout...). Running sudo iptables --flush follwed by sudo /raspi_secure/iptables.sh sets the rules as written in the script.
• /raspi_secure/firewall.rules is generated from an active iptables configuration by running: sudo iptables-save > /raspi_secure/firewall.rules

Unfortunately I've never had a list of hostnames - as @joshbgosh10592 points out, that would make iptables fixing a lot easier by grepping/piping nslookup output. Unfortunately the IPs only reverse-lookup'd to their very generic hosting provider server name, rather than a useful DNS entry. :(

I've advised @fatmagic that by uncommenting the last line in iptables.sh and re-implementing the iptables rules (ie flush and reload) the dropped packets will be logged to dmesg. Unfortunately that means digging out the info you need from a huge pile of rejected multicast packets, but you can at least use dmesg -T to get human-readable times. Also make sure you clear your dmesg regularly if you do this - it logs a lot.

To everyone, so sorry I hadn't replied. I had messages from fatmagic on Reddit but I had no idea you were all on here trying to fix this. You'd think I'd be subscribed to my own damn code's forum. My apologies. I appreciate you keeping this ticking along. :)

[joshbgosh10592]

@Pinchie No worries! This has gotten my creative/coding side alive and I'm enjoying it!
Based off your IP addresses, I can assume at least some hostnames used are above. However, once I get my new install of Pi-Hole running, I can tell you everything my 3DS is querying, clearly, so a script could be created to dynamically update IPTables' list every so often (maybe every hour or so).
I should have this up and running probably Monday.

If that's something you like to do/have done? It would make it truly set/forget it.

[Pinchie]

That's something that would be fantastic, thank you so much. 😄

[fatmagic]

Sorry for going quiet here - was busy this weekend. Thanks for dropping in @Pinchie :-D
@joshbgosh10592 - Very curious how your work goes on a dynamically updating IPTables list!
I had to teardown my Homepass relay temporarily, so I can't do any testing until Tues/Wednesday. Will check back in tomorrow!

[joshbgosh10592]

Ok, so my original Pi-Hole install somehow managed to start working (after the host OS crashed and needed rebooted. I don't know, it's giving me a headache...) Anywho, I have the hostnames my 3DS reached out to. I'm not sure if all 5 of them are needed for streetpass, but here they are.

Edit: Conntest.nintendowifi.net and service.spr.app.nintendo.net are required. conntest, if blocked, doesn't even try to do anything else (kind of expected, but wanted to validate anyway), and when I had service.spr.app.nintendo.net blocked, no streetpass came through.

l-npns.app.nintendo.net
nppl.c.app.nintendowifi.net
npdl.cnd.nintendowifi.net (this didn't come through every time my 3DS was asleep. May not be required)
service.spr.app.nintendo.net (Required)
conntest.nintendowifi.net (Required)

Now, to make the script, I don't know how to make the script loop, but we could just take the example script I liked to and make 5 copies of it, or if someone knows how to input multiple hostnames, it would be even better. Another problem is that the 3DSs are reaching out to a CDN, which frequently provide more than one IP address (usually two). Not sure if the 3DS needs access to both or just one.

I'm also not sure where RaspiPass is saving its log file, to put that into the script.

[fatmagic]

How are you able to find out what are the correct IPs to whitelist based on this list? Are you just pinging/tracerouting the TLD/URL? I have a build I want to finish (it's for someone else) and just deploy with the IPs for now. Then I'd like to see where you get with an automated list... will help where I can! I would say pull down as many IPs as you can find from those addresses. Play it safe. I have a question - forgive me for not fully understanding how Linux/Debian treats these. Can we only use IPs when whitelisting on IPTables, instead of using the FQDN?

…

On Tue, Mar 27, 2018 at 12:10 PM, joshbgosh10592 ***@***.***> wrote: Ok, so my original Pi-Hole install somehow managed to start working (after the host OS crashed and needed rebooted. I don't know, it's giving me a headache...) Anywho, I have the hostnames my 3DS reached out to. I'm not sure if all 5 of them are needed for streetpass, but here they are. l-npns.app.nintendo.netnppl.c.app.nintendowifi.netnpdl.cnd.nintendowifi.netservice.spr.app.nintendo.netconntest.nintendowifi.net Now, to make the script, I don't know how to make the script loop, but we could just take the example script I liked to and make 5 copies of it, or if someone knows how to input multiple hostnames, it would be even better. Another problem is that the 3DSs are reaching out to a CDN, which frequently provide more than one IP address (usually two). Not sure if the 3DS needs access to both or just one. I'm also not sure where RaspiPass is saving its log file, to put that into the script. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ATqJu6DUptoiDeEmCaAau5IH7WKIP0nxks5timSEgaJpZM4SyrXq> .