Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 1 reply
  • Subscribers 1 subscriber
  • Views 1110 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ASG eating DHCP offers?

ppadler
We have two SSIDs: One is a guest network that the ASG (2x120 in HA mode, 8.301 with 4xAP10 attached) handles IP addreses for. All is fine in there.

Then we have a wireless network that is bridged to our internal LAN, e.g. Internal WLAN. A Windows Server 2003 is the DHCP server in that subnet.
I can see on that server that devices associated with the internal WLAN send DHCP Discovers and that the Windows Server sends DHCP Offers to the broadcast MAC address.

But when I watch the packets on the device (notebook with Windows XP using Wireshark and filter "port 67 or port 68") I can only see the DHCP Discover packet and no offers at all.

The user symptom is that iOS devices (iPhone, iPad) and also notebooks don't get an IP address and fall back to auto IP.

It seems that the ethernet bridge inside the ASG does not bridge the broadcast packets from the internal LAN over the AP10s to the internal WLAN. That is the expected behaviour though. It did work in the past but seems to have stopped some time in the last few weeks. 

In the web admin under Interfaces & Routing -> Bridging there is no bridge defined. I am not sure if that is correct. I guess the "Bridge to AP LAN"-mode creates an implicit bridge?

Any ideas?

-- Paul


This thread was automatically locked due to age.
  • 0
    Broadcast DHCP offers are not the perfect choice for wireless networks (802.11). If at least one client is in powersave mode the APs will buffer broadcast frames and send them out in a bulk after each DTIM beacon. Hence, broadcast DHCP offers will (in that case) have an average latency of around 100ms (up to ~200ms). The amount of broadcast frames that are buffered on the AP is implementation specific. Hence, if you got quite a lot of broad- and multicast traffic in your network the chances of broadcast frames getting dropped is quite high.

    Furthermore broadcast frames in 802.11 networks are not retried and as such suffer a _much_ higher chance of getting lost "on the air".

    To decrease broadcast traffic in your environment you could use bridge-to-VLAN instead of bridge-to-LAN and use a separate VLAN for wifi which will then reduce the broadcast domain to a subset of which you've got right now.

    You could also reconfigure your DHCP server to send unicast offers instead of broadcast offers.

    HTH,
    Helmut
Unfiltered HTML