avahi-daemon allow/deny interfaces question

[Ram Ramesh]

Experts,

  I have a firewall machine built recently and it runs debian bullseye
(v11). It has two ethernet interfaces - one internal ($intf) and one
external ($extf). My external port runs dhclient to get its IP address
and internal port runs dnsmasq to provide DNS service to
internal/protected hosts. Usual iptables rules are established to
prevent attack/entry into internal net from external net and allow
proper internet access to internal net hosts.

  I had this system working fine (on an older machine) since debian
5.0.7. I have not upgraded that machine as it is working fine. However
that hardware is too old (10+ years) and I wanted to replace it with
something more modern running latest OS and that is why I built the
above machine.

 My old machine does not seem have avahi-daemon. So, it runs fine.
However, my new machine has this daemon running which notices that
$extif does not have much activity and disables it after some timeout
idle time. I initially thought my firewall rules are suspect and was
banging my head for a while adding extra rules for DHCPDISCOVER/REQUEST
etc thinking that those are blocked. Today I noticed that my $extif is
vanishing and /var/log/daemon.log shows some avahi-daemon messages about
that interface being disabled/withdrawn or some such thing.

As a next step, I want to tell avahi-daemon that it should not work on
that interface as it is not meant to be fooled around.  Do I use
deny-interface $extif or allow-interface $intif only? Which is proper?
Will doing one of these solve my problem of $extif vanishing from ifconfig?

If you think there is something else that I can do that is better,
please let me know that too.

Much appreciate any help.

Please let me know if you need anything else that will help to resolve
this problem.

Regards
Ramesh

[Gareth Evans]

> On 11 Jul 2022, at 17:48, Ram Ramesh <rrame...@gmail.com> wrote:
[...]

> . However, my new machine has this daemon running which notices that $extif does not have much activity and disables it after some timeout idle time.

> Today I noticed that my $extif is vanishing and /var/log/daemon.log shows some avahi-daemon messages about that interface being disabled/withdrawn or some such thing.

Hi Ramesh,

Please could you post some example daemon.log entries and any surrounding entries that seem related?

Also is there anything in

/var/log/syslog


that seems to relate?

Perhaps

$ sudo cat /var/log/syslog | grep x

where x = the interface name concerned.

Thanks,
Gareth

[Ram Ramesh]

It appears that this is not an issue with avahi-daemon. My $extif is
through usb NIC and that seem to go down due to some sort of powersave
autosuspend.  Currently I am running ping -i 60 <ext_gw> and that keeps
the net up and $extif has not vanished for a day.

I did some googling on how to disable autosuspend, but answers were
quite confusing. Do you know a simple way to disable autopowerdown of
just this usb NIC? May be there is something that I can do with ethtool?

Regards
Ramesh

[Gareth Evans]

On Wed 13 Jul 2022, at 01:21, Ram Ramesh <rrame...@gmail.com> wrote:
> Do you know a simple way to disable autopowerdown of
> just this usb NIC? May be there is something that I can do with ethtool?

I wonder if powertop may be of use here.

It has a "tunables" section where (I think) power-saving features can be toggled between "good" (on?) or "bad" (off?) by pressing Enter or Space when selected, though neither man powertop nor its (github) website

01.org/powertop

explains the significance or difference between "good" and "bad", but maybe worth trying?

Best wishes,
Gareth

[Ram Ramesh]

I take back some of what I said. It is both - I mean usb
autosupend+avahi_daemon. I need to keep the adaptor from autosuspending
and tell avahi-daemon not to disable the interface in the OS.

I also found the power/control entry in /sys/bus/usb/.... for my usb
NIC. It is not in the usual place. lsusb does not list my usb ethernet
adapter at all. I had to manually search to find it and set its
power/control to "on"

With all this done, so far my net is up and running fine. Will wait a
couple days with a couple of reboots to make sure I have captured all
fixes in some boot scripts. After that this problem can be thought of as
solved.

Regards
Ramesh

[Ram Ramesh]

> Hi Ramesh,
>
> Please could you post some example daemon.log entries and any surrounding entries that seem related?
>
> Also is there anything in
>
> /var/log/syslog
>
>
> that seems to relate?
>
> Perhaps
>
> $ sudo cat /var/log/syslog | grep x
>
> where x = the interface name concerned.
>
> Thanks,
> Gareth

Hi Gareth,

 This is what I find in daemon.log
> Jul 12 18:27:16 new-yoda avahi-daemon[441]: Withdrawing address record
> for fe80::daeb:97ff:febf:5ad0 on enxd8eb97bf5ad0.
> Jul 12 18:27:16 new-yoda avahi-daemon[441]: Withdrawing address record
> for 192.168.1.124 on enxd8eb97bf5ad0.

After this happens, most of my net access goes down. Firefox cannot get
to google.com/youtube.com. DNS lookup also returns nothing for external
hosts. I see similar messages on /var/log/syslog also


>> Jul 12 18:27:16 new-yoda avahi-daemon[441]: Interface
>> enxd8eb97bf5ad0.IPv6 no longer relevant for mDNS.
>> Jul 12 18:27:16 new-yoda avahi-daemon[441]: Leaving mDNS multicast
>> group on interface enxd8eb97bf5ad0.IPv6 with address
>> fe80::daeb:97ff:febf:5ad0.
>> Jul 12 18:27:16 new-yoda dhclient[550]: receive_packet failed on
>> enxd8eb97bf5ad0: Network is down
>> Jul 12 18:27:16 new-yoda avahi-daemon[441]: Interface
>> enxd8eb97bf5ad0.IPv4 no longer relevant for mDNS.
>> Jul 12 18:27:16 new-yoda avahi-daemon[441]: Leaving mDNS multicast
>> group on interface enxd8eb97bf5ad0.IPv4 with address 192.168.1.124.
>> Jul 12 18:27:16 new-yoda avahi-daemon[441]: Withdrawing address
>> record for fe80::daeb:97ff:febf:5ad0 on enxd8eb97bf5ad0.
>> Jul 12 18:27:16 new-yoda avahi-daemon[441]: Withdrawing address
>> record for 192.168.1.124 on enxd8eb97bf5ad0.
> Jul 12 18:27:17 new-yoda kernel: [ 8560.412306] asix 1-1:1.0 eth0:
> register 'asix' at usb-0000:00:14.0-1, ASIX AX88772 USB 2.0 Ethernet,
> d8:eb:97:bf:5a:d0
> Jul 12 18:27:17 new-yoda NetworkManager[448]: <info> [1657668437.0609]
> manager: (eth0): new Ethernet device
> (/org/freedesktop/NetworkManager/Devices/6)
> Jul 12 18:27:17 new-yoda systemd-udevd[1494]: Using default interface
> naming scheme 'v247'.
> Jul 12 18:27:17 new-yoda systemd-udevd[1494]: ethtool: autonegotiation
> is unset or enabled, the speed and duplex are not writable.
> Jul 12 18:27:17 new-yoda kernel: [ 8560.449674] asix 1-1:1.0
> enxd8eb97bf5ad0: renamed from eth0
> Jul 12 18:27:17 new-yoda NetworkManager[448]: <info> [1657668437.1103]
> device (eth0): interface index 5 renamed iface from 'eth0' to
> 'enxd8eb97bf5ad0'
> Jul 12 18:27:17 new-yoda systemd-udevd[1494]: ethtool: autonegotiation
> is unset or enabled, the speed and duplex are not writable.
> Jul 12 18:27:19 new-yoda ModemManager[489]: <info> [base-manager]
> couldn't check support for device
> '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1': not supported by any
> plugin

Looks like kernel finds usb NIC again and tries to do something? Since
dhclient is not aware, it does not know how to handle. I get this from
dhclient for the *next* DHCPDISCOVER/REQUEST

> Jul 12 19:45:04 new-yoda dhclient[550]: DHCPREQUEST for 192.168.1.124
> on enxd8eb97bf5ad0 to 192.168.1.254 port 67
> Jul 12 19:45:04 new-yoda dhclient[550]: send_packet: Network is
> unreachable
> Jul 12 19:45:04 new-yoda dhclient[550]: send_packet: please consult
> README file regarding broadcast address.

Hope you can find something useful. For now, I simply edited
avahi-daemon.conf and denied this interface as one not to be
observed/managed. That fixed the part of the problem. Other issue is
reported in one of my followup.

Regards
Ramesh

[Gareth Evans]

On Thu 14 Jul 2022, at 01:03, Ram Ramesh <rrame...@gmail.com> wrote:
[...]

> I take back some of what I said. It is both - I mean usb
> autosupend+avahi_daemon. I need to keep the adaptor from autosuspending
> and tell avahi-daemon not to disable the interface in the OS.
>
> I also found the power/control entry in /sys/bus/usb/.... for my usb
> NIC. It is not in the usual place. lsusb does not list my usb ethernet
> adapter at all. I had to manually search to find it and set its
> power/control to "on"
>
> With all this done, so far my net is up and running fine. Will wait a
> couple days with a couple of reboots to make sure I have captured all
> fixes in some boot scripts. After that this problem can be thought of as
> solved.

Hi Ramesh,

There are numerous reports (mostly old, afaics) of the issue you describe, but with various suggested reasons.

I suspect the avahi related part is a consequence rather than a cause - I didn't think avahi was capable of disabling interfaces, the message looks like it's updating a table/list (etc) and "...no longer relevant..." messages appear in my syslog if I deliberately disconnect from wifi.

Please can you provide syslog extracts from just before and during a time when this has happened, using:

$ sudo cat /var/log/syslog | grep -i -E "avahi|network"
(must be capital -E and no spaces around the | inside the speech marks)

Is there anything that seems relevant in

$ sudo dmesg -T

?

Out of interest, did you try running for a while with just the power management tweak?

Thanks,
Gareth

[Ram Ramesh]

> Hi Ramesh,
>
> There are numerous reports (mostly old, afaics) of the issue you describe, but with various suggested reasons.
>
> I suspect the avahi related part is a consequence rather than a cause - I didn't think avahi was capable of disabling interfaces, the message looks like it's updating a table/list (etc) and "...no longer relevant..." messages appear in my syslog if I deliberately disconnect from wifi.
>
> Please can you provide syslog extracts from just before and during a time when this has happened, using:
>
> $ sudo cat /var/log/syslog | grep -i -E "avahi|network"
> (must be capital -E and no spaces around the | inside the speech marks)
>
> Is there anything that seems relevant in
>
> $ sudo dmesg -T
>
> ?
>
> Out of interest, did you try running for a while with just the power management tweak?
>
> Thanks,
> Gareth

Yes, I believe I did. I did not use /sys/... power/control method.
Instead, I kept the network alive by "ping -i 60 <ext-gateway>".
However, I am not 100% sure of this. So, I will revert some of my
changes and get you the relevant logs.

Thanks for your continued interested in this matter.

Regards
Ramesh

[Ram Ramesh]

Mmm... It has been about 10 hours since my reboot after removing
"deny-interfaces=$extif," and I have not had the earlier issue of
interface disappearing. I will let it run overnight to see. However, I
think I wont be able to reproduce the problem.

Earlier, I was trying to keep the interface alive with "ping -i 60 xxx" 
instead of setting "/sys/usb/.... power/control" to "on". Not sure if
that was not enough and $extif actually powered off in between pings and
avahi-daemon was simply reporting this in daemon.log. However, kernel
reset the interface status and (may be) dhclient was not written to
handle this sort of issue. So, it simply could not work with the
interface anymore as it was not initialized to perform DHCP. I wonder
why this did not affect ping as it was chugging along without any
issues. That is too many wild guesses and I am not sure why the problem
does not exists now.

I will update again later tomorrow when it has run another 12+ hours.

Regards
Ramesh

[Ram Ramesh]

No issues still. So, I will call this done for now and report again, if
this shows up after a few days.

Regards
Ramesh