OpenWrt Forum Archive

Topic: AP bridging not working probably?

The content of this topic has been archived on 16 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi All,

I am not a experienced network engineer, I need your help very urgently - I have been trying to fix this for at least 8 weeks.

I use a OpenWRT powered AP with WPA-PSK encryption which acts as a bridge between wired and wireless interfaces. Its clients are a secound AP using wpa_supplicant and and notebook. The DHCP server is a ActiveDirectory controller in the wired environment - all other DHCP servers are disabled. Firewall and NAT are also disabled.

When I connect to the AP using the notebook, everything is working fine including DHCP autoconfiguration. But when I connect using the client AP it works only for the first time, as soon as the client AP disconnects DHCP is not working anymore.

This is a tcpdump of the wireless interface on the client AP:

00:43:33.393131 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:18:0a:01:1b:09 (oui Unknown), length: 277
00:43:36.453173 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:18:0a:01:1b:09 (oui Unknown), length: 277
00:43:39.513129 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:18:0a:01:1b:09 (oui Unknown), length: 277
00:43:42.573141 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:18:0a:01:1b:09 (oui Unknown), length: 277
00:43:45.633116 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:18:0a:01:1b:09 (oui Unknown), length: 277
00:43:48.693169 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:18:0a:01:1b:09 (oui Unknown), length: 277

As you can see, only DHCP requests were sent and no response is received.

To evaluate this issue I started to monitor using wireshark. This is a packet dump of the wired interface on the AP:

No.     Time        Source                Destination           Protocol Info
    181 5.643767    0.0.0.0               255.255.255.255       DHCP     DHCP Discover - Transaction ID 0x4886f13d

Frame 181 (319 bytes on wire, 319 bytes captured)
Ethernet II, Src: MerakiNe_01:1b:09 (00:18:0a:01:1b:09), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Bootstrap Protocol
    Message type: Boot Request (1)
    Hardware type: Ethernet
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x4886f13d
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: 0.0.0.0 (0.0.0.0)
    Next server IP address: 0.0.0.0 (0.0.0.0)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: MerakiNe_01:1b:09 (00:18:0a:01:1b:09)
    Server host name not given
    Boot file name not given
    Magic cookie: (OK)
    Option: (t=53,l=1) DHCP Message Type = DHCP Discover
    Option: (t=61,l=7) Client identifier
    Option: (t=60,l=11) Vendor class identifier = "udhcp 1.4.1"
    Option: (t=55,l=9) Parameter Request List
    End Option

No.     Time        Source                Destination           Protocol Info
    182 5.644095    172.16.101.10         255.255.255.255       DHCP     DHCP Offer    - Transaction ID 0x4886f13d

Frame 182 (356 bytes on wire, 356 bytes captured)
Ethernet II, Src: Ibm_8c:4b:8c (00:11:25:8c:4b:8c), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol, Src: 172.16.101.10 (172.16.101.10), Dst: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Bootstrap Protocol
    Message type: Boot Reply (2)
    Hardware type: Ethernet
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x4886f13d
    Seconds elapsed: 0
    Bootp flags: 0x0000 (Unicast)
    Client IP address: 0.0.0.0 (0.0.0.0)
    Your (client) IP address: 172.16.149.79 (172.16.149.79)
    Next server IP address: 172.16.159.29 (172.16.159.29)
    Relay agent IP address: 0.0.0.0 (0.0.0.0)
    Client MAC address: MerakiNe_01:1b:09 (00:18:0a:01:1b:09)
    Server host name not given
    Boot file name: oschooser\i386\startrom.com
    Magic cookie: (OK)
    Option: (t=53,l=1) DHCP Message Type = DHCP Offer
    Option: (t=1,l=4) Subnet Mask = 255.255.0.0
    Option: (t=58,l=4) Renewal Time Value = 4 hours
    Option: (t=59,l=4) Rebinding Time Value = 7 hours
    Option: (t=51,l=4) IP Address Lease Time = 8 hours
    Option: (t=54,l=4) Server Identifier = 172.16.101.10
    Option: (t=3,l=4) Router = 172.16.1.2
    Option: (t=6,l=8) Domain Name Server
    Option: (t=15,l=22) Domain Name = "douglas-informatik.de"
    End Option

Here you can see the bridged DHCP request of the client AP and the response of the DHCP server. But response ist not beeing bridged back to wireless by the AP.

Does anyone knows this issue?
What am I doing wrong?

When I use static IP addresses there are no errors.

Any help would be ver helpful.
Thanks in advance!!

Greetz,
tux

Based on your description you are running into one of the problems with bridged client-mode wireless.  802.11 packet headers do not contain the source mac address, which causes trouble when you attempt to hide multiple computers behind a single wireless card.  This is why bridged client-mode is considered a horrible hack, it tends to cause issues like the ones you describe.  The proper way to configure this network is to enable WDS on both routers.  WDS adds the missing fourth header in 802.11 packets, allowing your network to properly function with several machines connecting to the second router.  It also has the added benefit of allowing you to connect wirelessly to the second router (in addition to the wired connections.)

Thanks a lot for this detailed explanation, never thought on that.
Tomorrow I will try WDS in combination with wpa_supplicant, news on that soon.

Some hint in wiki would be grateful, will add this when I have a working setup.

You can also set up routing, but if you want a single DHCP server, that's not an option.

You might be able to do some nifty tricks with a dhcp relay and get that to work, though.  Hmnm.... "option 82" seems to also be useful.  I think you can use that to tell the dhcp server which subnet the request is from.

(Last edited by exobyte on 25 Apr 2007, 20:47)

tux wrote:

Thanks a lot for this detailed explanation, never thought on that.
Tomorrow I will try WDS in combination with wpa_supplicant, news on that soon.

Some hint in wiki would be grateful, will add this when I have a working setup.

Be bold!! Put a hint in the wiki smile

The discussion might have continued from here.