Real-time Environmental Monitoring

This topic has 27 replies, 5 voices, and was last updated 10 years, 1 month ago by Radu.

Viewing 12 posts - 16 through 27 (of 27 total)

← 1 2

Author

Posts
December 12, 2014 at 2:10 pm #874

Radu
Keymaster

So I am correct in assuming that on routers that send it we have a problem, on those that don’t we’re fine.

December 12, 2014 at 11:01 pm #896

Andromedan
Participant

No, the router *should* send a DHCP Offer to any device before it requests an IP, it must just be me that isn’t picking the packet up in Wireshark.

I think it’s still going to boil down to the DHCP implementation in the firmware, but without the ability to chew through the code & alter it on the fly, I’m unable to speculate further on why exactly some of us are having this issue.

December 12, 2014 at 11:12 pm #898

vinz
Member

ok, but what is wrong in this packages? wireshark is very unspecific …
We have to learn more about the contents of this packages, I think.

December 12, 2014 at 11:18 pm #899

Andromedan
Participant

Yeah, I can’t get any more information out of wireshark either. It’s error (as far as I’ve read), is because the packet decoder can’t decode that particular packet properly.

I’m attempting to do some DPI on the DHCP packet vs a valid packet to see what it’s flagging on, not sure how far I’ll get though.

December 13, 2014 at 12:05 am #900

vinz
Member

that’s a good idea. Have to look for a better doc.

What I wanted to say, viewing the code will not help, as long as we don’t know what we are looking for.
I’d assume problems with the device-name, but don’t see it. 😉

December 23, 2014 at 5:34 am #1027
Cyan Labs
Participant
I’m getting the same issue it seems.

I’m running a Windows 2003 DHCP server. Nothing special. I can see the MAC address hitting the switch and successfully negotiating a link but that’s where it stops.

However it works if I use the DHCP server built into pfSense (my router/firewall).

Any ideas?
- This reply was modified 10 years, 4 months ago by Cyan Labs.
December 29, 2014 at 6:55 pm #1038

vinz
Member

@Andromedan and others

Radu just sent me a new version of the firmware.
This version fixes the DHCP problem described here.
I see an all-green capture now. 🙂

Further comments on firmware here: https://www.uradmonitor.com/topic/the-new-firmware/

Vinz

January 2, 2015 at 6:49 pm #1101
Radu
Keymaster
hi Vinz!

Great to hear that. Let’s discuss the proper formatting and the JSON issue here if you wish.

You’ve indicated the minimum content for a valid HTML5 format:
```
<!doctype html><html lang=en>
<head><meta charset=utf-8><title>blah</title></head>
<body><p>I'm the content</p></body></html>
```
I agree, but we have a big problem: memory (RAM).
uRADMonitor model A uses the mega328p, which has a total of 2KB RAM. There is also 1KB of EEPROM (where HTML static text like the one you’ve indicated could be stored).

BUT,
To send data over Ethernet we need to maintain a buffer. This is already 400bytes long (consuming almost a quarter of all available memory). Adding the doctype, the head, any metas, the title, body or any other formatting would consume precious memory, a total of 125Bytes that we don’t have (hashing, RSA, etc will eat any free memory, and we need those to secure comm links)
So the best bet might be to go with absolute minimum, letting the browsers go for default.

What do you think?

Regarding the JSON:
```
Þ¿ýòü|ó¿s¿ ßó;÷ ö }‘° ß¿V{ï{ŽÿÝõ«þ‰~Ë~‘í Gó$cŸ½—Ýÿ ;úÝ —ß ne¿ û ß+ÖÓÿžóÄfÛã^û çùú± ýÀ"type":"1","detector":"SBM-20","cpm":18,"temperature":0.31,"uptime": 2463}}
```
What browser did you use? Do you see it in all browsers you have at hand?
(I tried in two and didn’t see this issue, so we need to see where this is coming from).

Also with your spoofed DNS, I’m curious what do you see under Server IP in the embedded web-page?
- This reply was modified 10 years, 4 months ago by Radu. Reason: html issues
- This reply was modified 10 years, 4 months ago by Radu.
- This reply was modified 10 years, 4 months ago by Radu.
- This reply was modified 10 years, 4 months ago by Radu.
- This reply was modified 10 years, 4 months ago by Radu.
- This reply was modified 10 years, 4 months ago by Radu. Reason: html and json formatting issues
January 3, 2015 at 10:13 pm #1117
vinz
Member
hi Radu,

Valid HTML
That’s OK, I see the problem with controllers memory.
We have to see, if there are issues with browsers.
I don’t need this server, but there is a benefit for local use or local (third party) data processing.

Maybe you should only return that JSON (with word-wrap \n), it is quite readable. A nice HTML5 version could be a HW-update with more EEPROM.

JSON
It looks like this at the moment.
Þ¿ýòü|ó¿s¿ßó;÷¬ö }‘° ß¿V{ï{ŽÿÝõ«þ‰~Ë~‘í Gó$cŸ½—Ýÿ ;úÝ—ß ne¿ û ß+ÖÓÿžóÄfÛã^û çùú±ýÀ"type":"1","detector":"SBM-20","cpm":20,"temperature":10.81,"uptime": 186086}}

I used current Firefoxes on Win7, OS-X and Linux. I checked others, all the same.
But have a look at lynx, attached. 😉

Do you have code included in EEPROM? I don’t think so.
What should I see in these cryptic parts? Think this is quite short, maybe it’s only “{{“.

Server IP
See attachment, too.

Vinz
Attachments:
1. lynx1.png
2. lynx2.png
January 18, 2015 at 9:21 pm #1244

vinz
Member

Thanks Radu for the current firmware.
It works fine and also fixes the JSON issues described here.

For all interested in this, JSON now looks like this:
{"data":{ "id":"11000035""type":"1","detector":"SBM-20","cpm":20,"temperature":4.69,"uptime": 19544}}

You could use it for your own analysis or 3rd-party processing.
See the nice work, Pixel K did:

Firmware upgrade

March 6, 2015 at 3:24 am #1491

Cyan Labs
Participant

I’m pleased to report that on Firmware version 111, my unit now correctly obtains an IP address from Windows DHCP servers.

March 6, 2015 at 1:22 pm #1494

Radu
Keymaster

Sounds good, thanks for the update!
Author

Posts