Fingbox Part 2: some nifty features

Fingbox Part 2: some nifty features

Pausing the Internet

While fiddling around with the Fing app, I noticed some fascinating functions under each individual device it had detected:

  • Assign it to a user
  • Block the device
  • Pause Internet
  • More…
    • Check the Event Log
    • Ping the device
    • Scan services on the device
    • Wake onLAN

The Blocking and Pausing features intrigued me, how do they manage to block a device while not being inline? The FAQ on fing.io doesn’t really explain; it refers to some “low level network programming and packet injections”. OK, and then?

I planned for some simple experiments; my 11 inch Macbook Air would be the ideal test bed as I could use the terminal for some simple network tests and capture the results. Note that the following experiments were all done over wifi.

I have both IPv4 as well as IPv6 at my disposition. I pinged (ping and ping6) www.google.com. I then “Paused the Internet” and to my astonishment, the ping to the IPv4 address simply stopped. After resuming it started getting replies again.

dhcp-108:~ dirk$ ping www.google.com
PING www.google.com (108.177.119.104): 56 data bytes
64 bytes from 108.177.119.104: icmp_seq=0 ttl=44 time=21.207 ms
64 bytes from 108.177.119.104: icmp_seq=1 ttl=44 time=21.134 ms
64 bytes from 108.177.119.104: icmp_seq=2 ttl=44 time=20.072 ms
64 bytes from 108.177.119.104: icmp_seq=3 ttl=44 time=23.206 ms
64 bytes from 108.177.119.104: icmp_seq=4 ttl=44 time=24.000 ms
64 bytes from 108.177.119.104: icmp_seq=5 ttl=44 time=23.316 ms
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
...
Request timeout for icmp_seq 23
Request timeout for icmp_seq 24
Request timeout for icmp_seq 25
Request timeout for icmp_seq 26
64 bytes from 108.177.119.104: icmp_seq=27 ttl=44 time=21.498 ms
64 bytes from 108.177.119.104: icmp_seq=28 ttl=44 time=21.732 ms
64 bytes from 108.177.119.104: icmp_seq=29 ttl=44 time=50.526 ms
64 bytes from 108.177.119.104: icmp_seq=30 ttl=44 time=80.681 ms
^C
--- www.google.com ping statistics ---
32 packets transmitted, 10 packets received, 68.8% packet loss
round-trip min/avg/max/stddev = 20.072/30.737/80.681/18.725 ms

The output has been shortened for brevity. The IPv6 address on the other hand wasn’t impacted by the “Pause Internet” function. This didn’t surprise me as the app has nowhere any reference to IPv6 and is clearly not yet IPv6 enabled.

dhcp-108:~ dirk$ ping6 www.google.com
PING6(56=40+8+8 bytes) 2a02:1811:2d22:ee00:f415:5cc9:ce43:b90b --> 2a00:1450:4013:c00::69
16 bytes from 2a00:1450:4013:c00::69, icmp_seq=0 hlim=45 time=28.547 ms
16 bytes from 2a00:1450:4013:c00::69, icmp_seq=1 hlim=45 time=35.016 ms
16 bytes from 2a00:1450:4013:c00::69, icmp_seq=2 hlim=45 time=41.580 ms
16 bytes from 2a00:1450:4013:c00::69, icmp_seq=3 hlim=45 time=33.157 ms
16 bytes from 2a00:1450:4013:c00::69, icmp_seq=4 hlim=45 time=28.403 ms
16 bytes from 2a00:1450:4013:c00::69, icmp_seq=5 hlim=45 time=31.477 ms
16 bytes from 2a00:1450:4013:c00::69, icmp_seq=6 hlim=45 time=32.193 ms
...
16 bytes from 2a00:1450:4013:c00::69, icmp_seq=24 hlim=45 time=30.804 ms
16 bytes from 2a00:1450:4013:c00::69, icmp_seq=25 hlim=45 time=32.615 ms
16 bytes from 2a00:1450:4013:c00::69, icmp_seq=26 hlim=45 time=32.642 ms
16 bytes from 2a00:1450:4013:c00::69, icmp_seq=27 hlim=45 time=34.136 ms
16 bytes from 2a00:1450:4013:c00::69, icmp_seq=28 hlim=45 time=29.293 ms
16 bytes from 2a00:1450:4013:c00::69, icmp_seq=29 hlim=45 time=32.861 ms
16 bytes from 2a00:1450:4013:c00::69, icmp_seq=30 hlim=45 time=29.787 ms
16 bytes from 2a00:1450:4013:c00::69, icmp_seq=31 hlim=45 time=34.264 ms
16 bytes from 2a00:1450:4013:c00::69, icmp_seq=32 hlim=45 time=30.488 ms
^C
--- www.google.com ping6 statistics ---
33 packets transmitted, 33 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 28.403/33.010/41.580/3.358 ms

The output was shortened for brevity.

Clearly the Fingbox is not IPv6 enabled and has seemingly no support for dual stacked environments. This makes the entire “Pause Internet” functionality rather moot. My Macbook Air, will happily surf to www.google.com over IPv6 while IPv4 is blocked.

Blocking devices

After this initial test I was quite sure the device block would also fail on IPv6. What I didn’t expect is the way blocking was enforced by the Fingbox. Again there is very little information available on this subject and only by using some low level hacks one can kick devices from a network.

I have an internal name server both on IPv4 and IPv6 that I would use as a target to ping to the device:

dhcp-108:~ dirk$ ping ns
PING ns.sj47.jumpertz.net (192.168.1.200): 56 data bytes
64 bytes from 192.168.1.200: icmp_seq=0 ttl=64 time=2.846 ms
64 bytes from 192.168.1.200: icmp_seq=1 ttl=64 time=3.788 ms
64 bytes from 192.168.1.200: icmp_seq=2 ttl=64 time=2.823 ms
64 bytes from 192.168.1.200: icmp_seq=3 ttl=64 time=3.379 ms
64 bytes from 192.168.1.200: icmp_seq=4 ttl=64 time=3.402 ms
64 bytes from 192.168.1.200: icmp_seq=5 ttl=64 time=5.115 ms
ping: sendto: No route to host
Request timeout for icmp_seq 6
ping: sendto: No route to host
Request timeout for icmp_seq 7
ping: sendto: No route to host
Request timeout for icmp_seq 8
ping: sendto: No route to host
...
Request timeout for icmp_seq 34
ping: sendto: No route to host
Request timeout for icmp_seq 35
Request timeout for icmp_seq 36
64 bytes from 192.168.1.200: icmp_seq=37 ttl=64 time=1.095 ms
64 bytes from 192.168.1.200: icmp_seq=38 ttl=64 time=0.994 ms
64 bytes from 192.168.1.200: icmp_seq=39 ttl=64 time=1.082 ms
64 bytes from 192.168.1.200: icmp_seq=40 ttl=64 time=1.448 ms
^C
--- ns.sj47.jumpertz.net ping statistics ---
41 packets transmitted, 10 packets received, 75.6% packet loss
round-trip min/avg/max/stddev = 0.994/2.597/5.115/1.326 ms

I removed some of the timeout print for brevity. While my Macbook Air was blocked it couldn’t reach the server anymore. I also received the following pop-up:

something is stealing my IP address

Within 30 seconds I received a second pop-up claiming that the next IP address was also in use. Differently said, I assume that the Fingbox simply impersonates the device that needs to be kicked off the network by taking over the IPv4 address. Theoretically this shouldn’t be sufficient to cause havoc, so I assume it does something else additionally. For wireless devices this could be via a deauthentication frame which would force the client to reconnect and send a new DHCP request. My Macbook Air did try to get another IP address via DHCP and was kicked off again. I wonder if this wouldn’t exhaust the available pool of IP addresses though and if there aren’t any side effects. I checked the leases on my DHCP server and they didn’t seem to be over-allocated.

So what about IPv6?

dhcp-108:~ dirk$ ping6 ns
PING6(56=40+8+8 bytes) 2a02:1811:2d22:ee00:f415:5cc9:ce43:b90b --> 2a02:1811:2d22:ee00::200
16 bytes from 2a02:1811:2d22:ee00::200, icmp_seq=0 hlim=64 time=310.615 ms
16 bytes from 2a02:1811:2d22:ee00::200, icmp_seq=1 hlim=64 time=3.667 ms
16 bytes from 2a02:1811:2d22:ee00::200, icmp_seq=2 hlim=64 time=4.234 ms
16 bytes from 2a02:1811:2d22:ee00::200, icmp_seq=3 hlim=64 time=3.940 ms
16 bytes from 2a02:1811:2d22:ee00::200, icmp_seq=4 hlim=64 time=3.165 ms
...
16 bytes from 2a02:1811:2d22:ee00::200, icmp_seq=18 hlim=64 time=3.284 ms
16 bytes from 2a02:1811:2d22:ee00::200, icmp_seq=19 hlim=64 time=3.085 ms
16 bytes from 2a02:1811:2d22:ee00::200, icmp_seq=20 hlim=64 time=2.658 ms
16 bytes from 2a02:1811:2d22:ee00::200, icmp_seq=21 hlim=64 time=3.002 ms
16 bytes from 2a02:1811:2d22:ee00::200, icmp_seq=22 hlim=64 time=5.115 ms
^C
--- ns.sj47.jumpertz.net ping6 statistics ---
23 packets transmitted, 23 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.828/16.892/310.615/62.637 ms

I shortened the output for brevity again. As expected blocking a device has absolutely no impact on the IPv6 part and since it stayed online, we can assume the Fingbox doesn’t send a deauthentication frame. I bet some good old fashioned Wiresharking will give more insight how they do it.

The Fing app does notice multiple IPv4 addresses on the blocked device though; but this is only temporary.

look ma, I have 2 IP addresses

Conclusion

For people with a traditional IPv4-only network at home the Fingbox does indeed what it promises on the wireless network. It will not only detect new systems on the network, it can also block them or prevent Internet access.

How this is done, remains a bit in a shroud of mystery for the moment.