Amazon Dash Button stopped ARPing?

问题:

I have implemented a home automation solution to track my childrens chores using two Amazon Dash buttons, a raspberry pi, and python code similar to what's been done here. This solution has worked for the past several months.

Yesterday, the buttons appear to have ceased ARPing. That is, I can no longer detect an ARP from them, nor do I appear to be able to detect their MAC address by sniffing it. I'm wondering if anyone else has had this problem? In addition to the python mechanism using scapy, I also tried "ip neigh" to no avail. An example of a bash scrip using the "ip neigh" command is here. I've attempted to detect the buttons both from a RaspberryPI and from a Mac. All machines are successfully configured to be on the same wireless network.

Some additional info. Originally I ordered 3 buttons, but 1 of them never seemed to ARP, so I set it aside. I'll update as I find out more information about this issue.

EDIT I have tried several times to solve this issue by utilizing the Amazon android app to add a new dash button and reconfigure them again.

回答1:

I was having a similar issue to you this week. I had setup my dash buttons to control and toggle my LIFX light bulbs and using them daily with no problems for the last few months. All of a sudden it just stopped working so I checked the detector script (using Scapy on a Raspberry Pi) and the buttons were not being detected.

I was still getting notifications on my phone that my buttons had been pressed and needed setup so I could tell they were still connecting to the network and the issue was the detector script or the Pi.

This may have been a different problem to you but changing the detection script on the Pi to this alternative (suggested on the original $5 baby tracker medium post) fixed my issues. https://gist.github.com/ibrahima/5e43439eb71066bf891f

I would also suggest that your router may have changed bands or channel to one which the dash button is not able to communicate over (and so cannot connect to the router). This has happened to me before with my lightbulbs (router auto-switched to channel 13 but LIFX only communicate over 1-11/12). I also had to play with my router settings to get the buttons to detect my network in the first place (but if you can do the whole setup process fine then that's probably not the case). Potentially router software update or change in security settings have caused the detection to break down?

回答2:

Seems like the Dash-Buttons do not "ARP" anylonger.

You can listen to DHCP requests insteads using this nice script: https://gist.github.com/mr-pj/75297864abef5c8f2d5c134be2656023#file-dashbutton-py

回答3:

It appears that "new" model Dash buttons (they have finally been released in the UK, and I'm playing with one on the day of release) behave differently when connecting to the network than the previous models. This breaks a lot of the code out there that detects them by monitoring for ARP requests with a source host of 0.0.0.0.

These new buttons instead seem to issue a DHCP request from 0.0.0.0 first, followed by ARP requests for other network devices (e.g. the gateway) using the IP address they have been assigned.

Detecting this new behaviour is fairly simple. For example, the dash-button node module can be made to work for both types of button by changing the libpcap filter spec in build/ArpProbes.js, from:

const ARP_PROBE_FILTER = 'arp src host 0.0.0.0';

to

const ARP_PROBE_FILTER = '(arp or (udp and src port 68 and dst port 67)) and src host 0.0.0.0';

I have also filed this dash-button issue here.

回答4:

I have two brand new dash buttons, instead of doing an arp for 0.0.0.0, they are doing a bootp request to get a dhcp address, this causes the common scripts that are looking for an arp 0.0.0.0 to ignore them.

you can modify the scripts to watch for bootp, instead of watching for arp 0.0.0.0, or just skip the first check in the script that tests for an arp for 0.0.0.0

回答5:

What I did to solve this issue, was to assign fixed IP addresses to the buttons on the wireless router they attached to (because I could see their MAC addresses in the DHCP table). I then rewrote the script to simply detect successful pings against the ipAddress the buttons had been assigned. I noticed that the buttons remain on the network for a little while (maybe 15-20 seconds) so I added a little bit of wait time between detections (kind of like a debounce filter on a physical switch) to ensure that the same button push wasn't detected twice. This did the trick.

First I found a pure python implementation of ping (which I copied lock, stock, & barrel into the python script), then I wrote this code:

#!/usr/bin/python
from scapy.all import *
import requests
import time
import os, sys
import subprocess
import re
import platform
import datetime

BUTTON_A = "<assigned IP address to Button A>"
BUTTON_B = "<assigned IP address to Button B>"
last_button_push_A = datetime.datetime(2013,12,30,23,59,59)
last_button_push_B = datetime.datetime(2005,12,30,1,1,1)
waittime_sec = 20
while (True):
        try:    
            delta = (datetime.datetime.now() - last_button_push_A).seconds
            print (delta > 20)
            if (do_one(BUTTON_A, 1) is not  None) and delta > waittime_sec:
                    last_button_push_A  = datetime.datetime.now();
                    logfile.write("<Child 1> Completed a Chore: "+time.strftime("%Y-%m-%d %H:%M")+"\n")
                    logfile.flush()
                    play_sound_child_1()
            delta = (datetime.datetime.now() - last_button_push_B).seconds
            if (do_one(BUTTON_B, 1) is not  None) and delta > waittime_sec:
                    last_button_push_B = datetime.datetime.now()
                    logfile.write("<child 2> Completed a Chore: "+time.strftime("%Y-%m-%d %H:%M")+"\n")
                    logfile.flush()
                    play_sound_child_2()
        except BaseException as e:
            logfile.write("EXCEPTION: {}\n".format(e))
            logfile.write("Loop Rest at "+time.strftime("%Y-%m-%d %H:%M")+"\n")

回答6:

I used WireShark to narrow down the problem. This is a great tool for troubleshooting any kind of networking related issue.

Like palerider said, my dash button seems to be doing a DHCP request each time it connects instead of a standard ARP, with a source IP of "0.0.0.0" (since it doesn't have one). I updated my listener app to look for DHCP requests from source IP "0.0.0.0" and I was able to see which MAC addresses were making these types of requests (not many) and then updated my app again to look specifically for this MAC address once it received a DHCP request from source IP "0.0.0.0".

回答7:

Did you happen to have deactivated the Dash button from your Amazon account? I found that if the Dash button has been deactivated (meaning no longer appear in your account), the next time the Dash button call mothership. It will tell the Dash that it is no longer activated. From now on, pressing the Dash button will only give a red light and it will not initiate Wi-Fi connection and therefore no ARP entry. It could also be that Amazon deactivated the Dash button from their end to save battery (since you apparently did not order anything for the last n presses).

If it matches your scenario, you can fix that by registering your Dash button again. Just don't select anything to order.