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:
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?
Not to my knowledge. At least WAN and switch are not connected by default. See VLAN configuration for Telekom for the network config.
If this is not relevant enough: How can I find out?
Since @chunkeey added initial support for FRITZ!Box 4040 and @craz showed a screenshot in another thread that displays certain connectivity with this device, I'm wondering if you two have no problems with VLAN tagging on WAN port?!
I know, this thread has become a bit long, but the essence is: sending via eth1.7 does not work for me.
hey,
have you maybe found a solution for this problem? i seem to have the exact same problem with my zyxel nbg6617...
see this thread: Need help with vlan tagging
Hi, unfortunately I have not found a way to get VLAN working for my device so I'm currently running the stock firmware.
Does your device also belong to the ipq40xx target? Maybe there is simply a bug preventing VLAN (on WAN interface).
Maybe you can try the latest development snapshot and see if the issue is still present. But otherwise I have no idea 
yes, my device is also ipq40xx.
i gonna try latest snapshot on monday with a factory reset and will report again.
hey,
thanks to this post Need help with vlan tagging
i got it to work 
should also work for you
Thanks for coming back and telling me about this. It's a suitable workaround.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.