Relayd not forwarding broadcast (BOOTP/DHCP) responses

muxx · January 26, 2020, 11:59pm

thank you for all your effort. I literally copied and pasted your config file onto a clean HH 5A, changed IP addresses and it still doesn't bloody work. I suspect what must be the difference is that my DHCP server is different from my access point. I have a router (192.168.100.128) and an AP I am bridging to (192.168.100.80), so the DHCP requests go via the AP then into LAN switch and into the router.
my AP (Mikrotik) supports DHCP relay which was disabled by default. I tried enabling it on the AP's 5GHz interface and it makes no difference. when I manually run the DHCP client on my PC connected to the HH 5A, the count of DHCP packets relayed by the AP is increasing accordingly (it has counters for requests and responses). I don't think I need the relay as I only have one subnet on the LAN so I turned it back off.

still, what I was seeing with tcpdump on OpenWRT confirms that the DHCP response makes it way back through the WiFi client.

my configs are now:

config interface 'loopback'
	option ifname 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd17:adad:8579::/48'

config atm-bridge 'atm'
	option vpi '1'
	option vci '32'
	option encaps 'llc'
	option payload 'bridged'

config dsl 'dsl'
	option annex 'a'
	option tone 'av'
	option xfer_mode 'ptm'
	option ds_snr_offset '0'

config interface 'lan'
	option type 'bridge'
	option ifname 'eth0.1'
	option proto 'static'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option ipaddr '192.168.99.128'

config device 'lan_dev'
	option name 'eth0.1'
	option macaddr '18:62:2C:3D:A1:8C'

config device 'wan_dev'
	option name 'ptm0'
	option macaddr '18:62:2C:3D:A1:8D'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '0 1 2 4 6t'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '5 6t'

config interface 'wwan'
	option _orig_ifname 'radio0.network1'
	option _orig_bridge 'false'
	option proto 'static'
	option netmask '255.255.255.0'
	option gateway '192.168.100.128'
	option dns '8.8.8.8'
	option ipaddr '192.168.100.83'

config interface 'stabridge'
	option proto 'relay'
	list network 'lan'
	list network 'wwan'
	option ipaddr '192.168.100.83'

---

config wifi-device 'radio0'
	option type 'mac80211'
	option hwmode '11a'
	option path 'pci0000:01/0000:01:00.0/0000:02:00.0'
	option channel '48'
	option country 'GB'
	option htmode 'VHT40'

config wifi-device 'radio1'
	option type 'mac80211'
	option channel '11'
	option hwmode '11g'
	option path 'pci0000:00/0000:00:0e.0'
	option htmode 'HT20'
	option disabled '1'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'DisabledWifi'
	option encryption 'none'

config wifi-iface
	option network 'wwan'
	option ssid '***'
	option encryption 'psk2'
	option device 'radio0'
	option mode 'sta'
	option key '***'

my firewall is disabled.

basically I've run out of ideas. thanks again.

bill888 · January 27, 2020, 3:31am

fwiw, I have a similar setup.

ie. router/DHCP-server (HH5A LEDE 17.01.6, 192.168.1.254) which is ethernet wired to dumb AP (192.168.1.236) for past 3+ years. The AP was formerly another HH5A (LEDE) but I recently changed to EA6350v3 (Linksys stock FW) using 'bridge' (ie. AP) mode, keeping same 192.168.1.236 address. I only use one subnet 192.168.1.x for everything.

Can I perhaps suggest temporarily installing another AP using your spare WNDR3800. ie. bypass your Microtik AP. For another test, verify relayd on HH5a can connect to standalone WNDR3800 configured as regular openwrt wifi router with its own DHCP server?

Your network and wireless config files are indeed practically identical to my originals. You haven't shared the firewall file.

I leave the firewall enabled. I presume the 'lan' zone is identical to the one I shared otherwise relayd probably wouldn't work at all.

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option network 'lan wwan'

muxx · January 27, 2020, 10:45am

I imported your firewall config unchanged. tried, then disabled and stopped firewall using /etc/init.d, tried again.

I will try another AP and another DHCP server. I was also thinking of enabling the DHCP server on the Mikrotik just for a test.

thanks again for your help.

I head there was another relay implementation, some kernel module. information is scarce on this.

muxx · January 27, 2020, 1:38pm

Bill, would it be possible for you to add the -d option to relayd on your relay unit and run a few DHCP requests to see what it should look like?

I don't know how to add arbitrary options to daemons in OpenWRT using configs, so one way to do this would be to SSH to the WiFi client's address, do ps | grep [r]elayd, note that line, then stop relayd and run it manually by adding the -d option to the noted arguments.

that way it will show all requests and responses and hopefully that will be different from mine. I checked the sourcecode and it seems to be validating quite a few things in DHCP packets before forwarding.

muxx · February 3, 2020, 8:02pm

the problem seems to be in the Mikrotik AP to which the wireless client is connected. it seems to mangle the DHCP responses somehow that they are not seen or accepted by relayd.

I set up a different AP (OpenWRT) without a DHCP server and plugged into the same LAN Mikrotik is plugged in, and I don't have the DHCP problem.

muxx · February 3, 2020, 10:31pm

I compared responses (DHCP ACKs) coming via Mikrotik and non-Mikrotik APs.
the only difference is that in the latter the response has a broadcast address in the Ethernet header (works) while in the former it's the MAC address of the WiFi client (doesn't work).

bozzochet · May 19, 2020, 10:32am

Hi,

I reply to this post even if is not "strictly" the same problem.

I followed this guide: https://openwrt.org/docs/guide-user/network/wifi/relay_configuration (even if changing something) to create a wireless extended using a Netgear Access Point (Netgear WN3000RPv3).

At the beginning I landed to this plot since I was not able to "see" a device (an IP cam) connected to the access point. Essentially it is the only device so far connected to this Access Point since all the others are connected to the main modem/router (Zyxel VMG8825-T50K by Tiscali Italy).
When I say "see" I mean that the MAC of this IP cam was not appearing here:

so to me the IP cam MAC was not "passed" to the Zyxel router.
The strange thing was that sometimes (even if this is not stable and I don't know if this is another problem...) it was working (I was able to access the cam even via mobile data connection: so it was on the Internet).

So:

the IP cam is connected to the AP-WDS network I created:

(I'm allowed only for one figure per post)

and the IP is the one I "assigned" as static in the Zyxel router

(I'm allowed only for one figure per post)

in the ARP table the IP cam is present but with the MAC of the Access Point:

(I'm allowed only for one figure per post)

as written before, the IP cam connection is very unstable. It works, maybe for one hour and then it drops and I'm not able to make it connecting again, even restarting the Zyxel modem and/or the Netgear Access point and/or the cam itself.
Is this related to some configuration problem and so the previous points?

Thanks,
Matteo

bozzochet · June 22, 2020, 1:04pm

Can somebody help me?

kolalok · June 27, 2020, 2:01pm

Thanks @muxx for sharing your findings.

Running a Mikrotik router/AP and an OpenWrt wireless bridge, after RouterOS upgrade to 6.47 I found myself in exact same situation as you describe. DHCP packets from the server are now coming with a unicast L2 address and are not relayed.

Judging from sources, relayd indeed only watches for DHCP packets with broadcast or multicast addresses. I don't feel up to devising a fix, maybe we could file a feature request.

Anyway, my current solution is to stop relying on relayd's DHCP capabilities and use a standalone DHCP relay. There are multiple implementations to choose from, I went for dnsmasq as it's already installed and well integrated (ready with init.d script etc.)

First step is to run relayd without the -D parameter. Can be done in /etc/config/network:

config interface 'sta_bridge'
        option proto 'relay'
        option network 'lan wwan'
        ...
        option forward_dhcp 0 # add this

Second, configure dnsmasq as DHCP relay. This is how my /etc/config/dhcp looks like:

config dnsmasq
        option port '0' # optional, disable dnsmasq's DNS server, I don't need it

config relay
        option interface 'wwan'
        option local_addr '192.168.2.1' # lan interface address
        option server_addr '192.168.1.1' # the actual dhcp server address

# the rest is only needed for IPv6 (odhcpd)

config dhcp 'lan'
        option interface 'lan'
        option dhcpv4 'disabled'
        option ra 'relay'
        option ndp 'relay'
        option dhcpv6 'relay'

config dhcp 'wwan'
        option interface 'wwan'
        option dhcpv4 'disabled'
        option ra 'relay'
        option ndp 'relay'
        option dhcpv6 'relay'
        option master '1'

The final step is to make sure the real DHCP server accepts requests from relay agents. On Mikrotik I did:
/ip dhcp-server set defconf relay=255.255.255.255)

Hope this helps anyone.

Xtreme512 · July 24, 2020, 7:02pm

sadly it didnt help for me. i recently bought archer C7 v5 and decided to flash openwrt for wireless bridge between my mikrotik for to extend local network to the whole house. its working if you create a seperate network in openwrt but doesnt work if you want to be on the same network, as the mikrotik gives warning messages about DHCP (dhcp1 offering lease 192.168.1.29 for xx:xx:60:x2 to Dx:xx:xx:03:x9:xF without success)

where first mac is my phone and the second is the openwrts wifi client.

tried your settings and a few in routeros firewall but nothing helped.. its just not compatible.

it sucks to have 2 different networks for no reason, yet i have to use it like that for now.

bozzochet · July 25, 2020, 3:06pm

I wasn't able also to make it work. Even "copying" the conf files a above. Should be said that I'm not a very expert and so I really understand all the steps I make...

What I really don't understand is why sometimes it's working...

Matteo

Xtreme512 · July 25, 2020, 5:19pm

Im planning to putting a wire to it, thats the only way.

kolalok · July 26, 2020, 11:57am

Does it still happen if you stop firewall on openwrt? Just guessing.

The error message suggests that either the Offer packet won't make it to the end device (phone) or the subsequent Request packet is not sent or never reaches the dhcp server.

In the search for the point of failure, tcpdump (opkg install tcpdump-mini) is your friend. Try listening on udp ports 67-68, whether the offer is received on the wireless interface and is relayed to the other interface.

Edit: and yes, if wired connection is an option, go for it and forget all of this...

bozzochet · July 26, 2020, 1:38pm

Can I ask you how to stop the firewall? I "disabled" for all the "interfaces" but I don't know if this is enough.

The strange thing (but again, I'm not at expert at all) is the one client (is an IPcam) sometimes connects to it and receive the right IP address (right in the sense that is the one that I configured in the main router and DHCP server, statically). In this case the IPcam is working fine but, however, the devides (MAC and IP) are not listed by the main router. After some time (10-30 minutes) the connection is lost...

Thanks,
Matteo

bozzochet · July 26, 2020, 2:00pm

Ciao,

root@OpenWrt:~# tcpdump -i wlan0 udp port 67
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:55:21.447047 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
13:55:21.547408 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
13:56:26.185739 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
13:56:26.264680 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
13:56:28.078538 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
13:56:28.107919 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
13:56:32.077600 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
13:56:32.105480 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
13:56:40.077722 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
13:56:40.192683 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
13:56:56.080586 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
13:56:56.165707 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
13:57:28.080992 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
13:57:28.118232 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300

the MAC address (08:ea:40:47:f5:9d) is the MAC address of the IPcam I'm trying to connect...

If I understand seems ok, isn't it? The request is forwarded to the main router (192.168.1.1 on port 67) and there's even a reply... Isn't it?

Thanks,
Matteo

bozzochet · July 26, 2020, 2:03pm

It even seems that the IP is got correctly!

root@OpenWrt:~# tcpdump -i wlan0 udp port 67 -vv
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:01:41.324015 IP (tos 0x0, ttl 255, id 5, offset 0, flags [none], proto UDP (17), length 336)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308, xid 0x72c9, Flags [Broadcast] (0x8000)
	  Client-Ethernet-Address 08:ea:40:47:f5:9d (oui Unknown)
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Discover
	    MSZ Option 57, length 2: 1500
	    Parameter-Request Option 55, length 4: 
	      Subnet-Mask, Default-Gateway, BR, Domain-Name-Server
14:01:41.351715 IP (tos 0x0, ttl 64, id 38224, offset 0, flags [none], proto UDP (17), length 328)
    192.168.1.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x72c9, Flags [Broadcast] (0x8000)
	  Your-IP 192.168.1.90
	  Server-IP 192.168.1.1
	  Client-Ethernet-Address 08:ea:40:47:f5:9d (oui Unknown)
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Offer
	    Server-ID Option 54, length 4: 192.168.1.1
	    Lease-Time Option 51, length 4: 86400
	    RN Option 58, length 4: 43200
	    RB Option 59, length 4: 75600
	    Subnet-Mask Option 1, length 4: 255.255.255.0
	    BR Option 28, length 4: 192.168.1.255
	    Default-Gateway Option 3, length 4: 192.168.1.1
	    Domain-Name-Server Option 6, length 8: resolver1.opendns.com,resolver2.opendns.com

Matteo

kolalok · July 26, 2020, 10:13pm

This means the Offer packet was transmitted from the router (zyxel) to the bridge (netgear). Which is fine, but it's only a part of the story.
I'd try tcpdump on the other bridged interface (possibly br-lan) to see if the same packet is sent towards the client.

If it is, try connecting another device, a laptop perhaps, to see if the dhcp procedure fails with it too, or the camera is the culprit.

If the packet is not being sent over, try my suggested setup above.

calling ps to list running processes, you should see relayd running without the -D parameter
in dnsmasq generated config file (/var/etc/dnsmasq.conf.*) there should be a line like
dhcp-relay=192.168.2.1,192.168.1.1,wlan0
matching your setup
make sure odhcpd ignores dhcpv4 packets, maybe just stop it for the moment (/etc/init.d/odhcpd stop)

Can I ask you how to stop the firewall?

I use /etc/init.d/firewall stop to stop temporarily. But your method likely works too. Either way, iptables -L should only print empty tables.

bozzochet · July 31, 2020, 7:18am

Hi,

I tried with a second device (my iPhone):

root@OpenWrt:~# tcpdump -i wlan0 udp port 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
07:10:09.188734 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
07:10:09.239595 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
07:11:13.916223 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
07:11:13.956923 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
07:11:15.805419 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
07:11:15.902659 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
07:11:19.804511 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
07:11:19.896192 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
07:11:27.804617 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
07:11:27.885297 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
07:11:33.894806 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 60:83:73:43:63:6c (oui Unknown), length 300
07:11:33.925067 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 305
07:11:35.174317 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 60:83:73:43:63:6c (oui Unknown), length 300
07:11:35.258158 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 305
07:11:37.766038 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 60:83:73:43:63:6c (oui Unknown), length 300
07:11:37.816299 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 305
07:11:42.738219 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 60:83:73:43:63:6c (oui Unknown), length 300
07:11:42.834000 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 305
07:11:43.807408 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:ea:40:47:f5:9d (oui Unknown), length 308
07:11:43.857968 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
07:11:51.262489 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 60:83:73:43:63:6c (oui Unknown), length 300
07:11:51.333249 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 305

at the beginning there's the camera MAC address, still trying to connect, and when I tried with the phone there's the new mac address.

The strange (to me) is that:

the two devices seems connected and with a good IP (in the case of the camera is even the one I set in the router, even if now I have the doubt that I set as static also when I configured the cam...) but, for example, my iPhone is still saying "no connection" and has 169.254.9.100 as IP...

Thanks,
Matteo

bozzochet · July 31, 2020, 7:22am

Just to ask: is normal that I cannot set a IPv4 netmask in my br-lan intrerface?
If I set with from LuCI it never ends and says that needs to come back to the backup configuration...

Matteo

bozzochet · July 31, 2020, 8:59am

For example now is working (without the "new" configuration, but with the standard "relay bridge"...) even if I don't understand why and why, for sure, after few minutes it will stop working...

One symptom (I think) is that the router sees the devices connected to the AP with the MAC of the AT itself:

if you see the MAC 10:da:43:0c:13:3a is present 4 times: 192.168.1.3 is the AP itself, the other 3 are devices connected...

I don't know if it's related but with the original firmware by NetGear the MAC address transmitted to the router was a sort of combination between the AP one and the device one...

Matteo

P.S.: after 1 hours it stopped working. And rebooting the NetGear repeater seems not solving.

Maybe for some reason after sometime the router (i.e. the main DHCP server) recognize the packets as a sort of "hacking" or something similar?