Usually, applications are using tun/tap devices for this kind of communication. eg: backreference.org/2010/03/26/tuntap-interface-tutorial

Agreed. I use tuntap for some slow path behaviors. The wifi interfaces are being added into an existing fast path infrastructure and the dummy interfaces are a tool to avoid changing that code. Would tuntap exhibit the expected behavior (i.e. writing vlan tagged packets into tap0 appear on tap0.100)?

I think a code review is unnecessary. I'm looking for help understanding the behavior I'm seeing. My code is working as I expect it to since packets are being written to the interfaces with proper headers. The issue is they're not appearing on vlan sub interfaces that match the VLAN of the packet. There aren't many ways to open raw sockets so I'm either using the wrong technologies, I've configured the interfaces incorrectly, or what I'm hoping to achieve is not possibe.

I can't reproduce your setup (without your application). Using dummy seems strange. Anyway, you could test if using a VLAN aware bridge helps. Check my answer on this Q/A related to VLAN-aware bridge (that does not use a sub-interface dummy0.100 at all): unix.stackexchange.com/questions/546136/…

@A.B Seems dummy interfaces don't support the bridge vlan options. To use pvid I'll have to used a different interface type.

@dirkt The vlans on the dummy interfaces appear on the surface to work. They receive traffic from the bridge and if I bind to it directly it seems to send and receive packets as i expect. The trouble is that sending a tagged packet using a raw socket on the base interface doesn't write the packets to the vlan interface.

@apschultz anyway I think using a dummy interface is a bad idea, but here assigning a VLAN to a dummy interface works:ip link set bridge0 vlan_filtering 1; ip link set dummy0 master bridge0; bridge vlan add vid 10 dev dummy0

@A.B Which kernel version are you using? That operation is returning not supported for me.

@apschultz "sending a tagged packet using a raw socket on the base interface doesn't write the packets to the vlan interface." I'd be surprised if this even works for normal interfaces. Raw sockets don't integrate too well with the rest of the add-ons.

Still saying dummy is a bad idea: stick to a tap interface. Using 5.6 kernel, but I don't think that's (only) the kernel version. Works on a 4.9 kernel too. Using a bridge having enslaved a wireless interface might bring additional limitations, maybe this is one of them. Also you need CONFIG_BRIDGE_VLAN_FILTERING=y

Understand you think tap is the right solution. I'm not trying to disagree, but the way dummy presents it does seem it should work and allow me to simplify code. I'm worried that @dirkt is correct and the raw socket is the cause of the issue. If that is the case, I'm not sure tap will solve this. It even seems unlikely that using the bridge to add/strip tags will work since I need the application side to be tagged and wireless side to be untagged (and removing raw sockets is not an option at the moment). I'm on kernel 4.14. I will experiment some more.

What I'd do in this situation is put the app with the raw socket in a network namespace, connect it up with a veth pair to the main namespace, and then re-arrange the VLANs on the veth pair end and/or the wifi interface to make everything work. Then you've cleanly separated the raw socket and the other master/slave constructions.

Of course TAP would solve raw sockets: TAP doesn't use sockets to read or write packets, so there's zero chance you get the same issue.

QEMU, used for VM's network interfaces in QEMU/KVM, uses TAP. Do you really think a VM can't properly use VLANs?

@A.B I'll try to be more clear. I've never written packets with vlan headers into a tap expecting them to appear on vlan interfaces (i.e. tap0.100). That is what I am unsure about.

and again same answer: TAP is intended to do such packet injection. It could be called an official interface for this. TAP has two sides: the process side and the network side.

Anyway you can follow dirkt's suggestion for minimal disruption of your code: inject on a veth instead of a dummy interface, and have the other side handle the vlan sub interface.

@A.B I resolved kernel support for bridge vlan configurations. It would seem there is some conflict on the wireless interface as removing vid 1 or setting pvid somehow presents hostapd processing packets.

@dirkt veth interfaces do the trick. I will need to make sure this much layering (bridge + veth pair) doesn't cause too much overhead but I thank you for the suggestion.