Xiaomi Router 3G (mir3g) with OpenWrt 19.07.1 IPv6 issue

lede_dude · February 21, 2020, 11:34pm

Can anyone point out the issue here:

What is the WAN_6 that is grayed out?

No IPv6 assigned to me as well...

Xiaomi Router 3G (mir3g) with OpenWrt 19.07.1

It opens empty.

Here is the /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 'XXXXXXXXXXXXXX'

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

config device 'lan_dev'
option name 'eth0.1'
option macaddr 'XXXXXXXXXXXXXXXX'

config interface 'wan6'
option ifname 'eth0.2'
option proto 'dhcpv6'
option reqprefix 'auto'
option reqaddress 'none'

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

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

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

config interface 'WAN'
option proto 'pppoe'
option username 'XXXXXXXXXXXXXXXX'
option password 'XXXXXXXXXXXXXXXX'
option ipv6 'auto'
option keepalive '0'
option ifname 'eth0.2'

trendy · February 22, 2020, 7:10pm

It is automatically created interface with DHCPv6 client protocol because you have

configured in wan interface. You can set the option to '1' and you'll configure the wan6 manually, or to '0' and IPv6 will not be negotiated over ppp.

lede_dude · February 26, 2020, 7:15pm

I have no idea what to fill in, the router should obtain and configure the ipv6 address automatically.

option ipv6 'auto'

Changing it to 1 changes nothing, changing it to 0 disables internet.

It gets stranger:

seems there are two types of wan6 networks ... wan6 and WAN_6....

Very strange:

root@OpenWrt:~# ifstatus wan6
{
        "up": false,
        "pending": true,
        "available": true,
        "autostart": true,
        "dynamic": false,
        "proto": "dhcpv6",
        "device": "eth0.2",
        "data": {

        }
}

root@OpenWrt:~# ifstatus WAN_6
{
        "up": false,
        "pending": true,
        "available": true,
        "autostart": true,
        "dynamic": true,
        "proto": "dhcpv6",
        "device": "pppoe-WAN",
        "data": {

        }
}

and:

root@OpenWrt:~# ubus call network.interface dump | egrep wan6
                        "interface": "wan6",

root@OpenWrt:~# ubus call network.interface dump | egrep WAN_6
                        "interface": "WAN_6",

Is this a BUG? FS#1763

https://bugs.openwrt.org/index.php?do=details&task_id=1763

trendy · February 27, 2020, 10:22am

You can read the documentation about this option. It is explained in section PPP-based protocols and option ipv6.

Nothing strange. When you set option auto, OpenWrt creates automatically an interface with the name of the wan with suffix '_6', so in your case you have wan interface called WAN and the automatically created interface is WAN_6.
The wan6 interface was there by default or you created it.

This is bug from 18.06 and it is fixed.

lede_dude · February 27, 2020, 11:01pm

I do not get it, when i do

firstboot

The default file

/etc/config/network

has configuration for wan6

I then change the protocol ONLY to PPPoE in Luci > Interfaces > WAN and enter the login and password. I do nothing else. Save and apply.

OpenWrt then for some weird reason creates a virtual grayed out WAN_6 entry on Luci.

There is no such entry as WAN_6 in the config file.
It cannot be edited by normal means in Luci.

My question is, what is wrong with the default wan6 entry in the /etc/config/network

Why doesn't OpenWrt create the config under the existing wan6 entry in the /etc/config/network file?

If this is not a bug, then I have no idea what a bug is.

I mean, I have done some tinkering with OpenWrt for many years now, this is very familiar to me.

I was able to get around the grayed out WAN_6 by following method:

I deleted the wan6 entry and added the below instead:

config interface 'wan_6'
	option ifname '@wan'
	option proto 'dhcpv6'
	option reqprefix 'auto'
	option reqaddress 'try'

And then it looks like this:

As you can see, the ISP issues an IPv6 address to the router.

But to the outside world, the router has no IPv6. I checked on all sites:

Marginaal 2020-02-28 011145

trendy · February 28, 2020, 9:36am

That is correct. By default wan interface is set to DHCP and there is also the wan6 interface for DHCP6.

Nothing wrong, it is still remaining there from the first configuration. You can erase it or keep it, depending on the value that you will set in 'option ipv6' in wan interface. If you set auto (or Automatic in Luci), then wan_6 will be automatically created, so you can delete wan6. If you set 1 (or manual in Luci), then you need to keep wan6 or create it yourself.

Correct, it is automatic and not configurable. You can only check its status in Luci or with ifstatus wan_6 in SSH.

The address that I can see starts from fe80 and is not assigned by your ISP. It is link local address and is automatically configured on the interfaces by the Operating System when IPv6 is enabled.
The same applies for the fd.. address that the LAN interface has, which is ULA, a private address same thing as the 192.168.1.X address.

The ping shows permission denied because OpenWrt hasn't got a public routable IPv6 address.
Have a look at my configuration:

config interface 'wan'
        option proto 'pppoe'
        option username 'user'
        option password 'pass'
        option ifname 'eth0'
        option macaddr '00:...:00'
        option ipv6 '1'
        option keepalive '6 10'

config interface 'wan6'
        option proto 'dhcpv6'
        option reqaddress 'try'
        option reqprefix 'auto'
        option ifname '@wan'

As you can see I have option ipv6 '1' under wan, so wan_6 does not appear automatically, but I have to configure myself the wan6 interface. Then I bind wan6 with wan interface with the @wan option for ifname. The rest of the options in wan6 will let the dhcp6 client to negotiate with the dhcp6 server of the ISP what to configure.
To be honest I don't see any evidence that your ISP is giving Ipv6 so far. You may want to consult with them first, as there are many more protocols for IPv6 than just DHCPv6, and they may be using a different one. If you confirm with them that DHCPv6 is what they are using, then go ahead and adapt your configuration like mine. You can verify that you indeed have acquired IPv6 from your provider when you see an address that starts with the range 2000 - 3FFF, which are the Global Unicast addresses.
You can also sniff for DHCPv6 packets using tcpdump:
tcpdump -i eth0.2 -vn udp port 546

lede_dude · February 28, 2020, 3:14pm

I checked with ISP and they said IPv6 address is indeed issued by SLAAC / DHCPv6 protocol.

I tried pretty much everything that the GUI and config file offers without success.

The config you suggested also does not work.

The situation is not normal.

An internet search gave me a possible solution:

To downgrade to Lede and then upgrade back to OpenWrt.

Now I need to compile a firmware to my router.

trendy · February 28, 2020, 3:43pm

Post here the output of tcpdump:

tcpdump -vvvni any ip6 and udp port 546 &
kill -SIGUSR1 $(pidof odhcp6c)
odhcp6c pppoe-wan
#wait for a minute to collect some packets
kill $(pidof tcpdump)

lede_dude · February 28, 2020, 4:04pm

odhcp6c is not running, so I do not need to kill it.

The result is completely empty.

However this command has an output:

tcpdump -i eth0.2 -vn udp port 546

tcpdump: listening on eth0.2, link-type EN10MB (Ethernet), capture size 262144 bytes
18:21:40.979953 IP6 (hlim 64, next-header UDP (17) payload length: 74) fe80::c225:e9ff:fe9a:4e5d.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=f48f9f (client-ID hwaddr/time type 1 time 636222099 c025e99a4e5d) (IA_NA IAID:5510803 T1:0 T2:0) (elapsed-time 102) (option-request DNS-server) (IA_PD IAID:5510802 T1:0 T2:0))
18:21:43.083971 IP6 (hlim 64, next-header UDP (17) payload length: 74) fe80::c225:e9ff:fe9a:4e5d.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=f48f9f (client-ID hwaddr/time type 1 time 636222099 c025e99a4e5d) (IA_NA IAID:5510803 T1:0 T2:0) (elapsed-time 313) (option-request DNS-server) (IA_PD IAID:5510802 T1:0 T2:0))
18:21:55.148017 IP6 (hlim 64, next-header UDP (17) payload length: 74) fe80::c225:e9ff:fe9a:4e5d.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=f48f9f (client-ID hwaddr/time type 1 time 636222099 c025e99a4e5d) (IA_NA IAID:5510803 T1:0 T2:0) (elapsed-time 1519) (option-request DNS-server) (IA_PD IAID:5510802 T1:0 T2:0))

trendy · February 28, 2020, 4:39pm

If odhcp6c is not running you cannot get the settings from dhcp6 server.
In the tcpdump your dhcp6 client is trying to contact the server (dhcp6 solicit) but is not getting any reply.

lede_dude · February 29, 2020, 12:39pm

Ok, I was not precise:

This command:

kill -SIGUSR1 $(pidof odhcp6c)

Is not necessary since odhcp6c is not running.

And the result of:

odhcp6c pppoe-wan

Is empty even after 1 hour.

I ran all other commands as necessary.

Now ... I will test with a different router and with LEDE 17.01.7 (TP-Link WDR4300 v1.7).

lede_dude · February 29, 2020, 1:27pm

I tested with a different router and with LEDE 17.01.7 (TP-Link WDR4300 v1.7).

Everything works out of the box. There is no WAN_6 grayed out bugged inferface - it modifies the existing WAN6 config automatically as needed, without adding the unnecessary and unchangeable WAN_6

IPv6 works with WAN6, without me doing anything other than changing the protocol to PPPoE and entering the login and password, and save+apply.

Now, tell me again, this is not a bug in the OpenWrt 19.07.1

tcpdump -vvvni any ip6 and udp port 546 &
odhcp6c pppoe-wan

shows this:

13:33:17.559071 ethertype IPv6, IP6 (hlim 1, next-header UDP (17) payload length: 93) fe80::89cc:874d:e516:7306.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=dcc424 (elapsed-time 6300) (client-ID hwaddr/time type 1 time 491624195 d8cb8a1e885e) (IA_NA IAID:64539530 T1:0 T2:0) (Client-FQDN) (vendor-class) (option-request DNS-search-list DNS-server vendor-specific-info Client-FQDN))
13:33:17.559084 IP6 (hlim 1, next-header UDP (17) payload length: 93) fe80::89cc:874d:e516:7306.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=dcc424 (elapsed-time 6300) (client-ID hwaddr/time type 1 time 491624195 d8cb8a1e885e) (IA_NA IAID:64539530 T1:0 T2:0) (Client-FQDN) (vendor-class) (option-request DNS-search-list DNS-server vendor-specific-info Client-FQDN))
13:33:21.355096 ethertype IPv6, IP6 (flowlabel 0x645bc, hlim 1, next-header UDP (17) payload length: 103) fe80::8caf:3ba7:ca0b:c42e.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=3d03d6 (elapsed-time 3103) (client-ID hwaddr/time type 1 time 593056730 3cd92b60f763) (IA_NA IAID:138205483 T1:0 T2:0) (Client-FQDN) (vendor-class) (option-request vendor-specific-info DNS-server DNS-search-list Client-FQDN))
13:33:21.355115 IP6 (flowlabel 0x645bc, hlim 1, next-header UDP (17) payload length: 103) fe80::8caf:3ba7:ca0b:c42e.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=3d03d6 (elapsed-time 3103) (client-ID hwaddr/time type 1 time 593056730 3cd92b60f763) (IA_NA IAID:138205483 T1:0 T2:0) (Client-FQDN) (vendor-class) (option-request vendor-specific-info DNS-server DNS-search-list Client-FQDN))
13:33:22.399908 ethertype IPv6, IP6 (hlim 64, next-header UDP (17) payload length: 74) fe80::c225:e9ff:fe9a:4e5d.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=fe60b7 (client-ID hwaddr/time type 1 time 636298372 c025e99a4e5d) (IA_NA IAID:5587076 T1:0 T2:0) (elapsed-time 2970) (option-request DNS-server) (IA_PD IAID:5587075 T1:0 T2:0))
13:33:22.399923 IP6 (hlim 64, next-header UDP (17) payload length: 74) fe80::c225:e9ff:fe9a:4e5d.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=fe60b7 (client-ID hwaddr/time type 1 time 636298372 c025e99a4e5d) (IA_NA IAID:5587076 T1:0 T2:0) (elapsed-time 2970) (option-request DNS-server) (IA_PD IAID:5587075 T1:0 T2:0))
13:33:27.699988 ethertype IPv6, IP6 (hlim 64, next-header UDP (17) payload length: 74) fe80::c225:e9ff:fe9a:4e5d.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=7d49ed (client-ID hwaddr/time type 1 time 636298407 c025e99a4e5d) (IA_NA IAID:5587110 T1:0 T2:0) (elapsed-time 0) (option-request DNS-server) (IA_PD IAID:5587109 T1:0 T2:0))
13:33:27.700001 IP6 (hlim 64, next-header UDP (17) payload length: 74) fe80::c225:e9ff:fe9a:4e5d.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=7d49ed (client-ID hwaddr/time type 1 time 636298407 c025e99a4e5d) (IA_NA IAID:5587110 T1:0 T2:0) (elapsed-time 0) (option-request DNS-server) (IA_PD IAID:5587109 T1:0 T2:0))

Ping works:

root@LEDE:~# ping ipv6.icanhazip.com
PING ipv6.icanhazip.com (2a01:4f8:c0c:4925::10): 56 data bytes
64 bytes from 2a01:4f8:c0c:4925::10: seq=0 ttl=54 time=38.013 ms
64 bytes from 2a01:4f8:c0c:4925::10: seq=1 ttl=54 time=37.836 ms
64 bytes from 2a01:4f8:c0c:4925::10: seq=2 ttl=54 time=37.750 ms
64 bytes from 2a01:4f8:c0c:4925::10: seq=3 ttl=54 time=37.917 ms
64 bytes from 2a01:4f8:c0c:4925::10: seq=4 ttl=54 time=37.781 ms
^C
--- ipv6.icanhazip.com ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 37.750/37.859/38.013 ms
root@LEDE:~# ping ipv4.icanhazip.com
PING ipv4.icanhazip.com (104.20.16.242): 56 data bytes
64 bytes from 104.20.16.242: seq=0 ttl=61 time=7.269 ms
64 bytes from 104.20.16.242: seq=1 ttl=61 time=7.346 ms
64 bytes from 104.20.16.242: seq=2 ttl=61 time=7.578 ms
64 bytes from 104.20.16.242: seq=3 ttl=61 time=7.273 ms
64 bytes from 104.20.16.242: seq=4 ttl=61 time=7.296 ms
64 bytes from 104.20.16.242: seq=5 ttl=61 time=7.256 ms
64 bytes from 104.20.16.242: seq=6 ttl=61 time=7.262 ms
64 bytes from 104.20.16.242: seq=7 ttl=61 time=7.234 ms
64 bytes from 104.20.16.242: seq=8 ttl=61 time=7.307 ms
^C
--- ipv4.icanhazip.com ping statistics ---
9 packets transmitted, 9 packets received, 0% packet loss
round-trip min/avg/max = 7.234/7.313/7.578 ms
root@LEDE:~#

I will now save the TP-Link backup and will attempt to use it with my Xiaomi router.

Update....

I upgraded my router with LEDE 17.01.7 (TP-Link WDR4300 v1.7) > OpenWrt 19.07.1 and keeping the settings.

And this is the result:

root@LEDE:~# ping ipv4.icanhazip.com
PING ipv4.icanhazip.com (104.20.17.242): 56 data bytes
64 bytes from 104.20.17.242: seq=0 ttl=61 time=7.314 ms
64 bytes from 104.20.17.242: seq=1 ttl=61 time=7.322 ms
64 bytes from 104.20.17.242: seq=2 ttl=61 time=7.285 ms
^C
--- ipv4.icanhazip.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 7.285/7.307/7.322 ms
root@LEDE:~# ping ipv6.icanhazip.com
PING ipv6.icanhazip.com (2a01:4f8:c0c:4925::10): 56 data bytes
64 bytes from 2a01:4f8:c0c:4925::10: seq=0 ttl=54 time=38.024 ms
64 bytes from 2a01:4f8:c0c:4925::10: seq=1 ttl=54 time=37.744 ms
64 bytes from 2a01:4f8:c0c:4925::10: seq=2 ttl=54 time=37.791 ms
64 bytes from 2a01:4f8:c0c:4925::10: seq=3 ttl=54 time=37.898 ms
64 bytes from 2a01:4f8:c0c:4925::10: seq=4 ttl=54 time=37.711 ms
64 bytes from 2a01:4f8:c0c:4925::10: seq=5 ttl=54 time=37.761 ms
^C
--- ipv6.icanhazip.com ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max = 37.711/37.821/38.024 ms
root@LEDE:~#

Still everything works.

So is the solution indeed to downgrade to LEDE 17.01.7, factory reset, enter the settings and then upgrade back to OpenWrt 19.07.1 ..?

This one has a proper WAN6 interface and a virtual WAN_6 interface that actually works.

Update 2...

I have noticed that the stock LEDE 17.01.7 and stock OpenWrt 19.07.1 have different protocols available from the drop-down menu in Interfaces....

Is this what is causing the problems?

LEDE 17.01.7 (pic is from before selecting the protocol PPPoE and entering the login and pass)

OpenWrt 19.07.1

trendy · February 29, 2020, 6:07pm

The only problem I have seen is that your odhcp6c was not running, not sure why.
Other than that the ipv6 over dhcpv6 works by default.
Keeping configuration over major releases is not advised, as there can be differences in the options. Same applies for migrating configuration over different devices.
The only thing I believe that fixed the problem was the reset you did after flashing 17.01.7
Since the problem is solved, feel free to mark the topic accordingly.

lede_dude · February 29, 2020, 7:21pm

The problem is not solved.

The problem was and still is with Xiaomi Router 3G - hence the thread topic is called accordingly.

I have reset this router countless times, I even mentioned this in my post.

To be clear, I have even erased the overlay and wrote back the firmware at least ten times.

And LEDE is not available for this Xiaomi Router 3G.

The other router (TP-Link WDR4300 v1.7) I only used to make sure that IPv6 is indeed issued by the ISP and works properly and that installing old LEDE and reverting back to OpenWrt indeed fixes problem FOR the TP-LINK router - since LEDE is not available for the Xiaomi Router 3G I obviously cannot test this method with this router.

Nothing to mark as solved.

trendy · February 29, 2020, 7:35pm

Apologies, looks like I misread the last post.

Is odhcp6c running on Xiaomi or not?

lede_dude · February 29, 2020, 7:40pm

I do not see it in any lists.

How can I check if it runs?

The command jobs shows nothing, and it is not in the init startup scripts.

trendy · February 29, 2020, 7:41pm

ps wwww | grep odhcp6c

lede_dude · February 29, 2020, 7:42pm

root@OpenWrt:~# ps wwww | grep odhcp6c
4585 root 1216 S grep odhcp6c

trendy · February 29, 2020, 7:43pm

So it is not running.
Verify it exists: which odhcp6c It should give /usr/sbin/odhcp6c
If not add it with opkg update ; opkg install odhcp6c

lede_dude · February 29, 2020, 7:45pm

Yes, it exists and it is in /usr/sbin/odhcp6c