Question: gateway setting(s)?

This is just a question, no problem:
I find that with OpenWRT on a WAP, the gateway dished out in the DHCP offer is the OpenWRT device itself. With the stock firmware (Engenius), the gateway dished out was always the 'real' gateway, connecting to WAN.
I wonder if this is a configuration error on my side, or is it done intentionally?

if you're using wan, you're routing, unless you've followed, and added the wan port to br-lan.

1 Like

I had followed that one, earlier already, and the IPv4 gateway is set to the router IP; in my case (if you remember) the Huawei glasfibre router.
As I said, everything works now. Still, after a DHCP-release and DHCP-renewal, the gateway-IP is still the OpenWRT-box.
It shouldn't make much difference, but still, IPv4-forwarding from the OpenWRT to the actual Huawei glasfibre WAN is not necessary. I my opinion, the clients could as well sent everything immediately to the actual WAN device, sitting in the same subnet?

right, I didn't connect the dots :wink:

that's normal, the openwrt device will always assume it's the default gw.

you need to

they won't, unless you tell them to.

Thanks for the helpful link!
Though, the question remains: Why? What is the point, if the WAP has the direct link to the (WAN-)gateway for not offering this direct link to the clients in the first place? I mean, if you don't want to NAT, filter, firewall ... I can see no need not to circumvent some processing within the box in the first place.
(And a minor one: why uci, and not luci; since this could be a not so rarely desired setting?)

how would the WAP know it's the actual gw host ?
it's not talking to it, the clients are (when set up properly), the ethernet cable is just a transport, and the WAP, an extension of it.
it being the DHCP host on the lan, is irrelevant, you could have used static IPs for everything.

seems you forgot to install the AI package :wink:

there's no "processing" done, unless you're routing.

I'm guessing it's because it's not trivial to figure out an end-users network setup from a single device in a foolproof manner and no-one has added the functionality to do this to either OpenWRT or dnsmasq directly. It's a fairly edge case anyway, and can be easily solved by the users adding a specfic gateway option (as is common across many DHCP server implementations).

1 Like

The 'edge case' made me smile.

I wonder if this is the right category, but I didn't see any better one. DHCP seems to be kind of a step-child in a great project full of other bells and whistles. And DHCP? Just compare #176627: DHCP dishes out to clients on radio* only, when you remove radio* from the interfaces to listen to. A counterintuitive solution.

I propose, with all due respect to the work done here, to look at previous projects like m0n0wall, and pfSense. Plus commercial ones. It seems most common to have a DHCP tab with each interface, where you can define the DHCP for that interface, gateway, DNS, range.
I myself had a project as sysadmin some 12 years ago, with multiple radios, where one radio needed DHCP and another one explicitly not. Of course, enabling a dhcpd would be linked to the respective interface, and the settings done in a (sub) tab to that interface, providing for different DHCP behaviour on different interfaces. In all those projects and commercial applications, I'd be able - no, required! - to set a gateway and preferably a DNS.

Just open the settings of a box with one or even a multitude of interfaces on OpenWRT. No single tab to define DHCP for that interface. Only entry point is 'lan', and that's exactly not where I'd come to define DHCP for 'radio*'.
I do understand that one can add virtual lan devices and then link to these. Though, what's the point to make things difficult, when they can be solved in a simple, straightforward manner?

That already exists within Luci. If you edit an interface then there's a specific 'DHCP server' tab which, amongst other things, let you set the gateway, DNS, range etc.

If that particular wifi radio is part of the 'lan' network then that's exactly where I'd go to define DCHP (or other network) settings for it.

The radio* 'interfaces' you had told dnsmasq to listen on weren't valid interfaces. It started working when you removed them because dnsmasq started listening on the actual valid interfaces on the AP. Not sure that's counterintuitive...

i feel you forget that your use case is not the most common. for not tech-savvy users owrt's default approach, which is one wan port and more lan ports+wifi for clients using wan port as default gateway, is a the "simple, straightforward manner".

having multiple interfaces, networks and different default gws case falls into advanced category. very advanced. you can use pbr package by the way to manage multiple gateways (it is not limited for VPN use case).

Nor openwrt's fault...

1 Like

When running the AP as a "dumb" bridge, it should not run a DHCP server. DHCP requests from wireless clients will be handled by the main router which is on the same subnet. The AP is a wireless to wired converter which operates at level 2 (MAC addresses) -- it doesn't route anything.

1 Like

they won't, unless you tell them to.

And how does one do that? I tried in the network configuration, didn't find it. Okay, reading ...
This is what I found:
uci add_list dhcp.lan.dhcp_option="6,"

I want another gateway, so it would probably be
uci add_list dhcp.lan.dhcp_option="3," #
So, no error. And no functionality. Okay:

# uci commit dhcp
# service dnsmasq restart
udhcpc: started, v1.36.1
udhcpc: broadcasting discover
udhcpc: no lease, failing

Which would be the correct location, and syntax, to add the other gateway under /etc, please?

As it is a dumb AP, there should be no DHCP service running on the dumb AP. Clients will configure their IP and gateway via DHCP served from the main router, which advertises itself as the gateway.

That looks OK though?

The udhcpc is unrelated.

The OP wants to use the AP as the DHCP server, rather than their main router. I believe the router has limited functionality and can't be flashed with OpenWRT.

What's the current content of /etc/config/dhcp?

1 Like
# 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/'
        option localservice '1'
        option ednspacket_max '1232'
        list server ''
        list server ''

config dhcp 'lan'
        option interface 'lan'
        option start ''
        option limit '99'
        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'

config host

followed by all sorts of static IPv4s-s.

Yes, the Huawei is highly restricted, and most of all, it has a very basic functionality, no hostnames, only a list of MAC- and IP-addresses. And cumbersome to enter. That's the reason, why I need a useful DHCPd on the network. And the only always-on are that router and the first WAP.
It WORKS with the OpenWRT as gateway, but I don't like it too much. Somehow goes against my 25 years of networking. And to the former sysadmin, I never found it difficult to have DHCPd dishing out gateway and DNS of my liking. Except here.

Those would be configured by adding dhcp_option 3 and 6 in the config dhcp lan section of /etc/config/dhcp.

This is not how it is done. Use just start 101. The actual starting IP is obtained by adding the number 'start' to the first IP of the subnet defined on the network (x.x.x.0 for a /24). The static IP of the OpenWrt device itself does not need to be x.x.x.1, but it must be outside the dynamic pool range created by start and limit.

is this your problem, or rather to use the gateways?

you can use dhcp option, that's surely not a problem in openwrt.
multiple gateway is another thing, that is indeed not simple.

so: your clients do not receive the proper dhcp option 3,6 values, or cannot use them? it is two different things.