Stable firmware release v15


 
Is there any logic to reconnect to wifi if it is dropped? I've been troubleshooting my wifi6 early release environment so have had a lot of firmware changes/restarts and I am seeing this behavior on raspi 3A+ and 3B+ on the latest v15.
 

Bryan Mayland

TVWBB Hall of Fame
It reconnects on its own if the connection drops, I have no control over it because it is in the wifi binary blob driver. I have seen it get stuck for a while before, but it usually resolves itself eventually.
 
Ok, I'm seeing this on both HMs on the Pi 3+ I can reboot them and they connect, however if Wifi is interrupted for more than a couple minutes they do not appear to auto-reconnect.
 
I confirmed this tonight when I updated my Ubiquiti firmware. All other devices reconnect including Raspi with raspi OS, ESP32 and BeagleBoneBlack. HM didn't. My Raspi(original) with Edimax would reconnect on its own but the Raspi 3B+ and 3A+ do not. One is on 'Legacy' Wifo mode and one is on AC, both with the same behavior.
 

Bryan Mayland

TVWBB Hall of Fame
As I said, I can't do anything about how the Pi's wifi works. It's a binary blob so you get what Broadcomm gives you. It's not happening in user space. There might be a newer version available but we'll evaluate that when everything is brought up to the latest version.

EDIT: Actually I forgot that I did have a monitor hooked up once when it wasn't reconnecting and even though I tried to restart the network, the driver was in a broken state so it wouldn't even respond to commands without taking several seconds and erroring out. The only way to fix it was to reboot.
 
Last edited:
Gotcha. It really does seem to be with the newer Pi so driver would make sense as to why the earlier and Zero are unaffected. Is the latest v15 based on 19.7.6?

And just to be clear, I'm not complaining, just trying to understand what exactly the issue is. I can always go back to my original PI and resolve this.
 
Last edited:

Bryan Mayland

TVWBB Hall of Fame
hehe actually I'd prefer if it were. The story goes that LEDE split off from OpenWRT and all the developers I knew (from their work) went to LEDE so I converted everything to follow that project, which meant rebasing patches as they were converting the way the project was layout. Then, like six months later, they worked out their differences with the OpenWRT people and decided to remerge into one project. I didn't want to go through the effort of reconverting everything back to OpenWRT so I put it off as "v16 milestone".

As part of the next HeaterMeter release cycle, I'll be converting it all to OpenWRT again and targeting their next release as our platform. They don't have any sort of roadmap with even approximate release dates so it is hard to target our releases to theirs, but at least we won't be tied to a dead tree any more. OpenWRT has since come up with their own way of doing OverlayFS on the Pi target, so it's going to be fun figuring out how to rearrange the OverlayFS I created for us to fit their way. They've also reorganized a lot of the project filesystem, and changed how the data that backs the web pages works completely so that's all going to be fun to figure out.

And I had a good laugh this morning when I rebooted my home wifi router and my always-on HeaterMeter v4.2 with an Edimax dongle failed to reconnect to the network. Oh wait! Just checked http://heatermeter.com/devices/ and it just got a new IP address. Wow. It had that IP for years, someone should just give it a static IP already.
 

KeithC

TVWBB Member
hehe actually I'd prefer if it were. The story goes that LEDE split off from OpenWRT and all the developers I knew (from their work) went to LEDE so I converted everything to follow that project, which meant rebasing patches as they were converting the way the project was layout. Then, like six months later, they worked out their differences with the OpenWRT people and decided to remerge into one project. I didn't want to go through the effort of reconverting everything back to OpenWRT so I put it off as "v16 milestone".

As part of the next HeaterMeter release cycle, I'll be converting it all to OpenWRT again and targeting their next release as our platform. They don't have any sort of roadmap with even approximate release dates so it is hard to target our releases to theirs, but at least we won't be tied to a dead tree any more. OpenWRT has since come up with their own way of doing OverlayFS on the Pi target, so it's going to be fun figuring out how to rearrange the OverlayFS I created for us to fit their way. They've also reorganized a lot of the project filesystem, and changed how the data that backs the web pages works completely so that's all going to be fun to figure out.

And I had a good laugh this morning when I rebooted my home wifi router and my always-on HeaterMeter v4.2 with an Edimax dongle failed to reconnect to the network. Oh wait! Just checked http://heatermeter.com/devices/ and it just got a new IP address. Wow. It had that IP for years, someone should just give it a static IP already.
Dumb thought, wouldn't this just sit on top of the regular RaspianOS as well, or is that just way too much retooling? Just curious is all. thanks for the dedication still on these releases.
 

Bryan Mayland

TVWBB Hall of Fame
Dumb thought, wouldn't this just sit on top of the regular RaspianOS as well, or is that just way too much retooling? Just curious is all. thanks for the dedication still on these releases.
Switching to Pi OS would mean everything would have to be rewritten for whatever platform we'd use there. The existing code won't run on Pi OS as far as I know. We'd have to pick a new platform (apache+???) and integrate some system admin stuff too like backups and wifi configuring. It would be a lot of work too, and then you'd also force people to download like a 2GB OS image that would have to be hosted, along with no automatic wifi configuration (or I'd have to custom build the giant OS image with the config baked in which won't work on the current way I do it). There's a lot of downside even after a lot of work so it isn't a clear win.
 

KeithC

TVWBB Member
Switching to Pi OS would mean everything would have to be rewritten for whatever platform we'd use there. The existing code won't run on Pi OS as far as I know. We'd have to pick a new platform (apache+???) and integrate some system admin stuff too like backups and wifi configuring. It would be a lot of work too, and then you'd also force people to download like a 2GB OS image that would have to be hosted, along with no automatic wifi configuration (or I'd have to custom build the giant OS image with the config baked in which won't work on the current way I do it). There's a lot of downside even after a lot of work so it isn't a clear win.
ok, that makes sense. hopefully OpenWRT is still a thing & supported well for the foreseeable future, then understandable why to not make that jump. thanks for the insight.
 
Top