VLAN configuration for Telekom

firefexx · September 23, 2018, 1:07pm

I just set up OpenWrt on a Fritz!Box 4040 and now I try to configure internet access (ISP is Deutsche Telekom).

I know that I need to configure VLAN tagging with ID 7. I already found a German explanation on the ISP's forum.

Unfortunately I cannot follow the instructions because the WAN interface (eth1) does not occur on the switch configuration page. Only the LAN ports associated to eth0 are there.

Therefore, I just opened the "Physical Settings" page of the WAN interface and typed in the "Custom Interface" eth1.7. (I did this for WAN and WAN6)

This does not seem to work since I only get "Connection attempt failed".

Can someone tell me what I'm doing wrong?

moeller0 · September 23, 2018, 1:23pm

The first question is, what kind of Link are you using, FTTH/fiber, DOCSIS/cable or FTTC/VDSL2? Then what other device sits between your FB4040 and the Internetsocket?

firefexx · September 23, 2018, 2:13pm

Ah, right. It is FTTH and the FB4040 sits behind a Telekom fiber modem.

mk24 · September 23, 2018, 3:06pm

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.

firefexx · September 23, 2018, 3:22pm

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:

Bildschirmfoto%20vom%202018-09-23%2017-15-58

Bildschirmfoto%20vom%202018-09-23%2017-16-14

Bildschirmfoto%20vom%202018-09-23%2017-16-29

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.

moeller0 · September 23, 2018, 6:23pm

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...

firefexx · September 29, 2018, 3:34pm

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.

firefexx · September 30, 2018, 9:47am

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 the Host-Uniq tag.
AVM receives an PADO answer after 8.7 seconds containing the PPPoE Tags AC-Name, Host-Uniq (replayed from PADI) and AC-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.

fuller · September 30, 2018, 12:49pm

have you tried setting option host_uniq like the fb does ?

moeller0 · September 30, 2018, 1:22pm

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.

firefexx · September 30, 2018, 4:02pm

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...

firefexx · October 6, 2018, 2:33pm

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

fuller · October 7, 2018, 9:00am

are you positive that this setup does indeed see vlan-tagged frames?

wan-if beeing up/downed after timeout is normal, afaik

firefexx · October 7, 2018, 9:17am

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.

fuller · October 7, 2018, 9:45am

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?

firefexx · October 7, 2018, 10:07am

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..

fuller · October 7, 2018, 10:26am

ping -b -I eth1.7 255.255.255.255

firefexx · October 7, 2018, 12:16pm

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.

fuller · October 7, 2018, 12:49pm

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 ...

firefexx · October 7, 2018, 3:04pm

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.