Hl2B9 - Stuck in strange mode

[Jiri Culak]

Hello group

I am currently on a visit to UK to see my friends at GBxHQ...anyway I left my HL2 running as a remote station (lucky with IC7300 as a spare) but suddenly my HL2 moved from it's DHCP assigned address to a default 169.254.19.221. I am unsure if that happened because of power cut (I use Extreme Network's RFS4K Wireless Controler also as Switch/PoE and it takes about 3 minutes to boot up) but what is strange is that in the past, I was able to use SparkSDR/Quisk to Flash RBF file, which then causes the HL2 to reboot and cycle the DHCP request. What is happening now is that regardless what I try, I fail with erasing the current gateware. Both Quisk and SparkSR jointly report same thing...after little while, erasing failed... 

Since I am away physically , and I dont have yet SmartAC Socket allowing me to power cycle just the PSU for HL2, is there anything (hidden CLI...etc.)which would cause the HL2 to reboot?

PS - Option RESET on EXIT in Quisk seems to do partial reset. If I opt out for fiexed IP, and tick reset-on-exit, and exit, next time HL2 broadcasts its new fixed IP address while still being only reachable on 169.254.x.x private address.

73 Jiri OK2IT/M0ITY

[Steve Haynal]

Hi Jiri,

Interesting behavior. Hermeslite.py does have a reboot, but it is the same as what Quisk does. This is a full warm reboot. Information such as the fixed IP, whether to use DHCP or not, and MAC etc., are stored in a separate EEPROM so are not overwritten by rewriting the gateware. The same chip which sets the bias has some free EEPROM and that is what is used. I wonder if something with the i2c interface on that chip went awry and now requires a full cold reboot. 

I assume you have checked and set fixed IP, favor DHCP, and other options the way you want? For remote settings, I usually set a default fixed IP in a subnet I like, but also set favor DHCP so DHCP will be used if available.

I'd also check your DHCP server. Maybe something failed during a DHCP renewal and your DHCP server thinks an address is assigned but the HL2 does not. Maybe you can manually remove any lease.

Regarding why any programming of the gateware now also fails, perhaps that is also related to some of the serial interfaces locking up. Gateware programming also must read/write another external EEPROM. It might also be related to the private address in use, although I haven't heard of other cases of that. Maybe you just experienced a bit flip due to the more active solar weather. :)

https://radiolab.org/podcast/bit-flip

Please let us know what you find. There have been about a dozen cases of HL2s going in to private IP mode without the user doing anything. Usually one can reboot in factory mode and clear the use fixed IP bit. I'd like to get to the bottom of this.

73,

Steve

kf7o

[Jiri Culak]

Hi Steve / group,

I managed to stop by and before power-cycling the HL2 I made sure that DHCP runs / etc.

It was actually powercycle which helped at the end, but I was trying to reproduce it and it seems that i my case (I am running older enterprise grade network, where my access switch also acts as Wireless Controller and after powercut, it takes up to 3-4 minutes to start passing any traffic!) I must have had a brief powercut, where HL2 broadcasted dhcp discovery but after a while it failed and reverted to default private IP (fixed that with fixed C class address that is same as DHCP Address reserved for HL2) but what was strange is that once it entered that mode, I could not get it to RESET itself. 

For that purposes I have a VNC onto the remote network and one of the older MacBooks is running a ethernet wire and indeed I coud ping the 169.254.x.x and could work the hermes just fine - when trying to reset via quisk, nothing, stayed on 169.254... and just for fun, when trying to flash new beta gateware, in hope that after successfull flash, it would ReBoot the HL2 also, it resulted in failed message (Failed to erase gateware).

I will try to reproduce it in the LAB once I am back at location.   BTW = it is build 9, one of the later builds by MakerFabs.

73 Jiri

Dne sobota 8. července 2023 v 20:39:52 UTC+2 uživatel softerh...@gmail.com napsal:

[Steve Haynal]

Hi Jiri,

Thanks for the update.

73,

Steve

kf7o