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.
 
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.
 
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:
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.
 
Bryan Mayland said:
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.
Click to expand...
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.
 
KeithC said:
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.
Click to expand...
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.
 
Bryan Mayland said:
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.
Click to expand...
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.
 
The MAC address of Raspberry Pi 3B+'s Ethernet port seems to change with every reboot.

I am using the Ethernet port on my Heatermeter 4.3's RPi while I do some configuration work and wanted to define a static LAN IP address for the Ethernet network device. While the Heatermeter is running, I looked up the RPi's Ethernet MAC address on the status page my DD-WRT router and configured DD-WRT's DHCP server to always allocate the same unique LAN IP address for the RPi's Ethernet MAC address. Amazingly, when I reboot, the MAC address on the Ethernet port on the RPi3B+ changes. I did it several times and on the DD-WRT status page got several different MAC addresses. Weird! This blocks having a static Ethernet LAN IP address for Ethernet. Any idea what is going on? I am not setup to check this on WiFi but would not be surprised if the same were true.
 
Mache said:
The MAC address of Raspberry Pi 3B+'s Ethernet port seems to change with every reboot.
Click to expand...
I can confirm this is the case. Because the LAN is actually a bridge, OpenWRT generates a new MAC address for the bridge adapter on every reboot.

Solution: In the webui go to Network -> Interfaces -> LAN (edit) -> Advanced Settings -> Override MAC address and set it to the current address. Save & Reboot.
 
Hello Bryan!
First let me thank you for the wonderful project - every time I fire the grill I really appreciate all the effort you put in this.
I have a question that you might know - is there any way to install ddns client? I tried to install using the guide from https://openwrt.org/docs/guide-user/services/ddns/client but got to this https://github.com/openwrt/luci/issues/722 error and now the repo is corrupted. I guess I can re-install the firmware but wonder if could help me installing it? Would be a nice feature to have a personal host name for bbq.
 
You must log in or register to reply here.

 

Back
Top