Re-flashing a WRT54GL running HSMM Ham Mesh firmware

I recently flashed the firmware on a spare Linksys WRT54GL to take a look at ham radio mesh networking on 2.4GHz re-using WiFi routers like the WRT54. I wanted to flash the router back to regular WiFi router firmware, and turned out this was more difficult than it should have been. For future reference, here’s a few notes.

The HSMM-Mesh firmware (3.0) has an admin page to either upload a new firmware to flash, or download an existing firmware from a list of available firmware versions. Neither of these worked for me – uploading a firmware gave an error that it wasn’t recognized, and then the router was connected to my network for internet access, it didn’t give any firmware options other than later versions of the HSMM firmware.

Elsewhere there are instructions for using the tftp approach to ftp a new firmware to the router as it boots. This seemed like an easy option, but I could not get it to work despite trying multiple times.

Instructions for OpenWrt here give steps for ensuring the tftp feature is enabled… this apparently is key, as before following the steps I could not get it to work, but after setting this options it worked first time.

ssh to the router using:

ssh root@10.72.105.9 -p 2222

this is the ip that my HSMM had on starting up, and sshd on the HSMM firmware is enabled by default and listening on 2222.

From thr OpenWrt page above, enter these commands to setup tftp:

nvram set boot_wait=on
nvram set boot_time=10
nvram set wait_time=10 #important for some models
nvram commit && reboot

Before the reboot step, set your ip address on laptop connected to router as:

192.168.1.2
netmask 255.255.255.0
router/gateway 192.168.1.1
Reboot router, start following the tftp procedure to upload the firmware:

If you are seeing WRQ messages with tftp trace turned on, the router is responding, but not yet accepting the tftp upload. You need to wait until you see messages like this to indicate the transfer is occurring:

sent DATA <block=6562, 512 bytes>
received ACK <block=6562>

These will repeat several times a second until the upload is complete, then they will stop, tftp will disconnect, and you’ll see the router power light flashing, indicating it is rebooting. Wait a couple of minutes until the lights are back to their normal state, and then try hitting the admin page for the new flashed firmware at 192.168.1.1

Amateur Radio Packet – Using Outpost with a software modem

My current packet setup is using the UZ7HO modem software – it seems to work pretty well, and as a software based packet modem it seems to work better than AGWPE since that seems to be a bit temperamental.

I’ve been experimenting using Outpost as a message client via UZ7HO. In the settings (Setup/TNC) on the AGW tab, you can enter an IP address of where your AGW software is running. This is an easy option to connect Outpost with UZ7HO since it can run in network mode. I also typically run a laptop running UZ7HO in my office where my radio is, and then I can connect to it from elsewhere in the house on another laptop.

The first issue I’ve noticed is that if I already have a terminal connected to UZ7HO remotely using my regular call, I can’t connect with Outpost using the same call. I guess this makes sense, and this is where the use of the ‘-number’ suffixes comes in that you commonly see on packet. This is what the error in Outpost looks like if you try and use the same call with no unique suffix:

3/4/2015 10:21:18 PM -- (N2) AGWPE Registration failed. Check for: 1. missing or invalid remote logon/password 2. station ID already in use by another AGWPE application

Ok, so to fix this you could put a number suffix on your call, but then when you connect to a local packet BBS to pick up messages, this doesn’t work as it appears to look for message sent to that matching call+suffix, so I’m guessing the callsign you configure in Outpost really does have to be your real callsign. This means you have to close any other connected terminal apps that you are running at the same time, or, configure the terminal to use a suffix on your call (maybe that makes more sense).

The next issue I’ve run into is that when I connect to a BBS using a terminal app directly, I have the ‘OP’ setting (‘output pause’, I think) set to some sensible number, like 10 lines, so I get the continue/cancel prompt when reading messages, or listing the messages on the BBS. It seems Outpost doesn’t know how to handle this, and will pause forever on message download, eventually timing out and disconnecting. There might be another way to configure this, but the only way I’ve found so far is to connect to the BBS directly, set ‘op 0’ and disconnect. Now when Outpost next connects, it downloads all your messages without interruptions.

 

Success! Packet Radio via the International Space Station

I think this was my third or fourth attempt, but I just successfully bounced a packet off of the ISS as it passed over this evening – if I understand this right, the red highlighted message is my message as I received it coming back from RS0SS (the callsign for the packet digipeater on the ISS):

2014 12 07 iss packet - 1st contact

Amateur Radio Packet via the International Space Station (update 2)

On yesterday’s pass I realized too late that the AGWTerminal software doesn’t send unproto packets needed to send packets via the ISS. I’ve now downloaded UISS, got it sent up and checked into the Sacramento Valley Sunday evening packet net, so looks like everything is good to go.

On this evening’s pass, I started sending my cq unproto packets, but looks like I wasn’t heard. I’m wondering after reading around that my ‘via’ value should be ARISS and not RS0ISS that I was using. Apparently your via should be ARISS, but the packets recevied from the digipeater on the ISS will come from RS0ISS. So, will give it another try on the next pass at a good time.

Here’s the packets I received this evening:

Fm K7LWV-6 To APRS Via RS0ISS* <UI pid=F0 Len=47 >[21:08:50]
=4454.96N/12319.98W`Dallas, OR Via ISS {UISS53}
Fm K7LWV-6 To APRS Via RS0ISS* <UI pid=F0 Len=33 >[21:08:59]
:NWS      :Hello from Dallas, OR!
Fm N7HQB To CQ Via RS0ISS* <UI pid=F0 Len=45 >[21:09:04]
=40.637569n/111.931580w/Hello From SLC Utah!