No DHCP for VLAN 5

Grimeton

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.

JKnott

@JKnott

We need more info from the OP. I'm going back to watch TV in the mean time.

Grimeton

The offer came from pfSense...

Anyway. As the guy with the problem is not online and you're more fighting a lost cause than trying to productively narrow down the problem, I suggest we all take a step back and relax.

Cu

NasKar

Update:
I moved the AP to the switch that is closest to my pfsense router. I adjusted on my Netgear GS108Ev3 a free port to be (hybrid) untagged on VLAN5 192.168.5.0/24 and tagged on all the other vlans. I got it working by not placing a vlan tag on VLAN5 in the AP and putting a VLAN tag on the other VLANS in the AP.

Will move it back and check the other switches to confirm they are setup with trunks between switches and hybrid setup like about on the AP switch port.

My best guess as to what happened is my AP wireless on VLAN5 was set to vlan5 in the AP on that wireless which may not be the correct setting. It worked with older version of the software but broke after an update.

Can someone confirm if they think I have the correct setup with the hybrid switch port with VLAN5 untagged and no vlan set on VLAN5 in the AP? Thanks for everyone's help.