Re: dnsmasq dhcp failure

"Robert K Coffman Jr. -Info From Data Corp." <[email protected]> Thu, 13 Oct 2022 15:36:51 -0400
Newsgroups gmane.linux.leaf.user
Organization Info From Data Corporation
Message-ID <[email protected]>
   Most of my systems (6.2.3) do not do DHCP but I've never seen it exit /
   hang at all.

   The primary function is DNS and I pass all external DNS requests to
   DNSMASQ, including on a lightly loaded email server with a SPAM filter
   running on it.  The email server used to be much more heavily loaded
   and I never had an issue like that.

   - Bob

   On 10/13/2022 1:16 PM, Steve Tell wrote:

     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: [1][email protected]
     [2]https://lists.sourceforge.net/lists/listinfo/leaf-user
     Support Request -- [3]http://leaf-project.org/

     --------------------------------------------------------------------
     ----
     leaf-user mailing list: [4][email protected]
     [5]https://lists.sourceforge.net/lists/listinfo/leaf-user
     Support Request -- [6]http://leaf-project.org/

--
Robert K Coffman Jr.
Info From Data Corp.
3307249000
[7][email protected]

References

   1. mailto:[email protected]
   2. https://lists.sourceforge.net/lists/listinfo/leaf-user
   3. http://leaf-project.org/
   4. mailto:[email protected]
   5. https://lists.sourceforge.net/lists/listinfo/leaf-user
   6. http://leaf-project.org/
   7. mailto:[email protected]

------------------------------------------------------------------------
leaf-user mailing list: [email protected]
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/