Can you detect device disconnection?

[FreshJR]

If you add a postlease into dnsmasq, you can do all sorts of cool stuff upon device connection.

Is there some alternative to trigger a script upon device disconnection. (besides monitoring the client list for changes).
(Yes I also know about power save/wifi sleep that will trigger many disconnect messages, but that is not an issue!)

--

Also while on the topic of dnsmasq. How does it know to assign my devices the same dhcp ip-addresses after a fill router reset. What magic is going that it remembers previous assignments>?!

 

[ColinTaylor]

If you add a postlease into dnsmasq, you can do all sorts of cool stuff upon device connection.

Is there some alternative to trigger a script upon device disconnection. (besides monitoring the client list for changes).

No, there's no disconnection event (it wouldn't be related to dnsmasq anyway). You can periodically poll the wireless connection list (I have a script that does this) but of course it only works for wireless devices not wired.

Also while on the topic of dnsmasq. How does it know to assign my devices the same dhcp ip-addresses after a fill router reset. What magic is going that it remembers previous assignments>?!

It uses a hash based on the device's MAC address, that way it always comes up with the same apparently random IP address. See --dhcp-sequential-ip

 

[FreshJR]

It uses a hash based on the device's MAC address, that way it always comes up with the same apparently random IP address. See --dhcp-sequential-ip

Thanks! I've been wondering that for the longest while. I figured it was something like that but I'm glad this has been confirmed.

Any links to your script?

 

[ColinTaylor]

Here you go. Note the comment about not working fully with Quantenna devices. See the link for information on the modifications necessary for those.

I kick this off from services-start (/jffs/scripts/wireless_monitor.sh &).

#!/bin/sh

# This script only works with Broadcom wireless chipsets, not Quantenna.
# https://www.snbforums.com/threads/to-trace-mobile-mac-adress.20022/#post-144852

oldlist=/tmp/assoclist.old
newlist=/tmp/assoclist.new
touch $oldlist        # Create an empty file the first time through
 
while sleep 15
do
    for iface in $(nvram get wl_ifnames) $(nvram get wl0_vifs) $(nvram get wl1_vifs)
    do
        wl -i $iface assoclist >> $newlist
        sed -i "s/assoclist/$iface/g" $newlist
    done

    grep -vxFf $newlist $oldlist | while read macinfo
    do
        macaddr="${macinfo#* }"
        arpinfo="$(arp -a | grep -iF $macaddr | awk '{print $1 " " $2}')"
        logger -t wireless $macinfo $arpinfo "has disconnected."
    done

    grep -vxFf $oldlist $newlist | while read macinfo
    do
        macaddr="${macinfo#* }"
        arpinfo="$(arp -a | grep -iF $macaddr | awk '{print $1 " " $2}')"
        logger -t wireless $macinfo $arpinfo "has connected."
    done

    mv $newlist $oldlist
done

 

[revnil]

This script works great when manually ran but putting it in services-start doesn't work for me. I can see the script running with ps but it doesn't function properly. the assoclist files aren't written to, logger isn't logging to syslog. Are you using the parenthesis in the script like you have written (/jffs/scripts/wireless_monitor.sh &) or do you just have a line with /jffs/scripts/wireless_monitor.sh & ?

 

[ColinTaylor]

No parenthesis.

#!/bin/sh
/jffs/scripts/wireless_monitor.sh &

 

[revnil]

That's how I have mine. It starts but doesn't write anything to the file or log. Is there anything obvious to check. I do have it enabled to run jffs scripts in the gui.

 

[ColinTaylor]

I can't think of any reason. I'm assuming you've rebooted the router. It seems odd that you can see it running with ps but there are no files created in /tmp. What router model and firmware version are you running?

 

[revnil]

I modified the script to put the files in the same folder maybe that is an issue. I'll point them back at /tmp and try. It's an RT AC66U on 380.70.

 

[revnil]

Yep, moved the assoclist back to /tmp and it works. Thank you for sharing that script.

 

[elorimer]

It uses a hash based on the device's MAC address, that way it always comes up with the same apparently random IP address.

Interesting. I had thought after this initial assignment it was because on renewal the client asked, in effect, can I continue to use this address, and DNSmasq said yes.

 

[ColinTaylor]

Interesting. I had thought after this initial assignment it was because on renewal the client asked, in effect, can I continue to use this address, and DNSmasq said yes.

Yes that would be the case when renewing an existing lease. Also, when the client reconnects and asks for the same IP that it previously had it should get it, assuming that it hadn't been assigned to someone else in the meantime. But if you were previously connected to a different network with 10.10.0.99 for example, when you reconnected to your home (192.) network it would ask for that address again but be refused.

The hashing of the MAC address is mostly useful for when the router gets rebooted and looses it's memory of what IP addresses it had previous given out. By using the hash method there's a better chance that it won't assign a duplicate IP address to another device.