I'm trying to help a friend set up OpenWrt on a Nexx WT3020 router. Got 19.07.2 flashed and running.
Problem: the router cannot connect to the ISP via PPPoE, and the ISP does not support IPv6.
We spent a few hours trying to get it to work, but no joy. The log always says: “Timeout waiting for PADO packets”. We can connect from macOS using PPPoE, so the ISP is working. Ergo, it must be an issue with the OpenWrt config.
At first, both the WAN and WAN6 interfaces bizarrely showed packets being sent, so I deleted the WAN6 interface. But still, there are "Advanced Settings" under WAN that seem to default to using IPv6. I tried disabling those but then the ISP sends other errors (e.g. "Unknown error (USER_REQUEST)").
My friend has become frustrated with OpenWrt and now wants to dump it and go back to the factory Nexx firmware. I have tried to say that OpenWrt is better, but it's hard to be persuasive when it acts like this.
Is there some simple, clear documentation that describes the exact steps to disable IPv6, i.e., in noob-friendly language??
Those timeouts occur for a variety of reasons: some ISPs want username and password, some insist that the packet come from a specific VLAN, other only answer if the device has a specific MAC address and so on and so forth.
Anyhow, disabling IPV6 in OpenWRT for a specific PPP interface can be done under Network->Interfaces:
Also, wan is what you get after the ppp exchange (including PAD0) has completed, I'm not sure it makes sense to worry about what happens before but perhaps someone else can confirm or deny this.
Thanks for your message. The connection between the two (i.e., "... and ...") was meant to emphasize that IPv6 is apparently not an option.
Starting from the very beginning (i.e., when OpenWrt is first installed), do I need to delete the WAN6 interface (by default, there seems to be WAN and WAN6), or just leave it alone and set "Obtain IPv6-Address" to Disabled?
My general understanding of this is limited, but I thought the very first exchange is PADI/PADO, e.g.:
From this, I assume that "Timeout waiting for PADO packets” means the very first step is failing, before the exchange of username/password, etc., as something about the PADI wasn't acceptable(?) to the ISP. Is that what this timeout indicates?
The Nexx WT3020 router's factory software worked to connect to the ISP, albeit jankily (before we reflashed it to OpenWrt), and a Mac (normally behind the router) can itself connect to the ISP via PPPoE (i.e., connecting the Mac directly to the optical modem, bypassing the router entirely), so I am guessing(?) the ISP isn't expecting a specific MAC address. As for a specific VLAN, I'm not sure how that would be specified, but I gather it's not necessary to provide a service name in the PADI.
Beyond that, is there some guide to troubleshoot the failure to get a WAN connection with OpenWrt?
Thing is, PPPoE operates below IPV4 / IPV6 so I can't really envision a way in which lack of IPV6 support on the ISP side would cause the negotiation to fail, not to mention how the mere presence of IPV6 support on your side could do that.
Anyhow, setting an interface to "disabled" should be equivalent to deleting it, it is just quicker to undo in case of problems.
Question: when you use MacOS directly connected to the modem, does it work immediately or do you have to wait a short while? Also, any interesting parameters in the config screens of the Mac?
@eduperez@trendy I had a quick look at the forums and I see most issues with these timeouts are due to VCI / VPI parameters, but this cannot be the case since here there is a ONT. MAC address lock is also probably out, MacOS works. Oh and... I also couldn't find a generic guide but this post was interesting.
Ah, I see. So then maybe the problem is really something else.
Anyhow, setting an interface to "disabled" should be equivalent to deleting it, it is just quicker to undo in case of problems.
Okay. If both WAN and WAN6 interfaces are defined by default, how should I disable one of them (or should I?)? Under "Advanced Settings", I see a Disabled option for "Obtain IPv6-Address", but does that actually disable the whole interface (as opposed to only disabling IPv6)? Basically, I'm still confused why the stock setting has both WAN and WAN6 interfaces defined and why both showed activity for TX. To me, this makes it look like two different interface definitions were being attempted simultaneously over a single channel, i.e., chaos.
Question: when you use MacOS directly connected to the modem, does it work immediately or do you have to wait a short while? Also, any interesting parameters in the config screens of the Mac?
Let me check and post a follow up. I don't have the machine here in front of me.
WAN6 is defined as an alias of WAN. Think of it as sitting on top of the WAN connection to provide ipv6 (if available). As far as activity stats they're the same interface so show the same.
IPv6 is very unlikely to be the issue here. WAN6 can be left alone, if you don't have IPv6 connectivity it'll remain dormant without issue. You're far more likely to cause issues by disabling/deleting stuff, especially when you're trying to solve an issue by looking in the wrong place.
If you can read this, my PPPoE connection is working, and I am sure that my ISP does not support IPv6... I would change the title of the post, because this issue is definitively not related to IPv6. Also, forget about WAN6 and leave it alone: you either get a WAN6 interface or you don't, but it is not going to break your IPv4 interface.
As @aboaboit pointed out, the first think I would look at VCP / VPI (for ADSL) / VLAN (for FFTH) parameters. You mentioned that a computer connected directly to the fiber modem can obtain a connection, that's good news. Can we know what exact configuration are you using on that computer, please? (a screenshot of the configuration screen would be fantastic)
disabling IPv6 is not what you need to do. I don't know how to get it working on your ISP but I know it is not ipv6. First try telling the forum what ISP you are trying to get working and what you have tried so far. It would be a good thing to do a full reset of the config files and start over.
Just to mention that disabling IPv6 in total is not a supported function for OpenWrt.
Nevertheless, as previously mentioned, IPv6 has nothing to do with the failed pppoe attempts.
I would start by looking at the configuration first.
Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have
uci export network; uci export wireless; \
uci export dhcp; uci export firewall; \
head -n -0 /etc/firewall.user; \
iptables-save -c; ip6tables-save -c; \
ip -4 addr ; ip -4 ro li tab all ; ip -4 ru; \
ip -6 addr ; ip -6 ro li tab all ; ip -6 ru; \
ls -l /etc/resolv.* /tmp/resolv.*; head -n -0 /etc/resolv.* /tmp/resolv.*
Also, any interesting parameters in the config screens of the Mac?
The ISP is DTI in Japan. We checked the macOS PPPoE settings, and I don't see anything unusual (the ISP explains the setup here). No service name is required by the ISP in the PPPoE settings. The only special option required appears to be enabling "Send PPP echo packet". I'm not sure how to configure OpenWrt for that.
As @aboaboit pointed out, the first thing I would look at VCP / VPI (for ADSL) / VLAN (for FFTH) parameters.
We messed around some and got it working(!). OpenWrt's default protocol for WAN is DHCP and that seemed to confuse the ISP. After we set up WAN as PPPoE and after a few more errors (e.g., Unknown error "USER_REQUEST" and "AUTH_TOPEER_FAILED") it started to work.
Questions...
(1) How would I configure OpenWrt to send a PPP echo packet?
(2) The WAN6 Interface defaults to DHCPv6 client — is it okay to leave this as-is?
In summary, I'm guessing the issue was that the default DHCP over WAN confused the ISP and it took some fiddling to get it to accept PPPoE. Does that sound right?
Out of curiosity, is it typical that ISPs now use DHCP over the WAN link? I'm asking because I think every ISP I've used over the years expects this sort of PPPoE config, and I'm wondering if it wouldn't be a nice default for OpenWrt.
Thanks everybody for helping to get this going. OpenWrt has always worked well for me, and I'm glad my friend is using it now too.
I think that PPP echo packets are sent by default. These are like pings that tell the ISP not to drop you.
ppp is completely different from DHCP. It is another layer of headers on the packets. Also there is a mechanism to authenticate the subscriber (though your particular ISP does not use it), and to communicate the IP, gateway, DNS server, etc settings within the pppoe driver in a way analogous to DHCP-- though it is completely not DHCP.
Many DSL and fiber services use pppoe, though cable never does. If you are using a provider modem in the non-bridge configuration where it is expecting to route several users to the line[1], you would obtain an IP from the modem by DHCP. That will be a private IP though.
[1] which is the default setup for nearly all provider modems since it offers plug and play operation to a non-technical user.
Hey, thanks for clarifying. I'm still a bit confused when you say "there is a mechanism to authenticate the subscriber (though your particular ISP does not use it)". I thought the PAP/CHAP username and password are to authenticate the user's PPP session with the ISP. This ISP does require both for PPPoE. The WAN address is definitely being assigned by the ISP, and I believe the DNS addresses, too.
As far as I can tell, the provider's modem is just converting between the optical "circuit" and Ethernet. It's a NTT GE-PON-ONU Type D, which is described as an "optical terminator". It doesn't have a built-in router. It connects between the Nexx router and the optical line. So, OpenWrt is doing all the heavy lifting to establish the WAN connection to the ISP.
So maybe my question should be: which style of modem is more common these days? This "optical terminator" type that doesn't have a built-in router, or a more sophisticated type of modem that does have a built-in router? The type under discussion here is pretty similar to what I've always used in the past, so I'm wondering if defaulting OpenWrt to PPPoE protocol might help save others some of the head-scractching that I just went through.
Nah, you can have multiple interfaces over the same channel, that's actually how you set multiple addresses if you need them. For example, on the physical eth1 port I have the wan port both as pppoe (to connect to the ISP) and as dhcp client (to reach the DSL modem GUI), which exist as two different logical interfaces (eth1 and pppoe-wan).
In this sense, "whole interface" means the IPV6 counterpart: try disabling it but I would be extremely surprised it if changed anything at all, let alone solve the issue.
I'm afraid my general fascination for Japan does not include ability to read the language
Interface, WAN, advanced:
LCP echo failure threshold: how many echo packets must be lost before an existing link is considered disconnected
LCP echo interval: delay in seconds between each echo packet
(I have 6 and 5, which means a minimum of 30 seconds must pass before the link is disconnected and the router begins a new connection attempt, if the interface is so configured)
I'm not a developer but I'd say that there is no way to pick a default that will cover all use-cases and this one is pretty reasonable: if you have an ISP-mandated router, you can plug your own OpenWRT router in one of its lan ports and you're good to go.
Thanks. So, AFAICT, the solution was that beyond specifying the correct protocol (PPPoE), PAP/CHAP username and password, it was necessary to Restart the interface several times (we also rebooted the router), because the ISP was seemingly unresponsive after OpenWrt attempted to connect the WAN link using the default protocol of DHCP.
My initial suspicion of IPv6 and the appearance of both WAN and WAN6 in the default config proved to be unfounded. I learned that "disabling IPv6 in total is not a supported function for OpenWrt" but that IPv6 is a non-issue for a failed PPPoE connection. The basic OpenWrt configuration was okay out of the box. It just required more patience than expected.
