0

I have a Pi with 2 wireless interfaces, 1 is connected to the networks gateway, the other which is acting as an access point thanks to hostapd.

The AP is not running any DHCP or NAT software, simply running hostapt to allow multiple devices to connect to it.

I am trying to connect my laptop to this access point.

Using static IP address and manually entering in gateway address, DNS etc it works perfectly fine.

However when I try to connect using DHCP it does not work, from wireshark I can see that the initial DHCP Discover packet is sent to the access point upon attempting to connect. However this packet is then not forwarded out of the interface connected to the gateway despite the fact I have some bridging software that i wrote in python running on the Pi.

The software simply sends packets out on the opposite interface they were received on (An oversimplification of what it does, but that is the general jist for this scenario, it is a Network Bridge). So the AP interface should receive the DHCP packet and forward it onto the gateway, which should reply with the DHCP offer etc.

The software works as i can see other DHCP inform messages on my laptop that have gone through the bridging software, as well as other DHCP discover/offer/request/acks that the bridging software is sending to my laptop at the moment due to them being broadcasts.

I am wondering whether the reason these DHCP Discover packets are not being forwarded onto the gateway is due to some setting or feature of the hostapd access point?

I am confident the problem does not lie with the code i have written as it works perfectly fine for DNS and the like.

Further more if I manually craft a DHCP Discovery packet then it gets forwarded and outputted by the interface connected to the gateway with no issues, the DHCP packets only don't get forwarded when they are sent automatically by my laptop trying to obtain and IP address from the access point it is trying to connect to.

I would assume that the access point does not need to supply the IP address directly, but can contact the actual DHCP server on the network to assign one correctly.

If anyone has any idea why the packet seems to get absorbed by the access point before it can be forwarded to the other interface please let me know!

  • Other people have already invested a lot of time in doing this. Bridging is impossible with WiFi and pseudobridging isn't that easy. – Daniel B Mar 17 '17 at 22:45
  • Well I currently have a setup that works, but only with static IP addresses (Must be pseudo bridging) I have Internet <-> Gateway <-> Pi <-> Pi <-> Pi <-> Laptops. Where each Pi is running my bridging software, sending packets out at layer 2. As it stands the Laptops are able to connect to the internet and do searches on google etc. The issue is that for some reason DHCP packets are not getting through the bridges, they never get past the access point that the laptops connect to, suggests to be perhaps something going on with the access point trying to resolve the DHCP packets? – Slinky Mar 18 '17 at 10:17
0

I assume you are using WPA2 on the "uplink" side. This won't work, as WPA2 is tied to the MAC address when encrypting. So relaying packets won't work.

You would need to construct something with proxy arp, or IP forwarding.

If you try to reinvent the wheel in python, don't worry, everything is in the linux kernel. But remember: DHCP Discover is a broadcast, and the answer is an layer2 unicast to the sending MAC. So if you translate here, you would need to rewrite inside the packets. It might be easier to experiment with a DHCP Relay setup, as the Raspi would be a switch doing exactly that.

My first recommendation would be to get the setup working with NAT and DHCP Server on the middle box working, then as a 2nd step working up towards more a transparent middle box.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.