I'm currently building a small scale version of a network I'm planning to deploy for a business, so I bought the TP-Link Archer C6 and flashed OpenWrt 20.02 on it.
Now I want to completely bypass the current router+modem I'm using (D-Link DSL-2888A) and let OpenWrt handle the PPPoE VDSL connection with the D-Link acting as a dumb modem and nothing else.
Now, whatever I do, I can't get this to work. Here's my OpenWRT wan interface config
config interface 'wan'
option proto 'pppoe'
option username 'USERNAME'
option password 'PASS'
option mtu '1500'
option device 'eth0.2'
option ipv6 '0'
option keepalive '10 5'
I tried both VDSL in bridged mode and ADSL in bridged mode through the D-Link, but I always get the "connection attempt failed" in the LuCi OpenWRT GUI
I also mirrored this config with the same results
I'm pretty comfortable with Linux, but not so much with low-level networking, so if I'm approaching this in completely the wrong way, just let me know.
Thank you in advance
I guess you need to figure out whether your ISP requires a specific vlan tag in addition to the PPPoE credentials. Then you need to make sure that vlan is actually used over the vdsl link.
What made me exclude this option is that when I configure the PPPoE through the D-Link Modem, VLAN tags are disabled / not required. Is it possible that VLANs are needed for a bridged connection but not for direct configuration through the modem?
You need to talk to your ISP. But at least over here the incumbent requires VLAN7 but quite a number of modems/routers offer ISP configuration shortcuts will set that VLAN automatically. It is not sure whether that is your issue, but in my experience this happens commonly enough to check it.
As expected, my amazing ISP does not know what a bridged connection is or what do I mean by "VLAN tags"
Here's a screenshot of my currently working PPPoE settings on the D-Link modem. It's showing VLAN tags as strictly disabled. The modem might still be doing some voodoo i don't know about though, but these are 100% of the WAN settings available through the modem.
That is sad, it means the support and the engineers are well separated, I am pretty sure someone at your ISP knows
If you switch to Enable Bridged Ethernet, can you still log into the modem and look at the DSL statistics?
The existence of someone who knows and my ability to reach them are two separate issues
I always feel like speaking klingon whenever I contact my ISP support
Yes, enabling the bridged connection gets DSL stats through the modem
These are the bridged settings
And this is the DSL stat page after applying bridge settings and restarting
And the main IPV4 stats while bridged
That's why I was under the impression that it's a OpenWrt config issue, because the modem is showing everything as fine and dandy
OK, I agree that seems to indicate the DSL link is up. Let's look at the OpenWrt side again.
#debug with just
/etc/ppp/options to get more verbose output in the log and then see what
logread | grep -e ppp reveals? Probably a timeout waiting for a PADO packet....
Just as you expected
Wed Feb 16 22:36:17 2022 daemon.warn pppd: Timeout waiting for PADO packets
Wed Feb 16 22:36:17 2022 daemon.err pppd: Unable to complete PPPoE Discovery
Wed Feb 16 22:36:17 2022 daemon.info pppd: Exit.
I'm afraid I'm way over my head, I appreciate the help
The debug info shows the packets going to a mac address of ff:ff:...., is that normal? I removed my own mac address from the logs, but it's showing correctly as the same mac address of the wan interface
Wed Feb 16 22:37:19 2022 daemon.debug pppd: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
Wed Feb 16 22:37:19 2022 daemon.debug pppd: dst ff:ff:ff:ff:ff:ff src IF_MAC
Wed Feb 16 22:37:19 2022 daemon.debug pppd: [service-name] [host-uniq 00 00 5e 10]
Wed Feb 16 22:37:24 2022 daemon.debug pppd: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
Wed Feb 16 22:37:24 2022 daemon.debug pppd: dst ff:ff:ff:ff:ff:ff src IF_MAC
Wed Feb 16 22:37:24 2022 daemon.debug pppd: [service-name] [host-uniq 00 00 5e 10]
Wed Feb 16 22:37:29 2022 daemon.debug pppd: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
Wed Feb 16 22:37:29 2022 daemon.debug pppd: dst ff:ff:ff:ff:ff:ff src IF_MAC
Wed Feb 16 22:37:29 2022 daemon.debug pppd: [service-name] [host-uniq 00 00 5e 10]
That really just means your router sent a PADI packet and the expected PADO response packet never arrived... this error can caused by anything affecting the connection between your router and the PPPOE-access concentrator (the server on the ISP side).
Does your modem also have traffic counters? If yes see whether these actually increase....
Yes, I can see the sent packets increasing, but nothing is received