Easyfind not updating changed IP

[Gordon]

Unfortunately, this does not work. I also tried subprocess.call to no avail. If you have an idea, let me know.

How do you test this exactly? I had some issues myself trying to dump some raw feedback from that script and eventually I found that there was in fact no TCP traffic when I ran the script from console. The script MUST be run with twistd, not python.

Also I tested the individual calls and in my case they appear to be working just fine. You can try the same by running the script like this:

Code: Select all

twistd -l - -n --python=/usr/share/bubba-backend/bubba-easyfind.tac

This will direct all output to screen and may hint what is wrong. To view the raw response from the easyfind server simply replace the string 'pass' on line 116 to 'print response'.

[bIO]

Also I tested the individual calls and in my case they appear to be working just fine. You can try the same by running the script like this:

Code: Select all

twistd -l - -n --python=/usr/share/bubba-backend/bubba-easyfind.tac

This will direct all output to screen and may hint what is wrong. To view the raw response from the easyfind server simply replace the string 'pass' on line 116 to 'print response'.

I did not call the bubba-easyfind.tac explicitly, but just changed the file and hoped, the altered part will be executed when the IP changes.

Now I did what you suggested and ran twistd on the command line. First difference I noticed between the syslog output and the stdout was that, according to syslog the IP change was recognized by printing something like twisted: [HTTP11ClientProtocol,client] Got new IP '<new-ip>' which is not the same as the last one '<old-ip>' whereas on stdout the message was [HTTP11ClientProtocol,client] Got new IP '<new-ip>' which is the same as the last one '<new-ip>'.

I think this implies that in the bubba-easyfind.tac funtion easyfind_ip_changed the wrong decision is made on line 105. So it never calls function easyfind_set_ip. I changed it temporarily to read '==' instead of '!='. It then called the function and I got a printed response from changed line 116:

Code: Select all

{"error":true,"opcode":16,"msg":"Unable to validate from production."}

I had this message in syslog before but only after enabling UPnP in the router/modem combo.

So if I interpret this message right, somehow my B3 MAC/Secret key combo is not valid on the remote machine called by bubba-easyfind.tac whereas it is when called by easyfind.pl. And as Gordon pointed out, there seems to be a problem with the config being updated with the new IP although the DNS update failed.

[Gordon]

Now I did what you suggested and ran twistd on the command line. First difference I noticed between the syslog output and the stdout was that, according to syslog the IP change was recognized by printing something like twisted: [HTTP11ClientProtocol,client] Got new IP '<new-ip>' which is not the same as the last one '<old-ip>' whereas on stdout the message was [HTTP11ClientProtocol,client] Got new IP '<new-ip>' which is the same as the last one '<new-ip>'.

That sounds weird. There should be no difference in running twistd in console mode versus as a daemon.

So if I interpret this message right, somehow my B3 MAC/Secret key combo is not valid on the remote machine

I second that conclusion. So the next step would be to find out what parameters you are in fact sending over by dumping the values of key and mac0. Also, it could be interesting to get the return value for `bubba-networkmanager-cli getwanif`. If that shows as br0 there could be a chance of the MAC address being resolved (if any) not having the correct vendor code (I actually do not think the two parameters are bound 1 on 1, but if they are the return from this should probably always be eth0).

[bIO]

That sounds weird. There should be no difference in running twistd in console mode versus as a daemon.

I was a bit fast with my conclusion on this one. Turns out I forced an IP update right after starting the console twistd, so the daemon (running in parallel) would recognize the IP change earlier. When the console twistd (after 1 min) checks for the IP, it then is of course the same. Here is an example:

Code: Select all

14:45:01 twistd on console started
14:45:10 IP change
14:45:18 twistd daemon recognizing change
14:46:01 twistd on console sees same IP address

I was able to also do it the other way around. So nothing special here.

I already printed the key and mac0 values. mac0 is the MAC address from eth0 and the key is the 'Secret system key' as obtained by cat /proc/cmdline. `bubba-networkmanager-cli getwanif` returns eth0.

[bIO]

I think the source of the error message

Code: Select all

{"error":true,"opcode":16,"msg":"Unable to validate from production."}

is to be found somewhere in the httpRequest function of bubba-easyfind.tac. It looks like somehow the wrong key is sent. Maybe something related to 'urlencode' or 'StringProducer'.

[Gordon]

I think the source of the error message

Code: Select all

{"error":true,"opcode":16,"msg":"Unable to validate from production."}

is to be found somewhere in the httpRequest function of bubba-easyfind.tac. It looks like somehow the wrong key is sent. Maybe something related to 'urlencode' or 'StringProducer'.

Seeing you mention urlencode - which I did see at some point but didn't ring any bells at that time - I wonder if there is any sense in urlencoding POST vars?

I already printed the key and mac0 values. mac0 is the MAC address from eth0 and the key is the 'Secret system key' as obtained by cat /proc/cmdline. `bubba-networkmanager-cli getwanif` returns eth0.

I must have missed that and in fact when looking back I still don't see them. Also would not recommend to post the key as this will allow other people to change your easyfind address.

As far as MAC address is concerned, the one you're sending should start with `00:22:02`. Quite interesting actually, because if you'd have to spoof a MAC address that your ISP assigned to your account this would also ban you from using easyfind.