PPPoE internet disconnects

I'd like you to try a simple configuration change.

Look for the MAC address of the ISP router...it should be on a printed label on the device.

It will be in a format that looks like "6A:1B:CD:E4:55:6F"

Copy that address down.

In LuCI, navigate to Network > Interfaces.

Click on the Devices tab.

Look for the device name in the list that matches what the WAN is using on the Interfaces page. (eth0.2 for example).

When you find it on the Devices page, click on the blue Configure button.

On the General Device Options page, look for the box labeled MAC address.

Enter the MAC address from the ISP device that you copied, in that box.

Double check that it's correct.

Then, click the green Save button.

Then, when your back at the Devices page, scroll down and click the blue Save and Apply button.

That's it.

Reboot the router and see if it makes a difference.

If not, you can always remove the MAC address by doing the same steps.

This is called "cloning" the MAC address.

There are cases when ISPs expect to see "their device" on their network, and when they don't, weird things can happen.

It's possible that it had been configured in the stock firmware at some point, but was not included in the backup of the stock configurations.

Or, nothing may change.

But it's simple and quick enough to try and undo if it doesn't do anything.

1 Like

Yes, good idea, easy to check and hence worth a test. Not super likely to be the solution, but also not impossible.

Hi,

I am a bit confused now by seeing all this devices. My WAN on interface says "pppoe-wan" and if I go to edit to check info in interfaces by that WAN it will say "device eth0.2". But when I then go to devices I find both...

So I do find a "pppoe-wan" and a "eth0.2" device. Which of both must I change/add the mac address from isp router to? The "pppoe-wan" doesn't even appear to have a mac address allocated to, or is this normal?

And the WAN6 on my interfaces I don't even use, but it is probably fine to leave it there just like it is? Cause I don't have IPv6 from my ISP.



What guide did you use to configure OpenWrt?

Not really a guide, all was straight forward, just downloaded latest Openwrt firmware from their site, then configured wireless and setup PPPoe protocol as on their site stipulated with login credentials from ISP.

And then added smart dns from a provider, and followed guidelines for setting up openvpn on openwrt. That Openvpn guidelines I found on a provider of vpn's their site to install on openwrt. (so creating that Tun0 unmanaged device)

Then as last I added custom firewall rules from smart dns provider to get around chromecast dns(so preroute google dns to smart dns)

Thats it.

I noticed you also had a thread 3 days ago on the VPN part...

Looks odd to me.

I'd like @moeller0 to take a look at your screenshots above, before doing anything more...

Ya openvpn question is another topic, but openvpn works fine, no issues there. But with my original Asus firmware I was used that I just could start openvpn client and disconnect again when done using openvpn without that I had to delete my smart dns.

Now each time it seems I must delete my smart dns in order to use and load pages with my openvpn. Without deleting smart dns, the Openvpn doesn't work. But ya that's the least of my worries, since I only use a vpn if smart dns fails to load apps or sites:).

I just was wondering if I couldn't use Openvpn as before so without deleting each time my smart dns. But thats for another topic, let us now stay on topic:). Will wait then on @moeller0 his view on this printscreens.

Thanks for helping to find solutions as well:)

Mmmh, not sure, I guess changing the MAC of eth0 might work. If your router has a dedicated WAN port and you just use VLAN2 on that then eth0 is exactly the right place, but if the router uses a switch for all LAN and the WAN port then things might be different (and I do not own a router like this and hence have no first-hand experience to offer)

Ok thanks man, we can always revert back to previous settings and if needed I flash all over again, no problem:). I now did just changed the mac of eth0 to mac address of ISP router. Now after doing that and rebooting router, eth0 and eth0.2 got that newly added mac address.

Furthermore I also noticed mtu of 1480 at pppoe-wan, which looked odd, since all of other devices has 1500. So I made it 1500 as well as rest of devices. Hope this is right as well. And let us now wait and see again if and what happens in the next hours/day concerning disconnections.

I would not touch that, OpenWrt defaults to using MSS-clamping which typically solves the issues that arise because the 8 byte PPPoE header "lives" with in the ethernet payload. So no active MTU configuration over OpenWrt's defaults should be required. "Should be" because there likely are links where manual work is required, but let's hope your's is not among them :slight_smile:

My internet just went down, so I checked my logs again, but this time nothing to see about pppoe-wan disconnected. But instead I found this back in my log:

Wed Feb 16 20:05:45 2022 daemon.notice hostapd: wlan0: AP-STA-POSSIBLE-PSK-MISMATCH d8:eb:46:7b:9e:cf

Is this maybe a result of the MAC change on the eth0 device earlier today? So far this is the first issue I have seen of this kind since I changed MAC adress about 8 hours ago.

This is my full systemlog:

Wed Feb 16 20:05:45 2022 daemon.info hostapd: wlan0: STA d8:eb:46:7b:9e:cf IEEE 802.11: authenticated
Wed Feb 16 20:05:45 2022 daemon.info hostapd: wlan0: STA d8:eb:46:7b:9e:cf IEEE 802.11: authenticated
Wed Feb 16 20:05:45 2022 daemon.info hostapd: wlan0: STA d8:eb:46:7b:9e:cf IEEE 802.11: associated (aid 1)
Wed Feb 16 20:05:45 2022 daemon.info hostapd: wlan0: STA d8:eb:46:7b:9e:cf IEEE 802.11: associated (aid 1)
Wed Feb 16 20:05:45 2022 daemon.notice hostapd: wlan0: AP-STA-POSSIBLE-PSK-MISMATCH d8:eb:46:7b:9e:cf
Wed Feb 16 20:05:46 2022 daemon.notice hostapd: wlan0: AP-STA-CONNECTED d8:eb:46:7b:9e:cf
Wed Feb 16 20:05:46 2022 daemon.info hostapd: wlan0: STA d8:eb:46:7b:9e:cf WPA: pairwise key handshake completed (RSN)
Wed Feb 16 20:05:46 2022 daemon.info dnsmasq-dhcp[2532]: DHCPREQUEST(br-lan) 192.168.1.131 d8:eb:46:7b:9e:cf
Wed Feb 16 20:05:46 2022 daemon.info dnsmasq-dhcp[2532]: DHCPACK(br-lan) 192.168.1.131 d8:eb:46:7b:9e:cf Chromecast
Wed Feb 16 20:05:49 2022 daemon.info dnsmasq-dhcp[2532]: DHCPREQUEST(br-lan) 192.168.1.109 5c:49:7d:51:cf:57
Wed Feb 16 20:05:49 2022 daemon.info dnsmasq-dhcp[2532]: DHCPACK(br-lan) 192.168.1.109 5c:49:7d:51:cf:57
Wed Feb 16 20:05:54 2022 daemon.info hostapd: wlan1: STA 6c:c4:d5:55:2f:fb IEEE 802.11: authenticated
Wed Feb 16 20:05:54 2022 daemon.info hostapd: wlan1: STA 6c:c4:d5:55:2f:fb IEEE 802.11: associated (aid 1)
Wed Feb 16 20:05:55 2022 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 6c:c4:d5:55:2f:fb
Wed Feb 16 20:05:55 2022 daemon.info hostapd: wlan1: STA 6c:c4:d5:55:2f:fb WPA: pairwise key handshake completed (RSN)
Wed Feb 16 20:05:58 2022 daemon.info dnsmasq-dhcp[2532]: DHCPDISCOVER(br-lan) 6c:c4:d5:55:2f:fb
Wed Feb 16 20:05:58 2022 daemon.info dnsmasq-dhcp[2532]: DHCPOFFER(br-lan) 192.168.1.208 6c:c4:d5:55:2f:fb
Wed Feb 16 20:05:58 2022 daemon.info dnsmasq-dhcp[2532]: DHCPREQUEST(br-lan) 192.168.1.208 6c:c4:d5:55:2f:fb
Wed Feb 16 20:05:58 2022 daemon.info dnsmasq-dhcp[2532]: DHCPACK(br-lan) 192.168.1.208 6c:c4:d5:55:2f:fb android-e7e7bbb06323587d
Wed Feb 16 20:06:09 2022 daemon.info hostapd: wlan1: STA 00:22:fa:88:eb:de IEEE 802.11: authenticated
Wed Feb 16 20:06:09 2022 daemon.info hostapd: wlan1: STA 00:22:fa:88:eb:de IEEE 802.11: associated (aid 2)
Wed Feb 16 20:06:09 2022 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 00:22:fa:88:eb:de
Wed Feb 16 20:06:09 2022 daemon.info hostapd: wlan1: STA 00:22:fa:88:eb:de WPA: pairwise key handshake completed (RSN)
Wed Feb 16 20:06:09 2022 daemon.info dnsmasq-dhcp[2532]: DHCPREQUEST(br-lan) 192.168.1.222 00:22:fa:88:eb:de
Wed Feb 16 20:06:09 2022 daemon.info dnsmasq-dhcp[2532]: DHCPACK(br-lan) 192.168.1.222 00:22:fa:88:eb:de WIN-4SGHEROGVUU
Wed Feb 16 20:14:31 2022 daemon.info hostapd: wlan1: STA 9a:49:ab:1d:10:0d IEEE 802.11: authenticated
Wed Feb 16 20:14:31 2022 daemon.info hostapd: wlan1: STA 9a:49:ab:1d:10:0d IEEE 802.11: associated (aid 3)
Wed Feb 16 20:14:31 2022 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 9a:49:ab:1d:10:0d
Wed Feb 16 20:14:31 2022 daemon.info hostapd: wlan1: STA 9a:49:ab:1d:10:0d WPA: pairwise key handshake completed (RSN)
Wed Feb 16 20:14:34 2022 daemon.info dnsmasq-dhcp[2532]: DHCPDISCOVER(br-lan) 9a:49:ab:1d:10:0d
Wed Feb 16 20:14:34 2022 daemon.info dnsmasq-dhcp[2532]: DHCPOFFER(br-lan) 192.168.1.244 9a:49:ab:1d:10:0d
Wed Feb 16 20:14:34 2022 daemon.info dnsmasq-dhcp[2532]: DHCPDISCOVER(br-lan) 9a:49:ab:1d:10:0d
Wed Feb 16 20:14:34 2022 daemon.info dnsmasq-dhcp[2532]: DHCPOFFER(br-lan) 192.168.1.244 9a:49:ab:1d:10:0d
Wed Feb 16 20:14:34 2022 daemon.info dnsmasq-dhcp[2532]: DHCPREQUEST(br-lan) 192.168.1.244 9a:49:ab:1d:10:0d
Wed Feb 16 20:14:34 2022 daemon.info dnsmasq-dhcp[2532]: DHCPACK(br-lan) 192.168.1.244 9a:49:ab:1d:10:0d M2006C3MG-Redmi9C
Wed Feb 16 20:21:05 2022 daemon.err uhttpd[1518]: luci: accepted login on / for root from 192.168.1.208

Do I still leave the new MAC adress on eth0? Or should I change it back to original one?

Leave it for now.

SSH in to the router and run cat /etc/config/wireless.

Redact the passwords in the "option key" sections.

Post the results.

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '36'
        option hwmode '11a'
        option path 'pci0000:00/0000:00:00.0/0000:01:00.0'
        option htmode 'VHT80'
        option cell_density '0'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option encryption 'psk2'
        option key 'PASSWORD'
        option macfilter 'deny'
        list maclist '00:22:68:16:33:3B'
        option ssid 'Stroopwafel'

config wifi-device 'radio1'
        option type 'mac80211'
        option channel '11'
        option hwmode '11g'
        option path 'platform/10180000.wmac'
        option htmode 'HT20'
        option cell_density '0'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'Stroopwafel'
        option encryption 'psk2'
        option key 'PASSWORD'
        option macfilter 'deny'
        list maclist 'D8:EB:46:7B:9E:CF'

Like your SSID :wink:

while I think looking after these WiFi issues should be done, I am not sure that the title of this thread is still fitting?

Yes, leave it, the question is still open whether that helps on the PPPoE side of things. (But even if that seems to help, I would still recommend to switch back to the original MAC in a few days, just to confirm that the disconnects are somehow MAC related and it is not just that your ISP fixed his PPPOE-server in the mean time :wink: )

This is the device having the key issue.

Looks like a Google MAC...maybe the Chromecast.

Run arp -a and see what IP address matches that MAC.

Ip adress is 192.168.1.131 and it is indeed my chromecast ya. But it works fine, I only forced the chromecast to use 5Ghz and I do block the google dns 8.8.8.8 and 8.8.4.4 via iptables in firewall. Strange it kicked my whole wifi off earlier on all devices. Anyway will see how router reacts on the pppoe side overnight. Will update tomorrow. So far all still fine on PPPoe since this afternoon, but the issues mostly are around this time or later into the next Morning.

Possible cause.

Thanks, now I see:). Learning more by the day, so I just had to follow the mac address mentioned in error message.

Easy way to keep an eye on the PPPoE WAN and the key mismatch issues is to filter the system log using "grep"

logread | grep "link is down"

logread | grep PSK-MISMATCH

If you want to watch for something happening at a certain time of day, you can use date and time filters...

Example -

(Today at the 5 PM hour)

logread | grep "Feb 16 17:"