Shark hunt on LW301


Shark hunt? As a passionate diver, shark hunt is an absolute “no-go” for me. But as a networker I love to go hunting with a shark – with the Wireshark. Wireshark is one of the best network protocol analyzers. It lets you see what’s happening on a network at a microscopic level.

Why shark hunting?

In spring I wrote about the problems I have with my Oregon Scientific LW301 weather station. Several readers contacted me because they encounter the same problem. Fact is that one owns a weather station but can only read the gathered data over the Internet using a rather badly developed Android, iPhone or Windows App.

The weather station’s data is inside your own network, but you have no access.  This had to change. Two guys In France and South Africa gave me very useful input. The only thing I lacked was time. Yesterday I found enough time for the hunt.

Set up the hunt

Shark hunt with WiresharkClick on the photo to enlarge

On the left side you see the Oregon Scientific LW301 with the attached wireless receiver (single green LED). The LW301 is connected to a hub (an old Netgear 4 port hub). This hub is connected to the laptop on the right (black cable) and to the WAN router (pink cable).

In the laptop runs the latest version of Wireshark. You may want to download it – here it is!

Step by step

I absolutely do not know what is inside the Oregon Scientific LW301. There must be a micro-controller like an Arduino or a Raspberry Pi or a  BeagleBone. But I do not want to open the “Black Box” – never touch a running system. So I had to look inside over the network.

Step 1: The network address

Fortunately the LW301 has the MAC address printed on the label stick on the case. A media access control address (MAC address) is a unique identifier assigned to network interfaces for communications on the physical network segment. MAC addresses are used as a network address for most IEEE 802 network technologies. So it hadn’t been to difficult to see what the Oregon Scientific LW301 is doing on the network when powered on. Network gurus may want to click on the pictures below to read the data from Wireshark.

Sharkhunt with Wireshark

The Oregon Scientific LW301 first tries to get an IP address from the DHCP server. Wireshark also detected the brand of the network module – it’s a Mirochi. My Linksys (CISCO) router then assigned an IP address to the Oregon Scientific LW301 using DHCP.

Sharkhunt with Wireshark

Here  are the details of captured frame 166:
Sharkhunt with Wireshark

The Oregon Scientific LW301 got the IP address from the DHCP server. This is good to know because now we can leave the hardware layer (MAC address) and move up to the Internet Protocol layer. But before we leave the underground, the Wireshark detected that the LW301 is already contacting Oregon Scientific ( It sends a DNS request to the name server of my network provider –

Sharkhunt with Wireshark

Oregon Scientific then answers much later – it’s across the whole Pacific Ocean – and tells our LM301 where it can be found. Now let’s quit this low level of data communication.

Step 2: Find the right server

 Sharkhunt with Wireshark

How is this data transmitted to Oregon Scientific? How it comes back to my PC doesn’t interest me because I want to read the data in my house without traveling twice under or over the Pacific Ocean.

The chat is now open between (my weather station) and (a server at Wharf T&T Limited in Kowloon). The surprise will come later …

 Sharkhunt with Wireshark

The Oregon Scientific LW301 sends a synchronization request on TCP level (Transmission Control Protocol)  to the remote server. Important to know is that the LW301 uses port 1109, a non standard port, and the remote server uses port 80, which means that it is a web server understanding HTML. This will make the future investigation much simpler because HTML is very readable for humans.

The remote server then confirms the SYN request and asks the LM301 to communicate from his port 1109 to the servers port 80

Sharkhunt with Wireshark

In sequence 432 the LW301 sends a GET query to  And then in a long chat the LW301 gets a new server name. The chat is so long because many packets did not arrive completely due to network congestion. And frankly, I do not know in which packet the new server name had been transmitted. The new server to contact is:  This is the Anywhere Weather homepage.

Sharkhunt with Wireshark

During a chat with the Oregon Scientific name server our LW301 gets a new address to contact … The big surprise !

Sharkhunt with Wireshark

Address “” belongs to !

I seems that Oregon Scientific has abandoned Google’s cloud services and has moved to Amazon. This finally also explains the very long data exchange between the weather box and the Oregon Scientific servers. Our little box had to find out, where to send the weather data.

 Step 3: The weather data transmission

Now the Oregon Scientific LW301 is ready to exchange weather data with the cloud server. The following sequence runs now about every minute.

Sharkhunt with Wireshark

The most important packet is # 1145. Inside this packet comes the desired payload, the data from our weather station:

Sharkhunt with Wireshark

The data starts after the dark grey zone. It reads:

mac=00 04 a3 68 e9 74 (that’s the MAC address of our LW301)
id=84 (I don’t know what ID this is)
rid=b3 (Again, I don’t know)
pwr=0 (Power ?)
htr=0 (Again ???)
cz=0 (Still cryptic ?)
oh=65 (Aah, Outdoor Humidity is 65%)
ttr=0 (???)
ot=31.5 (Outdoor Temperature is 31.5 Celsius Grades)
ch=1 (The sensor’s channel is number 1)
p=1 (Again, I don’t know)

But at least 4 of the 11 items are identified.  So the LW301 sends this data as one sausage to :
The Amazon server then acknowledges and our box continues to send. The next payload contains wind inforation:

mac=00 04 a3 68 e9 74 (that’s the MAC address of our LW301)
id=90 (I don’t know what ID this is)
rid=dd (Again, I don’t know)
pwr=0 (Power ?)
gw=0 (Don’t know. Seems to be an average)
av=0 (Don’t know. Seems to be an average)
wd=45 (Wind direction is 45 degrees
wg=2.2 (Wind gusts is 2.2 m/s))
ws=0.0 (Current wind is 0.0 m/s)
ch=1 (The sensor’s channel is number 1)
p=1 (Again, I don’t know)

Barometric pressure and rainfall are still missing.

mac=00 04 a3 68 e9 74 (that’s the MAC address of our LW301)
id=82 (I don’t know what ID this is)
rid=5a (Again, I don’t know)
pwr=0 (Power ?)
rro=0 (A rainfall average)
rr=0.00 (Another rainfall average ?)
rfa=0.204 (Current rainfall is 0.204 mm) It really rained!
ch=1 (The sensor’s channel is number 1)
p=1 (Again, I don’t know)

mac=00 04 a3 68 e9 74 (that’s the MAC address of our LW301)
id=c2 (I don’t know what ID this is)
pv=0 (?)
lb=0 (?)
ac=0 (?)
reg=0803 (Region ?)
lost=0000 (?)
baro=1006 (Barometric pressure in hPa)
ptr=0 (?)
wfor=0 (Weather forecast ?)
p=1 (?)

Now we have a lot of data. Some data can be decrypted, other information needs more observation. Important for the network gurus is that the LW301 increases the portnumber with each transmission.

The next transmission after a few seconds is again a wind information:

mac=00 04 a3 68 e9 74 (that’s the MAC address of our LW301)
id=90 (It is again 90. Seems to be the sensor ID)
rid=dd (Again, the same. Seems also to be a sensor ID )
pwr=0 (Power ?)
gw=0 (Don’t know. Seems to be an average)
av=0 (Don’t know. Seems to be an average)
wd=292 (Wind direction is 292 degrees
wg=1.9 (Wind gusts is 1.9 m/s))
ws=1.5 (Current wind is 1.5 m/s)
ch=1 (The sensor’s channel is number 1)
p=1 (Again, I don’t know)

Let’s stop for now. There is a lot of information to crunch and to interpret. For me still the big question is how to intercept this data and redirect it to my in-house server.

For those who have network knowledge and want to help me. I have two Wireshark capture files. One containing the initial server data exchange and one containing the weather data exchange. Send a comment and ask for the files, I’ll then send them by e-mail. I am now going hunting with the real sharks.


Stop Shark Hunting – hunt with the Sharks !


Share if you like

You may also like...

11 Responses

  1. dees talma says:

    I am playing the same game, with the same end. I would appreciate your pcap files by email. We may end up a workable package for both and others.

  2. waebi says:

    Hello Dees,
    Welcome in the club! Now we are already four! I’ll send you two pcap files tomorrow morning. Here it’s already dark night.

  3. Steven says:

    Yesterday afternoon mine stopped showing the data for all 5 sensors. I initially thought it lost the connection to the sensors so tried to reset, but nothing. Now connected to my laptop and with Wireshark I can see HTTP500 Internal Server Error when calling the /update scripts on their website.
    This is where logging to local site might prove useful. From my wireshark I can see that its a post with a bunch of params. I can see UV index, for example. Each sensor has its own post to /update.

  4. Steven says:

    Ok, so I have gone through all the POST requests and the data is pretty clear like you have dissected it in your post. The best solution would be to use Squid as a transparent proxy and configure logger to dump headers for HTTP POST. Then use a simple script to parse out the name/value pairs and write them to a mysql or sqlite3 db. This way, it will still go to Oregon and you can have a local copy.

  5. Steven says:

    Just so that it may help someone:
    Two solutions: 1 – both local + Oregon, 2 – only local.

    1. Setup any Linux box attached to the local net with ip forwarding (on dhcp set the gw as this box) and use tcpdump to capture:

    root@nas:~# tcpdump -A -s 0 ‘src and tcp dst port 80 and (((ip[2:2] – ((ip[0]&0xf)<>2)) != 0)’ | grep mac

    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes


    then its just a matter of using awk or something to get all the parameters out and store them in db.

    2. Standalone solution. Create an entry in router DNS to resolve to your Linux box which runs apache or tomcat or use iptables to redirect traffic setup through the Linux box as gateway (as in solution 1) destined for or from Oregon blackBox ip to apache or tomcat port and then write a script (or servlet) to extract all POST data and place the script under /update on the web server.

    • waebi says:

      Thank you Steven.
      I can confirm the 24+ hours black-out of the Oregon Scientific server (cloud).
      Thank you also for your solutions with a Linux box.
      This solution is similar to the one Dees had already proposed.

      I have decided to send the Oregon Scientific LW301 to the trash bin. I think that giving it away even for free is not honest.
      I’ll replace the Oregon Scientific LW301 by a Davis Vantage Pro2.

      Here in the Philippines we need reliable weather information. The government’s meteorologists are good, but aren’t allowed to publish the analysis when an approaching storm system is still outside PAR – the Philippines Area of Responsibility. I get the best data from JMA – the Japan Meteorological Agency..
      But when it comes to local weather, I need a reliable tool.

      Stay tuned guys. In January I’ll publish the first results from the Davis Vantage Pro2.

      Wish you sunny and nice weather

  6. Tammo says:

    reg=0803 (Region ?)

    “reg” seem to be the registered sensors.
    0803: Wind, Temp, Rain
    1803: Wind, Temp, Rain, UV

    wfor=0 : forecast (0=partly cloudy, 1=sunny, 2=cloudy, 3=rainy, 4=snowy)

    lost=?? Value went to 0800 as i took out batteries from rain gauge.

  7. andru says:

    it’s simple php script to write station data to text file
    ” . file_get_contents(“php://input”);
    $f = fopen(‘/var/www/html/lw301/log/lw301.log’, ‘a’);
    fwrite($f, $req . “\n”);

  8. Gengis says:

    I found this free software that supports LW301 Oregon pseudoScientist 🙂

Leave a Reply

Your email address will not be published.

Enter Captcha Here : *

Reload Image

error: Content is protected !!