Guest Network Errors. "udhcpc: no lease, failing"

Installing and Using OpenWrt
1

Just following https://openwrt.org/docs/guide-user/network/wifi/guestwifi/guest-wlan

When doing the last step of part 3, I get these responses in the shell:

root@OpenWrt:~# service dnsmasq restart
udhcpc: started, v1.36.1
udhcpc: broadcasting discover
udhcpc: no lease, failing
udhcpc: started, v1.36.1
udhcpc: broadcasting discover
udhcpc: no lease, failing
root@OpenWrt:~# service dnsmasq restart
udhcpc: started, v1.36.1
udhcpc: broadcasting discover
udhcpc: no lease, failing
udhcpc: started, v1.36.1
udhcpc: broadcasting discover
udhcpc: no lease, failing

So, how to resolve? Is it conflicting with an already set up pbr / openvpn?

2

This is expected behaviour if there is no other dhcp server in the lan.

1 Like
3

Okay. So a guest network isn't possible then?

I've carried through to the rest of the guide twice now. And it never works.

Because among two devices, it never authenticates. The devices come back with a message to double check the password, which I have checked 20 times over and changed a few times.

I guess my last attempt is to try without any kind of encryption set just to see if it works.

4

That's not what he said. The "error" message is expected in cases where dnsmasq is the only dhcp server on the network. During startup it sends out a dhcp discover and checks for a response. The message shows no response was received which is what should be the case.

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:
grafik
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
1 Like
5

I figured it out, possibly. I have to run off now so I leave this pending for after work. But without any security set up, it works.

It may have been old SSIDs were being broadcast. I tried to set up a wireless guest network via GUI and that failed. So I turned to the guide.

When I got to the step for securing, that's when I would toggle back to the GUI and set it up. I might have deviated because that's also when I set my preferred SSID. And in repeating the guide a second time through, I didn't do that, but I kept trying to connect to the preferred SSID instead of the guide-set "guest" SSID name.

So either caching of devices for ssids to connect to (weird behavior if that exists), or the router kept broadcasting zombie SSIDs to networks that had tried to be dismantled and so the same errors kept coming up. And why changing the password (being on a different tab than where the ssid name is) repeatedly wasn't getting me anywhere when I went to as simple of a pw as 12345678; the new network probably was set up with that pw but I kept trying to connect to the old/zombie network.

The other boneheaded complication is of course I have an established guest network on one router which is to be decommissioned and replaced with the openwrt router. I was also quite possibly trying to connect to that network with the wrong password, as I was looking to mirror it. Just terrible mistakes on my part and I thought the dnsmasq stuff had something to do with it when it would give me an error, expected or not.

6

I also had:

/etc/init.d/dnsmasq restart
udhcpc: started, v1.36.1
udhcpc: broadcasting discover
udhcpc: no lease, failing

and this was bothering me.

The problem was that udhcpc was trying to get an address on local interfaces, although it didn't need to. Here is my dump:

~ # tcpdump -i any port 67 or port 68 -vv
tcpdump: data link type LINUX_SLL2
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
03:14:28.513915 br-lan Out IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 88:c3:97:c4:58:28 (oui Unknown), length 300, xid 0x54d7a547, Flags [none] (0x0000)
          Client-Ethernet-Address 88:c3:97:c4:58:28 (oui Unknown)
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Discover
            MSZ (57), length 2: 576
            Parameter-Request (55), length 7:
              Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
              Domain-Name (15), BR (28), NTP (42)
            Vendor-Class (60), length 12: "udhcp 1.36.1"
            Client-ID (61), length 7: ether 88:c3:97:c4:58:28
03:14:28.513924 lan2  Out IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 88:c3:97:c4:58:28 (oui Unknown), length 300, xid 0x54d7a547, Flags [none] (0x0000)
          Client-Ethernet-Address 88:c3:97:c4:58:28 (oui Unknown)
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Discover
            MSZ (57), length 2: 576
            Parameter-Request (55), length 7:
              Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
              Domain-Name (15), BR (28), NTP (42)
            Vendor-Class (60), length 12: "udhcp 1.36.1"
            Client-ID (61), length 7: ether 88:c3:97:c4:58:28
03:14:28.513935 lan1  Out IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 88:c3:97:c4:58:28 (oui Unknown), length 300, xid 0x54d7a547, Flags [none] (0x0000)
          Client-Ethernet-Address 88:c3:97:c4:58:28 (oui Unknown)
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Discover
            MSZ (57), length 2: 576
            Parameter-Request (55), length 7:
              Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
              Domain-Name (15), BR (28), NTP (42)
            Vendor-Class (60), length 12: "udhcp 1.36.1"
            Client-ID (61), length 7: ether 88:c3:97:c4:58:28
^C
3 packets captured
5 packets received by filter
0 packets dropped by kernel

In the end, I applied the following code change to /etc/init.d/dnsmasq:

dhcp_check() {
    local ifname="$1"
    local stamp="${BASEDHCPSTAMPFILE_CFG}.${ifname}.dhcp"
    local rv=0

    # Exclude lan1, lan2, and br-lan from dhcp_check
    if [ "$ifname" = "lan1" ] || [ "$ifname" = "lan2" ] || [ "$ifname" = "lan3" ] || [ "$ifname" = "lan4" ] || [ "$ifname" = "br-lan" ]; then
        return 0
    fi

    [ -s "$stamp" ] && return $(cat "$stamp")

    # If interface is down, skip it.
    # The init script will be called again once the link is up
    case "$(devstatus "$ifname" | jsonfilter -e @.up)" in
            false) return 1;;
    esac

    udhcpc -n -q -s /bin/true -t 1 -i "$ifname" >&- && rv=1 || rv=0

    echo $rv > "$stamp"
    return $rv
}

Maybe I'm wrong, I don't understand anything about this, and the great GPT helped me.

7

This is actually working as intended. The DHCP discovery broadcast is to ensure that there are no other active DHCP servers on the network.

This is not recommended. As I said above, the interface in question should not have any other DHCP servers, so the message is simply verification of that fact before the DHCP server in dnsmasq starts up.

1 Like
8

It's so weird....
Why don't I write something like: "No active DHCP servers found on the network: OK"

9

Because it is actually the DHCP client that is producing the log entries.

Basically, the DHCP server wants to know if there are any other servers active on the network. Instead of writing special code to answer that question, it calls code that already exists -- the DHCP client functions. The client code, in this case, finds that it is unable to obtain a lease, reports that, and then exits. The DHCP server now knows that it is safe to start up.

3 Likes
10

Is there any way to disable this behavour on a per subnet basis?

My configuration includes a dozen of vlans, where my openWRT router is supposed to deliver DHCP for.

ObviousIy I geht the udhcpc: no lease, failing for any of those subnets, and they are not called in parallel, but in sequence, so all timeouts are adding up - to a minute or so. Any time I change an entry in /etc/config/dhcp ....

Do I see it correct, that during this time, there is not even DNS available from the same dnsmasq instance?

11

This is expected behavior. dnsmasq will test to make sure there isn't already another DHCP server on the network by issuing a DHCP request. As long as there is no response, it knows it is safe to start the DHCP server.

You can, but it is not recommended. Leave it alone -- this error is normal and expected behavior which is specifically in place to prevent conflicting DHCP servers.

1 Like
12

hm ... is this the reply from the forum AI or from a diligent maintainer, who is just running out of time?
Did you read and get my point, or just jump to catchwords?

I agree that dhcpd should ask for colleagues on any subnet before starting to shout out. However, in my case, with a reasonable number of subnets, this takes about a minute - on every change of the DHCP file, eg after adding a static lease.

This may be ok for DHCP, but not for DNS, when the router is going to be the central DNS supplier in my LAN, because then any Internet user traffic is closed to blocked during that time.

13

The message you are getting indicates that you are RESTARTING dnsmasq. As @psherman said, the message is normal - telling you there are no conflicts.

How often do you need to add a static lease? Something wrong with what you are doing if you need to add loads of them, over and over....
How are you adding static leases anyway?

The sensible way (if your "static leases" are very dynamic), is to:

  1. use uci to make each change
  2. do a uci commit
  3. then RELOAD dnsmsaq instead of restarting it.
2 Likes
14

then RELOAD dnsmsaq instead of restarting it.

ah, thank you, I have missed that dnsmasq has a reload option, too, since most openwrt demons do not.

How are you adding static leases anyway?

At the moment, as I'm migrating from an old installation, I'm adding batches of leases as script generated config stanzas. Does this make a difference for reload? Will have to check...