I have had the same issue since moving to vWLAN, but with VM's. My host can always acquire an IP, but the guest VM's cannot. After combing through my DHCP logs, I can see the DISCOVERY, REQUEST and OFFER, but the client never receives the OFFER once the reply comes back through the BSAP. So then it just starts the REQUEST process all over again. I have reported this for two years, and it just now showed up on the latest errata for the new firmware builds.
The issue is that most wireless bridge devices use physical address translation, meaning the vWLAN sees the MAC address of the bridge, not the client. This further means that the bridge would have to proxy-arp for all devices behind them. In other words, the bridge itself does not have an IP address, but rather the client does, and vWLAN or the AP may not ever see the client MAC address. This creates a problem with ARP among other things.
harmlessrobot, your solution would be to use network address translation (NAT) such that the guest VM's IP is translated to the host OS's IP. Most virtualization software allows this, and I know at least one other vWLAN deployment has this working. The client uses Mac OS X with Windows 7 running as a guest OS, or so I recall.
skliffi, you might also consider checking if the device in question can perform NAT.
In both cases, one thing to look at is the frame headers, either 802.3 or 802.11, to check the MAC addresses. Are we seeing the MAC address of the client or the bridge? Does ARP for the IP address return the client or the bridge, or does ARP even work in general?
In fact, Nanostation bridge use its own MAC when sending packet to BSAP, so you are right about L2 address translation.
But its not a problem - problem is that I cannot see broadcast response from DHCP in BSAP wireless interface capture (nor in other linux-PC wireless capture, if I use open SSID and put PC wlan interface in monitor mode).
If I connect with other PC to BSAP, I have only ARP packets, that designated to me. It means that BSAP filter some broadcast packets (ARP, DHCP response and mb some others).
Its good for security and performance, when WiFi clients cant see all network traffic, but for me its a big problem, because one of the demand in our large project is to manage WiFi bridge and CPE behind the bridge without static IP and NAT. Our customer - ISP, so I suppose we will lose the project.
I think you should implement some kind of WDS bridge feature for such cases, it will expand possible scope of vWLAN
Did you get a capture on the BSAP wired interface?
Do clients directly connected to the AP - ie. not behind a bridge - have an issue?
Yes, I do. BSAP wire capture is attached to my first post.
Directly connected clients has no issues.
I suppose that BSAP has some kind of firewall, that forward Ethernet (L2) broadcast traffic only designed to known for BSAP hosts.
I would really appreciate, if you explain how it works in fact, and why I can't use AP as L2-bridge
All of the firewall rules are defined in the Roles, and the those policies are applied at the AP. The vWLAN solution uses a distributed architecture, and wireless client traffic is not tunneled through vWLAN. Once the client traffic passes through the AP, it is placed on the LAN as if it were any other wired traffic. APs are effectively smart hubs with switch-like capabilities. That said, the Bluesocket Access Points (BSAPs) are essentially rooted in basic layer 2 bridge technology, with notable improvements and differences such as the ability to filter traffic at layers 3 and 4 (note that traffic is not filtered using layer 2 addresses).
The AP does maintain a list of clients, similar to a CAM table in a switch. Wireless clients will be associated with a radio interface. The AP checks the source and destination MAC address of incoming packets for switching purposes, however, the AP does not learn the source of a client based on the interface a frame was received. A switch will typically learn the source port of a frame by looking at the port on which the frame was received and update its CAM table accordingly. The BSAP builds its client table using the 802.11 authentication and association frames; the source port is not considered when maintaining the client table. This works because an AP is typically an edge device, and the bulk of the network is connected through the AP's Ethernet port. In other words, if the AP did not receive 802.11 authentication and association frames from a specific MAC address, then that MAC address is assumed to be reachable from the Ethernet interface rather than a radio interface.
In your scenario, the wireless bridge device is what performs the 802.11 authentication and association, and therefore, it is the wireless bridge MAC address that populates the AP's client table. If the wireless bridge performs proxy ARP for the attached client, then there should not be a problem. However, if the wireless bridge does NOT proxy ARP, then a problem occurs. What should likely happen is that the attached client's traffic will pass through the AP, because the AP does not have an 802.11 authentication and association for the client, and the AP simply forwards the traffic out its Ethernet interface. Return traffic, however, might reach the AP, but when the AP checks its client tables, it will not find the MAC address, and so the AP will forward the traffic back out its Ethernet interface.
I hope this answers your questions. I am going to mark your question as "assumed answered" since we effectively know the issue. If any of the comments are helpful or correct, please mark them as such to make this post appear more easily to other members of the support community.