Rocket0634 Please provide me with the output from maccheck.cmd and
schtasks /query /tn nzone /v /fo csv
You can check which MACs was already set in nzone.macs file, used MAC have "x" before it.
ItsAllParticles Try this:
ifconfig $(nvram get wl0_ifname)
wc -l /tmp/nzone.macs
grep ^x /tmp/nzone.macs | wc -l
This will show the actual MAC, number of MACs in list and number of MACs already set. MAC addres in WEB-GUI will not show any changes.
sabata2 said:Okay. This is where I am messing up then because I *can* access my AP (atleast with the cronjob off) but I constantly get a Communication Error message when trying to reach the ORAS demo page.
Looking at the iptables I see this:
Code:root@Aviarch:/usr/local/sbin# iptables -t nat --list Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- anywhere anywhere
This looks like (to my understanding) I'm not actually redirecting any traffic, nor am I forwarding to any set destination (based on the Source:Anywhere, Dest:Anywhere part)
sabata2 with changing the MAC list you also musr delete nzone.macs file or just run nzone reload (which is doing the same), otherwise the old mac list se will be used untill all macs is used, and only then script will download from the server the new lists. The NAT postrouting rule is not enough, also a forward chain rule must exist, check it with iptables -L -v -n, also ip forwarding must be enabled, I suppose it must be supported by the kernel
root@Aviarch:/usr/local/sbin# iptables -L -v -n
Chain INPUT (policy ACCEPT 630 packets, 106K bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- wlan0 * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 1033 packets, 134K bytes)
pkts bytes target prot opt in out source destination
If any client is able to connect to the created AP, then NAT+Masquerading+IPForwarding should share the internet connection to the client.So the rule is in place, how can I check that ip forwarding is enabled?
duke_srg According to the task scheduler, the nzone task correctly runs every By the way, if I remember correctly there was a nzone.macs file in the nzone directory when I used an older version of the script. There's no such file now. Is it normal?
ItsAllParticles The last one returns number of MACs already set, the second one returns total number of MACs.
okay, so it returns 16, for base 16... can we force it to use the 256 list on a longer time limit than 2 minutes? (only because i'd like to spread the area of affect out more?)
nzone.macs must exist, if not, just run nzone.vbs start BASE256 once again, it will recreate the task with the updated list parameter. If nzone.macs will not be crated automatically on the next run, just run nzone.vbs BASE256, it must download nzone.macs file or will give the error.
The nzone.macs file wouldn't be created automatically, so I ran nzone.vbs BASE256 and it created the file. However, the script doesn't seem to change the MAC at all (it seems to have changed it once after rebooting, but the "new" MAC is completely different from any mac address from the nzone.macs file - and the "old" one was 02:00:00:00:00:00, which I find quite strange). Actually I'm pretty sure that "new" MAC address, which I thought had been changed by your script, is the actual MAC address of the Intel wi-fi card from before I even started using your script. It's as if rebooting gives it the "strange" mac with almost all 0, and your script changes the mac for the "correct" one, but doesn't work after that.
Well all that seems very strange to me. I think my laptop doesn't want me to use a homepass relay.
02:00... Is the custom mac that was last set by the maccheck.cmd. After runnung nzone.vbs BASE356 wait 2 minutes and run just nzone.vbs, it must change the address and modify nzone.macs file adding "x" in the beginning of the string with the changed MAC.
When I manually run nzone.vbs, it changes the MAC address successfully, so yay! But when the scheduled task is running, it doesn't seem to work. But that's already great so thanks
Rocket0634 did you run maccheck.cmd from the administrator command prompt? Please also run
wmic nic get macaddress,name,pnpdeviceid
Hello to everyone.
I have a DD-WRT router and a European 3DS XL. Many months ago I did the router thing to fake a nintendo relay station.
More specifically, I renamed the SSID to "attwifi" and cloned the WLAN MAC address to the general one (4E:53:50:4F:4F:46). Also the connection is password protected (WPA2). I wasn't interested in cycling Mac addresses. Just a few streetpass hits every now and then.
Until the last system updates, the whole thing worked like a dream. But now, the 3DS doesn't recognize as a nintendo Zone the Wi-Fi connection and I don't have streetpass hits. It behaves just like a normal Wi-Fi connection.
UPDATE: From what I read here, I should rename the SSID to NZ@McD1. I'll try that as soon as I return home.