New user's registration have been closed due to high spamming and low trafic on this forum. Please contact forum admins directly if you need an account. Thanks !
Easyfind: what is the road map for this service?
Re: Easyfind: what is the road map for this service?
Hi
You may see some weird entries popping up with the same mac using different keys. I was just checking to see if there's any weird return, but on this level I can't see any. I also don't see any different behaviour between URL encoded and non URL encoded.
Some thoughts however:
If a percent sign '%' can be part of the secret then failure will be imminent when URL decoding what was not URL encoded.
If a backslash '\' can be part of the secret then the combination with the character following it may be interpreted as an escape sequence by the data backend.
I can't verify either of this, because none of my B3's have such characters in their secret.
You may see some weird entries popping up with the same mac using different keys. I was just checking to see if there's any weird return, but on this level I can't see any. I also don't see any different behaviour between URL encoded and non URL encoded.
Some thoughts however:
If a percent sign '%' can be part of the secret then failure will be imminent when URL decoding what was not URL encoded.
If a backslash '\' can be part of the secret then the combination with the character following it may be interpreted as an escape sequence by the data backend.
I can't verify either of this, because none of my B3's have such characters in their secret.
Re: Easyfind: what is the road map for this service?
The problem was not de encoding, this was fine. THe problem was the decoding. The default decoder did not decode "+" for example. This is mostly taken care of, but the remaining problem is that for 'changes' in easyfind the B3 does not supply the preferred DNS name (only mac and key). So any B3 that was 'registered' before the code fix remains wrong until easyfind is switched off and then on *ON THE CLIENT*. Theres nothing on the server possible to retreive the client information that I need.
anyway theres a lot of logging on the server that remembers the encoded and decoded keys at all stages of negiotation. But because the unit that set off this thread was registered after the change in server code, I think the problem is elsewhere. My gut feeling is that the essence is in a client-side bug, but I have no evidence for this except the funny inconsistent error that you posted.
anyway theres a lot of logging on the server that remembers the encoded and decoded keys at all stages of negiotation. But because the unit that set off this thread was registered after the change in server code, I think the problem is elsewhere. My gut feeling is that the essence is in a client-side bug, but I have no evidence for this except the funny inconsistent error that you posted.
Re: Easyfind: what is the road map for this service?
Actually, 15377 never registered. I only ran the getname command on this one. I did register two others though: one still running squeeze and another one running gentoo. It's those two that are returning the "Not a HASH" error when attempting to fetch fields from a record that is not a record but a boolean value.
As such this is not inconsistent, because it happens on two boxes. And the other behaviour was also verified on two boxes - of which currently only one remains because the other one was used to verify that it breaks when you register a name and then deregister.
I don't really get the '+' issue you talk about. Except for the Squeeze box the keys that I send are all not URL encoded and the box that has proven to be able to set an easyfind name does in fact have two '+'s in it's secret. If your decoder was supposed to handle those differently, that clearly didn't work because then it would not have been able to verify.
As such this is not inconsistent, because it happens on two boxes. And the other behaviour was also verified on two boxes - of which currently only one remains because the other one was used to verify that it breaks when you register a name and then deregister.
I don't really get the '+' issue you talk about. Except for the Squeeze box the keys that I send are all not URL encoded and the box that has proven to be able to set an easyfind name does in fact have two '+'s in it's secret. If your decoder was supposed to handle those differently, that clearly didn't work because then it would not have been able to verify.
Re: Easyfind: what is the road map for this service?
Hé?
You changed something. I was just trying to see if I could push a NULL value rather than "", which didn't work, but after running 'easyfind.pl disable' the getname command now returns:Verified on both boxes returning the HASH error
The other one now returns:
You changed something. I was just trying to see if I could push a NULL value rather than "", which didn't work, but after running 'easyfind.pl disable' the getname command now returns:
Code: Select all
{"name":"","msg":"Not enabled","error":"false"}
The other one now returns:
Code: Select all
function get_record_id failed
Re: Easyfind: what is the road map for this service?
Nope, just added logging and changed the return error phrases (so your second error is indeed something new), but i did not change any logic. Interesting to see it give an error message whilst stating error=false.
Re: Easyfind: what is the road map for this service?
That is strange. Because on both systems I had to run the disabl...
I'm an idiot. That sets 'enable = no' in the conf file, so that is a local generated response. That's the second time this script got me.
And you're right. It should have error = true for this type of response. That is clearly a mistake in the client side script.
I'm an idiot. That sets 'enable = no' in the conf file, so that is a local generated response. That's the second time this script got me.
And you're right. It should have error = true for this type of response. That is clearly a mistake in the client side script.
Re: Easyfind: what is the road map for this service?
if only the client would send the preferred DNS name together eith the request for IPupdate it would solve so many issues.
ANyway another thing is that there's a lot of clients that try to update their IP when that is not necessary. Its not a spectacular load on the server but its strange that this happend considering the check to ping.mybubba.org prior to the ipupdate request.
ANyway another thing is that there's a lot of clients that try to update their IP when that is not necessary. Its not a spectacular load on the server but its strange that this happend considering the check to ping.mybubba.org prior to the ipupdate request.
Re: Easyfind: what is the road map for this service?
another fun thing is that some clients seem to connect with their mac2 pretending it is mac1. I can just add this possiblity to the validation function clause and see if it helps
Re: Easyfind: what is the road map for this service?
Yes. However scanning the forum for easyfind issues there are a lot of posts complaining that the easyfind service (the python script being run through twistd) does not update their IP. There are probably a number of people that solved that issue by using cron to periodically call the perl script.Ubi wrote:if only the client would send the preferred DNS name together eith the request for IPupdate it would solve so many issues.
ANyway another thing is that there's a lot of clients that try to update their IP when that is not necessary. Its not a spectacular load on the server but its strange that this happend considering the check to ping.mybubba.org prior to the ipupdate request.
Another possibility could be the dhcp hook. If they have their B3 behind some other router that hands out a different IP from time to time, this will cause the perl script to be run for an update.
As for the scripts choosing to use eth1 over eth0, this may in fact be caused that the scripts are not hardcoded to use eth0, but ask bubba-networkmanager which interface is the WAN interface. Although I have never seen it return something other than eth0 I suppose it is possible the server-only profile could return eth1.
Re: Easyfind: what is the road map for this service?
Guys, I'm just about to install a B3 for a friend of mine and started testing Easyfind. I never needed it myself since I have static public IP and a domain name, so I just now found it doesn't work for me. I'm using standard system image.
This is what I get:
I'm not sure what other diagnostic data I can provide? Can you help me debug what's wrong?
This is what I get:
Code: Select all
# /usr/lib/web-admin/easyfind.pl
Updating IP on file.
Wrote config to file
{"debug_uid":"ID997488285","msg":"function get_record_id failed for combination 00:22:02:00:35:28 and Lyc8E9FVNy7yGb93Vl50vP2COro= (EF_ERR_501)","opcode":18,"record":{},"error":true,"operation":"Get record"}
Code: Select all
# cat /etc/network/easyfind.conf
enable = True
ip = <redacted>
name = stasheck.myownb3.com
Code: Select all
# ping stasheck.myownb3.com
ping: unknown host stasheck.myownb3.com
Re: Easyfind: what is the road map for this service?
That error is the same one I'm seeing on a B3 that has never had easyfind enabled, so it would seem that easyfind was actually not enabled server side. This is a known bug in the client I'm afraid, that it updates the config file without verifying whether the server call succeeded.
Re: Easyfind: what is the road map for this service?
All right, but can I do something about it?
Re: Easyfind: what is the road map for this service?
Yes
On the client, use the web interface to turn easyfind off , then on with another name.
Do not use the command line, unless you know exactly what sequence to use.
On the client, use the web interface to turn easyfind off , then on with another name.
Do not use the command line, unless you know exactly what sequence to use.
Re: Easyfind: what is the road map for this service?
I guess you could try setting the name again. Run the script with parameters 'setname' and your chosen name (e.g. stasheck.myownb3.com).
Edit: I know that's not what Ubi said, but it will give more feedback in case it doesn't work.
Edit: I know that's not what Ubi said, but it will give more feedback in case it doesn't work.
Re: Easyfind: what is the road map for this service?
just try both I guess. You cant really break anything, only make it 'not work'. The server end has a routine that deletes the record when you turn off easyfind in the web environment (Im sure it can be done in CLI also).