I've got openwrt 18.06.4 successfully flashed via uboot's webUI, and it boots up and I can get in and configure it via the CLI like I have numerous other openwrt devices, but if I reboot with the cables (1 LAN and 1 WAN) plugged in (each to their own switch), it will fail to come up completely. I can ping it, but no ssh or web. I noticed that the ping response latency for uboot is typically lower than 1ms and the ping response latency for openwrt is greater than 1ms , and when it's in this partially booted state, the ping latency would indicate that it is uboot and not openwrt that is loaded.
Oddly, I did not observe this phenomenon while configuring and rebooting when connected to my laptop directly via ethernet cable.
I'm wondering if anyone else has seen this.
Incidentally, I ran a quick speedtest and on gigabit fiber routed via pppoe, I was able to clock 700mbit with the CPU of the router at 65% sirq. This is with offloading enabled in the firewall. This would indicate that it's a good candidate for gigabit fiber.
Just to confirm, this is a build from OpenWrt sources, not GL.Inet firmware, correct?
Do you have any different config for the switch? The ipq40xx has different architecture and drivers than most OpenWrt devices. VLANs, in particular need careful thought and configuration.
Good questions. I should clarify. The config is almost entirely stock with 2 well-tested changes entirely outside of the switch config. In /etc/config/network I have a route to a private subnet behind another firewall, and in the WAN config I have commented out dhcp and added the 3lines necessary for PPPOE. I've been using these config changes on openwrt for about 2yrs on at least 5 different routers. The firmware is openwrt, yes, specifically 18.06.4, the latest recommended stable release for this device.
There are also a few standard 'open port and redirect behind the NAT' type changes in /etc/config/firewall. I also changed the hostname in /etc/config/system, but that's it.
My guess was that VLAN configuration was conflicting with the internal use of VLAN 1 and VLAN 2 in the switch driver (this is "not negotiable") and that one is tied to the WAN port (untagged) and the other to the LAN port(s) (also untagged).
If it were in my hands, I'd be hooking up an appropriate 3.3 V serial adapter and looking at the boot sequence. Another option would to log to a USB drive (and capture the output of dmesg there as well, as the stock logger misses early boot messages). Using a non-volatile part of the file system would also work (not /tmp/ and not /var/), as this would be a "one-off" situation, rather than something that was thrashing flash.
Is there any chance that not renaming the openwrt firmware .bin file to lede-gl-b1300.bin could cause issues like this? I just assumed that an incorrect filename would simply result in flash failure.
I don't have a GL-B1300, so I don't know how its boot loader works. At least with the GL-AR300M and GL-AR750S it is either the filename extension or the upload button clicked, not the name of the base name of the file itself. You should be able to confirm the firmware you're running from the logon message, or with cat /etc/os-release
Thanks for the info. With is particular router, there were at least initially instructions to rename the openwrt firmware thusly:
the sysupgrade image need to be renamed to lede-gl-b1300.bin in both method. https://lists.infradead.org/pipermail/lede-commits/2018-February/006048.html
I would not think this would be necessary for more than just getting uboot to flash successfully, but once I got booted into openwrt-18.06.4 I figured I was past that issue.
I've looked into this a bit more, and I can confirm that the router is not making it to openwrt, but is stuck in uboot at some point. It will respond to ping, but no ports are open yet. It boots fine when connected to my laptop via ethernet, but when plugged into either of my switches, it won't boot. All my other openwrt routers boot fine when connected in the same way.
On this particular network segment, no. There are numerous devices that would be sending packets to the IP that I have assigned to the LAN port on this router, 192.168.1.1. I know, terrible choice for a production network, and that will be changing soon. I did try booting with it plugged into the WAN port which is connected only to my fiber provider using PPP, so I wouldn't expect any DHCP, nor packets bound for 192.168.1.1. It fails to boot even when the WAN port is plugged in.
I can confirm that once I changed my DMZ network from 192.168.1.0 to a new subnet, the problems have ceased. I can reboot in the absence of any 192.168.1.x traffic successfully and boot completely into openwrt.