Weather Station Hardware > LaCrosse Technologies/Hyundai

LaCrosse Wireless Internet Gateway Model GW1000U ERF-100

<< < (2/99) > >>


--- Quote from: thobas on March 13, 2012, 07:31:34 PM ------The part that is making me return this device and look elsewhere for this
5)The octet stream is not in any way human readable, so I tried other possible encodings.
It is not UTF-8
It is not ASCII
It is not JSON compatible
It is not MIME

--- End quote ---

Ah!  A puzzle!  I like puzzles and am a senior software engineer.  I am sniffing packets now to see if I can figure out the data format.

Did you use a dumb hub or did you sniff your switch/router in promiscuous mode?

Just saw the reply from skydvrz.  I finally got around to trying my ERF-100 registration on a DSL connection and it worked just fine.  Apparently my problem was coming from my wimax internet provider in Missouri.  Now I think I'll go buy another C84612 (Costco has them in stock again) and start playing with it again.  @skydvrz, I used a dumb hub when I was sniffing packets.  I haven't looked at the packets on this network but probably will once I get a new 84612 to play with.  Right now I just have the gateway.  I left the rest of the stuff installed back home in Missouri.  Have you had any luck?


>Had any luck?

A little  8-)

I have analyzed several hours of data from the IG module.  I used a dumb hub to tee the connection between the IG and my router. 

The IG sends the server 3 different commands, denoted by the two bytes before and after the 64-bit hex number in the HTTP header. I believe the 64 bit number is cryptographically related to your "Activation Code", so that they can ignore your IG for "revenue control" purposes.  Someone earlier in the thread found the IG MAC address in the hex string before the commands - I believe they are correct.

Commands in no particular order:

Command 01:/:00 is some sort of ack/status command - the packet sent with it contains 5 bytes that are mostly the same in each packet, but change occasionally.  The trailing two bytes are probably a 16-bit checksum.  The entire packet could also be the IG probing the server to check if it is valid, but that is a long shot.

Command 00:/:70 is some sort of ping / RTS command.  The server usually responds with 16 null bytes, but sometimes not.  Sometimes the server fails to respond at all.  I believe the trailing two bytes of the server's response is a 16-bit checksum, but I have not verified this.  This command may be a throttling command to lower bandwidth on the server, or to verify that the server is up, working and ready to receive data.  I will have to look at the timing data to see if this is a throttling mechanism for the server or something else.

Command 01:/:01 is the sensor data packet.  It *looks* like unencrypted data fields.  But seriously!  197 bytes to send this teensie amount of data?!  I could send full-precision data for all the sensors in one 8-9 byte packet.  I suspect the data fields are sent in some sort of record or structure, probably full of double precision numbers in binary format.  They may or may not be packed, but I doubt they are encrypted.  Unpacked data would have "padding bytes" stuffed in between fields with odd-numbered field-width byte counts.  Most of the payload records have only minor changes when compared to previous records;  They should look completely random if the fields are encrypted.  I believe the trailing two bytes of the sensor data payload is a 16-bit checksum - probably CRC16.

The only thing to figure out is the data type and field locations within the record for each sensor reading, and how to simulate a server - you would need to "keep the IG talking".  It may clam up if it cannot contact the mother ship.   I doubt a server simulator would take much rocket science.  It is possible to set the DNS server IP in the IG to an address of your choice, so it would be trivial to hijack it and have it chat with your PC instead of its normal server.

I noticed occasional data packets of 0x25 length.  These appear to be alarm packets produced if you set a min/max alarm value on your LCD controller.  They do not appear to be encrypted.  More research needed here.

Note: encryption may be in use, but if so it is probably simple XOR encryption with a fixed key.  Clueless newbie stuff.

I have no idea why they used checksums on all the data - the TCP/IP hardware layer insures there are no data errors, so it was a waste of time and bandwidth.

I am designing a program to do further analysis on the sensor data payload packets.  More to follow...

When the server responds with 38 bytes of data in response to an 01/00 command from the gateway, the contents sent by the server is the time of day, DMY info.  Used to keep the LCD controller clock accurate I would assume.  I am not sure what the leading 22 bytes do, and some of the trailing bytes remain a mystery.

great! I sprung for another weather station and have it up and running with Their server seems a bit flakey imho. I'll have to get my sniffer back up and running to see if I can replicate what you found and add to it.
Good work so far.


[0] Message Index

[#] Next page

[*] Previous page

Go to full version