Re: dnsmasq dhcp failure
Steve Tell <[email protected]> Thu, 13 Oct 2022 13:16:04 -0400 (EDT)
| Newsgroups | gmane.linux.leaf.user |
|---|---|
| Message-ID | <alpine.LRH.2.23.451.2210131308490.685@helena> |
On Sun, 2 Oct 2022, marko via leaf-user wrote: > I just had dnsmasq stop serving requests. Restart of dnsmasq required. > > LEAF Bering-uClibc 7.1.3-rc2 Rev 1, up for 20 days I see dnsmasq stop every so often - like many months, but I confess to not keeping detailed notes on whether it exited or simply hung/stopped operating. (Bering-uClibc 6.2.6 Rev 1 uClibc 1.0.3, up 172 days) A mechanism to automaticly restart daemons that exit would be nice. But its not worth converting to systemd just for that - or at least I'm not offering to do the work :-) > On Friday, 9 September 2022 10:20:15 PM AEDT Erich Titl wrote: >> Hi Folks >> >> Am 29.08.2022 um 00:31 schrieb marko via leaf-user: >> >>> Hi ET, >>> >>> I have run leaf for a very long time, normally on fast hardware with >>> plenty of > memory. >>> >>> I've never seen dnsmasq not serve requests or allocate leases. >>> >>> I think dnsmasq fits the smaller network that is a bit complex scenario >>> very > well. Making it more complex would be a mistake as would making it >>> more like commodity routers which have many functions now. >> >> >> I can show now that with assigning a fixed address to a win10 client I >> can connect to the uplink LEAF system and the internet correctly. So >> obviously the dhcp request is _not_ handled correctly. >> >> Once connected to the LEAF box I see the folloging on the internal >> interface > >> SALT# tcpdump -i br0 port 67 >> tcpdump: verbose output suppressed, use -v[v]... for full protocol decode >> listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes >> 11:51:55.058168 IP .bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request >> from 34:46:ec:b2:ab:e7 (oui Unknown), length 324 >> 11:51:55.061890 IP .bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request >> from 34:46:ec:b2:ab:e7 (oui Unknown), length 324 >> 11:52:00.059480 IP .bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request >> from 34:46:ec:b2:ab:e7 (oui Unknown), length 324 >> 11:52:04.063118 IP .bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request >> from 34:46:ec:b2:ab:e7 (oui Unknown), length 318 >> 11:52:09.065633 IP .bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request >> from 34:46:ec:b2:ab:e7 (oui Unknown), length 318 >> 11:52:14.068486 IP .bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request >> from 34:46:ec:b2:ab:e7 (oui Unknown), length 318 >> 11:52:19.077023 IP .bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request >> from 34:46:ec:b2:ab:e7 (oui Unknown), length 318 >> >> >> So again, it looks like dhcp requests are coming in but are not replied to. >> >> So for completeness I copy the configuration here >> >> SALT# ip addr >> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN >> group default qlen 1000 >> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 >> inet 127.0.0.1/8 scope host lo >> valid_lft forever preferred_lft forever >> 2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group >> default qlen 1000 >> link/ether 12:66:bb:45:54:68 brd ff:ff:ff:ff:ff:ff >> 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast >> master br0 state UP group default qlen 1000 >> link/ether 00:0d:b9:04:6e:d8 brd ff:ff:ff:ff:ff:ff >> 4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state >> UP group default qlen 1000 >> link/ether 04:f0:21:17:32:8e brd ff:ff:ff:ff:ff:ff >> inet 192.168.1.69/24 brd 192.168.1.255 scope global dynamic >> noprefixroute wlan0 >> valid_lft 2522sec preferred_lft 2072sec >> 5: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue >> master br0 state UP group default qlen 1000 >> link/ether 04:f0:21:17:32:8b brd ff:ff:ff:ff:ff:ff >> 6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state >> UP group default qlen 1000 >> link/ether 00:0d:b9:04:6e:d8 brd ff:ff:ff:ff:ff:ff >> inet 192.168.217.1/24 scope global br0 >> valid_lft forever preferred_lft forever >> >> Restarting shorewall took forever so I looked at the processes running >> and I found that dnsmasq is quite prominent in the CPU score. >> >> Mem: 47060K used, 9576K free, 2448K shrd, 0K buff, 2448K cached >> CPU: 97.2% usr 1.3% sys 0.0% nic 0.0% idle 0.0% io 0.0% irq 1.3% sirq >> Load average: 2.35 2.55 1.87 2/55 8490 >> PID PPID USER STAT VSZ %VSZ %CPU COMMAND >> 1724 1 nobody R 1200 2.1 97.4 /usr/sbin/dnsmasq >> 8330 8283 root R 1320 2.3 1.5 top >> 8281 1989 root S 4136 7.2 0.5 sshd: root@pts/2 >> 2005 1 root S 968 1.7 0.1 /usr/sbin/cron >> 8380 2 root IW 0 0.0 0.1 [kworker/u2:0-ph] >> 1628 1 root S 12600 22.1 0.0 /usr/sbin/rsyslogd >> >> These systems used to run fine in the past so I am suspicious that newer >> linux software starts to become bloatware just like on the winblows side. >> >> I definitely will replace dnsmasq and see if a combination of dnscache >> and dhcpd works better. >> >> cheers >> >> ET >> >> >> > > > > > > ------------------------------------------------------------------------ > leaf-user mailing list: [email protected] > https://lists.sourceforge.net/lists/listinfo/leaf-user > Support Request -- http://leaf-project.org/ > ------------------------------------------------------------------------ leaf-user mailing list: [email protected] https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/