Okay, removed the cable from the Huawei to the injector, and pulled the power supply. Power back, the EAP 600 started. No client connection. I plugged back the cable between the Huawei and the injector, and the clients connected automatically with some seconds.
So it is 100%: the EAP 600 / OpenWRT does not dish out IPv4 addresses.
What next?
I'd reset it.
I guess by now, that resetting is the last resort.
Before I'll do that, however: I have read through heaps of pages of documentation, but failed to find a single one that describes DHCP from the ground (I mean, in OpenWRT) up. A lot of specialized stuff, but no basic items. And if so, then contradictory (?) : the one cited above states that DHCP runs by default, the one indicated states that DNS and DHCP are not active by default.
In a nutshell: after resetting, what are the correct steps to activate DHCP for IPv4 properly, please?
A short list, or a comprehensive URL will be gratefully accepted!
none, it should work OOTB.
Let's see your config and then we'll go from there:
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
It's long, but since you didn't want the file, here it comes:
root@OpenWrt:~# ubus call system board
{
"kernel": "5.15.134",
"hostname": "OpenWrt",
"system": "Atheros AR9344 rev 2",
"model": "EnGenius EAP600",
"board_name": "engenius,eap600",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "23.05.0",
"revision": "r23497-6637af95aa",
"target": "ath79/generic",
"description": "OpenWrt 23.05.0 r23497-6637af95aa"
}
}
root@OpenWrt:~# cat /etc/config/network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fda1:4618:3ed5::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.3.201'
option netmask '255.255.255.0'
option ip6assign '60'
option gateway '192.168.3.1'
option broadcast '192.168.3.255'
root@OpenWrt:~# cat /etc/config/wireless
config wifi-device 'radio0'
option type 'mac80211'
option path 'platform/ahb/18100000.wmac'
option channel '36'
option band '5g'
option htmode 'HT20'
option country 'ES'
option cell_density '0'
option txpower '23'
config wifi-device 'radio1'
option type 'mac80211'
option path 'pci0000:00/0000:00:00.0'
option channel '1'
option band '2g'
option htmode 'HT20'
option cell_density '0'
option txpower '20'
config wifi-iface 'wifinet2'
option device 'radio0'
option mode 'ap'
option ssid 'MyNet'
option encryption 'psk2+ccmp'
option key 'MyPass'
option network 'lan'
config wifi-iface 'wifinet3'
option device 'radio1'
option mode 'ap'
option ssid 'MyNet'
option encryption 'psk2+ccmp'
option key 'MyPass'
option network 'lan'
root@OpenWrt:~# cat /etc/config/dhcp
config dnsmasq
option domainneeded '1'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option cachesize '1000'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
option localservice '1'
option ednspacket_max '1232'
list server '192.168.3.1'
list server '8.8.8.8'
list interface 'radio0'
list interface 'radio1'
config dhcp 'lan'
option interface 'lan'
option start '192.168.3.101'
option limit '99'
option leasetime '12h'
option dhcpv4 'server'
option ra 'server'
list ra_flags 'managed-config'
list ra_flags 'other-config'
option dns_service '0'
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'
root@OpenWrt:~# cat /etc/config/firewall
config defaults
option syn_flood 1
option input REJECT
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
### EXAMPLE CONFIG SECTIONS
# do not allow a specific ip to access wan
#config rule
# option src lan
# option src_ip 192.168.45.2
# option dest wan
# option proto tcp
# option target REJECT
# block a specific mac on wan
#config rule
# option dest wan
# option src_mac 00:11:22:33:44:66
# option target REJECT
# block incoming ICMP traffic on a zone
#config rule
# option src lan
# option proto ICMP
# option target DROP
# port redirect port coming in on wan to lan
#config redirect
# option src wan
# option src_dport 80
# option dest lan
# option dest_ip 192.168.16.235
# option dest_port 80
# option proto tcp
# port redirect of remapped ssh port (22001) on wan
#config redirect
# option src wan
# option src_dport 22001
# option dest lan
# option dest_port 22
# option proto tcp
### FULL CONFIG SECTIONS
#config rule
# option src lan
# option src_ip 192.168.45.2
# option src_mac 00:11:22:33:44:55
# option src_port 80
# option dest wan
# option dest_ip 194.25.2.129
# option dest_port 120
# option proto tcp
# option target REJECT
#config redirect
# option src lan
# option src_ip 192.168.45.2
# option src_mac 00:11:22:33:44:55
# option src_port 1024
# option src_dport 80
# option dest_ip 194.25.2.129
# option dest_port 120
# option proto tcp
root@OpenWrt:~#
This looks fine.
I would recommend changing the start to simply 101 instead of the full address.
You’re also going to need to specify option 3 or your clients will get the wrong gateway address.
Are your clients actually not getting an address, or are they just not working properly with internet access? There is a big difference.
Yeah, thought so. (looking fine)
It'd be a silly way to give an IP address, in my humble opinion, though as described further above, I had started with '101' and '99'; no chance, and then I thought 'what a silly method!' and input the complete address.
Which 'option 3', please?
No, no address at all. kubuntu client, disconnect, reconnect, and interface configuration 'rotates' indefinitely. The very moment I plug in the cable to the Huawei, or better: a few seconds later, everything turns back to normal.
If you plug a computer into the Huawei device, does it get an IP address?
Of course, of course with the DHCP activated, a connected ThinkPad obtains an IP and connects to the Internet.
Also, I have set a static IP on the Huawei, MAC-address, and so forth, and the WiFi client on OpenWRT gets exactly the set address. So OpenWRT is transparent, so to say, for the DHCP assignment.
By the way, I have also checked on OpenWRT, dropbear IS running.
[Now is bedtime here, I'll check back tomorrow morning. In case that someone might think, I lost interest ...]
This must be turned off. This is why you're having the problem. It was already described earlier -- the upstream DHCP server must be turned off.
Only one dhcp server is allowed on a network. If you want to use the openwrt dhcp server, you must completely disable the dhcp server in the huawei device. Full stop.
Can it work without these 2 listen interfaces defined?
Good catch... I missed those.
That WAS a good catch, actually!
I remember vaguely that, when it wouldn't work in the beginning, I thought that it ought to listen to potential clients on the WiFi-/radio interfaces, wouldn't it?
Thanks a lot to everyone involved!
(And maybe one day someone takes the time to write up a page on the concept and BASIC settings of DHCP in OpenWRT? They ARE unusual in comparison with what I have come across in the last 25 years.)
that's why you were told to reset it ...
Thanks, @frollic, but I don't give up easily. And already 35 years ago I hated that Ctrl-Alt-Del.
If it doesn't work in 'our' world, at least mine, "reinstall it!" isn't the solution of choice. Chances are, I had entered the radio* again.
Understanding is my preferred way of solving things.