GL-b1300 won't boot past uboot when connected to switch

Technical Support for Routers
1

I’m using the GL-B1300 as an edge router wired only. I have openwrt-18.06.4 on there and everything works great except that it will not boot when connected to either of my tp-link switches. I can tell from the status lights that it never gets past uboot, and the ping times are uboot’s as openwrt has higher latency. I’m wondering if this is a known issue and whether it has anything to do with openwrt? Is there a way to upgrade uboot if that is the issue and there is a newer version?
any help is appreciated. thanks.

I should add that it’s entirely possible that the issue is traffic on the network trying to reach 192.168.1.1 which is the default IP uboot comes up with, so it seems possible that some of those packets are triggering uboot to go into a state that prevents boot. There is no DHCP server or TFTP server on that network, but there are going to be PPP packets on the WAN side looking to reestablish that connection and TCP/IP packets on the LAN side from existing connections.

2

@hansome pls check it out

3

Would you please kindly check the uboot version by command;
strings /dev/mtd6 | grep “U-Boot.*2012”
At uboot stage, 192.168.1.1 should not be able to ping unless you hold reset button to
start uboot webfailsafe.
Can you got a serial port to log what happpened?
Serial log will also show the uboot version.

4

unfortunately I don’t have serial access to this unit, but I can confirm that once it was removed from the 192.168.1.x subnet, it reboots successfully with both LAN and WAN cables plugged in. The uboot version reported by the command you gave is this:
U-Boot 2012.07 [Chaos Calmer 15.05.1,r35193] (Apr 13 2018 - 13:54:46)

5

What model of your tp-link switch? Do you have any advice to reproduce this issue.

6

the latest all-metal cheapie 8port dekstop gigabit switch. I suspect that it’s not the switch, but Uboot’s response to packets coming in on 192.168.1.1 which is what the routers address used to be. I’ve since switched to a different subnet on that network segment and the boot problem is gone.

7

I have notice this issue when there is a device on the network with the IP address 192.168.1.2. It will get stuck on uboot. Is there an updated uboot that will fix that issue?

8

@heavymetal Is your device B1300? Would please show the version of U-boot：
strings /dev/mtd6 | grep “U-Boot.*2012”
if you are using B1300.

10

Mine is this version below:
U-Boot 2012.07 [Chaos Calmer 15.05.1,r35193] (Apr 13 2018 - 13:54:46)

And yes I am using the B1300 also.

11

Please try this uboot:
https://github.com/gl-inet/uboot-ipq40xx/blob/master/uboot-gl-b1300-20190822-md5-a0b9751a6402a44adfa63460ba3e1d10.bin
which fix the issue when 192.168.1.2 is reachable by ping, but firewall block tftp port 69 icmp not reachable packet. Our uboot use ping and then tftp to detect a server for auto firmware update.

Method:
push reset button and plug in power, for about 8 seconds till middle led constantly light, then release button, then use browser go to http://192.168.1.1/uboot.html.

1 Like
12

Thanks and I can confirm that is working. I am wondering if there is a way to turn off TFTP in uboot so it will not even try TFTP unless you press the mesh button?

This seems like a security risk if it tries firmware update from using a public ethernet network.

13

@hansome do you know if it is possible to turn off TFTP attempt on boot?

14

Many thanks for your advice.
This is the updated uboot which turn off the TFTP, https://github.com/gl-inet/uboot-ipq40xx/blob/master/uboot-gl-b1300-20190901-md5-b74531bf769fa7713bb28d0d80113a3a.bin
Also I’d like to start a internal review for making this update in our next release by default.

1 Like
15

Thanks @hansome tested the new uboot and also I can see that the b1300 boots faster as it doesn’t have to try TFTP.

16

I also updated and am grateful for the tftp-less version. It does boot faster, but I don’t have an environment to verify any of the other claims. Thanks!