Bug 1226586

Summary:	avahi-browse -a fails with "Invalid service type"
Product:	[openSUSE] openSUSE Distribution	Reporter:	Martin Wilck <martin.wilck>
Component:	GNOME	Assignee:	Michael Gorse <mgorse>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	mgorse
Version:	Leap 15.6
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	log of "avahi-daemon --debug" DBus monitor log wireshark packet log for MDNS (port 5353)

Description Martin Wilck 2024-06-20 10:53:56 UTC

The following error occurs on multiple openSUSE systems, both 15.6 and Factory:

Error:

> avahi-browse -v -a
Server version: avahi 0.8; Host name: ares.local
E Ifce Prot Name                                          Type                 Domain
+   eth0 IPv4 connector-0                                   _spotify-connect._tcp local
+   eth0 IPv4 one-s-0                                       _spotify-connect._tcp local
: Cache exhausted
+   eth0 IPv4 Raumfeld-One-S-5aa49215a71dce5d5e3942e76961a1d1 _googlecast._tcp     local
+   eth0 IPv4 Raumfeld-Connector-d40ebb7d92cef2980bd98614fc032254 _googlecast._tcp     local
+   eth0 IPv4 5aa49215-a71d-ce5d-5e39-42e76961a1d1          _googlezone._tcp     local
+   eth0 IPv4 d40ebb7d-92ce-f298-0bd9-8614fc032254          _googlezone._tcp     local
+   eth0 IPv4 192-168-1-4                                   Microsoft Windows Network local
+   eth0 IPv4 fritz-box                                     Microsoft Windows Network local
+   eth0 IPv4 PROXY                                         Microsoft Windows Network local
+   eth0 IPv4 ANANAS                                        Microsoft Windows Network local
+   eth0 IPv4 one-s                                         SFTP File Transfer   local
+   eth0 IPv4 connector                                     SFTP File Transfer   local
+   eth0 IPv4 2064991846AFDD81                              _matterd._udp        local
+   eth0 IPv4 dahua1                                        Web Site             local
+   eth0 IPv4 PROXY                                         Device Info          local
+   eth0 IPv4 ANANAS                                        Device Info          local
avahi_service_browser_new() failed: Invalid service type

> avahi-browse -v -a
Server version: avahi 0.8; Host name: ares.local
E Ifce Prot Name                                          Type                 Domain
avahi_service_browser_new() failed: Invalid service type


# Preliminary analysis via dbus monitor

The client makes an invalid ServiceBrowserNew() method call with empty service type parameter:

‣ Type=method_call  Endian=l  Flags=0  Version=1 Cookie=31  Timestamp="Thu 2024-06-20 10:05:32.977645 UTC"
  Sender=:1.657  Destination=org.freedesktop.Avahi  Path=/  Interface=org.freedesktop.Avahi.Server  Member=ServiceBrowserNew
  UniqueName=:1.657
  MESSAGE "iissu" {
          INT32 -1;
          INT32 -1;
          STRING "";
          STRING "";
          UINT32 0;
  };

‣ Type=error  Endian=l  Flags=1  Version=1 Cookie=137  ReplyCookie=31  Timestamp="Thu 2024-06-20 10:05:32.977975 UTC"
  Sender=:1.656  Destination=:1.657
  ErrorName=org.freedesktop.Avahi.InvalidServiceTypeError  ErrorMessage="Invalid service type"
  UniqueName=:1.656
  MESSAGE "s" {
          STRING "Invalid service type";
  };


It appears that this service type has been previously passed from the daemon to the client via a DBus signal, either one of the following:

Type=signal  Endian=l  Flags=1  Version=1 Cookie=133  Timestamp="Thu 2024-06-20 10:05:32.976296 UTC"
  Sender=:1.656  Destination=:1.657  Path=/Client1/ServiceTypeBrowser1  Interface=org.freedesktop.Avahi.ServiceTypeBrowser  Member=ItemNew
  UniqueName=:1.656
  MESSAGE "iissu" {
          INT32 2;
          INT32 0;
          STRING "";
          STRING "";
          UINT32 4;
  };

‣ Type=signal  Endian=l  Flags=1  Version=1 Cookie=134  Timestamp="Thu 2024-06-20 10:05:32.976485 UTC"
  Sender=:1.656  Destination=:1.657  Path=/Client1/ServiceTypeBrowser1  Interface=org.freedesktop.Avahi.ServiceTypeBrowser  Member=ItemNew
  UniqueName=:1.656
  MESSAGE "iissu" {
          INT32 2;
          INT32 0;
          STRING "";
          STRING "local";
          UINT32 4;
  };

Comment 1 Martin Wilck 2024-06-20 10:54:40 UTC

Created attachment 875595 [details]
log of "avahi-daemon --debug"

Comment 2 Martin Wilck 2024-06-20 10:55:16 UTC

Created attachment 875596 [details]
DBus monitor log

Comment 3 Martin Wilck 2024-06-20 10:57:44 UTC

Created attachment 875598 [details]
wireshark packet log for MDNS (port 5353)

This logs and the previous two are from the same test run. 

I found two suspicious entries in the packet log.

Frame 41: 534 bytes on wire (4272 bits), 534 bytes captured (4272 bits) on interface eth0, id 0
Ethernet II, Src: AmazonTe_3c:91:23 (84:28:59:3c:91:23), Dst: IPv4mcast_fb (01:00:5e:00:00:fb)
Internet Protocol Version 4, Src: 192.168.1.200, Dst: 224.0.0.251
User Datagram Protocol, Src Port: 5353, Dst Port: 5353
Multicast Domain Name System (response)
    Transaction ID: 0x0000
    Flags: 0x8400 Standard query response, No error
    Questions: 0
    Answer RRs: 20
    Authority RRs: 0
    Additional RRs: 0
    Answers
        _services._dns-sd._udp.local: type PTR, class IN, <Root>
            Name: _services._dns-sd._udp.local
            Type: PTR (domain name PoinTeR) (12)
            .000 0000 0000 0001 = Class: IN (0x0001)
            0... .... .... .... = Cache flush: False
            Time to live: 3600 (1 hour)
            Data length: 1
            Domain Name: <Root>

        _services._dns-sd._udp.local: type PTR, class IN, local
            Name: _services._dns-sd._udp.local
            Type: PTR (domain name PoinTeR) (12)
            .000 0000 0000 0001 = Class: IN (0x0001)
            0... .... .... .... = Cache flush: False
            Time to live: 3600 (1 hour)
            Data length: 2
            Domain Name: local

Comment 4 Martin Wilck 2024-06-20 10:59:15 UTC

Possibly related:

https://github.com/avahi/avahi/issues/212 
"avahi-browse -a breaks with "Invalid service type" if a device sends a malformed service"

https://github.com/avahi/avahi/pull/523 
"core: no longer supply bogus services to callbacks"

Comment 5 Martin Wilck 2024-06-20 12:56:16 UTC

I can confirm that the patch from avahi#523 fixes the issue. The daemon log now shows the following messages:

Failed to split service name ''
Failed to split service name 'local'

Comment 6 Martin Wilck 2024-06-20 13:04:23 UTC

The upstream discussion about this has been ongoing for a _very_ long time.
Some distros, for example arch, have used downstream patches.

See avahi#212 and https://avahi.freedesktop.narkive.com/2Vi2UDCe/daemon-dies-on-certain-hostnames (discussion from 2006!).

Upstream seems to have settled on the commit from avahi#523 in 0.9-rc1.

Comment 7 Martin Wilck 2024-06-20 14:13:37 UTC

Background in my home network: I added new printer (HP smarttank 7305) yesterday. This morning I saw the issue mentioned in this bug for the first time. Because the printer is the only new device in my network, and it uses mDNS to advertize its services, it's not unlikely that something this printer is doing caused the issue.

However, the apparently broken mDNS records are not sent by the printer, but from my Amazon fire TV stick (192.168.1.200) in packet 41. It appears that this host violates the mDNS spec by responding with PTR records it doesn't provide itself, such as _uscan._tcp.local (https://datatracker.ietf.org/doc/html/rfc6762#section-6: "When a Multicast DNS responder constructs and sends a Multicast DNS response message, the Resource Record Sections of that message must contain only records for which that responder is explicitly authoritative" - but I'm no expert on the mDNS protocol). Some of these would naturally be provided by my printer only.

Anyway, no such breakage should cause the operation of avahi to be disrupted.

Comment 8 Martin Wilck 2024-06-20 14:20:36 UTC

Here's another bogus response from the Fire TV which I just captured:

0000   01 00 5e 00 00 fb 84 28 59 3c 91 23 08 00 45 00   ..^....(Y<.#..E.
0010   00 51 ef 3e 40 00 01 11 e6 f1 c0 a8 01 c8 e0 00   .Q.>@...........
0020   00 fb 14 e9 14 e9 00 3d 6a 0c 00 00 84 00 00 00   .......=j.......
0030   00 01 00 00 00 00 09 5f 73 65 72 76 69 63 65 73   ......._services
0040   07 5f 64 6e 73 2d 73 64 04 5f 75 64 70 05 6c 6f   ._dns-sd._udp.lo
0050   63 61 6c 00 00 0c 00 01 00 00 0e 0f 00 01 00      cal............

It contains only the broken 0-byte response that is displayed as "<ROOT>" in the wireshark dissection:


Frame 74: 95 bytes on wire (760 bits), 95 bytes captured (760 bits) on interface eth0, id 0
Ethernet II, Src: AmazonTe_3c:91:23 (84:28:59:3c:91:23), Dst: IPv4mcast_fb (01:00:5e:00:00:fb)
Internet Protocol Version 4, Src: 192.168.1.200, Dst: 224.0.0.251
User Datagram Protocol, Src Port: 5353, Dst Port: 5353
Multicast Domain Name System (response)
    Transaction ID: 0x0000
    Flags: 0x8400 Standard query response, No error
    Questions: 0
    Answer RRs: 1
    Authority RRs: 0
    Additional RRs: 0
    Answers
        _services._dns-sd._udp.local: type PTR, class IN, <Root>
            Name: _services._dns-sd._udp.local
            Type: PTR (domain name PoinTeR) (12)
            .000 0000 0000 0001 = Class: IN (0x0001)
            0... .... .... .... = Cache flush: False
            Time to live: 3599 (59 minutes, 59 seconds)
            Data length: 1
            Domain Name: <Root>

Comment 9 Martin Wilck 2024-06-20 14:45:54 UTC

Perhaps not unexpectedly, the error is gone (for now) after restarting the Amazon FireTV stick.

I'll observe this further. Regardless, I'd recommend applying the patch mentioned in comment 5.

Comment 10 Martin Wilck 2024-06-20 15:00:32 UTC

created sr#1181978 for GNOME:Factory/avahi

Comment 11 OBSbugzilla Bot 2024-06-20 17:45:04 UTC

This is an autogenerated message for OBS integration:
This bug (1226586) was mentioned in
https://build.opensuse.org/request/show/1181998 Factory / avahi

Comment 14 Maintenance Automation 2024-06-25 12:30:09 UTC

SUSE-SU-2024:2200-1: An update that solves two vulnerabilities and has one security fix can now be installed.

Category: security (moderate)
Bug References: 1216594, 1216598, 1226586
CVE References: CVE-2023-38469, CVE-2023-38471
Maintenance Incident: [SUSE:Maintenance:34466](https://smelt.suse.de/incident/34466/)
Sources used:
openSUSE Leap 15.6 (src):
 avahi-qt5-0.8-150600.15.3.1, avahi-0.8-150600.15.3.1, avahi-glib2-0.8-150600.15.3.1
Basesystem Module 15-SP6 (src):
 avahi-0.8-150600.15.3.1, avahi-glib2-0.8-150600.15.3.1
Desktop Applications Module 15-SP6 (src):
 avahi-0.8-150600.15.3.1, avahi-glib2-0.8-150600.15.3.1
SUSE Package Hub 15 15-SP6 (src):
 avahi-0.8-150600.15.3.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

Comment 15 Martin Wilck 2024-07-01 09:37:05 UTC

Closing per comment 14, thanks!