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

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?

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

1 Like

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.

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

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.

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.

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

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

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