WAN link problems on 18.06.2 with wrt3200acm

Installing and Using OpenWrt
1

Hi.

I've got a linksys wdr3200acm plugged into an arris surfboard cable modem, and it's not picking up an IP from DHCP. If I connect a laptop directly to the modem, the laptop gets an IP successfully, but the OpenWRT router is having problems.

When I reset all the config on OpenWrt SNAPSHOT, r9640-e7a7749a3c, what I get in dmesg is an apparently never-ending stream of messages that look like this, when the wan interface is plugged into the modem:

[  327.899358] mvneta f1070000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[  327.907495] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[  328.004127] mvneta f1070000.ethernet eth1: Link is Down
[  328.015446] mvneta f1070000.ethernet eth1: configuring for fixed/rgmii-id link mode
[  328.023275] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[  328.029337] mvneta f1070000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[  328.037271] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[  328.134244] mvneta f1070000.ethernet eth1: Link is Down
[  328.145655] mvneta f1070000.ethernet eth1: configuring for fixed/rgmii-id link mode
[  328.153490] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[  328.159418] mvneta f1070000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[  328.169548] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[  328.255526] mvneta f1070000.ethernet eth1: Link is Down
[  328.266967] mvneta f1070000.ethernet eth1: configuring for fixed/rgmii-id link mode
[  328.274782] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[  328.280759] mvneta f1070000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[  328.288789] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[  328.384217] mvneta f1070000.ethernet eth1: Link is Down
[  328.395530] mvneta f1070000.ethernet eth1: configuring for fixed/rgmii-id link mode
[  328.403340] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[  328.409307] mvneta f1070000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[  328.417236] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[  328.524191] mvneta f1070000.ethernet eth1: Link is Down
[  328.535368] mvneta f1070000.ethernet eth1: configuring for fixed/rgmii-id link mode
[  328.543168] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[  328.549073] mvneta f1070000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[  328.558891] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[  328.654189] mvneta f1070000.ethernet eth1: Link is Down
[  328.665262] mvneta f1070000.ethernet eth1: configuring for fixed/rgmii-id link mode
[  328.673080] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[  328.679041] mvneta f1070000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[  328.690297] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[  328.804564] mvneta f1070000.ethernet eth1: Link is Down
[  328.815771] mvneta f1070000.ethernet eth1: configuring for fixed/rgmii-id link mode
[  328.823570] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[  328.829565] mvneta f1070000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off

(plus /sbin/netifd running at ~20-50% cpu, which I don't really blame it...)

Of course, no address appears on wan.

After disabling ipv6 by commenting out the wan6 block in /etc/config/network and adding this to /etc/sysctl.conf:

net.ipv6.conf.default.forwarding=0
net.ipv6.conf.all.forwarding=0

I also tried moving to my own build of 18.06.2, which says OpenWrt 18.06.2, r7676-cddd7b4c77 at login, but the behavior seems no different to me.

Anyway, I now get a saner-looking dmesg, it's not spinning like crazy anymore.

After searching around, I also tried editing the clientid as suggested in one of the comments here:
https://dev.archive.openwrt.org/ticket/13581

But no joy.

My /etc/config/network looks like this:

root@OpenWrt:~# cat /etc/config/network 
config interface 'loopback'
  option ifname 'lo'
  option proto 'static'
  option ipaddr '127.0.0.1'
  option netmask '255.0.0.0'

config globals 'globals'
  option ula_prefix 'fd31:b646:6e96::/48'

config interface 'lan'
  option type 'bridge'
  option ifname 'eth0.1'
  option proto 'static'
  option ipaddr '192.168.1.1'
  option netmask '255.255.255.0'
  option ip6assign '60'

config interface 'wan'
  option ifname 'eth1.2'
  option proto 'dhcp'
  option clientid '01:38:e0:bc:c0:f0'

#config interface 'wan6'
#   option ifname 'eth1.2'
#   option proto 'dhcpv6'

config switch
  option name 'switch0'
  option reset '1'
  option enable_vlan '1'

config switch_vlan
  option device 'switch0'
  option vlan '1'
  option ports '0 1 2 3 5t'

config switch_vlan
  option device 'switch0'
  option vlan '2'
  option ports '4 6t'

One odd thing I notice is the wan interface says it's not up:

root@OpenWrt:/etc/config# ifstatus wan
{
	"up": false,
	"pending": true,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"proto": "dhcp",
	"device": "eth1.2",
	"data": {
		
	}
}

But even though ifstatus says it's down, ip addr seems to think the interface is up, just failing to learn an IP:

root@OpenWrt:~# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 532
    link/ether 60:38:e0:bc:c0:f0 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::6238:e0ff:febc:c0f0/64 scope link 
       valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 532
    link/ether 62:38:e0:bc:c0:f0 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::6038:e0ff:febc:c0f0/64 scope link 
       valid_lft forever preferred_lft forever
5: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 60:38:e0:bc:c0:f2 brd ff:ff:ff:ff:ff:ff
6: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 60:38:e0:bc:c0:f1 brd ff:ff:ff:ff:ff:ff
7: mlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 60:38:e0:bc:c0:f3 brd ff:ff:ff:ff:ff:ff
11: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 62:38:e0:bc:c0:f0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
       valid_lft forever preferred_lft forever
    inet6 fd31:b646:6e96::1/60 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::6038:e0ff:febc:c0f0/64 scope link 
       valid_lft forever preferred_lft forever
12: eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether 62:38:e0:bc:c0:f0 brd ff:ff:ff:ff:ff:ff
13: eth1.2@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 60:38:e0:bc:c0:f0 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::6238:e0ff:febc:c0f0/64 scope link 
       valid_lft forever preferred_lft forever

At this point, I figured I'm stuck enough to come beg for help.

Anyone have any ideas? I'm stumped for tonight.

Thanks.

1 Like
2

You mean Linksys WRT3200ACM, right?

3

Yes, sorry, that's what I meant.

4

eth0 and eth1 should stay up all the time since they are connected to the switch chip, not the ports.

Since it is easy to do on this model, flash back to factory firmware to rule out hardware problems.

5

This sounds like a good idea, but when I hold the reset button I get just a different OpenWRT build than mine. I searched, and I found some suggestions for other pre-built OpenWRT builds, plus one path that suggests it might be possible to get the original Linksys firmware back on, but if I'm reading it right, it seems to require connectivity through the wan link of the router, which I don't have:

Any suggestions on the easy way to do this?

Also, just to clarify: eth0 and eth1 (and also eth1.2, which is the wan link, and I think an alias on eth1) are up according to ifconfig and ip addr/ip link, but not according to "ifstatus wan".

One more interesting thing I noticed. I checked tcpdump of the DHCP request from both the laptop (which worked) and the router (which didn't). I noticed in particular the clientid matches the mac address of the laptop, so I tried using the straight mac address of eth1, as well as using 01 in the first byte, but neither works when I add use it in a clientid option in /etc/confic/network, and in fact it seems not to show up in the tcpdump.

laptop's dhcp request (works):

08:18:20.283988 IP (tos 0x0, ttl 255, id 54494, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from ac:7f:3e:e5:9a:3f, length 300, xid 0x215cc07d, Flags [none] (0x0000)
	  Client-Ethernet-Address ac:7f:3e:e5:9a:3f
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Request
	    Parameter-Request Option 55, length 10: 
	      Subnet-Mask, Classless-Static-Route, Default-Gateway, Domain-Name-Server
	      Domain-Name, Option 119, Option 252, LDAP
	      Netbios-Name-Server, Netbios-Node
	    MSZ Option 57, length 2: 1500
	    Client-ID Option 61, length 7: ether ac:7f:3e:e5:9a:3f
	    Requested-IP Option 50, length 4: xxx
	    Lease-Time Option 51, length 4: 7776000
	    Hostname Option 12, length 9: "lap-name3"
	    END Option 255, length 0
	    PAD Option 0, length 0, occurs 8

router's dhcp request (doesn't work):

08:28:56.255382 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 60:38:e0:bc:c0:f0, length 300, xid 0x17758b6b, secs 547, Flags [none] (0x0000)
	  Client-Ethernet-Address 60:38:e0:bc:c0:f0
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Discover
	    MSZ Option 57, length 2: 576
	    Parameter-Request Option 55, length 8: 
	      Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
	      Domain-Name, BR, NTP, Classless-Static-Route
	    Vendor-Class Option 60, length 12: "udhcp 1.30.1"
	    Hostname Option 12, length 7: "OpenWrt"
	    END Option 255, length 0
	    PAD Option 0, length 0, occurs 19

wan interface config in /etc/config/network:

config interface 'wan'                         
        option ifname 'eth1.2'                 
        option proto 'dhcp'                    
        option clientid '60:38:e0:bc:c0:f0'

As far as I can tell, configuring clientid this way should produce a clientid in the DHCP request, according to this:
https://openwrt.org/docs/guide-user/base-system/basic-networking

But I'm not seeing it work right. Maybe also worth noting is that the udhcp command running according to top doesn't seem to include it:

udhcpc -p /var/run/udhcpc-eth1.2.pid -s /lib/netifd/dhcp.script -f -t 0 -i eth1.2 -x hostname:OpenWrt -C -O 121

Does that give any hints?

6

OK, one more interesting observation. When I tried tcpdump after setting the first byte of clientid to 01, it did show up, so I changed it again to have 7 bytes including the full mac address after the 01, and then it produced a good ClientID in tcpdump:

wan interface from /etc/config/network:

config interface 'wan'                         
        option ifname 'eth1.2'                 
        option proto 'dhcp'                    
        option clientid '01:60:38:e0:bc:c0:f0'

Resulting tcpdump:

12:28:02.095385 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 60:38:e0:bc:c0:f0, length 300, xid 0x24e6e014, secs 64, Flags [none] (0x0000)
	  Client-Ethernet-Address 60:38:e0:bc:c0:f0
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Discover
	    MSZ Option 57, length 2: 576
	    Parameter-Request Option 55, length 8: 
	      Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
	      Domain-Name, BR, NTP, Classless-Static-Route
	    Vendor-Class Option 60, length 12: "udhcp 1.30.1"
	    Hostname Option 12, length 7: "OpenWrt"
	    Client-ID Option 61, length 7: ether 60:38:e0:bc:c0:f0
	    END Option 255, length 0
	    PAD Option 0, length 0, occurs 10

However, this still did not result in successfully learning an IP through the cable modem, unfortunately.

I hope that's helpful info that means something to somebody...

7

OK, I think I figured it out.

I think the DHCP lease is being granted upstream of the cable modem, and that it's tied to something about the cable modem's id so that I get only 1 IP address, but it also is associated with the mac address that learns the actual IP address.

On this theory, I changed the mac address of my router's wan interface to match the mac address of the laptop that got the initial lease (granted for 90 days, if I'm reading "7776000" correctly), and that let me learn an IP address after all. Now I'll just have to get it to auto-propagate the DNS and it should be in decent shape.

Thanks for looking, folks, I appreciate the feedback.