Bug alert ! be3600 ipv6 native/static (4.7.3/4.8.1)

So, let me start by saying that with the mt3000 I passed the native ipv6 tests and tested many configurations, including lw4over6, paying for a single crash that was resolved with a reboot.

Okay, now with NAT6 in DHCP, the be3600 seems to be working, and after all, I prefer the router to create its own private network, but I wasted a week on a crash course in IPv6, and I want to point out that the be3600 has a bug on 4.7.3 that has not been resolved in 4.8.1 beta.

I spent days resetting it, just because I was using native IPv6 and nothing else. After three hours, it became unreachable on the LAN, and after another half hour, it also disconnected from the WAN. Or it would freeze on reboot every time, and when I dared to restore it from Luci, it froze on the logo and I switched to uboot. Luckily, it has a display that made everything easier.

I returned it to Amazon as faulty, and with the refund I bought it again, another day lost after the great successes on the little mt3000. As I said, I'll keep it in NAT6, the rest is worth the expense, but I hope you fix it before the 4.8.1 release.

Hi,

I would like to confirm one more time, the ipv6 enabled and the mode native, will this issue be randomly reproduced?

There is a difference with the screenshots. After enabling it as in the first one, in the second (Ethernet) the ipv6 tab appears. After that, it is more than random, at the first reboot, or after 3 hours of powering on. Without exception, with the returned one and with the new one. And I have the mt3000 as a comparison, it is not my oversight, however I confirm that with nat6 it is holding up.

Off topic: in the meantime, I noticed that the WAN from 2.2Gb on the mt3000 has dropped to 1.9Gb (iperf3), and the 1Gb WiFi on the mt3000 has dropped to 600Mb (ookla). Perhaps openwrt 23 is still uncharted territory, but I have faith in the next versions of the firmware.

[EDIT AFTER 13 HOURS]

Update: with nat6, it was active after 12 hours, then the power went out and when it restarted, it couldn't get the IP from the wireless network. I reset it, and tomorrow I'll let you know if it works without ipv6. I should add that in addition to trying two be3600s, I tried two ISPs, one with ont/pppoe and one with a main router or ont+lw4over6.

So, I'm not editing the previous post because I have a priority detail: unreachable on reboot with IPv6 turned off, but Windows received the local IPv6 address. This makes me think that ULA is a bit intrusive and hinders native IPv6.

But unreachability is explained: Windows (and Android) did not receive IPv4, GW4, and DNS4. So maybe I should add that in addition to wifi, dns-doh, and ipv6, a setting I immediately put is 10.x.x.1 on the lan, even on the mt3000 I've always done that, but... could that be the bug that makes ipv4 disappear on reboot?

However, with nat6 it didn't crash after 3 hours, so if that's the case, ipv6 and subnet contribute to the problem: the native on uptime and the subnet on reboot.

I'm sorry, the specs are fabulous, but I need native IPv6 to limit the ISP router to ONT. The LAN is just to save keys from the shell, but considering the iperf3/ookla performance, I'm thinking of returning it again to Amazon and keeping the MT3000. Unless you find it to be a problem and include the solution in the program.

Further testing confirms everything:

  1. The disappearance of IPv4 upon reboot, which prevents the router from being reached from the LAN, does not occur when keeping 192.1.168.8/24, so it is a problem with the modification script from the GUI. 2) Native IPv6 is a real mess. I hadn't noticed that on the mt3000, all it takes is a click to see the prefix on wan6 and the proxies on lan. Anyway, even without that click, the IPv6 native is a real mess.

  2. Native IPv6 is a real mess. I hadn't noticed that on the MT3000, all it takes is one click to see the prefix on wan6 and the delegations on lan. However, even without fixing it from Luci (which is necessary, since the GUI itself says that ping6 is not working), that click causes enough chaos to block everything in 3 hours. Nat6 doesn't block, but it doesn't get ping6.

So I thank the Slate 7 for forcing me to fill in my ignorance about ipv6, which I will use to better align the “plug&play” aka Beryl AX, for which you deserve as much credit as Xiaomi. I'm writing from Beryl, the Slate is back in its box... greetings to display-quadcore/GBram-dualeth2.5, we'll see each other again in a few firmware updates.

Hi,

Thanks for your updates.

Learned from your description, I may need to change the LAN subnet to another segment, for example 192.168.12.0/24.

And I'll check the ipv6 tab of the WAN (Ethernet).

I will try to reproduce it again

After manually restarting the device, IPv4 & IPv6 can be obtained normally.

Keeping on standby for observation.

Okay, but just to be clear... try class 10 on the LAN switch, and check the prefix delegation on IPv6.

It may be imposing class 192.168, so try class 10. However, the real problem is the second one. See if uci network has ip6prefix and if luci shows PD-ipv6 on wan6 and on lan... I don't think so, since your screenshot shows a ULA. Use it on isp ipv6 and get a public prefix. On mt3000, all it takes is one click, and I've tried two be3600s on two ISP a hundred times.

It's no longer my problem, amazon.it will refund everything within 14 days, but I speak highly of you for Beryl, so I urge you to investigate further, ruling out that it depends on two different ISPs, two different slates, or an error that I repeat 100 times on the slate and never on Beryl.

Then there is the 15% drop in iperf3 performance on wan / ookla 40% (15% wan + 25% lan) on lan. I understand you perfectly, the product has little history, the firmware can be considered in beta, it will certainly improve, but my home network has no reason to prefer it to the MT3000.

1 Like

I come back to report an error on the mt3000, which is not there in the be3600: in the firewall, the wan6 is merged with the wan, inward reject, which with native creates problems for the masquerading option.

After a pause, I put the mt3000 back up and the delegated ip6 on windows was detected by the test, lowering the firewall a moment, it should be managed on the devices, more cannot be asked.

Hi,

Sorry, how to reproduce this issue? I did not quite understand the reproduce steps.

@bruce Sorry, maybe it's not GL but openwrt from 21 to 23, you reproduce it on Luci (firewall->general wan->reject). On 23, wan6 has its own reject to avoid using masquerading, otherwise devices exit with the router's IP even if they have native delegation.

Something from Luci also needs to be done on mt3000 for native, it's more convenient to use static from the ipv6 tab of the GL GUI. But I think I'll go back to nat6, I prefer it after all. However, I confirm on the be3600 that if any observation was approximate, it is that resetting it 50 times in 10 days does not leave time to think. It certainly has some problems, in addition to lower performance than its little brother.

[edit /myfault/vpn ... given that the VPN is the last thing I set up, so it did not cause the disappearance of IPv4 from the DHCP with the change of subnet 10.x.y.z/24 at restart, nor the loops & leaks on IPv6-native that block the WAN in a few hours ... between Beryl and Slate, I used different subnets, and the second one coincided with the default of the wgclient. Furthermore, on the second ISP, there is cgnat, which also causes problems for the client ... so exclude the VPN from my report]