New buttons are using UDP instead of ARP

[kim3er]

My button was initially picked up using the ARP method, but after about 20 minutes, stopped being picked up. Turns out, possibly through a firmware update, the message protocol had switched to UDP.

This pull request adds the ability to monitor UDP. I've implemented in a way as to not break existing implementations. The index script defaults to ARP only, which you can configure to search for UDP only or both protocols. findbutton now searches both by default, and outputs the protocol used.

I've updated the documentation, but have not written any additional tests. I've not really tested anything on the network before, so guidance would be appreciated.

Thanks for the library! It allowed me (initially at least), to get up and running very quickly.

[coveralls]

Coverage decreased (-6.0%) to 92.063% when pulling 1063db0 on kim3er:feature/udp into f969c3a on hortinstein:master.

[coveralls]

Coverage decreased (-6.0%) to 92.063% when pulling 3e30b79 on kim3er:feature/udp into f969c3a on hortinstein:master.

[coveralls]

Coverage increased (+0.4%) to 98.413% when pulling 7f3f926 on kim3er:feature/udp into f969c3a on hortinstein:master.

[kim3er]

I've added some tests.

[thbaumbach]

this is working way better than just the ARP-method (which missed some requests), good job, thank you +1

[Bastl34]

Wouldn't it be better if you try to catch all requests from a dash-button mac address?
Then you wouldn't need a ARP/UDP filter.

[kim3er]

Hi @Bastl34. Logically, I'd say yes. Do you know if pcap can be configured in that way?

[Bastl34]

What if you just check if the package was sent by the mac address by removing these checks:

packet.payload.ethertype === 2054
packet.payload.ethertype === 2048

[kim3er]

Those checks are required, because I detect the UDP MAC differently to that of the ARP MAC. It maybe that the ARP MAC can be identified using the same method that I'm employed for UDP, but I haven't checked. The focus of this pull request was to get UDP working, not refactoring the existing process.

If @hortinstein is up for it, I have couple more ideas for optimisations, once this PR has been resolved.

[hortinstein]

hey thank you for the pull request! I haven't been able to put much work into this library for a while so community help means a lot.

I will merge and push to NPM today. (thanks for writing tests too!)

[kim3er]

That's great, and no problem!

[Bastl34]

This is still not pushed to npm? :) Latest npm version is 0.5.5

[kim3er]

I'm sure you're probably aware of this (and it's not ideal), but just in case!

You can switch the version for 'hortinstein/node-dash-button' in the package.json file. This will allow you to install from GitHub Master.

"node-dash-button": "hortinstein/node-dash-button"

[hortinstein]

strange, on search results it shows that 0.6.0 is published:
https://www.npmjs.com/search?q=node-dash-button

But on the actual page:
https://www.npmjs.com/package/node-dash-button it shows 0.5.5.

I will try to repub.

[hortinstein]

weird so it rejected my repub of 0.6.0 but took 0.6.1. It appears to be updated now, let me know if there are anymore issues!

[johnmckerrell]

Hi, I had issues too, I have a button that definitely used to work and I haven't changed anything, it's on a Pi running openelec so I definitely haven't updated anything since setting it up. It really does seem like they updated the firmware. I continued to have issues until I found that I needed to specify all protocols (well, udp would probably do but all protects me for the future). So my updated code for setting up a button is:

var dash_button = require('node-dash-button'),
    dash = dash_button(dashAddress, null, null, 'all'), //REPLACE WITH YOUR ADDRESS
    exec = require('child_process').exec;