Ah, right. It is FTTH and the FB4040 sits behind a Telekom fiber modem.
That should work. Make sure that eth1.7 is the only interface in WAN. Do not connect anything to plain eth1 without a VLAN number.
Thanks for your answer!
I think it is the only interface in WAN. but WAN and WAN6 are configured equally. That means I gave them both the login data and set custom interface to eth1.7. See screenshots:
When I look at the system log, I see the following:
Thu Aug 16 13:25:01 2018 daemon.notice pppd[10336]: pppd 2.4.7 started by root, uid 0
Thu Aug 16 13:25:13 2018 daemon.warn pppd[10281]: Timeout waiting for PADO packets
Thu Aug 16 13:25:14 2018 daemon.err pppd[10281]: Unable to complete PPPoE Discovery
Thu Aug 16 13:25:14 2018 daemon.info pppd[10281]: Exit.
EDIT: I thought maybe the ISP is blocking me due to malformed connection attempts in the beginning. But waiting an hour and trying again did not solve the problem. I flashed the AVM stock image back to the FB4040, restored the settings and internet is working again. I captured the PPPoE traffic. There, the PADI request is regularly answered with PADO and the protocol flow continues. Don't know what's wrong with my OpenWrt setup.
That is not required, DTAG uses the IPv4 PPPoE Session to also negotiate the IPv6 Prefix for the router and also the homenetwork. Here is what I se on a DTAG VDSL2 link:
config interface 'wan'
option _orig_ifname 'eth1'
option _orig_bridge 'false'
option proto 'pppoe'
option ipv6 'auto'
option ifname 'eth1.7'
option username 'usercode@t-online.de'
option password 'secret_passcode'
That by itself got me IPv4 connectivity. Please note that I use a vdsl2-router in bridge-mode to get from the eth1 wan interface onto the true VDSL2/PTM link.
Any hick-up in the connectivity will result in PADO timeouts...
Thanks for your configuration sample.
I gave it another try but did not succeed Same problem as before.
The following network config was used. The two _orig_*
options were not generated by LUCI so I added them manually.
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd...someipv6here...::/48'
config interface 'lan'
option type 'bridge'
option ifname 'eth0'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
config interface 'wan'
option _orig_ifname 'eth1'
option _orig_bridge 'false'
option proto 'pppoe'
option username 'mynumbers@t-online.de'
option password 'mypass'
option ipv6 'auto'
option ifname 'eth1.7'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '1 2 3 4 0'
Currently I'm out of ideas. Someone else?
Besides, I wanted to capture the connection attempt with tcpdump for comparision with a stock firmware. But I did not find the tcpdump ipk in the repository. Don't know how to get it.
Regarding tcpdump, I found that base packages are in a different repository.
Now I have network dumps of AVM firmware and OpenWrt. I will explain what I observed:
- In the traffic flow, AVM has a little bit DHCP mixed in, while OpenWrt likes to speak ICMPv6 early. I hope that's irrelevant, so let's focus on PPPoED.
- OpenWrt sends 3 identical PADI requests, whereas AVM also sends 3 identical PADI requests plus one from another MAC without VLAN tagging. Since the latter is never answered, let's focus on the others.
- The PADI requests from AVM and OpenWrt look similar but there is one difference: AVM sets the PPPoE Tag
Host-Uniq
to a 30 bytes long value, also containing the MAC address and the string "F!Box". OpenWrt does not set theHost-Uniq
tag. - AVM receives an PADO answer after 8.7 seconds containing the PPPoE Tags
AC-Name
,Host-Uniq
(replayed from PADI) andAC-Cookie
. On the other hand, OpenWrt times out after 10 seconds without a reply.
May it be the case that the Host-Uniq
tag is important? Or what else is going on?! I'm a bit clueless now.
have you tried setting option host_uniq
like the fb does ?
Well on a VDSL50/100 Telekom VDSL2@BNG link I was facing similar issues, and I also noted the difference in the host_uniq tag, but it turned out that I could happily live with that after getting the VLAN to work properly.
Now I tried setting the host_uniq
tag but the problem remains the same.
VLAN ID 7 is also set. I posted the configuration for reference in a previous comment.
The PADI messages are now identical on a byte level but it still does not work. How can this even be... I don't get it...
Ok, I think I know why there is no PADO answer. The PADI is actually never going out! Now I need your help figuring out why.
I sniffed the traffic at three points:
- tcpdump for eth1 on OpenWrt: I see the PADI packets with VLAN ID 7
- tcpdump for eth1.7 on OpenWrt: I see the PADI packets but without VLAN header (guess this is expected?!)
- Hardware TAP between router and modem, alternatively direct connection from router to laptop: There are no PPPoE packets on the wire! Only some IPv6 discovery.
So for some reason, it seems the PPPoE packets (maybe because they are VLAN tagged) do not leave the WAN interface, despite tcpdump shows them on the sender device.
What is going on there?! oO
Besides, I noticed the WAN interface goes regularly down and up again (after the PPPoE timeout). Is this normal? Example:
Thu Aug 16 08:18:55 2018 daemon.warn pppd[7460]: Timeout waiting for PADO packets
Thu Aug 16 08:18:55 2018 daemon.err pppd[7460]: Unable to complete PPPoE Discovery
Thu Aug 16 08:18:55 2018 daemon.info pppd[7460]: Exit.
Thu Aug 16 08:18:55 2018 daemon.notice netifd: Interface 'wan' is now down
Thu Aug 16 08:18:55 2018 kern.info kernel: [ 1671.594374] IPv6: ADDRCONF(NETDEV_UP): eth1.7: link is not ready
Thu Aug 16 08:18:55 2018 daemon.notice netifd: Interface 'wan' is disabled
Thu Aug 16 08:18:55 2018 kern.info kernel: [ 1671.677790] device eth1 left promiscuous mode
Thu Aug 16 08:18:55 2018 kern.info kernel: [ 1671.680162] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
Thu Aug 16 08:18:55 2018 daemon.notice netifd: Interface 'wan' is enabled
Thu Aug 16 08:18:55 2018 daemon.notice netifd: Interface 'wan' is setting up now
Thu Aug 16 08:18:55 2018 kern.info kernel: [ 1671.682434] ess_edma c080000.edma: eth1: GMAC Link is up with phy_speed=1000
Thu Aug 16 08:18:55 2018 kern.info kernel: [ 1671.687678] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
are you positive that this setup does indeed see vlan-tagged frames?
wan-if beeing up/downed after timeout is normal, afaik
Yes. I also was in doubt but I tried with AVM firmware and OpenWrt and my laptop with Wireshark received VLAN tagged PPPoE packets from AVM but not from OpenWrt. The latter emitted just some IPv6 discovery stuff.
So I guess either there is still something wrong with my VLAN setup (maybe because it does not appear in the switch config?!) or there is a bug somewhere.
you don't use vlan on/over the switch, so i doesn't show up.
i tend to agree
could you try to send out and record tagged frames with the non-working setup to discern between likelyhood of a bug in pppd
or driver?
Good idea. I already thought about how I could do this at best. Any ideas? The thing is, I guess when I send something with a packet crafting tool, it will probably be injected that low in the networking stack that it will be sent. Probably I need an application similar to pppd that I can tell to send something via eth1.7. Do you have a suitable application in mind? Otherwise I need to play around a bit..
ping -b -I eth1.7 255.255.255.255
Great, simple idea
-b
flag is not supported by busybox ping but test works also without the flag.
Sending on eth1 transmits the echo requests. Sending on eth1.7 don't. When switching from PPPoE to DHCP mode, the DHCP requests are also lost.
So it seems sending on eth1.7 does not work. While tcpdump on eth1.7 shows everything, nothing gets on the wire.
could you further confirm that this is not due to firewall rules? (accept
on default and/or wan output)
confirm this behaviour with the most default config on latest 18.06 as well as with the lede-17 branch.
then probably make bugreport along the lines vlan not working ...
Thanks for your help.
I already tried latest snapshot for the previous test run. I did not test lede-17 because my device is only supported since 18.06.
I checked the firewall settings in LUCI, changed everything to accept and in the end I even flushed iptables completely. No packets go through eth1.7...
For reference here the default iptables output before I changed anything.
# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere /* !fw3 */
input_rule all -- anywhere anywhere /* !fw3: Custom input rule chain */
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED /* !fw3 */
syn_flood tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN /* !fw3 */
zone_lan_input all -- anywhere anywhere /* !fw3 */
zone_wan_input all -- anywhere anywhere /* !fw3 */
Chain FORWARD (policy DROP)
target prot opt source destination
forwarding_rule all -- anywhere anywhere /* !fw3: Custom forwarding rule chain */
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED /* !fw3 */
zone_lan_forward all -- anywhere anywhere /* !fw3 */
zone_wan_forward all -- anywhere anywhere /* !fw3 */
reject all -- anywhere anywhere /* !fw3 */
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere /* !fw3 */
output_rule all -- anywhere anywhere /* !fw3: Custom output rule chain */
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED /* !fw3 */
zone_lan_output all -- anywhere anywhere /* !fw3 */
zone_wan_output all -- anywhere anywhere /* !fw3 */
Chain forwarding_lan_rule (1 references)
target prot opt source destination
Chain forwarding_rule (1 references)
target prot opt source destination
Chain forwarding_wan_rule (1 references)
target prot opt source destination
Chain input_lan_rule (1 references)
target prot opt source destination
Chain input_rule (1 references)
target prot opt source destination
Chain input_wan_rule (1 references)
target prot opt source destination
Chain output_lan_rule (1 references)
target prot opt source destination
Chain output_rule (1 references)
target prot opt source destination
Chain output_wan_rule (1 references)
target prot opt source destination
Chain reject (3 references)
target prot opt source destination
REJECT tcp -- anywhere anywhere /* !fw3 */ reject-with tcp-reset
REJECT all -- anywhere anywhere /* !fw3 */ reject-with icmp-port-unreachable
Chain syn_flood (1 references)
target prot opt source destination
RETURN tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 25/sec burst 50 /* !fw3 */
DROP all -- anywhere anywhere /* !fw3 */
Chain zone_lan_dest_ACCEPT (4 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere /* !fw3 */
Chain zone_lan_forward (1 references)
target prot opt source destination
forwarding_lan_rule all -- anywhere anywhere /* !fw3: Custom lan forwarding rule chain */
zone_wan_dest_ACCEPT all -- anywhere anywhere /* !fw3: Zone lan to wan forwarding policy */
ACCEPT all -- anywhere anywhere ctstate DNAT /* !fw3: Accept port forwards */
zone_lan_dest_ACCEPT all -- anywhere anywhere /* !fw3 */
Chain zone_lan_input (1 references)
target prot opt source destination
input_lan_rule all -- anywhere anywhere /* !fw3: Custom lan input rule chain */
ACCEPT all -- anywhere anywhere ctstate DNAT /* !fw3: Accept port redirections */
zone_lan_src_ACCEPT all -- anywhere anywhere /* !fw3 */
Chain zone_lan_output (1 references)
target prot opt source destination
output_lan_rule all -- anywhere anywhere /* !fw3: Custom lan output rule chain */
zone_lan_dest_ACCEPT all -- anywhere anywhere /* !fw3 */
Chain zone_lan_src_ACCEPT (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere ctstate NEW,UNTRACKED /* !fw3 */
Chain zone_wan_dest_ACCEPT (2 references)
target prot opt source destination
DROP all -- anywhere anywhere ctstate INVALID /* !fw3: Prevent NAT leakage */
ACCEPT all -- anywhere anywhere /* !fw3 */
Chain zone_wan_dest_REJECT (1 references)
target prot opt source destination
reject all -- anywhere anywhere /* !fw3 */
Chain zone_wan_forward (1 references)
target prot opt source destination
forwarding_wan_rule all -- anywhere anywhere /* !fw3: Custom wan forwarding rule chain */
zone_lan_dest_ACCEPT esp -- anywhere anywhere /* !fw3: Allow-IPSec-ESP */
zone_lan_dest_ACCEPT udp -- anywhere anywhere udp dpt:isakmp /* !fw3: Allow-ISAKMP */
ACCEPT all -- anywhere anywhere ctstate DNAT /* !fw3: Accept port forwards */
zone_wan_dest_REJECT all -- anywhere anywhere /* !fw3 */
Chain zone_wan_input (1 references)
target prot opt source destination
input_wan_rule all -- anywhere anywhere /* !fw3: Custom wan input rule chain */
ACCEPT udp -- anywhere anywhere udp dpt:bootpc /* !fw3: Allow-DHCP-Renew */
ACCEPT icmp -- anywhere anywhere icmp echo-request /* !fw3: Allow-Ping */
ACCEPT igmp -- anywhere anywhere /* !fw3: Allow-IGMP */
ACCEPT all -- anywhere anywhere ctstate DNAT /* !fw3: Accept port redirections */
zone_wan_src_REJECT all -- anywhere anywhere /* !fw3 */
Chain zone_wan_output (1 references)
target prot opt source destination
output_wan_rule all -- anywhere anywhere /* !fw3: Custom wan output rule chain */
zone_wan_dest_ACCEPT all -- anywhere anywhere /* !fw3 */
Chain zone_wan_src_REJECT (1 references)
target prot opt source destination
reject all -- anywhere anywhere /* !fw3 */
I think I'm going to create a bug report now.
There it is: https://bugs.openwrt.org/index.php?do=details&task_id=1883
Let's hope someone has an idea what's going on.
So I wonder whether the 4040 "routes" its WAN port via the switch? In that case you might also need to configure the switch to use VLAN tag 7 on the appropriate port?