Script hangs when no eth1 device is present (TP Link Archer C7v5)

[rklasen]

Hi,

thank you for this script, I've used it successfully on a TP Link WDR1043ND. I'm just now trying in my new Archer C7, but the script hangs after it outputs "--- configuring v6 bridge" and the device becomes unresponsive on ipv4 (and I'm connected on ipv4). The actual ipv6 bridging works though.

I saw that this router doesn't expose an eth1 interface, but even though the documentation header states eth1 should be the wan interface, the actual name eth1 is not hardcoded. I found that this device name is resolved to eth0.1 in the config file with $(/sbin/uci get network.wan.ifname), so I'm not really sure how I can debug this.

Do you have any idea what I can try? Thanks!

Edit: Sorry I forgot to mention, I'm on OpenWRT 19.07, ebtables is installed.

[cvmiller]

Please run the script and capture the output, and paste into this issue: sh -x ./v6brouter_openwrt_sh

This will output each line of the script, and we'll be able to see where it is hanging.

[rklasen]

Hi, thanks for your reply! This is the output, it seems the script turns off the bridge interface and encounters issues when turning it back on.

sh -x v6brouter_openwrt.sh -E | tee /root/v6brouter.log
+ source /root/v6brouter.conf
+ /sbin/uci get network.wan.ifname
+ WAN_DEV=eth0.2
+ BRIDGE=br-lan
+ BRIDGE_IP6=2001:470:ebbd:0::11
+ VERSION=2.0.3
+ CLEANUP=0
+ RESTORE=0
+ ENABLE=0
+ FIREWALL=0
+ STATUS=0
+ numopts=0
+ getopts '?hERFs' options
+ ENABLE=1
+ numopts=1
+ getopts '?hERFs' options
+ shift 1
+ '[' 0 -ne 0 ]
+ '[' -z br-lan ]
+ '[' -z eth0.2 ]
+ echo '--- checking for ebtables'
--- checking for ebtables
+ which ebtables
/usr/sbin/ebtables
+ ERR=0
+ '[' 0 -eq 1 ]
+ '[' 0 -eq 1 ]
+ '[' 0 -eq 1 ]
+ '[' 0 -eq 1 ]
+ '[' 0 -eq 1 ]
+ '[' 1 -eq 1 ]
+ echo '--- configuring v6 bridge'
--- configuring v6 bridge
+ brctl addbr br-lan
+ brctl addif br-lan eth0.2
+ ip link set br-lan down

I had to reboot the device at this point. After reboot, the logs first half is missing somehow, but this is left:

root@OpenWrt:~# cat v6brouter.log 
--- checking for ebtables
/usr/sbin/ebtables
--- configuring v6 bridge
bridge name     bridge id               STP enabled     interfaces
br-lan          7fff.50d4f7c01ec0       no              eth0.1
                                                        wlan0
                                                        wlan1
                                                        wlan1-1
                                                        eth0.2
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
--- Disable IPv6 RA and DHCPv6 Server on LAN
--- assigning IPv6 management address 2001:470:ebbd:0::11 to br-lan
--- configuring brouter to route everything but IPv6
Bridge table: broute

Bridge chain: BROUTING, entries: 1, policy: ACCEPT
-p ! IPv6 -i eth0.2 -j DROP 
--- pau

[cvmiller]

I think you are seeing a hang, because at that point the bridge is disabled, and you are connecting through the bridge, and you lose your session.

However, as you can see from the log file, the script completed running.

You will need to change the IPv6 Management IP address to something in your bridged IPv6 subnet in the v6brouter.conf file.

My question is, instead of rebooting the router, have you tried pinging the br-lan interface again (with IPv4 or IPv6) and ssh-ing back in?

Take note of the br-lan IPv6 link-local address before running the script, and ping that after running the script.

[rklasen]

I left the bridge IPv6 the default, which seems to have been a mistake. I set it to address in the prefix my ISP assigns, and tried again. The script still hangs at the same line, and I can't connect to the routers ipv6 either. After I solicit the router for addresses a few times, after about a minute I can finally connect to ipv6, which is great! ip a shows all addresses are set correctly:

root@OpenWrt:~# ip a
[...]
6: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 50:d4:f7:c0:1e:c0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.4/24 brd 192.168.1.255 scope global br-lan
       valid_lft forever preferred_lft forever
    inet6 2a02:xxxx:xxxx:xxxx:52d4:f7ff:fec0:1ec0/64 scope global dynamic mngtmpaddr 
       valid_lft 298sec preferred_lft 298sec
    inet6 2a02:xxxx:xxxx:xxxx::1337/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::52d4:f7ff:fec0:1ec0/64 scope link 
       valid_lft forever preferred_lft forever
[...]

While ssh'ed into the router, I can access the ipv4 and 6 internet just fine.

But from my desktop, ipv4 connectivity is partially dead, I can ping 2606:4700:4700::1111 just fine, but no answer for 1.1.1.1. Once I request a new ipv4 again for my desktop with dhclient, the router assigns an ipv4 again and this time I can even ping 1.1.1.1 just fine, but not the router itself at 192.168.1.4. I have no idea how that could possibly be, since 192.168.1.4 is supposed to be my gateway to even get to 1.1.1.1.

After about another minute, I can finally ping the router at it's ipv4, but this time, it refuses ssh connections (but it accepts connections on ipv6):

ssh root@192.168.1.4
ssh: connect to host 192.168.1.4 port 22: Connection refused

I am pretty confused right now.

Edit: scratch that, I made a mistake. I was connected to another router on another interface and got my ipv4 route from there. ipv4 on this router is completely dead, of course I can't ping 1.1.1.1 from my desktop. I can however login to the router and ping 1.1.1.1 from there without issue. But I can not ping my desktop on 192.168.1.225, nor can I ping the router at 192.168.1.4 from my desktiop. It seems the ipv4 connection between my desktop and router is broken, which explains why the script seemingly hangs after the bridge is activated.

[rklasen]

Okay I finally figured it out, the problem was somewhere else.

I tested this router in my current lan so as not to disturb the current lan config. My (old) lan has the ip range 192.168.1.1/24, and I attached the new routers wan to the old lan. The new router was supposed to have 192.168.1.4/24, but of course it can't route from 192.168.1.1/24 to 192.168.1.4/24 since they're in the same subnet. i assume no valid routes could be found this way.

To continue testing, I put the new router in 192.168.2.4/24, and now the bridge script works perfectly fine and without issues. It still takes over a minute until I can ping it over ipv6, but I think the ipv6 routes are just not available yet.

So thank you again for your help and your great bridge script!

[cvmiller]

Glad you got it working.