No DHCP for VLAN 5
-
#1 Rule of networking: We don't want to assume, we want to know.
Depending on how your switch is configured and handles tagged frames on an untagged port: delete them, forward them untouched (QinQ), remove the tag and so on, it can work and it cannot work. It's important to VERIFY the configuration along the way.
Cu
-
@Grimeton said in No DHCP for VLAN 5:
Depending on how your switch is configured and handles tagged frames on an untagged port: delete them, forward them untouched (QinQ), remove the tag and so on, it can work and it cannot work. It's important to VERIFY the configuration along the way.
My setup is not ideal I have 4 netgear switches between the pfsense and the AP. Would have been best to have one switch with all the cables going directly to it. I can try to move the AP temporarily to the switch connected to the pfsense
-
@NasKar
If the interface on the pfSense is tagged and the interface on the switch is NOT tagged this can lead to all kind of confusions. Same happens when vice versa.So it's important to know that your VLAN-configuration on pfSense and on the switch is fine.
As DHCP is a system that uses broadcast and relies more on L2 than on L3, having a valid and working VLAN-config is important.
-
Given the phone is sending out discovers and receiving offers, that's not an issue. Also, you'd not see VLAN tags on a switch port that's already been assigned to a VLAN.
-
@JKnott I can tell you from experience that all you've just written is false.
-
Four switches is not a problem if they're configured properly. You have a VLAN. I assume you have the VLAN configured on pfSense and any switch that has to pass VLAN frames configured appropriately. At some point, either a switch or in the AP, the VLAN frames are converted to native frames, by removing the VLAN tags. However, given that you're getting an offer after a discover, there is communication between the iPhone and DHCP server, so I doubt VLAN tags are the problem.
-
False in what way? I have viewed the captured traffic in Wireshark and I can see the discover, coming from the iPhone, followed immediately by the offer, coming from the DHCP server. That tells me the phone and server are communicating up to that point. The next step is for the phone to request the offered address, but that's not happening. The question is why. If it was a VLAN issue, we'd see the discover, but not the offer.
-
@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.
-
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.
-
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?
-
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.
-
@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.
-
Exactly!! Where exactly was this sniff taken? On the pfsense vlan interface?
-
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.
-
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.
-
@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.
-
^ 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?
-
@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.
-
You wouldn't see the tag if you sniffed in pfsense gui on the vlan.
-
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.
-
@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 ;)
-
@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.
-
And again @JKnott if you sniff in the gui in pfsense on the vlan interface - you will not see any tags!
-
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.
-
@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.
-
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.
-
@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 ?
-
@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.
-
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
-
@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.
-
@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.
-
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.
-
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.
-
We need more info from the OP. I'm going back to watch TV in the mean time.
-
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
-
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.