I’ve found a strange issue in the managed switch mentioned in the subject.
I have a very simple setup:

• port 1: attached to a DHCP server via trunking (T) on many VLANs, and with the DHCP service being served in the VLAN 113
• port 2: attached to a client device requesting DHCP. The port is untagged (U) and enters directly in the VLAN 113

I have verified that I have perfect network communication between the two ports: if I assign a static IP to the client in the same subnet of the server, I can ping and otherwise communicate with the server without any problem.

THe problem comes when the client tries to request an address via DHCP to the server: it just hangs there and being a Windows device, it resorts to the 169.254 APIPA address.

I have debugged the problem with tcpdump / wireshark both on client and server side:

• on the server: I can see the DHCP requests getting to the server (from 0.0.0.0 port 68 to 255.255.255.0 port 67) and the server responding correctly (92.168.x.y port 67 to 255.255.255.255 port 68)
• on the client: I can see the generated DHCP request leaving the client (from 0.0.0.0 port 68 to 255.255.255.0 port 67), but the response is not getting back to the client

So it seems that the DHCP reponse is blocked by the switch. I have checked in the web interface but it’s default settings, there is no filtering activated anywhere and all other network protocols seems to work correctlty.

Has anybody else come across this strange issue?