No DHCP for VLAN 5

JKnott

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 ?

JKnott

@Grimeton said in No DHCP for VLAN 5:

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

Then please explain why the DHCP server was able to send that offer, if it couldn't possibly have seen the discover, if there had been a VLAN problem.

Perhaps the OP can confirm this, but my understanding is that capture was taken with Packet Capture on pfSense. At that point, inside pfSense, there would be no VLAN tags. The tags would be added as the frame heads out on the wire. What we need is info from the OP and we haven't seen much. He mentioned he had a desktop computer, which I suggested he run Wireshark on, to see what's on that part of the network.

Grimeton

@JKnott

Let's assume a configuration:

The WIFI-Interface of the AP is configured to assign incoming, untagged packets a default VLAN, which is 5. (Rather common configuration). From there on everything travels fine over the switches to pfSense, which sends out the response fine.

But now the WIFI-interface of the AP is not configured to remove any VLAN-tags and instead just has the port configured as tagged with VID 5.

So the packet that gets send out is tagged with VID 5, which the phone ignores.

There's your problem.

Just one of the hundreds of possible ways to create this problem.

Cu

JKnott

@Grimeton said in No DHCP for VLAN 5:

So where does the .41 come from ?

That indicates a possible 2nd DHCP server, unless there's a static mapping, which cannot be within the pool. We know the MAC address of the DHCP server. Does it match the VLAN interface on pfSense? I don't recognize the name in the MAC.

Grimeton

@JKnott IT ANSWERS to .41.

So the DESTINATION is .41.

DHCP-servers don't talk to each other. The client picks one offer and declines the others. That's how it's defined in the RFC and worked for ages.

JKnott

@Grimeton

You may have missed my update to that post, where I mentioned the static mapping. You cannot assign an address within the pool, so it's entirely appropriate for the same DHCP server to hand out an address within that pool or a mapped address that's not within the pool.

JKnott

@Grimeton

Yes, I'm aware of how that RFC specifies this. But that doesn't answer where that offer came from. The MAC address will tell that.