No DHCP for VLAN 5

Grimeton

@JKnott This is pointless. I'm not here to measure the size of my dick. I can tell you from experience that switches are the most buggy devices on earth. They leak all kinds of information across VLANs, while other devices like to ignore VLAN-tags in the L2-header based on the moon phase. Especially when it comes to WIFI. There are WIFI devices that forward VLAN-tagged packets and the receiving device just happily ignores them.

So from my experience it's important to make sure that the configuration is fine, ESPECIALLY when the communication is just lost in a brodcasted setup like this one.

JKnott

@Grimeton

Please explain why there's an offer, if the devices are not communicating. If there was a switch failure, there would be no offer, as the server wouldn't have heard from the phone.

Have you looked at that capture? I have it opened in Wireshark right now.

johnpoz

We know that pfsense gets the discover and makes the offer, we have no idea if the phone is getting it.

You really need to validate that by connecting to the wifi if that is where your having a problem.

Are you saying these are 4 dumb switches between your AP and pfsense?

JKnott

I just noticed something curious, though I doubt it has anything to do with the problem. The first frame in the capture is an 802.3 LLC frame, whereas everything to do with IP uses Ethernet ll frames.

Grimeton

@JKnott The trace is from one end of the problem.

The device requests an IP-address and gets handed an offer. If the WIFI-device is forwarding the L2 package with tagged headers the phone might be lost/ignoring it, hence the answer is thrown away.

Just one explanation.

So please, please, please, with lots of sugar on top of it. Make sure that the VLAN-configuration is fine across all devices.

johnpoz

Exactly!! Where exactly was this sniff taken? On the pfsense vlan interface?

JKnott

@Grimeton

Again, there is no sign of VLAN tags in the capture, from either end. Also, devices not configured for VLANs should not accept them. For them to do that, it means accepting a frame with the wrong Ethertype. The frames show the Ethertype for IPv4, not VLAN, which means the VLAN tags have been removed before that point.

johnpoz

If he is sniffing on the vlan interface vs the parent physical he wouldn't see the tags in his sniff.. He would have to sniff on the parent physical interface with -e to see the tags.

Grimeton

@JKnott Depending on WHERE the trace was taken you do not see VLAN-tags because they were filtered out by a lower layer.

But above in the description people are talking about VLANs and VLAN5.

So we ASSUME that it's 802.1q.

johnpoz

^ exactly I would for assure assume 802.1q but he prob sniffed on the vlan interface directly... But lets make sure we know exactly where that sniff was taken.

And we don't have a sniff from the other end via a wireless client (laptop) connected to that same ssid do we?

JKnott

@johnpoz said in No DHCP for VLAN 5:

Exactly!! Where exactly was this sniff taken? On the pfsense vlan interface?

If taken there, I'd expect to see VLAN tags, unless the port connects to a managed switch that puts the frame on a VLAN. So, we'd expect VLAN tags somewhere, but we haven't yet determined where they're added & removed. If it's just dumb switches, then we'd see VLAN tags everywhere between pfSense and the AP. However, I believe that capture was taken on the network used for the AP, which is VLAN 5 somewhere, but there are no tags at that point.

johnpoz

You wouldn't see the tag if you sniffed in pfsense gui on the vlan.

Grimeton

@johnpoz

Yeah besides that, tagged L2 packets via WiFi are a a thing on its own. As I wrote before: some devices ignore the tags and take the packet, others ignore the packets completely and so on...

It gets really nasty really quick if this isn't setup correctly.

johnpoz

@Grimeton said in No DHCP for VLAN 5:

It gets really nasty really quick if this isn't setup correctly.

Preaching to the choir there my friend ;)

JKnott

@Grimeton said in No DHCP for VLAN 5:

So we ASSUME that it's 802.1q.

Again, at what point? Where was that capture taken? Where ever it was, there are no VLAN tags. If you don't believe me, download that capture file and look at it in Wireshark.

johnpoz

And again @JKnott if you sniff in the gui in pfsense on the vlan interface - you will not see any tags!

JKnott

@johnpoz

I think we're arguing the same point. We don't have enough info about the network config and where that capture was made. Did you notice any mention of VLAN tags in what I posted from Wireshark? I even have an extra column configured in Wireshark to display VLAN ID, but don't see anything in that column.

Grimeton

@JKnott We're all humans and we can be wrong, so stop fighting a lost cause.

From a guy that checked the configuration of each single interface accross 10 switches, a firewall and a WiFi-AP:

Check that the VLAN config is fine.

This literally smells for a VLAN-failure along the way.

johnpoz

Agreed - really the only info we have is that pfsense saw the discover and sent an offer.. What happened after that offer left we have no idea. Tagged and dropped along the way, the AP? Not tagged? And was stripped before it got to pfsense but would never get back... We are just guessing with out full info.

Grimeton

@JKnott Besides...

The DHCP-Server is answering .41 in the subnet. It's implementation specific if the DHCP-server sends the answer to the broadcast of the network, the new host-ip or just 255.255.255.255, but when it sends to .41 it gets suspicious, as the range is 100-200 and the subnet is /24.

So where does the .41 come from ?