[avahi] avahi not publishing ssh/sftp records (workaround)

[Janos Farkas]

On 8/27/07, Lennart Poettering <lennart at poettering.net> wrote:
> On Tue, 21.08.07 22:31, Janos Farkas (chexum+0f4f4 at gmail.com) wrote:
> I assume this is Linux?

Yes, both machines are.

> Hmm, it is very interesting that apparently the workstation service
> has been registered on both machines while the ssh/sftp services are
> not. This looks very suspicious. I have no experience with VLANs. Is
> it possible that the packets sent out on one vlan iface are looped
> back on the other?

Trying to not divert from the topic, each vlan should be a completely
separate ethernet looking device, except for the fact, that the "base"
eth0 device is "up", without ipv4 addresses, and this device may see some
some weird packets (the vlan-tagged ones), if watched closely.  (That is,
they will not be recognized by the OS as a duplicate of the "other"
packet, but with tcpdump, you can examine them just as well.)

> If you register a service manually on GW, by calling:
>
> avahi-publish-service test _test._tcp 80
>
> does this work?

"Too many arguments", but the following works:

# avahi-publish -s test _test._tcp 80
Established under name 'test'
(after ctrl-c)
Got SIGINT, quitting.

And it appears on the other machine.

I got an idea though; I had "use-ipv6=no" in avahi-daemon.conf, but it
still printed a few ipv6 related log lines; setting it to
"use-ipv6=yes" on GW made the whole thing to work as I would expect!

Though I don't use ipv6, it's compiled into the kernel, and they have
the link-local addresses autoconfigured.

I'm appending a diff between the output of the ipv6=no vs. the ipv6=yes cases:

--- avano6.txt  2007-08-29 20:52:43.303329148 +0000
+++ ava6.txt    2007-08-29 20:59:06.798540000 +0000
@@ -5,12 +5,20 @@
 Successfully dropped remaining capabilities.
 Loading service file /services/sftp-ssh.service.
 Loading service file /services/ssh.service.
+Joining mDNS multicast group on interface vlan814.IPv6 with address
fe80::280:XXXX:XXXX:XXXX.
+New relevant interface vlan814.IPv6 for mDNS.
+Joining mDNS multicast group on interface vlan1.IPv6 with address
fe80::280:XXXX:XXXX:XXXX.
+New relevant interface vlan1.IPv6 for mDNS.
 Joining mDNS multicast group on interface vlan1.IPv4 with address 192.168.N.N.
 New relevant interface vlan1.IPv4 for mDNS.
+Joining mDNS multicast group on interface eth0.IPv6 with address
fe80::280:XXXX:XXXX:XXXX.
+New relevant interface eth0.IPv6 for mDNS.
 Network interface enumeration completed.
 Registering new address record for fe80::280:XXXX:XXXX:XXXX on vlan814.*.
 Registering new address record for fe80::280:XXXX:XXXX:XXXX on vlan1.*.
 Registering new address record for 192.168.N.N on vlan1.IPv4.
 Registering new address record for fe80::280:XXXX:XXXX:XXXX on eth0.*.
-Server startup complete. Host name is GW.local. Local service cookie
is 2035288746.
 Registering HINFO record with values 'I586'/'LINUX'.
+Server startup complete. Host name is GW.local. Local service cookie
is 2851350256.
+Service "GW" (/services/ssh.service) successfully established.
+Service "SFTP File Transfer on GW" (/services/sftp-ssh.service)
successfully established.

vlan814 is only a pppoe link (think ~ eth2), without actual ipv4
addresses, just like eth0 (which has only vlan traffic, no actual IP)

It may be of interest that each ll ipv6 interface has the same address
(and the vlans the same as the base eth0).  How this (when disabling
ipv6) affects the registering of the ssh services is a bit too above
my head right now :)

Janos