Real-time Environmental Monitoring

This topic has 23 replies, 8 voices, and was last updated 10 years, 3 months ago by Radu.

Viewing 15 posts - 1 through 15 (of 23 total)

1 2 →

Author

Posts
December 11, 2014 at 11:50 am #838

Peter
Participant

– 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 #847
Lars
Participant
Connected 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 traffic

Response:
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:

Home

Server side error?
- This reply was modified 10 years, 4 months ago by Lars. Reason: screenshot
Attachments:
1. Screenshot-from-2014-12-11-133440.png
December 11, 2014 at 12:48 pm #850

Andromedan
Participant

Yep, 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 #851

Lars
Participant

Yes, 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 #852

Andromedan
Participant

Indeed very odd. Tried another PSU?

December 11, 2014 at 8:23 pm #857

vinz
Member

Hello,

@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 #859

Radu
Keymaster

I’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 #877
Radu
Keymaster
Lars, 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.
December 12, 2014 at 2:34 pm #878
Radu
Keymaster
Here 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:
1. Screen-Shot-2014-12-12-at-16.31.25-copy.jpg
December 12, 2014 at 6:51 pm #885

Orellanine
Participant

I think we need a support forum.

December 12, 2014 at 9:12 pm #889
Radu
Keymaster
Good 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 10 years, 4 months ago by Radu.
December 12, 2014 at 9:46 pm #891
Radu
Keymaster
@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 10 years, 4 months ago by Radu.
December 12, 2014 at 9:54 pm #894

Lars
Participant

I’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 #895

Radu
Keymaster

It 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.

December 14, 2014 at 6:48 am #922

Erik
Participant

Im not if’s related,
But if you use 3g/4g mobile net, alle trafick runs over a transparent poxy.(router can do the same)
This proxy is use to block “virus” (after som time) or any other programs that sends requst the same info over long periods. This is done to keep the trafick down for the use that pay pr Mbytes off data.
The isp use this to block botnet’s from geting to report back, and avoid ther users from be used in a ddos atack.
Author

Posts