Forum Replies Created
-
AuthorPosts
-
uRADMonitorKeymaster
Nice.. there should be a prize for this 🙂
The checksum will be changed to a more secure implementation.
uRADMonitorKeymasterYes!
We should start this discussion and decide how to handle such events / alarms.
uRADMonitorKeymasterI will do my best to implement everything that helps this project, so it becomes useful.
uRADMonitorKeymasterThe temperature is the internal temperature of the unit, as the DS18B20 sensor is mounted inside.
It is equal to the ambient temperature plus a few degrees added by internal electronic component heating (especially the Ethernet module).uRADMonitorKeymasterThe “real” address pool is in plan.
uRADMonitorKeymasterYup, that’s the one. Just remember to set it to 3.3V when using it with the uRADMonitor PCB.
By default it comes configured for 5V, and there is a switch (or a resistor that needs to be cracked/unsoldered) to change it to 3.3V. There is silk print indicating this on one of the sides.
uRADMonitorKeymasterSounds great! I’ll just need a few more days to have an automated clone / deployment in place, and all the GIT repos.
uRADMonitorKeymasterIt does look normal, but the header is missing. This results in the 400 Error code. The image shows a dash on each row. For other units there’s the user agent there.
What’s strange is that a few days ago, 11000016 was working fine . Did anything change in the network setup?
For Rick’s unit, 11000009 the problem was from the beginning.
But both units worked perfectly here, while running the tests.
uRADMonitorKeymaster@Rick, the problem for 11000009:
[Fri Dec 12 21:46:27 2014] [debug] protocol.c(792): [client 72.47.*.*] Request header field is missing ‘:’ separator: \x01\xff\xff\xff
[Fri Dec 12 21:46:27 2014] [error] [client 72.47.*.*] request failed: error reading the headers
@Lars, the problem for 11000016:
[Fri Dec 12 21:44:42 2014] [debug] protocol.c(792): [client 178.255.*.*] Request header field is missing ‘:’ separator: /\xf3\x01\xff\xff\xff
[Fri Dec 12 21:44:42 2014] [error] [client 178.255.*.*] request failed: error reading the headers- This reply was modified 9 years, 10 months ago by uRADMonitor.
uRADMonitorKeymasterGood idea. Support forum created and this topic moved.
Regarding the problem, I have investigated things further. Must say this seems to be an elusive bug and I have wasted a few hours to track it already.
Apparently the two units get to the server with their User Agent info stripped. Probably other parts of the packages are changed as well. Also the source IP is null. I don’t know what on their route changes their HTTP headers. Local tests didn’t show this issue, and it is impossible to consider a malfunction of any kind.
I can only assume a firewall would be able to have this intrusive result.
With the User Agent info removed and no source IP, the server denies the packages with a HTTP 400 Error code (Bad request).
I will see what I can do about this.
- This reply was modified 9 years, 10 months ago by uRADMonitor.
uRADMonitorKeymasterFeel free to post a link Mike!
uRADMonitorKeymasterHere is a snapshot of the access log. Because the packets are not landing on data.uradmonitor.com, the server issues a HTTP 400.
As the unit is unable to get a valid reply, it auto-resets after 5 minutes. See the ts parameter, which is the local time of the unit in seconds, it never goes over 240 (=4×60 seconds, on the fifth it resets).
Two units are currently having this problem, 11000016 and 11000009 . I will find out why.
Attachments:
uRADMonitorKeymasterLars, 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 9 years, 10 months ago by uRADMonitor.
uRADMonitorKeymasterSo I am correct in assuming that on routers that send it we have a problem, on those that don’t we’re fine.
uRADMonitorKeymaster -
AuthorPosts