Easyfind: what is the road map for this service?

[Gordon]

Having ported easyfind to the gentoo release, I found that at least one of the B3's I recently purchased gives me the following return message when trying to query the easyfind server:

Code: Select all

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

It appears that this B3, although it comes from old stock is not included in the production database. While that may not seem illogical on account of the problems preceding the takeover of the Excito brand, I found that a B3 that I already did own before has a higher serial number and apparently does validate.

1. Where it says "production table", should that in fact state "sold items table"?
2. Or does the easyfind server verify a "sold" state flag causingit to ignore this particular B3?
3. Will newly produced B3's be able to use this service, i.e. does Rodeus have a means to maintain the table on mybubba.org?

[MouettE]

I cannot answer on the technical side but Rodeus intends to maintain the easyfind service for the b3. We are still in the transition process though.

[Ubi]

This is strange as the production table really should contain all the IDs from any B23 ever made.
I'll look into the log files whats happening, and if needs be I can add the ID. One caveat again is that this could be an encoding issue still. For some reason the IDs are not hex but contain characters that break URL encoding.

[Gordon]

Hmmm. But these codes are transported using POST method, not GET. So URL encoding should not be an issue. Also, this particular key contains just one special character and that one also exists in the working key/mac0 combo from the other B3. That working one actually contains probably every possible conflicting character that can be in the key: a '=', '/' and '+'.

I also just verified and none of the B3's I got on eBay appear to be known. I suspect this will be the case for all B3's that came from this source: said to be 80 wifi versions and 107 non-wifi

[Ubi]

can you PM or post one or more of the IDs so i can varify on the DB level?

[Gordon]

Will serial numbers do as well?

15377
16144
16742

[Ubi]

I have serial numbers in that table that reach until 12073 only

[Gordon]

That is weird, because I have one that does return a correct response with serial number 160xx (currently don't have access to it). That one I got from the Excito store about a year ago.

[Ubi]

well if you dont give me the ID string I cannot find out

[Gordon]

I'm currently just interested in finding out whether the database is up to date and new production will be added to it.

However, I just added the one that has serial number 16052 with the name 'petibonum' so you should be able to reference that. Possibly the serial numbers you have in the database have some kind of offset, because there appears to be a relation between the serial number printed on the board (and in u-boot env) and the mac0 address: if I multiply the difference by 2 and subtract this from petibonum's mac0 address it gives me the mac0 address for the one with serial number 15377

[Ubi]

ah stupid, looking at the wrong ID column
Yes, found 16052. Also found 15377, 16144 and 16742. The secret-IDs on those do not look special. I'll need to dive into the code to see why these secrets are rejected. I can confirm the keys are not in the dns tables.

now the *real* flaw is that the secret / dns name combination is only negotiated when a new dns name is requested. If however this request fails but the client doesnt know, then the subsequent 'update' requests do not contain both the requested dns name and the key anymore. So if there is a mistake it cannot be solved on the server side.

I think a solution would be to make the client *always* send complete record information to the server. If needs be then this info can be encrypted through public key or whatever, but the current client setup is definitely a problem.

[Gordon]

Right. So they are in there.

Can you verify that the key for 15377 is '****************************'?

[Ubi]

yes

Code: Select all

id    serial   mac1               mac2               secret                        
5137  15377    00:XX:XX:00:37:22  00:XX:XX:00:37:23  ####################

[edit] edited bij Binkem [/edit]

[Gordon]

Then there has to be some kind of secondary check that causes it to return "Unable to validate from production table."

Mind editing that code block? We don't want a non B3 user to try and use that info to steal a myownb3.com entry.

[Ubi]

No I dont mind at all, but how could somebody possible steal an entry?

the way it works is that the client requests a new DNS entry, and it gives its secret-key to the server. The server asks the database if this is a valid key. Database says no. Then server says to client "unable to verify from production". The only way to 'steal' an entry is by guessing a secret-key, which is not very likely considering the entropy of that key.

which code do you want me to alter and in what way?