WiFi calling and VLAN 1

JKnott

Recent discussions had me examining a packet capture of a WiFi call in more detail One thing I noticed is that the ESP packets are on VLAN 1, often with a priority of 3. I find the VLAN 1 curious, as I thought VLAN ID 0 was used when just adding priority to a frame, without a separate VLAN. I also thought it was a bad idea to use VLAN 1. This capture was taken from a Pixel 2 phone connection via WiFi calling. Any idea why VLAN 1 would be used, instead of 0? I also see IP code point CS0 is used, which indicates no priority.

I have attached the caputure file.

WiFicall.pcapng

stephenw10

Hmm, no idea. I would never choose to use VLAN1 there, or anywhere. I notice only outbound packets are tagged also.

VLAN 1 can cause issues because it can be handled in different ways. Some switches use VLAN1 internally for example for the native VLAN and that means that traffic coming in tagged in VLAN1 might be untagged in the switch unintentionally.
If course if you have tagged traffic anywhere you should be handling that specifically and not just hoping connected switches pass it! But not using VLAN1 at all avoids an issues there.

https://docs.netgate.com/pfsense/en/latest/book/vlan/vlans-and-security.html#using-the-default-vlan1

Steve

JKnott

@stephenw10 said in WiFi calling and VLAN 1:

Hmm, no idea. I would never choose to use VLAN1 there, or anywhere. I notice only outbound packets are tagged also.

I wouldn't use it either, as that's what VLAN 0 is used for. Also, for inbound packets to be tagged, pfSense would have to create them, as they wouldn't pass through any router. In this case, pfSense would have to read the IP code point and convert it to an VLAN tag, with appropriate priority and correct VLAN ID. How would it do that? However, the incoming packets are CS0, which indicates no priority.

BTW, any switch that doesn't pass a VLAN frame is broken. A managed switch might block it, if so configured. Regardless, it is obviously reaching pfSense and being sent out to the Internet, without any VLAN tag on the WAN side.

stephenw10

Ah, of course, it's an internal pcap. Should have considered that.

I agree unmanaged switches should pass vlan frames and most do. But some don't, you shouldn't rely on that.

The cost of quasi managed switch chips is low enough these days that I could well believe many unmanaged switches just don't have the management interface. See for example most SOHO 'router' devices with a built in switch.

Steve

JKnott

@stephenw10 said in WiFi calling and VLAN 1:

I agree unmanaged switches should pass vlan frames and most do. But some don't, you shouldn't rely on that.

Here is a list of Ethertype numbers. Any switch that can't pass every one of those is defective. Other than the additional 4 bytes, the only difference between a VLAN frame and any other, is the contents of the Ethertype/Length field. Frame expansion to handle VLANs and other has been around for several years.

Years ago, networking was more than just IP over Ethernet. There were a variety of Ethernet frame types for different protocols. This means that switches and hubs before them, had to handle any frame type that came along, just as the old 10base2 and 10base5 coax networks did. For a switch to fail at passing a VLAN frame, it would have to read the contents of the Ethertype/Length field and then deliberately reject it, when it shouldn't be reading that field at all, except in managed switches that can properly handle VLANs.

NogBadTheBad

I still work on an account that uses DecNET

JKnott

@NogBadTheBad said in WiFi calling and VLAN 1:

I still work on an account that uses DecNET

What would use that these days? It would have to be ancient.

My first Ethernet experience was with DECnet (10base5), connecting several VAX 11/780 systems. Later, I hand wired, on prototyping boards, Ethernet controllers for Data General Eclipse computers, to share the network. My first network experience was in early 1978, on the Air Canada reservation system, which used a TDM loop, rather than packets. Each device was assigned a time slot in which to transmit. The destination would be told to listen to that time slot. The heart of the system was a UNIVAC computer, which I did not work on. I worked on some Collins 8500C computers, which were the communications front end for the UNIVACs. The Collins system, in turn, had a bunch of PDP-11s, each with up to 4 6800 CPUs, which controlled 8 serial ports each.

I also worked with token ring at IBM.

NogBadTheBad

@JKnott said in WiFi calling and VLAN 1:

@NogBadTheBad said in WiFi calling and VLAN 1:

I still work on an account that uses DecNET

What would use that these days? It would have to be ancient.

An old Dec server running a legacy application, due to be retired soon.