Why is my OS11.2 sending out MDNS packets to 224.0.0.251:5353?

The packets have this kind of content:

16 48.521611 192.168.0.102 224.0.0.251 MDNS Standard query SRV mybox [00:ab:54:fd:af:bf]._workstation._tcp.local, “QM” question SRV mybox._ssh._tcp.local, “QM” question SRV SFTP File Transfer on mybox._sftp-ssh._tcp.local, “QM” question

107 243.968283 192.168.0.102 224.0.0.251 MDNS Standard query response SRV, cache flush 0 0 22 mybox.local AAAA, cache flush fe80::223:54ff:fefd:afbf A, cache flush 192.168.0.102 SRV, cache flush 0 0 9 mybox.local SRV, cache flush 0 0 22 mybox.local

I don’t recall seeing this on my OS11.2 system at work. I installed my system at home in a hurry, and certainly don’t recall the details. Did I install something, or select an option that made this happen?

Is this default behavior of OS11.2?

It’s the Avahi MDNS service.

http://en.wikipedia.org/wiki/Avahi_(software)

I wonder if this represents a path to recovery. Zero configuration networking - Wikipedia, the free encyclopedia sounds kind of like CIFS/NetBIOS over TCP/IP B node behavior - without the Microsoft-pathology.

Implementing CIFS: NBT
1.3.1.2 Fully Qualified NBT Names

Now that we’ve managed to convert the NetBIOS name into a DNS-aligned form, it is time to combine it with the NBT Scope ID. The result will be a fully-qualified NBT address, which we will call the “NBT Name”. To be pedantic, when the RFCs talk about First Level Encoding, this fully qualified form is what they really mean.

As expected, the syntax of the Scope ID follows the DNS recommendations given in RFC 883 (and repeated in RFC 1035). That is, a Scope ID looks like a DNS name. So, if the Scope ID is cat.org, and the NetBIOS name is Neko, the resultant NBT name would be:

EOGFGLGPCACACACACACACACACACACACA.CAT.ORG 

Imagine typing that into your web browser. This is why the RFC 1001/1002 scheme for merging the NBNS with the DNS never took hold.

Just for cheep bragging rights, this is my answer to the C code in Implementing CIFS: NBT It has two advantages, IMO. 1) it is cleaner. 2) it works. DomainName can be replace by std::string without impacting the example.

  
DomainName NBTName::levelOneEncoding() const {
    // RFC 1001, Section 14.1. 
   
    std::string result(32,'A');
    std::string paddedName =  16 > _name.length() 
      ? _name + std::string(16 - _name.length(),' ') 
      : _name.substr(0,16);
     
    for(int i = 0; i < paddedName.length(); ++i ) {
      result[2 * i    ] += ((paddedName* >>4) & 0x0F);
      result[2 * i + 1] += ( paddedName*      & 0x0F);
    }
    return result+"."+std::string(_scope);
  }

NBT Listing 1.1


#ifndef uchar
#define uchar unsigned char
#endif /* uchar */
  
uchar *L1_Encode( uchar *dst, const uchar *name )
  {
  int i = 0;
  int j = 0;

  /* Encode the name. */
  while( ('\0' != name*) && (i < 16) )
    {
    dst[j++] = 'A' + ((name* & 0xF0) >> 4);
    dst[j++] = 'A' + (name* & 0x0F);
    }

  /* Encode the padding bytes. */
  while( j < 32 )
    {
    dst[j++] = 'C';
    dst[j++] = 'A';
    }

  /* Terminate the string. */
  dst[32] = '\0';

  return( dst );
  } /* L1_Encode */

$Revision: 1.12 $
$Date: 2003/02/18 21:43:58 $ 

And when you swallowed the information oin Avahi, this is where you can switch it off:
YaST > System > System services (runlevel). Search for avahi-deamon and switch it off.
When you have no Zero conf in your network, you do not need it.

Search for avahi-deamon and switch it off. When you have no Zero conf in your network, you do not need it.

avahi-daemon seems to be switched ON by default. Why is this? I think a daemon not needed by most users and consuming RAM space should be off by default?

Bah, a daemon with a resident footprint of 1.3MB is small beer for the service location facilities it provides.