Goes into boot loop when setting WAN mode to PPPoE

[urbanvisuals]

Haven't investigated too much further but I installed it twice and both times, once I set it to PPPoE and entered my credentials, it would boot endlessly. Needed to TFTP restore to get out of it.

[infinitnet]

Open /etc/config/network and change

config interface 'wan6'
    option ifname 'eth0.2'
    option proto 'dhcpv6'

to

config interface 'wan6'
    option ifname 'eth0.3'
    option proto 'dhcpv6'

restart network service or routerand let me know if that resolves the issue.

[madduci]

it solved my issue as well. Connecting the WAN interface (without setting PPPoE) caused the bootloop on latest release.

The /etc/config/network editing solved it.

[infinitnet]

Thanks for the confirmation. I'm not sure why IPv6 stopped working when using the same ifname as for IPv4 - this works fine using unmodified sources. Would be awesome if someone could help figure this out. I don't have IPv6 here.

[madduci]

what I noticed is the overall usage of resources. The previous release used around 30% of memory, not on average it uses ~50% and the connection feels slower. I've not enabled the Ad Blocker service yet.

[infinitnet]

Higher memory consumption doesn't equal worse performance. Someone at LEDE forums benchmarked the throughput with iperf and it's much higher than it was before with recent builds (you should use the nightly ones --- edit: I see you already do). If you want to free up some memory, just stop & disable services you don't use, such as TOR which consumes quite a lot of memory. Disabling collectd also helps with performance if you don't need historic stats.

[madduci]

thanks for the hint. Anyway, great job!

[infinitnet]

Could someone with PPPoE check if the boot loop issue still exists?

[killmoinsneuf]

Hi, It is a great job ! I have bought an Archer C7 V2 three monthes ago to use it ! ^^

About this issue (or perhaps, a similar), but with no PPPoE setting on the WAN for me, the router looped on first reboot after the update. An hard stop (power switch) and reboot fixed the trouble !

In the syslog, it looped on the following messages : Fri Jun 30 12:15:20 2017 kern.warn kernel: [ 22.623795] qca_ssdk: Unknown symbol ppp_channel_get_protocol (err 0) Fri Jun 30 12:15:20 2017 kern.warn kernel: [ 22.630500] qca_ssdk: Unknown symbol ppp_is_multilink (err 0) Fri Jun 30 12:15:20 2017 kern.warn kernel: [ 22.661181] qca_ssdk: Unknown symbol ppp_hold_channels (err 0) Fri Jun 30 12:15:20 2017 kern.warn kernel: [ 22.667393] qca_ssdk: Unknown symbol ppp_release_channels (err 0) Fri Jun 30 12:15:20 2017 kern.warn kernel: [ 22.673761] qca_ssdk: Unknown symbol ppp_channel_get_protocol (err 0)

[infinitnet]

@killmoinsneuf Thanks for reporting this. You're the first one running into that issue. Are you using the nightly or the latest release? It's related to the hardware NAT kernel module, which is pretty much useless for now anyway, because nobody knows the commands yet that you need to set it up on a C7. If this keeps causing issues, I'll just remove hardware NAT capabilities. Moved to #4

[killmoinsneuf]

It was the nightly from july the 2nd. The date (june the 30th in the log is erratic). Release : Reboot (SNAPSHOT, r4504-eaaba94bf6)

[infinitnet]

Alright. Nightlies are always untested, so it's possible that some upstream updates broke the hardware NAT code. Although if a reboot resolved the issue, it was probably something random related to your configs or upgrade path.

[killmoinsneuf]

No problem ! I'm an adventurer ! ^^ And i'm aware that nightlies are untested (it is clearly written), and my post was just to notify a deadlock on boot with "ppp" messages, but guessing it is perhaps not the same issue.

[infinitnet]

This has been fixed in the latest build. All you need to do is set mtu_fix 1 in /etc/config/firewall