Forum Replies Created
-
AuthorPosts
-
Radu
KeymasterLars, I found the problem
Your unit resolves the server DNS as it would be uradmonitor.com instead of data.uradmonitor.com
The packets are hitting the wrong server.
I will see what I can do at my end.
-
This reply was modified 10 years, 4 months ago by
Radu.
Radu
KeymasterSo I am correct in assuming that on routers that send it we have a problem, on those that don’t we’re fine.
Radu
KeymasterRadu
KeymasterI think you’re right Ben. And this makes it strange: to get inconsistent behaviour depending on the network!
I have a router that I know was causing some problems with uRADMonitor units. I’ll need to find it and run some tests before I can report back.
The DHCP code was mainly written by me, and in the last revision I added the hostname option (in the form uRADMonitor-
). Previously you would only see the MAC, the allocated IP and no hostname. I might have done something wrong so hopefully things will clarify. Another option is checking it against the Arduino implementation, but I find that complicated with all the Arduino libs and custom I/O code.
Radu
KeymasterSounds great! And nice work
Radu
KeymasterLooks great, Peter! Congrats on the nice installation.
Radu
KeymasterThe 02…. are locally administered addresses. Nothing special about them just that they are free. To register universal administered addresses I will have to pay some money. I will do that in the future.
Vinz, are you getting the same issues with DHCP? can you post more details?
In my local tests, DHCP was fine, so it’s a bit hard for me to replicate this for a fix:
Attachments:
Radu
KeymasterI’m afraid there were no updates. So the change must have been local. Yes, currently there are several IP used. The one for data is correct: 23.239.13.18.
Lars, just as a note, I don’t think this is physical, nevertheless if you are unable to find the problem, you can send the unit back anytime to get a replacement.
Radu
KeymasterHello Vinz,
I think you have covered pretty much everything to secure the problem and even beyond that to detect if a device is behaving suspicious.
Also @Jeff ‘s suggestion on checking upload interval is important in limiting invalid data.
Unless anyone has anything else to add, I will propose this as solution, and standardise it in a specs document written for the next firmware release.
Radu
KeymasterIndeed patching would automate the production of unique firmware binaries, without compiling the source code every time.
But there is also the approach presented here: https://www.uradmonitor.com/topic/automated-device-ids/
The eeprom can also be written without changing the firmware using a separate script, after main firmware is written.
Radu
KeymasterVery good ideas, I find the one with the favourite station particularly useful.
Radu
KeymasterI’d say yes, it seems a useful thing to have, although my experience with Wiki is limited.
Radu
Keymasterhighcarts.com looks interesting, I will check it out in more detail.
@vinz, would you post the link to your implementation here?Radu
KeymasterI love this idea. Clean and efficient!
-
This reply was modified 10 years, 4 months ago by
-
AuthorPosts