- This topic has 23 replies, 8 voices, and was last updated 9 years, 9 months ago by uRADMonitor.
-
AuthorPosts
-
December 11, 2014 at 9:59 am #837LarsParticipant
After 09.12.2014 my unit 11000016 won’t connect anymore.
I don’t think it’s the same as in https://www.uradmonitor.com/topic/networking-issues/, because it worked before.
I haven’t tried wireshark yet, but have tested it on several networks. Blinking lights, but no updates on web.
- This topic was modified 9 years, 10 months ago by uRADMonitor.
- This topic was modified 9 years, 9 months ago by Lars.
- This topic was modified 9 years, 9 months ago by Lars.
December 11, 2014 at 11:50 am #838PeterParticipant– look at the router, delete dhcp ip adress for uradmonitor. Than reconnect.
– If you have a Fritzbox that make problems…
– test at another router.
Peter
December 11, 2014 at 12:43 pm #847LarsParticipantConnected via laptop to check out the traffic. Wireshark says the urad is getting “400 Bad Request”.
Request:
416 706.134489 10.42.0.22 23.239.13.18 HTTP 228 [TCP Retransmission] GET http://data.uradmonitor.com/upload/0.1/upload.php?id=11000016&p=82&ts=60&inv=377&ind=453&s1t=27.00&cpm=30 HTTP/1.1 Continuation or non-HTTP trafficResponse:
456 886.170028 23.239.13.18 10.42.0.22 HTTP 520 HTTP/1.1 400 Bad Request (text/html)And nothing on map:
Server side error?
- This reply was modified 9 years, 10 months ago by Lars. Reason: screenshot
Attachments:
December 11, 2014 at 12:48 pm #850AndromedanParticipantYep, defintitely server side, look at the originiating IP address in Wireshark.
Although code 400 is for bad client side data sent. Corrupted packets?
December 11, 2014 at 1:59 pm #851LarsParticipantYes, perhaps corrupted packets:
1199 5505.750204 23.239.13.18 10.42.0.22 TCP 58 [TCP Previous segment lost] http > metaconsole [SYN, ACK] Seq=142071037 Ack=1 Win=29200 Len=0 MSS=1460
Buy why? Bad soldering? Bad cable? Too low input voltage?
I have tried two different TP cables.
December 11, 2014 at 3:27 pm #852AndromedanParticipantIndeed very odd. Tried another PSU?
December 11, 2014 at 8:23 pm #857vinzMemberHello,
@Radhoo, could you comment this, maybee there were updates this time?
Is it correct you have two IPs, for data. and main domain?
@Lars, do you have a selfmade firewall which hacks packets out? 🙂Vinz
December 11, 2014 at 8:34 pm #859uRADMonitorKeymasterI’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.
December 12, 2014 at 2:29 pm #877uRADMonitorKeymasterLars, 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.
December 12, 2014 at 2:34 pm #878uRADMonitorKeymasterHere 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:
December 12, 2014 at 6:51 pm #885OrellanineParticipantI think we need a support forum.
December 12, 2014 at 9:12 pm #889uRADMonitorKeymasterGood 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.
December 12, 2014 at 9:46 pm #891uRADMonitorKeymaster@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.
December 12, 2014 at 9:54 pm #894LarsParticipantI’ve got a new modem/router now (unrelated), so I’ll see over the weekend if that helps.
How ever, is there anything missing in the packets you see in https://www.uradmonitor.com/wordpress/wp-content/uploads/2014/12/Screen-Shot-2014-12-12-at-16.31.25-copy.jpg ? The requests look normal to me.
December 12, 2014 at 10:09 pm #895uRADMonitorKeymasterIt 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.
-
AuthorPosts
- You must be logged in to reply to this topic.