LAN clients not getting DHCP ips

This is a fresh install of 22.03.5 in an LXD container on Arch Linux host.

eth0 passed through (physical) to container - works fine, gets DHCP form ISP
lan0 (192.168.18.1) - bridged to a bridge br0 on host (192.168.18.2), which is bridged to eth1 (no ip)
Client(s) - connected to eth1 by cable.

This works fine (internet access) as long, as clients have manually set IPs (eg: 192.168.18.6), but DHCP doesn't work. I have been trying to fix it for two days, but found no solution or even cause. Everything seem to be set correctly - I have another setup which is almost identical (the only difference, br0 on host is bridged to 3 nics, instead of 1) and there were no issues like that. I also set up several other systems in this way in the past without issues.

Any help appreciated.

/etc/config/network

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

config interface 'wan'
	option proto 'dhcp'
	option device 'wan0'

config interface 'lan'
	option proto 'static'
	option ipaddr '192.168.18.1'
	option netmask '255.255.255.0'
	option device 'br0'

config device
	option name 'wan0'
	option ipv6 '0'

config device
	option name 'br0'
	option ipv6 '0'

/etc/config/dhcp

config dnsmasq
	option domainneeded '1'
	option boguspriv '1'
	option filterwin2k '0'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option nonegcache '0'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option nonwildcard '1'
	option localservice '1'
	option ednspacket_max '1232'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

NetCtl br0 config on host:
cat /etc/netctl/br0

Interface=br0
Connection=bridge
BindsToInterfaces=(eth1)
IP=static
Address=('192.168.18.2/24')
Gateway=('192.168.18.1')
DNS=('192.168.18.1')
# Ignore (R)STP and immediately activate the bridge
# SkipForwardingDelay=yes

let's see your firewall file.

And can the host 192.168.18.2 ping 192.168.18.1?

The host 192.168.18.2 can ping 192.168.18.1
Other lan hosts can also ping it as long as their IP is set manually to 192.168.18.x

/etc/config/firewall

config defaults
	option syn_flood	1
	option input		ACCEPT
	option output		ACCEPT
	option forward		REJECT
# Uncomment this line to disable ipv6 rules
#	option disable_ipv6	1

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

config zone
	option name		wan
	list   network		'wan'
	list   network		'wan6'
	option input		REJECT
	option output		ACCEPT
	option forward		REJECT
	option masq		1
	option mtu_fix		1

config forwarding
	option src		lan
	option dest		wan

# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
	option name		Allow-DHCP-Renew
	option src		wan
	option proto		udp
	option dest_port	68
	option target		ACCEPT
	option family		ipv4

# Allow IPv4 ping
config rule
	option name		Allow-Ping
	option src		wan
	option proto		icmp
	option icmp_type	echo-request
	option family		ipv4
	option target		ACCEPT

config rule
	option name		Allow-IGMP
	option src		wan
	option proto		igmp
	option family		ipv4
	option target		ACCEPT

# Allow DHCPv6 replies
# see https://github.com/openwrt/openwrt/issues/5066
config rule
	option name		Allow-DHCPv6
	option src		wan
	option proto		udp
	option dest_port	546
	option family		ipv6
	option target		ACCEPT

config rule
	option name		Allow-MLD
	option src		wan
	option proto		icmp
	option src_ip		fe80::/10
	list icmp_type		'130/0'
	list icmp_type		'131/0'
	list icmp_type		'132/0'
	list icmp_type		'143/0'
	option family		ipv6
	option target		ACCEPT

# Allow essential incoming IPv6 ICMP traffic
config rule
	option name		Allow-ICMPv6-Input
	option src		wan
	option proto	icmp
	list icmp_type		echo-request
	list icmp_type		echo-reply
	list icmp_type		destination-unreachable
	list icmp_type		packet-too-big
	list icmp_type		time-exceeded
	list icmp_type		bad-header
	list icmp_type		unknown-header-type
	list icmp_type		router-solicitation
	list icmp_type		neighbour-solicitation
	list icmp_type		router-advertisement
	list icmp_type		neighbour-advertisement
	option limit		1000/sec
	option family		ipv6
	option target		ACCEPT

# Allow essential forwarded IPv6 ICMP traffic
config rule
	option name		Allow-ICMPv6-Forward
	option src		wan
	option dest		*
	option proto		icmp
	list icmp_type		echo-request
	list icmp_type		echo-reply
	list icmp_type		destination-unreachable
	list icmp_type		packet-too-big
	list icmp_type		time-exceeded
	list icmp_type		bad-header
	list icmp_type		unknown-header-type
	option limit		1000/sec
	option family		ipv6
	option target		ACCEPT

config rule
	option name		Allow-IPSec-ESP
	option src		wan
	option dest		lan
	option proto		esp
	option target		ACCEPT

config rule
	option name		Allow-ISAKMP
	option src		wan
	option dest		lan
	option dest_port	500
	option proto		udp
	option target		ACCEPT

Change this to lowercase lan (in the network config file). Openwrt has the lan preconfigured, but it is case sensitive and assumes lowercase.

Try that and report back (don’t forget to restart after making the change).

1 Like

Yup, fixed that but no change - still no DHCP ips.

If you set an external host (i.e. one not on the same VM host) and set it with a static IP (i.e. 192.168.18.5, subnet mask 255.255.255.0, DNS 192.168.18.1, router/gateway 192.168.18.1), can you reach the internet using ping tests to 8.8.8.8 and google.com.

Yes, manually set up external hosts can browse the internet just fine.

is dnsmasq running properly?

do you see anything in the logs?

I can see in top that dnsmasq is running, but I can't find any logs.

You may need to run something like tcpdump and then force a client to request/renew a DHCP lease so that you can see if the DHCP traffic is hitting br0 in OpenWrt, and what is happening (are responses happening, and if so, are they making it back out, etc.).

Should I run it on the host or OpenWrt container?
br0 is on host. lan0 is in the container.

I'd run it inside OpenWrt first to see if the requests are arriving.

If you don't see anything, then you may want to run it on the VM host.

Openwrt results. I dumped it to a file and fed it to wireshark:

1	0.000000	0.0.0.0	255.255.255.255	DHCP	334	DHCP Request  - Transaction ID 0xf2433ded
2	0.000060	0.0.0.0	255.255.255.255	DHCP	334	DHCP Request  - Transaction ID 0xf2433ded
3	1.999796	0.0.0.0	255.255.255.255	DHCP	334	DHCP Discover - Transaction ID 0x6c46d185
4	1.999816	0.0.0.0	255.255.255.255	DHCP	334	DHCP Discover - Transaction ID 0x6c46d185
5	4.659796	0.0.0.0	255.255.255.255	DHCP	334	DHCP Discover - Transaction ID 0x3c47a8
6	4.659845	0.0.0.0	255.255.255.255	DHCP	334	DHCP Discover - Transaction ID 0x3c47a8
7	8.685749	0.0.0.0	255.255.255.255	DHCP	334	DHCP Discover - Transaction ID 0x2496fad1
8	8.685768	0.0.0.0	255.255.255.255	DHCP	334	DHCP Discover - Transaction ID 0x2496fad1
9	16.928662	0.0.0.0	255.255.255.255	DHCP	334	DHCP Discover - Transaction ID 0x7836d667
10	16.928715	0.0.0.0	255.255.255.255	DHCP	334	DHCP Discover - Transaction ID 0x7836d667
11	33.009013	0.0.0.0	255.255.255.255	DHCP	334	DHCP Discover - Transaction ID 0x6905b36b
12	33.009066	0.0.0.0	255.255.255.255	DHCP	334	DHCP Discover - Transaction ID 0x6905b36b
13	39.618288	0.0.0.0	255.255.255.255	DHCP	334	DHCP Request  - Transaction ID 0x77136515
14	39.618337	0.0.0.0	255.255.255.255	DHCP	334	DHCP Request  - Transaction ID 0x77136515
15	41.618211	0.0.0.0	255.255.255.255	DHCP	334	DHCP Discover - Transaction ID 0xd76be772
16	41.618263	0.0.0.0	255.255.255.255	DHCP	334	DHCP Discover - Transaction ID 0xd76be772
17	42.873998	0.0.0.0	255.255.255.255	DHCP	334	DHCP Request  - Transaction ID 0xf69ba367
18	43.849712	0.0.0.0	255.255.255.255	DHCP	334	DHCP Discover - Transaction ID 0xa3947116
19	43.849731	0.0.0.0	255.255.255.255	DHCP	334	DHCP Discover - Transaction ID 0xa3947116
20	48.601846	0.0.0.0	255.255.255.255	DHCP	334	DHCP Discover - Transaction ID 0x74614514
21	48.601866	0.0.0.0	255.255.255.255	DHCP	334	DHCP Discover - Transaction ID 0x74614514
22	57.265976	0.0.0.0	255.255.255.255	DHCP	334	DHCP Discover - Transaction ID 0xf8f87fa8
23	57.266029	0.0.0.0	255.255.255.255	DHCP	334	DHCP Discover - Transaction ID 0xf8f87fa8
24	74.182257	0.0.0.0	255.255.255.255	DHCP	334	DHCP Discover - Transaction ID 0xf4f52760
25	74.182310	0.0.0.0	255.255.255.255	DHCP	334	DHCP Discover - Transaction ID 0xf4f52760

I see only the Discover and Request traffic... no Offers or Acks. I'm not sure why that would be.

could it be related to this ?

Maybe try with the previous version of OpenWrt ? or the snapshot as suggested in the link.

1 Like

I think they were coming from the WAN port, as the IPs seen in details were 192.168.7.x range (the wan port is connected to my production lan, which is run by another openwrt (the one that works).
I unplugged the cable from WAN and repeated the exercise with the same results, except not instead of 192.168.7.x ip, they are 0.0.0.0 in most cases:

Yeah.... check to see that tcpdump is looking at the right interface.

Running OpenWrt in VMs can be tricky insofar as getting the interface I/O to work properly. Your config appears to be okay and would be expected to work... so I'm thinking that there is something happening at the VM level that is impacting the situatoin here.

Alright, some development.

@shdf suggested to try a snapshot, but that didn't fix things. But then I tried 21.02, and now the clients do get IPs from DHCP. Finally! There must have been some regression in 22.03 recently, as I am running 22.03.3 r20028-43d71ad93e on another machine, and it works flawless.

The problem is, now my clients (nor openwrt vm, or the host) can access the internet. 192.168.7.1 cannot be reached.

this is the uptream network (i.e. the wan of the OpenWrt VM)? Is 192.168.7.1 the actual upstream router address?

And from where are you trying to reach it? From the OpenWrt VM itself, or from a device behind the OpenWrt VM?

Yes, 192.168.7.1 is the upstream router.
Unreachable from OpenWrt VM, OpenWrt host, and other remote devices on .18.x