Nabble - Free Desktop - avahi

How to filter out local services?

2009-11-26T08:42:08Z

Hi,
I wrote a similiar application like avahi-browser, which just "collect"
2 different types of services. Unfortunatelly it "listens" local
services too, which I would like to filter out. How can I do that? Where
do I have put the parameter?

Thank you!
Floh

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Re: Avahi Stops Advertising My New Service...

2009-11-22T20:26:32Z

On Nov 22, 2009, at 9:38 PM, Trent Lloyd wrote:

However, since you are using VMWare on a mac, which works as best I am aware (although I will test again later)... I recommend you check the firewall on Fedora and MacOS.

Trent,

Thank you for your prompt reply.

As you suggest above, the problem was the Fedora default firewall. I'll write this up for my personal blog but I think I should also create a FAQ answer for this problem. (It seems like an easy to avoid pothole.) Should I just mail my FAQ&A to this list or is there someone I should send this paragraph to?

Anon,
Andrew
____________________________________
Andrew W. Donoho
Donoho Design Group, L.L.C.
awd@..., +1 (512) 750-7596

"We did not come to fear the future.

We came here to shape it."

-- President Barack Obama, Sept. 2009

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Re: Avahi Stops Advertising My New Service...

2009-11-22T19:38:38Z

Andrew,

On 23/11/2009, at 10:01 AM, Andrew W. Donoho wrote:

> Folks,
>
> I am defining a new service for Avahi to vend to the network. It starts up and all of the parameters are correct and it can be found by my custom software and by "Bonjour Browser". But then Avahi stops advertising the service in about 5 minutes. This is running a "stock" Fedora 11 on VMware on a Mac. To simplify the configuration, I've given the linux image a static IP address and it is bridged onto my local network. Internet access is working properly. SSH, _ssh._tcp, as delivered by Fedora, also suffers from this problem.
>
> Below is as much data as I know how to dig up about Avahi's status. I, of course, can perform any system experiments any of you might desire to get more data about this problem. I am confused and would appreciate your help. Thanks in advance.

Most likely basically, the machine is not receiving packets on port 5353 multicast.. usually this is caused by faulty wireless drivers that do not speak multicast properly.

The reason they disappear after 5 minutes is that initially when Avahi starts up, it advertises the services manually, over time it backs off and new clients need to be able to request it re-advertise itself, the problem is it never receives the queries and thus never replies.

However, since you are using VMWare on a mac, which works as best I am aware (although I will test again later)... I recommend you check the firewall on Fedora and MacOS.

Regards,
Trent
_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Avahi Stops Advertising My New Service...

2009-11-22T18:01:44Z

Folks,

I am defining a new service for Avahi to vend to the network. It starts up and all of the parameters are correct and it can be found by my custom software and by "Bonjour Browser". But then Avahi stops advertising the service in about 5 minutes. This is running a "stock" Fedora 11 on VMware on a Mac. To simplify the configuration, I've given the linux image a static IP address and it is bridged onto my local network. Internet access is working properly. SSH, _ssh._tcp, as delivered by Fedora, also suffers from this problem.

Below is as much data as I know how to dig up about Avahi's status. I, of course, can perform any system experiments any of you might desire to get more data about this problem. I am confused and would appreciate your help. Thanks in advance.

Anon,
Andrew

P.S. I have already submitted these service identifiers, _rest._tcp and _rest-http._tcp, to the DNS-SD registry. (These are named similarly to my submissions made in an earlier life, _ws._tcp, _soap._tcp and _upnp._tcp.) Since I'm now using REST services, I believe they need their own identifier.

____________________________________
Andrew W. Donoho
Donoho Design Group, L.L.C.
awd@..., +1 (512) 750-7596

Knowing is not enough; we must apply.
Willing is not enough; we must do.
-- Johann Wolfgang von Goethe

Using avahi-daemon 0.6.25

Here are the two services:

<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">

<service-group>
<name replace-wildcards="yes">%h</name>
<service>
<type>_ssh._tcp</type>
<port>22</port>
</service>
</service-group>

<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">

<service-group>
<name replace-wildcards="no">weLost</name>
<service>
<type>_rest._tcp</type>
<port>3000</port>
<txt-record>txtvers=1</txt-record>
</service>
</service-group>

Here is the result of ip addr:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether 00:0c:29:bb:87:5d brd ff:ff:ff:ff:ff:ff
inet 192.168.1.126/24 brd 192.168.1.255 scope global eth0
inet6 fe80::20c:29ff:febb:875d/64 scope link
valid_lft forever preferred_lft forever
3: pan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
link/ether e6:db:70:18:3c:07 brd ff:ff:ff:ff:ff:ff

And here are the pertinent lines from the Fedora messages log:

Nov 22 13:36:36 Ghost avahi-daemon[1439]: Got SIGTERM, quitting.
Nov 22 13:36:36 Ghost avahi-daemon[1439]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.126.
Nov 22 13:36:37 Ghost avahi-daemon[30528]: Found user 'avahi' (UID 497) and group 'avahi' (GID 489).
Nov 22 13:36:37 Ghost avahi-daemon[30528]: Successfully dropped root privileges.
Nov 22 13:36:37 Ghost avahi-daemon[30528]: avahi-daemon 0.6.25 starting up.
Nov 22 13:36:37 Ghost avahi-daemon[30528]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Nov 22 13:36:37 Ghost avahi-daemon[30528]: Successfully called chroot().
Nov 22 13:36:37 Ghost avahi-daemon[30528]: Successfully dropped remaining capabilities.
Nov 22 13:36:37 Ghost avahi-daemon[30528]: Loading service file /services/rest.service.
Nov 22 13:36:37 Ghost avahi-daemon[30528]: Loading service file /services/ssh.service.
Nov 22 13:36:37 Ghost avahi-daemon[30528]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.126.
Nov 22 13:36:37 Ghost avahi-daemon[30528]: New relevant interface eth0.IPv4 for mDNS.
Nov 22 13:36:37 Ghost avahi-daemon[30528]: Network interface enumeration completed.
Nov 22 13:36:37 Ghost avahi-daemon[30528]: Registering new address record for fe80::20c:29ff:febb:875d on eth0.*.
Nov 22 13:36:37 Ghost avahi-daemon[30528]: Registering new address record for 192.168.1.126 on eth0.IPv4.
Nov 22 13:36:37 Ghost avahi-daemon[30528]: Registering HINFO record with values 'I686'/'LINUX'.
Nov 22 13:36:37 Ghost avahi-daemon[30528]: Server startup complete. Host name is Ghost.local. Local service cookie is 1953088544.
Nov 22 13:36:38 Ghost avahi-daemon[30528]: Service "Ghost" (/services/ssh.service) successfully established.
Nov 22 13:36:38 Ghost avahi-daemon[30528]: Service "weLost" (/services/rest.service) successfully established.

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Re: Fwd: On DBus

2009-11-17T19:34:57Z

Jean-Lou,

On 18/11/2009, at 1:17 AM, Jean-Lou Dupont wrote:

> Hi,
>
> I've been working on a pet-project ( a browser NPAPI plugin for
> exposing local HTTP services ) and I've been "slowed down" (to say the
> least) with the DBus interface. It seems that in order to fully
> "resolve" a new service through DBus a 3 step process is required:
>
> 1. Register a ServiceBrowser
> 2. Once an "ItemNew" signal is received, register a "ServiceResolver"
> in order to get the full details of the said service
> 3. Grab the service details on reception of the "Found" signal
>
> This is painful.
>
> Why can't Avahi just announce everything on DBus without having to ask
> for it?? It is not like we are talking about an unreasonable amount
> of traffic on DBus here.

This is because of thew ay the mDNS protocol works, and it is designed to reduce traffic.

As I explained on IRC last night, services do not immediately advertise all their details on the network, the only detail that is sent out is basically that a service called "X" with a type of "Y" exists.

To get further detail about the service, you must resolve it, this then makes an additional query and gets a response. If we were to "automatically" do this on every service, the level of mDNS traffic would be insane, particularly on wireless networks and even more particularly if they were large.

Scaling issues have already been seen on conference wireless networks without this 'additional load'

Additionally.. due to the 'unreliable' nature of the protocol, such things are not guarnateeable, for example, if you just join a network, you will not immediately see announcements from people.. you have to request them.. so you can see even if everyone broadcasted all their records (which actually, they do at the start the first time a record exists) - every time someone joined the network - literally everyone would have to re-broadcast their entire catalogue of records.

Your application should try as hard as possible to not actually 'resolve' a service until it is required, this is not always possible since people often want extra data, but you can cheat and encode some flags into the service name, this is done by iTunes for example, password-protected shares have an _ prefixed to their name, so iTunes can show a padlock that its password protected before you click on it, without having to resolve the service.

>
> Am I missing something? Is there a better way of doing this? ( FYI:
> an NPAPI plugin is best coded in C )

Why don't you use the avahi-client library?

It is much better than using DBUS directly...

Thanks,
Trent

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Fwd: On DBus

2009-11-17T09:17:28Z

Hi,

I've been working on a pet-project ( a browser NPAPI plugin for
exposing local HTTP services ) and I've been "slowed down" (to say the
least) with the DBus interface. It seems that in order to fully
"resolve" a new service through DBus a 3 step process is required:

1. Register a ServiceBrowser
2. Once an "ItemNew" signal is received, register a "ServiceResolver"
in order to get the full details of the said service
3. Grab the service details on reception of the "Found" signal

This is painful.

Why can't Avahi just announce everything on DBus without having to ask
for it?? It is not like we are talking about an unreasonable amount
of traffic on DBus here.

Am I missing something? Is there a better way of doing this? ( FYI:
an NPAPI plugin is best coded in C )

Thanks,
Jean-Lou Dupont.

--
http://www.jldupont.com/
http://jldupont.blogspot.com/
twitter: jldupont
skype: jean-lou.dupont
_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Re: [PATCH] autoipd: also use :avahi when using ifconfig in linux action script

2009-11-13T17:42:43Z

On Fri, 19.06.09 15:40, Peter Korsgaard (jacmet@...) wrote:

> avahi-autoipd.action.linux creates <dev>:3 aliases when using ifconfig
> instead of the <dev>:avahi aliases used when ip is used. Fix it to always
> use <dev>:avahi for consistency.

Thanks!

Applied.

Lennart

--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

auto-ipd and multiple addresses

2009-11-12T09:33:57Z

Hi,

We would like to use auto-ipd to assign IP addresses to slave DSP process (we don’t want to port auto-ipd to the DSP). Is this possible? Will we have to modify auto-ipd to achieve this?

Thanks,
Neil

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message.
Thank you.

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Avahi autoipd behaviour when Link goes down

2009-11-10T02:02:38Z

Hi,

I am using avahi autoipd alongwith udhcpc. The scenario is following

DHCP server is switched off, so after lease time expiry autoipd is triggered and it assign an IPv4LL address.

Now the ethernet link goes down, this causes the avahi-autoipd daemon to exit.Is this the default behavior ?

In case when the link comes up and dhcp server is still not there then how should the autoip be triggered again.

I have added creation of avahi-autoipd in "deconfig" event of udhcpc.script.

Even when the link is down udhcpc keeps running shouldn't autoipd also continue running ?

Regards,

Rajat

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Re: Published service still browseable in other machines even if network it's down

2009-11-05T08:12:17Z

On 05/11/2009, at 8:14 PM, José Félix Ontañón wrote:

From what I remember reading the docs, what is supposed to happen is when someone goes to try and use a service that is no longer there, it should fail and immediately flush that entry from the cache so that its no longer an option in the user interface.

Rob

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

How do i "try and use" the failing service for flushing the cache entry? I mean, the way i'm doing now it's:

* Slaves publish address and port via avahi
* When the master discover a slave (via avahi), it makes a connection to slave address:port and call some rpc's (via my own xmlrpc implemented service).

Thanks in advance!

Robin is correct.. if you try run a ServiceResolver (rather than the browser), the "POOF" (passive observation of failure) should expire it, i think.

Trent

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Re: Published service still browseable in other machines even if network it's down

2009-11-05T04:14:30Z

2009/11/5 Robin Perkins <robin.perkins@...>

On 05/11/2009, at 6:16 PM, José Félix Ontañón wrote:

2009/11/5 Trent Lloyd <lathiat@...>

Hi Jose,

On 05/11/2009, at 6:35 AM, José Félix Ontañón wrote:

> Hi everyone!
>
> I'm a newbie playing with python-avahi trying to code some kind of
> master-slave application for shutdown every machine at same time.
> When the master it's ordered to shutdown, it sends the signal to the
> slaves. The slaves publish/unpublish the service via avahi, and the
> master
> discover them via ItemNew/ItemRemove signals. Very strait-forward,
> isn't?
>
> The avahi publish/unpublish/discover services it's gorgeous but i've
> found that if a slave, that has published the service via avahi,
> losts it
> network (i.e. the wifi ap goes out of power), the master still
> discovering it! and no ItemRemove signal it's raised at all. Is it
> normal? Am i doing something wrong?
>
> To solve it, i've implemented some kind of "ping" to the slaves
> service every Xseconds. When a new slave it's discovered, the
> periodic ping starts.
> When ping it's failing i know there be some problem with networking.
>
> I wonder if avahi itself provides a native workaround to avoid the
> coding of those nasty "ping" cycles ...

This is normal.. it will disappear after some time.

The instant removal of an advertised service relies on the host
sending a "gone away" message (more specifically, it updates the TTL
of its record to expire in I think.. 1 second)

This is because mDNS uses caching.. if it didn't use caching it would
cause alot more network traffic and would hammer especially wireless
networks.

Having not really worked with it for a while.. I can't remember all
the details but I suspect you can change the TTL in the Avahi API call
to make these timeouts happen a little quicker, but you will increase
network traffic by doing so.

Really your application should not rely on Avahi for "service
undiscovery".. it's meant generally for "unreliable service
discovery". You are best of actually having some protocol between the
master and slave and just using avahi for the slave to find the master
in the first instance.

Regards,
Trent
_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Ok, in this case i'll continue with my ping aproximation. It works fairly well.

Thanks Trent.

From what I remember reading the docs, what is supposed to happen is when someone goes to try and use a service that is no longer there, it should fail and immediately flush that entry from the cache so that its no longer an option in the user interface.

Rob

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

How do i "try and use" the failing service for flushing the cache entry? I mean, the way i'm doing now it's:

* Slaves publish address and port via avahi
* When the master discover a slave (via avahi), it makes a connection to slave address:port and call some rpc's (via my own xmlrpc implemented service).

Thanks in advance!

--
http://nosigasleyendo.blogspot.com

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Re: Published service still browseable in other machines even if network it's down

2009-11-05T02:52:13Z

On 05/11/2009, at 6:16 PM, José Félix Ontañón wrote:

2009/11/5 Trent Lloyd <lathiat@...>
Hi Jose,

On 05/11/2009, at 6:35 AM, José Félix Ontañón wrote:

> Hi everyone!
>
> I'm a newbie playing with python-avahi trying to code some kind of
> master-slave application for shutdown every machine at same time.
> When the master it's ordered to shutdown, it sends the signal to the
> slaves. The slaves publish/unpublish the service via avahi, and the
> master
> discover them via ItemNew/ItemRemove signals. Very strait-forward,
> isn't?
>
> The avahi publish/unpublish/discover services it's gorgeous but i've
> found that if a slave, that has published the service via avahi,
> losts it
> network (i.e. the wifi ap goes out of power), the master still
> discovering it! and no ItemRemove signal it's raised at all. Is it
> normal? Am i doing something wrong?
>
> To solve it, i've implemented some kind of "ping" to the slaves
> service every Xseconds. When a new slave it's discovered, the
> periodic ping starts.
> When ping it's failing i know there be some problem with networking.
>
> I wonder if avahi itself provides a native workaround to avoid the
> coding of those nasty "ping" cycles ...

This is normal.. it will disappear after some time.

The instant removal of an advertised service relies on the host
sending a "gone away" message (more specifically, it updates the TTL
of its record to expire in I think.. 1 second)

This is because mDNS uses caching.. if it didn't use caching it would
cause alot more network traffic and would hammer especially wireless
networks.

Having not really worked with it for a while.. I can't remember all
the details but I suspect you can change the TTL in the Avahi API call
to make these timeouts happen a little quicker, but you will increase
network traffic by doing so.

Really your application should not rely on Avahi for "service
undiscovery".. it's meant generally for "unreliable service
discovery". You are best of actually having some protocol between the
master and slave and just using avahi for the slave to find the master
in the first instance.

Regards,
Trent
_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Ok, in this case i'll continue with my ping aproximation. It works fairly well.

Thanks Trent.

From what I remember reading the docs, what is supposed to happen is when someone goes to try and use a service that is no longer there, it should fail and immediately flush that entry from the cache so that its no longer an option in the user interface.

Rob

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Re: Published service still browseable in other machines even if network it's down

2009-11-05T00:16:46Z

2009/11/5 Trent Lloyd <lathiat@...>

Hi Jose,

On 05/11/2009, at 6:35 AM, José Félix Ontañón wrote:

> Hi everyone!
>
> I'm a newbie playing with python-avahi trying to code some kind of
> master-slave application for shutdown every machine at same time.
> When the master it's ordered to shutdown, it sends the signal to the
> slaves. The slaves publish/unpublish the service via avahi, and the
> master
> discover them via ItemNew/ItemRemove signals. Very strait-forward,
> isn't?
>
> The avahi publish/unpublish/discover services it's gorgeous but i've
> found that if a slave, that has published the service via avahi,
> losts it
> network (i.e. the wifi ap goes out of power), the master still
> discovering it! and no ItemRemove signal it's raised at all. Is it
> normal? Am i doing something wrong?
>
> To solve it, i've implemented some kind of "ping" to the slaves
> service every Xseconds. When a new slave it's discovered, the
> periodic ping starts.
> When ping it's failing i know there be some problem with networking.
>
> I wonder if avahi itself provides a native workaround to avoid the
> coding of those nasty "ping" cycles ...

This is normal.. it will disappear after some time.

The instant removal of an advertised service relies on the host
sending a "gone away" message (more specifically, it updates the TTL
of its record to expire in I think.. 1 second)

This is because mDNS uses caching.. if it didn't use caching it would
cause alot more network traffic and would hammer especially wireless
networks.

Having not really worked with it for a while.. I can't remember all
the details but I suspect you can change the TTL in the Avahi API call
to make these timeouts happen a little quicker, but you will increase
network traffic by doing so.

Really your application should not rely on Avahi for "service
undiscovery".. it's meant generally for "unreliable service
discovery". You are best of actually having some protocol between the
master and slave and just using avahi for the slave to find the master
in the first instance.

Regards,
Trent
_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Ok, in this case i'll continue with my ping aproximation. It works fairly well.

Thanks Trent.

--
http://nosigasleyendo.blogspot.com

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Re: Published service still browseable in other machines even if network it's down

2009-11-04T22:15:10Z

Hi Jose,

On 05/11/2009, at 6:35 AM, José Félix Ontañón wrote:

> Hi everyone!
>
> I'm a newbie playing with python-avahi trying to code some kind of
> master-slave application for shutdown every machine at same time.
> When the master it's ordered to shutdown, it sends the signal to the
> slaves. The slaves publish/unpublish the service via avahi, and the
> master
> discover them via ItemNew/ItemRemove signals. Very strait-forward,
> isn't?
>
> The avahi publish/unpublish/discover services it's gorgeous but i've
> found that if a slave, that has published the service via avahi,
> losts it
> network (i.e. the wifi ap goes out of power), the master still
> discovering it! and no ItemRemove signal it's raised at all. Is it
> normal? Am i doing something wrong?
>
> To solve it, i've implemented some kind of "ping" to the slaves
> service every Xseconds. When a new slave it's discovered, the
> periodic ping starts.
> When ping it's failing i know there be some problem with networking.
>
> I wonder if avahi itself provides a native workaround to avoid the
> coding of those nasty "ping" cycles ...

This is normal.. it will disappear after some time.

The instant removal of an advertised service relies on the host
sending a "gone away" message (more specifically, it updates the TTL
of its record to expire in I think.. 1 second)

This is because mDNS uses caching.. if it didn't use caching it would
cause alot more network traffic and would hammer especially wireless
networks.

Having not really worked with it for a while.. I can't remember all
the details but I suspect you can change the TTL in the Avahi API call
to make these timeouts happen a little quicker, but you will increase
network traffic by doing so.

Really your application should not rely on Avahi for "service
undiscovery".. it's meant generally for "unreliable service
discovery". You are best of actually having some protocol between the
master and slave and just using avahi for the slave to find the master
in the first instance.

Regards,
Trent
_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Published service still browseable in other machines even if network it's down

2009-11-04T14:35:05Z

Hi everyone!

I'm a newbie playing with python-avahi trying to code some kind of master-slave application for shutdown every machine at same time.
When the master it's ordered to shutdown, it sends the signal to the slaves. The slaves publish/unpublish the service via avahi, and the master
discover them via ItemNew/ItemRemove signals. Very strait-forward, isn't?

The avahi publish/unpublish/discover services it's gorgeous but i've found that if a slave, that has published the service via avahi, losts it
network (i.e. the wifi ap goes out of power), the master still discovering it! and no ItemRemove signal it's raised at all. Is it normal? Am i doing something wrong?

To solve it, i've implemented some kind of "ping" to the slaves service every Xseconds. When a new slave it's discovered, the periodic ping starts.
When ping it's failing i know there be some problem with networking.

I wonder if avahi itself provides a native workaround to avoid the coding of those nasty "ping" cycles ...

Cheers!

--
http://nosigasleyendo.blogspot.com

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Re: How to stop ipv6 address from being registered

2009-10-28T23:36:52Z

On Oct 28, 2009, at 7:46 PM, Trent Lloyd <lathiat@...> wrote:

> Mark,
>
> On 29/10/2009, at 8:51 AM, Mark Edwards wrote:
>
>> I am running avahi-daemon 0.6.22 on Ubuntu 8.04, and it publishes an
>> ipv6 address even though I'm trying to tell it not to:
>>
>> Oct 28 17:45:09 labserver avahi-daemon[9603]: avahi-daemon 0.6.22
>> starting up.
>> Oct 28 17:45:09 labserver avahi-daemon[9603]: Successfully called
>> chroot().
>> Oct 28 17:45:09 labserver avahi-daemon[9603]: Successfully dropped
>> remaining capabilities.
>> Oct 28 17:45:09 labserver avahi-daemon[9603]: No service file found
>> in /etc/avahi/services.
>> Oct 28 17:45:09 labserver avahi-daemon[9603]: Joining mDNS multicast
>> group on interface eth0.IPv4 with address 192.168.1.101.
>> Oct 28 17:45:09 labserver avahi-daemon[9603]: New relevant interface
>> eth0.IPv4 for mDNS.
>> Oct 28 17:45:09 labserver avahi-daemon[9603]: Network interface
>> enumeration completed.
>> Oct 28 17:45:09 labserver avahi-daemon[9603]: Registering new address
>> record for fe80::211:d8ff:fe33:766e on eth0.*.
>> Oct 28 17:45:09 labserver avahi-daemon[9603]: Registering new address
>> record for 192.168.1.101 on eth0.IPv4.
>> Oct 28 17:45:09 labserver avahi-daemon[9603]: Registering HINFO
>> record
>> with values 'I686'/'LINUX'.
>> Oct 28 17:45:10 labserver avahi-daemon[9603]: Server startup
>> complete.
>> Host name is labserver.local. Local service cookie is 3357143783.
>>
>>
>> This is despite the fact that I have these settings in /etc/avahi/
>> avahi-daemon.conf:
>>
>> use-ipv4=true
>> use-ipv6=false
>> publish-a-on-ipv6=no
>
> Try set publish-aaaa-on-ipv4=no also
>
> Thanks,
> Trent

That seems to do it. This seems counter to the documentation, which
states that these settings don't have an effect if use-ipv6 is false.
I guess having any of them set triggers registration?

Thanks!
_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Re: How to stop ipv6 address from being registered

2009-10-28T19:46:44Z

Mark,

On 29/10/2009, at 8:51 AM, Mark Edwards wrote:

> I am running avahi-daemon 0.6.22 on Ubuntu 8.04, and it publishes an
> ipv6 address even though I'm trying to tell it not to:
>
> Oct 28 17:45:09 labserver avahi-daemon[9603]: avahi-daemon 0.6.22
> starting up.
> Oct 28 17:45:09 labserver avahi-daemon[9603]: Successfully called
> chroot().
> Oct 28 17:45:09 labserver avahi-daemon[9603]: Successfully dropped
> remaining capabilities.
> Oct 28 17:45:09 labserver avahi-daemon[9603]: No service file found
> in /etc/avahi/services.
> Oct 28 17:45:09 labserver avahi-daemon[9603]: Joining mDNS multicast
> group on interface eth0.IPv4 with address 192.168.1.101.
> Oct 28 17:45:09 labserver avahi-daemon[9603]: New relevant interface
> eth0.IPv4 for mDNS.
> Oct 28 17:45:09 labserver avahi-daemon[9603]: Network interface
> enumeration completed.
> Oct 28 17:45:09 labserver avahi-daemon[9603]: Registering new address
> record for fe80::211:d8ff:fe33:766e on eth0.*.
> Oct 28 17:45:09 labserver avahi-daemon[9603]: Registering new address
> record for 192.168.1.101 on eth0.IPv4.
> Oct 28 17:45:09 labserver avahi-daemon[9603]: Registering HINFO record
> with values 'I686'/'LINUX'.
> Oct 28 17:45:10 labserver avahi-daemon[9603]: Server startup complete.
> Host name is labserver.local. Local service cookie is 3357143783.
>
>
> This is despite the fact that I have these settings in /etc/avahi/
> avahi-daemon.conf:
>
> use-ipv4=true
> use-ipv6=false
> publish-a-on-ipv6=no

Try set publish-aaaa-on-ipv4=no also

Thanks,
Trent

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

How to stop ipv6 address from being registered

2009-10-28T17:51:31Z

I am running avahi-daemon 0.6.22 on Ubuntu 8.04, and it publishes an
ipv6 address even though I'm trying to tell it not to:

Oct 28 17:45:09 labserver avahi-daemon[9603]: avahi-daemon 0.6.22
starting up.
Oct 28 17:45:09 labserver avahi-daemon[9603]: Successfully called
chroot().
Oct 28 17:45:09 labserver avahi-daemon[9603]: Successfully dropped
remaining capabilities.
Oct 28 17:45:09 labserver avahi-daemon[9603]: No service file found
in /etc/avahi/services.
Oct 28 17:45:09 labserver avahi-daemon[9603]: Joining mDNS multicast
group on interface eth0.IPv4 with address 192.168.1.101.
Oct 28 17:45:09 labserver avahi-daemon[9603]: New relevant interface
eth0.IPv4 for mDNS.
Oct 28 17:45:09 labserver avahi-daemon[9603]: Network interface
enumeration completed.
Oct 28 17:45:09 labserver avahi-daemon[9603]: Registering new address
record for fe80::211:d8ff:fe33:766e on eth0.*.
Oct 28 17:45:09 labserver avahi-daemon[9603]: Registering new address
record for 192.168.1.101 on eth0.IPv4.
Oct 28 17:45:09 labserver avahi-daemon[9603]: Registering HINFO record
with values 'I686'/'LINUX'.
Oct 28 17:45:10 labserver avahi-daemon[9603]: Server startup complete.
Host name is labserver.local. Local service cookie is 3357143783.

This is despite the fact that I have these settings in /etc/avahi/
avahi-daemon.conf:

use-ipv4=true
use-ipv6=false
publish-a-on-ipv6=no

Having an ipv6 address published is causing timeouts from Macs. Is
there a way I can get avahi to stop publishing the ipv6 address?

Thanks!
_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Re: nss_mdns 0.10

2009-10-27T19:27:01Z

Dev,

On 28/10/2009, at 6:54 AM, dev nath wrote:

Hi *,

We were trying to use nss-mdns to support mdns query from the applications. We want to use "enable-legacy" option which has the mini MDNS stack. But in this mode nss-mdns supports resolving IPv6 addresses but does so via IPv4 multicasts only. Is there any reason why this is not supported on IPV6 packets.

IPv6 support was simply not coded into nss-mdns originally.

Since it was later replaced by the functionality to use Avahi - it is now deprecated and has not received any further work. Using the avahi backend is the recommended method for full support.

Regards,

Trent

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

nss_mdns 0.10

2009-10-27T15:54:54Z

Hi *,
 
We were trying to use nss-mdns to support mdns query from the applications. We want to use "enable-legacy" option which has the mini MDNS stack.  But in this mode nss-mdns supports resolving IPv6 addresses but does so via IPv4 multicasts only. Is there any reason why this is not supported on IPV6 packets. 
 
Please do comment.
 
Regards,
Dev

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Re: Resolving many ( > 200 ) items seems to lead to apparent congestion in the dbus

2009-10-18T06:31:50Z

lennart is really the only person that can respond to this since he
moved to git I no longer have direct commit access so he is the gate
keeper!

Trent

On 16/10/2009, at 3:03 PM, Daniel Wynne wrote:

> Hey Guys!
>
> Really dont want to be annoying, but it would be really nice if we
> could
> get at least one reliable statement from somebody responsible
> regarding
> the issue below.
>
> Thanx
>
> Daniel
>
>> Hi again!
>>
>> Is there anyone responsible available who is capable of answering my
>> previous question? Everybody on vacation? ;-)
>>
>> Kind Regards
>>
>> Daniel
>>
>>
>>
>> Daniel wrote:
>>
>>> Hi Folks,
>>>
>>> just returning from my summer vacation I reflected about past
>>> projects.
>>>
>>> Thereby I also wondered about our little conversation concerning
>>> Avahi
>>> cache sizes.
>>>
>>> Trent, you made those promising hints that you will loosen the
>>> strict
>>> limitations to meet requirements of larger network implementations.
>>>
>>> Could you, or any other responsible person please make a definite
>>> authorative statement about this issue so we can proceed with
>>> development?
>>> Me and my boss would be very appreciated about this ;-)
>>>
>>> Kind Regards
>>>
>>> Daniel
>>>
>>>
>>> Daniel wrote:
>>>
>>>
>>>> Hi Trent!
>>>>
>>>> These are great news for us! :-)
>>>> We were seriously concerned about the issue, that the Avahi mDNS
>>>> implementation prevented us from developing Linux camera management
>>>> applications for huge setups.
>>>>
>>>> In the following I provide a short calculation to give you a hint
>>>> of
>>>> what we need:
>>>>
>>>> - Right now we have setups with deployments of up to 800
>>>> devices We
>>>> do not think that deployments with even more devices in one
>>>> network make
>>>> sense, as this already can be considered as a individual
>>>> feasibility
>>>> study. But lets calculate with this worst case scenario and for
>>>> the sake
>>>> of convenience we even round it up to N = 1000 devices per network.
>>>>
>>>> - Since every device typically comes up with 2-3 ip addresses,
>>>> we
>>>> have to reserve cache entries for N*( 3 A's, 1 PTR, 1 SRV, 1
>>>> TXT. ) =>
>>>> AVAHI_CACHE_ENTRIES_MAX >= 6*N = 6000 entries.
>>>>
>>>> - As the dbus limitations are concerned the maximum number of
>>>> dbus
>>>> objects per client will have to be increased, too. Since we have to
>>>> create N*3 AddressRecordBrowsers, N*1 ServiceResolver, 1 Client, 2
>>>> ServiceBrowsers => OBJECTS_PER_CLIENT_MAX >= 4*N + 3 = 4003 ~
>>>> 4000 entries
>>>>
>>>> As I do not have that much insight into the Avahi-code there
>>>> might be
>>>> even more limits that might have to be adapted to achieve a
>>>> coherent
>>>> configuration.
>>>>
>>>> If you need any additional information, let me know.
>>>>
>>>> Thank you Guys for the great support so far!
>>>>
>>>> Kind Regards
>>>>
>>>> Daniel
>>>>
>>>>
>>>> Trent Lloyd wrote:
>>>>
>>>>
>>>>
>>>>> FWIW, I've always felt this was a little restrictive as well but
>>>>> never
>>>>> really ran into it in production.
>>>>>
>>>>> I am personally keen on upping them a little - Daniel, can you
>>>>> tell us
>>>>> what values seem to work well for you?
>>>>>
>>>>> Thanks,
>>>>> Trent
>>>>>
>>>>> On 27/06/2009, at 12:04 AM, Daniel Wynne wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hi Lennart!
>>>>>>
>>>>>> After a short interrupt I am back in avahi-business ;-)
>>>>>>
>>>>>> PLaying around a little bit with parameters I boiled it down to
>>>>>> AVAHI_CACHE_ENTRIES_MAX
>>>>>> OBJECTS_PER_CLIENT_MAX
>>>>>>
>>>>>> These Parameters are slightly tight I think when it comes to
>>>>>> bigger
>>>>>> networks i.e. more than 100 Services.
>>>>>>
>>>>>> You said these limitations are implemented to avoid misuse, i.e.
>>>>>> DOS-Attacks.
>>>>>>
>>>>>> Do you think it is possible in future releases of Avahi to loosen
>>>>>> these
>>>>>> limitations a little bit, to enable more comprehensive usage of
>>>>>> Avahi,
>>>>>> even for professional applications like ours ;-)
>>>>>> DOS Attacks are way above the limitations of 500, even way above
>>>>>> 5000. I
>>>>>> think when talking about DOS we are in millions and above.
>>>>>>
>>>>>> What do you say?
>>>>>>
>>>>>> Kind Regards
>>>>>>
>>>>>> Daniel
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, 2009-06-07 at 01:47 +0200, Lennart Poettering wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Thu, 28.05.09 13:43, Daniel Wynne (daniel.wynne@...)
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> But I think thats exactly the problem in our case. In our
>>>>>>>> Testnetwork
>>>>>>>> reside about 250 cameras we want to find and resolve via
>>>>>>>> Avahi. So
>>>>>>>> the
>>>>>>>> cache is way big enough.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> No. The limit of 500 entries in the cache that Avahi enforces
>>>>>>> is for
>>>>>>> RRs, not services or hosts.
>>>>>>>
>>>>>>> For each service you need (at least) one A, one PTR one SRV
>>>>>>> and one
>>>>>>> TXT RR. Usually even more. I.e. if you register 250 services
>>>>>>> and want
>>>>>>> to browser for them all at the same time you need as absolute
>>>>>>> minimum
>>>>>>> space for 1000 entries, and practically even more.
>>>>>>>
>>>>>>> Lennart
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> avahi mailing list
>>>>>> avahi@...
>>>>>> http://lists.freedesktop.org/mailman/listinfo/avahi
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> avahi mailing list
>>>>> avahi@...
>>>>> http://lists.freedesktop.org/mailman/listinfo/avahi
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> avahi mailing list
>>> avahi@...
>>> http://lists.freedesktop.org/mailman/listinfo/avahi
>>>
>>
>> _______________________________________________
>> avahi mailing list
>> avahi@...
>> http://lists.freedesktop.org/mailman/listinfo/avahi
>>
>
>
> --
> ---------------------------------------------------------------------
> Daniel Wynne, Softwareentwicklung
> MOBOTIX AG - Security Vision Systems
> Kaiserstrasse, 67722 Langmeil
> ---------------------------------------------------------------------
> daniel.wynne@..., http://www.mobotix.com
> ---------------------------------------------------------------------
> Vorstandvorsitzender: Dr. Ralf Hinkel
> Vorstandsmitglieder: Lutz Coelen
> Aufsichtsratsvorsitzender: Dr. Thomas Hoch
> Registergericht: HRB Kaiserslautern 3724
>
> _______________________________________________
> avahi mailing list
> avahi@...
> http://lists.freedesktop.org/mailman/listinfo/avahi
>

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Re: Resolving many ( > 200 ) items seems to lead to apparent congestion in the dbus

2009-10-16T00:03:11Z

Hey Guys!

Really dont want to be annoying, but it would be really nice if we could
get at least one reliable statement from somebody responsible regarding
the issue below.

Thanx

Daniel

> Hi again!
>
> Is there anyone responsible available who is capable of answering my
> previous question? Everybody on vacation? ;-)
>
> Kind Regards
>
> Daniel
>
>
>
> Daniel wrote:
>
>> Hi Folks,
>>
>> just returning from my summer vacation I reflected about past projects.
>>
>> Thereby I also wondered about our little conversation concerning Avahi
>> cache sizes.
>>
>> Trent, you made those promising hints that you will loosen the strict
>> limitations to meet requirements of larger network implementations.
>>
>> Could you, or any other responsible person please make a definite
>> authorative statement about this issue so we can proceed with development?
>> Me and my boss would be very appreciated about this ;-)
>>
>> Kind Regards
>>
>> Daniel
>>
>>
>> Daniel wrote:
>>
>>
>>> Hi Trent!
>>>
>>> These are great news for us! :-)
>>> We were seriously concerned about the issue, that the Avahi mDNS
>>> implementation prevented us from developing Linux camera management
>>> applications for huge setups.
>>>
>>> In the following I provide a short calculation to give you a hint of
>>> what we need:
>>>
>>> - Right now we have setups with deployments of up to 800 devices We
>>> do not think that deployments with even more devices in one network make
>>> sense, as this already can be considered as a individual feasibility
>>> study. But lets calculate with this worst case scenario and for the sake
>>> of convenience we even round it up to N = 1000 devices per network.
>>>
>>> - Since every device typically comes up with 2-3 ip addresses, we
>>> have to reserve cache entries for N*( 3 A's, 1 PTR, 1 SRV, 1 TXT. ) =>
>>> AVAHI_CACHE_ENTRIES_MAX >= 6*N = 6000 entries.
>>>
>>> - As the dbus limitations are concerned the maximum number of dbus
>>> objects per client will have to be increased, too. Since we have to
>>> create N*3 AddressRecordBrowsers, N*1 ServiceResolver, 1 Client, 2
>>> ServiceBrowsers => OBJECTS_PER_CLIENT_MAX >= 4*N + 3 = 4003 ~ 4000 entries
>>>
>>> As I do not have that much insight into the Avahi-code there might be
>>> even more limits that might have to be adapted to achieve a coherent
>>> configuration.
>>>
>>> If you need any additional information, let me know.
>>>
>>> Thank you Guys for the great support so far!
>>>
>>> Kind Regards
>>>
>>> Daniel
>>>
>>>
>>> Trent Lloyd wrote:
>>>
>>>
>>>
>>>> FWIW, I've always felt this was a little restrictive as well but never
>>>> really ran into it in production.
>>>>
>>>> I am personally keen on upping them a little - Daniel, can you tell us
>>>> what values seem to work well for you?
>>>>
>>>> Thanks,
>>>> Trent
>>>>
>>>> On 27/06/2009, at 12:04 AM, Daniel Wynne wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Hi Lennart!
>>>>>
>>>>> After a short interrupt I am back in avahi-business ;-)
>>>>>
>>>>> PLaying around a little bit with parameters I boiled it down to
>>>>> AVAHI_CACHE_ENTRIES_MAX
>>>>> OBJECTS_PER_CLIENT_MAX
>>>>>
>>>>> These Parameters are slightly tight I think when it comes to bigger
>>>>> networks i.e. more than 100 Services.
>>>>>
>>>>> You said these limitations are implemented to avoid misuse, i.e.
>>>>> DOS-Attacks.
>>>>>
>>>>> Do you think it is possible in future releases of Avahi to loosen
>>>>> these
>>>>> limitations a little bit, to enable more comprehensive usage of Avahi,
>>>>> even for professional applications like ours ;-)
>>>>> DOS Attacks are way above the limitations of 500, even way above
>>>>> 5000. I
>>>>> think when talking about DOS we are in millions and above.
>>>>>
>>>>> What do you say?
>>>>>
>>>>> Kind Regards
>>>>>
>>>>> Daniel
>>>>>
>>>>>
>>>>>
>>>>> On Sun, 2009-06-07 at 01:47 +0200, Lennart Poettering wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Thu, 28.05.09 13:43, Daniel Wynne (daniel.wynne@...)
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> But I think thats exactly the problem in our case. In our
>>>>>>> Testnetwork
>>>>>>> reside about 250 cameras we want to find and resolve via Avahi. So
>>>>>>> the
>>>>>>> cache is way big enough.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> No. The limit of 500 entries in the cache that Avahi enforces is for
>>>>>> RRs, not services or hosts.
>>>>>>
>>>>>> For each service you need (at least) one A, one PTR one SRV and one
>>>>>> TXT RR. Usually even more. I.e. if you register 250 services and want
>>>>>> to browser for them all at the same time you need as absolute minimum
>>>>>> space for 1000 entries, and practically even more.
>>>>>>
>>>>>> Lennart
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> avahi mailing list
>>>>> avahi@...
>>>>> http://lists.freedesktop.org/mailman/listinfo/avahi
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> avahi mailing list
>>>> avahi@...
>>>> http://lists.freedesktop.org/mailman/listinfo/avahi
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>> _______________________________________________
>> avahi mailing list
>> avahi@...
>> http://lists.freedesktop.org/mailman/listinfo/avahi
>>
>
> _______________________________________________
> avahi mailing list
> avahi@...
> http://lists.freedesktop.org/mailman/listinfo/avahi
>

--
---------------------------------------------------------------------
Daniel Wynne, Softwareentwicklung
MOBOTIX AG - Security Vision Systems
Kaiserstrasse, 67722 Langmeil
---------------------------------------------------------------------
daniel.wynne@..., http://www.mobotix.com
---------------------------------------------------------------------
Vorstandvorsitzender: Dr. Ralf Hinkel
Vorstandsmitglieder: Lutz Coelen
Aufsichtsratsvorsitzender: Dr. Thomas Hoch
Registergericht: HRB Kaiserslautern 3724

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Issue found in avahi-autoipd when running in default mode of operation.

2009-10-08T15:51:03Z

Hi,

I've found a bug when using avahi-autoipd in its default mode
of operation (as described on the AvahiAutoipd page in the Wiki):

If a routeable address is configured, avahi-autoipd goes to sleep without
configuring the interface, but it is still listening for ARP packets.
If an ARP packet is seen from the LL address it chose for itself
at start-up, it acts on this ARP as if there was a conflict and configures
the network interface with an LL address.

The following patch to main.c fixes this problem:

{{{
1267c1267,1280
< daemon_log(LOG_INFO, "Trying address %s", inet_ntop(AF_INET, &addr, buf, sizeof(buf)));
---
> if (state == STATE_SLEEPING)
> daemon_log(LOG_INFO, "Selected new address %s", inet_ntop(AF_INET, &addr, buf, sizeof(buf)));
> else {
> daemon_log(LOG_INFO, "Trying address %s", inet_ntop(AF_INET, &addr, buf, sizeof(buf)));
>
> n_conflict++;
>
> set_state(STATE_WAITING_PROBE, 1, addr);
>
> if (n_conflict >= MAX_CONFLICTS) {
> daemon_log(LOG_WARNING, "Got too many conflicts, rate limiting new probes.");
> elapse_time(&next_wakeup, RATE_LIMIT_INTERVAL*1000, PROBE_WAIT*1000);
> } else
> elapse_time(&next_wakeup, 0, PROBE_WAIT*1000);
1269,1279c1282,1283
< n_conflict++;
<
< set_state(STATE_WAITING_PROBE, 1, addr);
<
< if (n_conflict >= MAX_CONFLICTS) {
< daemon_log(LOG_WARNING, "Got too many conflicts, rate limiting new probes.");
< elapse_time(&next_wakeup, RATE_LIMIT_INTERVAL*1000, PROBE_WAIT*1000);
< } else
< elapse_time(&next_wakeup, 0, PROBE_WAIT*1000);
<
< next_wakeup_valid = 1;
---
> next_wakeup_valid = 1;
> }
}}}

Essentially, I'm just adding a state check right after a new address is selected. If sleeping, the new address is just logged and autoipd goes back to sleep, otherwise the conflict handling code that was there before is executed.

Thanks.

--JT

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Avahi object path in d-bus

2009-10-08T07:53:46Z

Hi

I need to connect to Avahi from php via d-bus.
I get the message:

Warning: dbusconnection::

sendwithreplyandblock():
dbus_connection_send_with_reply_and_block() failed (Launch helper exited
with unknown return code 255) in
....

When executing:

$m = new DBusMessage(DBUS_MESSAGE_TYPE_METHOD_CALL);
$m->setDestination("org.freedesktop.Avahi");
$m->setPath("/org/freedesktop/Avahi");
$m->setInterface("org.freedesktop.Avahi.Server");
$m->setMember("GetHostName");
$m->setAutoStart(true);

$r = $dbus->sendWithReplyAndBlock($m,3);

What is the correct object path Avahi(Server) is registered under, I get
the same error with different pathes
including /org/freedesktop/Avahi/Server .
I set the property 'enable-dbus=yes' in avahi-daemon.conf, and I have created a .service file
/usr/share/dbus-1/services/org.freedesktop.Avahi.service
contaning:

[D-BUS Service]
Name=org.freedesktop.Avahi
Exec=/usr/sbin/avahi-daemon
User=root

It solved the problem of destination, but maybe the problem is there?

Hopefully thanks from Morten Telling Nielsen.

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Re: Packets larger than MTU

2009-10-07T07:04:31Z

In the Sugarlabs project (sugar-presence-service), public keys are
published by with multiple key/value pairs.

For example
<key-part-1, first 100 bytes>
<key-part-2, second 100 bytes>
...

Kind Regards
--Thomas

On Wed, Oct 7, 2009 at 3:19 PM, Jakob Blomer <jakob.blomer@...> wrote:

> Hi,
>
> I am trying to (mis)use the txt record to publish a global configuration
> file together with a service, basically key value pairs that usually
> reside in /etc/...
>
> For publishing, I use (a slightly modified) avahi-publish utility and
> add strings linewise to the txt record. It seems that if the packet
> size exceeds the MTU, the txt record is cut off. I played around a
> little and hard coded the MTU to a high value.
>
> Though this seems to work, even with unmodified Avahi instances on
> receiver side, I'm wondering if there is a more elegant way of
> publishing big records. In particular, being able to publish arbitrary
> large records would be helpful.
>
> Cheers,
> Jakob
> _______________________________________________
> avahi mailing list
> avahi@...
> http://lists.freedesktop.org/mailman/listinfo/avahi
>

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Packets larger than MTU

2009-10-07T06:19:13Z

Hi,

I am trying to (mis)use the txt record to publish a global configuration
file together with a service, basically key value pairs that usually
reside in /etc/...

For publishing, I use (a slightly modified) avahi-publish utility and
add strings linewise to the txt record. It seems that if the packet
size exceeds the MTU, the txt record is cut off. I played around a
little and hard coded the MTU to a high value.

Though this seems to work, even with unmodified Avahi instances on
receiver side, I'm wondering if there is a more elegant way of
publishing big records. In particular, being able to publish arbitrary
large records would be helpful.

Cheers,
Jakob
_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Services not registered when DHCP request occurs during avahi-daemon start-up

2009-10-05T03:09:53Z

I'm using avahi 0.6.25 with OpenWrt (Linux kernel 2.6.30.7, busybox 1.13.4) on a PowerPC custom board with 2 Ethernet ports.

I have a problem a boot time if a configure one of the 2 Ethernet ports to get it's IP address with DHCP.
What I see is that if the DHCP client (udhcpc from busybox) gets the IP address while the avahi-daemon is starting, the services are never published by avahi.

With the exact same set-up if I configure both Ethernet ports with static IP addresses the services are published correctly.

The problem can be seen in the following logs. The first one is missing the 3 following lines:
Oct 1 08:51:11 E106926 daemon.info avahi-daemon[855]: Service "VM XMC16 [E106926]" (/etc/avahi/services/xnp-sysconfig.service) successfully established.
Oct 1 08:51:11 E106926 daemon.info avahi-daemon[855]: Service "Secure Shell on E106926" (/etc/avahi/services/ssh.service) successfully established.
Oct 1 08:51:11 E106926 daemon.info avahi-daemon[855]: Service "Web Server on E106926" (/etc/avahi/services/http.service) successfully established.

Here is a log of the boot with eth0 set-up with DHCP and eth1 using a static IP address, showing the problem:
root@E106926:~# logread
Jan 1 01:00:05 E106926 user.debug kernel: pci 0000:00:00.0: reg 18 64bit mmio: [0x000000-0x3fffffff]
Jan 1 01:00:05 E106926 user.debug kernel: pci_bus 0000:00: resource 0 io: [0x00-0xffffff]
Jan 1 01:00:05 E106926 user.debug kernel: pci_bus 0000:00: resource 1 pref mem [0x80000000-0x8fffffff]
Jan 1 01:00:05 E106926 user.debug kernel: pci_bus 0000:00: resource 2 mem: [0x90000000-0x9fffffff]
Jan 1 01:00:05 E106926 user.debug kernel: Registering ipic with sysfs...
Jan 1 01:00:05 E106926 user.warn kernel: bio: create slab <bio-0> at 0
Jan 1 01:00:05 E106926 user.notice kernel: SCSI subsystem initialized
Jan 1 01:00:05 E106926 user.info kernel: usbcore: registered new interface driver usbfs
Jan 1 01:00:05 E106926 user.info kernel: usbcore: registered new interface driver hub
Jan 1 01:00:05 E106926 user.info kernel: usbcore: registered new device driver usb
Jan 1 01:00:05 E106926 user.info kernel: NET: Registered protocol family 2
Jan 1 01:00:05 E106926 user.debug kernel: Switched to high resolution mode on CPU 0
Jan 1 01:00:05 E106926 user.info kernel: IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
Jan 1 01:00:05 E106926 user.info kernel: TCP established hash table entries: 4096 (order: 3, 32768 bytes)
Jan 1 01:00:05 E106926 user.info kernel: TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
Jan 1 01:00:05 E106926 user.info kernel: TCP: Hash tables configured (established 4096 bind 4096)
Jan 1 01:00:05 E106926 user.info kernel: TCP reno registered
Jan 1 01:00:05 E106926 user.info kernel: NET: Registered protocol family 1
Jan 1 01:00:05 E106926 user.debug kernel: irq: irq 9 on host /soc8349@e0000000/pic@700 mapped to virtual irq 16
Jan 1 01:00:05 E106926 user.debug kernel: irq: irq 10 on host /soc8349@e0000000/pic@700 mapped to virtual irq 17
Jan 1 01:00:05 E106926 user.info kernel: WDT driver for MPC8xxx initialized. mode:reset timeout=65535 (13 seconds)
Jan 1 01:00:05 E106926 user.info kernel: Freescale PowerQUICC MII Bus: probed
Jan 1 01:00:05 E106926 user.info kernel: squashfs: version 4.0 (2009/01/31) Phillip Lougher
Jan 1 01:00:05 E106926 user.warn kernel: Registering mini_fo version $Id$
Jan 1 01:00:05 E106926 user.info kernel: JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
Jan 1 01:00:05 E106926 user.info kernel: msgmni has been set to 246
Jan 1 01:00:05 E106926 user.info kernel: alg: No test for lzma (lzma-generic)
Jan 1 01:00:05 E106926 user.info kernel: alg: No test for stdrng (krng)
Jan 1 01:00:05 E106926 user.info kernel: io scheduler noop registered
Jan 1 01:00:05 E106926 user.info kernel: io scheduler anticipatory registered (default)
Jan 1 01:00:05 E106926 user.info kernel: io scheduler deadline registered
Jan 1 01:00:05 E106926 user.info kernel: io scheduler cfq registered
Jan 1 01:00:05 E106926 user.info kernel: pci_hotplug: PCI Hot Plug PCI Core version: 0.5
Jan 1 01:00:05 E106926 user.info kernel: Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
Jan 1 01:00:05 E106926 user.info kernel: serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
Jan 1 01:00:05 E106926 user.info kernel: console handover: boot [udbg0] -> real [ttyS0]
Jan 1 01:00:05 E106926 user.info kernel: serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A
Jan 1 01:00:05 E106926 user.info kernel: brd: module loaded
Jan 1 01:00:05 E106926 user.info kernel: loop: module loaded
Jan 1 01:00:05 E106926 user.warn kernel: Driver 'sd' needs updating - please use bus_type methods
Jan 1 01:00:05 E106926 user.debug kernel: irq: irq 32 on host /soc8349@e0000000/pic@700 mapped to virtual irq 32
Jan 1 01:00:05 E106926 user.debug kernel: irq: irq 33 on host /soc8349@e0000000/pic@700 mapped to virtual irq 33
Jan 1 01:00:05 E106926 user.debug kernel: irq: irq 34 on host /soc8349@e0000000/pic@700 mapped to virtual irq 34
Jan 1 01:00:05 E106926 user.info kernel: eth0: Gianfar Ethernet Controller Version 1.2, 00:1e:63:00:00:27
Jan 1 01:00:05 E106926 user.info kernel: eth0: Running with NAPI enabled
Jan 1 01:00:05 E106926 user.info kernel: eth0: 256/256 RX/TX BD ring size
Jan 1 01:00:05 E106926 user.debug kernel: irq: irq 35 on host /soc8349@e0000000/pic@700 mapped to virtual irq 35
Jan 1 01:00:05 E106926 user.debug kernel: irq: irq 36 on host /soc8349@e0000000/pic@700 mapped to virtual irq 36
Jan 1 01:00:05 E106926 user.debug kernel: irq: irq 37 on host /soc8349@e0000000/pic@700 mapped to virtual irq 37
Jan 1 01:00:05 E106926 user.info kernel: eth1: Gianfar Ethernet Controller Version 1.2, 00:1e:63:00:00:26
Jan 1 01:00:05 E106926 user.info kernel: eth1: Running with NAPI enabled
Jan 1 01:00:05 E106926 user.info kernel: eth1: 256/256 RX/TX BD ring size
Jan 1 01:00:05 E106926 user.err kernel: Error: Driver 'Marvell 88E1118' is already registered, aborting...
Jan 1 01:00:05 E106926 user.err kernel: Marvell 88E1118: Error -17 in registering driver
Jan 1 01:00:05 E106926 user.warn kernel: UIO: Starting MPC834x GPIO driver
Jan 1 01:00:05 E106926 user.info kernel: fe000000.flash: Found 1 x16 devices at 0x0 in 16-bit bank
Jan 1 01:00:05 E106926 user.warn kernel: Amd/Fujitsu Extended Query Table at 0x0040
Jan 1 01:00:05 E106926 user.warn kernel: fe000000.flash: CFI does not contain boot bank location. Assuming top.
Jan 1 01:00:05 E106926 user.notice kernel: number of CFI chips: 1
Jan 1 01:00:05 E106926 user.notice kernel: cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Jan 1 01:00:05 E106926 user.notice kernel: cmdlinepart partition parsing not available
Jan 1 01:00:05 E106926 user.notice kernel: RedBoot partition parsing not available
Jan 1 01:00:05 E106926 user.notice kernel: Creating 5 MTD partitions on "fe000000.flash":
Jan 1 01:00:05 E106926 user.notice kernel: 0x000000000000-0x000000060000 : "loader"
Jan 1 01:00:05 E106926 user.notice kernel: 0x000000060000-0x000000080000 : "loader_cfg"
Jan 1 01:00:05 E106926 user.notice kernel: 0x000000080000-0x0000000a0000 : "dtb"
Jan 1 01:00:05 E106926 user.notice kernel: 0x0000000a0000-0x0000002a0000 : "kernel"
Jan 1 01:00:05 E106926 user.notice kernel: 0x0000002a0000-0x000002000000 : "rootfs"
Jan 1 01:00:05 E106926 user.notice kernel: mtd: partition "rootfs" set to be root filesystem
Jan 1 01:00:05 E106926 user.info kernel: mtd: partition "rootfs_data" created automatically, ofs=4C0000, len=1B40000
Jan 1 01:00:05 E106926 user.notice kernel: 0x0000004c0000-0x000002000000 : "rootfs_data"
Jan 1 01:00:05 E106926 user.debug kernel: irq: irq 16 on host /soc8349@e0000000/pic@700 mapped to virtual irq 18
Jan 1 01:00:05 E106926 user.info kernel: e0007000.spi: MPC83xx SPI Controller driver at 0x890f8000 (irq = 18)
Jan 1 01:00:05 E106926 user.info kernel: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
Jan 1 01:00:05 E106926 user.info kernel: fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
Jan 1 01:00:05 E106926 user.info kernel: fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
Jan 1 01:00:05 E106926 user.info kernel: fsl-ehci fsl-ehci.0: irq 38, io base 0xe0023000
Jan 1 01:00:05 E106926 user.info kernel: fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
Jan 1 01:00:05 E106926 user.info kernel: usb usb1: configuration #1 chosen from 1 choice
Jan 1 01:00:05 E106926 user.info kernel: hub 1-0:1.0: USB hub found
Jan 1 01:00:05 E106926 user.info kernel: hub 1-0:1.0: 1 port detected
Jan 1 01:00:05 E106926 user.info kernel: ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
Jan 1 01:00:05 E106926 user.info kernel: uhci_hcd: USB Universal Host Controller Interface driver
Jan 1 01:00:05 E106926 user.info kernel: Initializing USB Mass Storage driver...
Jan 1 01:00:05 E106926 user.info kernel: usbcore: registered new interface driver usb-storage
Jan 1 01:00:05 E106926 user.info kernel: USB Mass Storage support registered.
Jan 1 01:00:05 E106926 user.info kernel: i2c /dev entries driver
Jan 1 01:00:05 E106926 user.debug kernel: irq: irq 14 on host /soc8349@e0000000/pic@700 mapped to virtual irq 19
Jan 1 01:00:05 E106926 user.debug kernel: irq: irq 15 on host /soc8349@e0000000/pic@700 mapped to virtual irq 20
Jan 1 01:00:05 E106926 user.info kernel: TCP cubic registered
Jan 1 01:00:05 E106926 user.info kernel: NET: Registered protocol family 17
Jan 1 01:00:05 E106926 user.info kernel: RPC: Registered udp transport module.
Jan 1 01:00:05 E106926 user.info kernel: RPC: Registered tcp transport module.
Jan 1 01:00:05 E106926 user.warn kernel: VFS: Mounted root (squashfs filesystem) readonly on device 31:4.
Jan 1 01:00:05 E106926 user.warn kernel: Freeing unused kernel memory: 168k init
Jan 1 01:00:05 E106926 user.warn kernel: Please be patient, while OpenWrt loads ...
Jan 1 01:00:05 E106926 user.info kernel: mini_fo: using base directory: /
Jan 1 01:00:05 E106926 user.info kernel: mini_fo: using storage directory: /jffs
Jan 1 01:00:05 E106926 user.info sysinit: udhcpc (v1.13.4) started
Jan 1 01:00:05 E106926 user.info sysinit: Sending discover...
Jan 1 01:00:07 E106926 user.info sysinit: Firmware upgrate daemon starting...
Jan 1 01:00:07 E106926 user.info sysinit: SVN revision: 1810
Jan 1 01:00:07 E106926 user.info sysinit: Process is now running as a daemon
Jan 1 01:00:07 E106926 user.info sysinit: /tmp/upgrade successfully created
Jan 1 01:00:07 E106926 user.info sysinit: Working directory successfully changed to /tmp/upgrade
Jan 1 01:00:07 E106926 user.info kernel: PHY: mdio@e0024520:01 - Link is Up - 1000/Full
Jan 1 01:00:07 E106926 user.info sysinit: Stream socket (3) successfully created
Jan 1 01:00:07 E106926 user.info sysinit: Stream socket (4) successfully created
Jan 1 01:00:07 E106926 user.info sysinit: Server socket options successfully set
Jan 1 01:00:07 E106926 user.info sysinit: Bind() was successful
Jan 1 01:00:07 E106926 user.info sysinit: Listen on port 50003 was successful
Jan 1 01:00:07 E106926 user.info sysinit: Datagram socket (5) successfully created
Jan 1 01:00:07 E106926 user.info sysinit: Server socket options successfully set
Jan 1 01:00:07 E106926 user.info sysinit: Bind() was successful
Jan 1 01:00:07 E106926 user.info sysinit: BindToDevice (eth0) was successful
Jan 1 01:00:07 E106926 user.info sysinit: Datagram socket (6) successfully created
Jan 1 01:00:07 E106926 user.info sysinit: Server socket options successfully set
Jan 1 01:00:07 E106926 user.info sysinit: Bind() was successful
Jan 1 01:00:07 E106926 user.info sysinit: BindToDevice (eth1) was successful
Jan 1 01:00:07 E106926 user.info sysinit: recv() FAILED: Transport endpoint is not connected
Jan 1 01:00:07 E106926 user.info sysinit: Socket (3) successfully closed
Jan 1 01:00:07 E106926 user.info kernel: PHY: mdio@e0024520:02 - Link is Up - 1000/Full
Jan 1 01:00:08 E106926 daemon.info avahi-daemon[855]: Found user 'nobody' (UID 65534) and group 'nogroup' (GID 65534).
Jan 1 01:00:08 E106926 daemon.info avahi-daemon[855]: Successfully dropped root privileges.
Jan 1 01:00:08 E106926 daemon.info avahi-daemon[855]: avahi-daemon 0.6.25 starting up.
Jan 1 01:00:08 E106926 daemon.warn avahi-daemon[855]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Jan 1 01:00:08 E106926 daemon.info avahi-daemon[855]: Loading service file /etc/avahi/services/http.service.
Jan 1 01:00:08 E106926 daemon.info avahi-daemon[855]: Loading service file /etc/avahi/services/ssh.service.
Jan 1 01:00:08 E106926 daemon.info avahi-daemon[855]: Loading service file /etc/avahi/services/xnp-sysconfig.service.
Jan 1 01:00:08 E106926 daemon.info avahi-daemon[855]: Joining mDNS multicast group on interface eth1.IPv4 with address 10.10.52.195.
Jan 1 01:00:08 E106926 daemon.info avahi-daemon[855]: New relevant interface eth1.IPv4 for mDNS.
Jan 1 01:00:08 E106926 daemon.info avahi-daemon[855]: Network interface enumeration completed.
Jan 1 01:00:08 E106926 daemon.info avahi-daemon[855]: Registering new address record for 10.10.52.195 on eth1.IPv4.
Jan 1 01:00:08 E106926 daemon.info avahi-daemon[855]: Registering HINFO record with values 'PPC'/'LINUX'.
Jan 1 01:00:08 E106926 authpriv.info dropbear[865]: Running in background
Oct 1 09:35:52 E106926 daemon.notice ntpdate[882]: step time server 10.10.2.110 offset 1254382543.344729 sec
Oct 1 09:35:52 E106926 daemon.info avahi-daemon[855]: Server startup complete. Host name is E106926.local. Local service cookie is 3422980960.
Oct 1 09:35:52 E106926 user.info sysinit: Sending discover...
Oct 1 09:35:52 E106926 user.info sysinit: Sending select for 10.10.21.103...
Oct 1 09:35:52 E106926 user.info sysinit: Lease of 10.10.21.103 obtained, lease time 432000
Oct 1 09:35:52 E106926 daemon.notice ntpd[884]: ntpd 4.2.4p7@... Wed Sep 30 10:35:54 UTC 2009 (1)
Oct 1 09:35:52 E106926 daemon.info ntpd[892]: precision = 0.751 usec
Oct 1 09:35:52 E106926 daemon.debug ntpd[892]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
Oct 1 09:35:52 E106926 daemon.info ntpd[892]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Oct 1 09:35:52 E106926 daemon.info ntpd[892]: Listening on interface #1 lo, 127.0.0.1#123 Enabled
Oct 1 09:35:52 E106926 daemon.info ntpd[892]: Listening on interface #2 eth1, 10.10.52.195#123 Enabled
Oct 1 09:35:52 E106926 daemon.info ntpd[892]: kernel time sync status 0040
Oct 1 09:35:52 E106926 user.info sysinit: udhcpc: ifconfig eth0 10.10.21.103 netmask 255.255.0.0 broadcast +
Oct 1 09:35:52 E106926 daemon.info avahi-daemon[855]: Joining mDNS multicast group on interface eth0.IPv4 with address 10.10.21.103.
Oct 1 09:35:52 E106926 daemon.info avahi-daemon[855]: New relevant interface eth0.IPv4 for mDNS.
Oct 1 09:35:52 E106926 daemon.info avahi-daemon[855]: Registering new address record for 10.10.21.103 on eth0.IPv4.
Oct 1 09:35:52 E106926 daemon.info avahi-daemon[855]: Withdrawing address record for 10.10.21.103 on eth0.
Oct 1 09:35:52 E106926 daemon.info avahi-daemon[855]: Leaving mDNS multicast group on interface eth0.IPv4 with address 10.10.21.103.
Oct 1 09:35:52 E106926 daemon.info avahi-daemon[855]: Interface eth0.IPv4 no longer relevant for mDNS.
Oct 1 09:35:52 E106926 daemon.info avahi-daemon[855]: Joining mDNS multicast group on interface eth0.IPv4 with address 10.10.21.103.
Oct 1 09:35:52 E106926 daemon.info avahi-daemon[855]: New relevant interface eth0.IPv4 for mDNS.
Oct 1 09:35:52 E106926 daemon.info avahi-daemon[855]: Registering new address record for 10.10.21.103 on eth0.IPv4.
Oct 1 09:35:52 E106926 user.info sysinit: udhcpc: setting default routers: 10.10.1.254
Oct 1 09:35:52 E106926 user.info sysinit: watchdog: WDIOC_SETTIMEOUT: Inappropriate ioctl for device
Oct 1 09:35:52 E106926 user.info sysinit: udhcpc: setting dns servers: 10.10.2.100 10.10.2.101
Oct 1 09:35:52 E106926 user.info sysinit: sysctl: error: 'net.netfilter.nf_conntrack_checksum' is an unknown key
Oct 1 09:35:52 E106926 user.info sysinit: sysctl: error: 'net.ipv4.netfilter.ip_conntrack_checksum' is an unknown key
Oct 1 09:35:52 E106926 user.info sysinit: sysctl: error: 'net.ipv4.netfilter.ip_conntrack_max' is an unknown key
Oct 1 09:35:52 E106926 user.info sysinit: sysctl: error: 'net.ipv4.netfilter.ip_conntrack_tcp_timeout_established' is an unknown key
Oct 1 09:35:52 E106926 user.info sysinit: sysctl: error: 'net.ipv4.netfilter.ip_conntrack_udp_timeout' is an unknown key
Oct 1 09:35:52 E106926 user.info sysinit: sysctl: error: 'net.ipv4.netfilter.ip_conntrack_udp_timeout_stream' is an unknown key
Oct 1 09:35:53 E106926 daemon.info ntpd[892]: Listening on interface #3 eth0, 10.10.21.103#123 Enabled
Oct 1 09:35:53 E106926 daemon.debug ntpd[892]: new interface(s) found: waking up resolver
Oct 1 09:35:59 E106926 daemon.info ntpd[892]: synchronized to 10.10.2.110, stratum 5
Oct 1 09:35:59 E106926 daemon.notice ntpd[892]: kernel time sync status change 0001
Oct 1 09:36:00 E106926 daemon.info init: starting pid 673, tty '/dev/ttyS0': '/bin/ash --login'
Oct 1 09:36:49 E106926 authpriv.info dropbear[912]: Child connection from 10.10.21.231:2279
Oct 1 09:36:51 E106926 authpriv.notice dropbear[912]: password auth succeeded for 'root' from 10.10.21.231:2279

#########################################################################################

Here is a log of the boot with eth0 set-up with DHCP and eth1 using a static IP address, showing the problem:
root@E106926:~# logread
Jan 1 01:00:05 E106926 user.debug kernel: High memory: 0k
Jan 1 01:00:05 E106926 user.info kernel: Memory: 126164k/131072k available (3272k kernel code, 4744k reserved, 160k data, 110k bss, 168k init)
Jan 1 01:00:05 E106926 user.info kernel: Kernel virtual memory layout:
Jan 1 01:00:05 E106926 user.info kernel: * 0xfffef000..0xfffff000 : fixmap
Jan 1 01:00:05 E106926 user.info kernel: * 0xff800000..0xffc00000 : highmem PTEs
Jan 1 01:00:05 E106926 user.info kernel: * 0xfe7fa000..0xff800000 : early ioremap
Jan 1 01:00:05 E106926 user.info kernel: * 0x89000000..0xfe7fa000 : vmalloc & ioremap
Jan 1 01:00:05 E106926 user.info kernel: SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Jan 1 01:00:05 E106926 user.info kernel: Calibrating delay loop... 164.86 BogoMIPS (lpj=329728)
Jan 1 01:00:05 E106926 user.warn kernel: Mount-cache hash table entries: 512
Jan 1 01:00:05 E106926 user.info kernel: net_namespace: 324 bytes
Jan 1 01:00:05 E106926 user.info kernel: NET: Registered protocol family 16
Jan 1 01:00:05 E106926 user.debug kernel: irq: irq 38 on host /soc8349@e0000000/pic@700 mapped to virtual irq 38
Jan 1 01:00:05 E106926 user.info kernel: PCI: Probing PCI hardware
Jan 1 01:00:05 E106926 user.debug kernel: pci 0000:00:00.0: reg 10 32bit mmio: [0x000000-0x0fffff]
Jan 1 01:00:05 E106926 user.debug kernel: pci 0000:00:00.0: reg 18 64bit mmio: [0x000000-0x3fffffff]
Jan 1 01:00:05 E106926 user.debug kernel: pci_bus 0000:00: resource 0 io: [0x00-0xffffff]
Jan 1 01:00:05 E106926 user.debug kernel: pci_bus 0000:00: resource 1 pref mem [0x80000000-0x8fffffff]
Jan 1 01:00:05 E106926 user.debug kernel: pci_bus 0000:00: resource 2 mem: [0x90000000-0x9fffffff]
Jan 1 01:00:05 E106926 user.debug kernel: Registering ipic with sysfs...
Jan 1 01:00:05 E106926 user.warn kernel: bio: create slab <bio-0> at 0
Jan 1 01:00:05 E106926 user.notice kernel: SCSI subsystem initialized
Jan 1 01:00:05 E106926 user.info kernel: usbcore: registered new interface driver usbfs
Jan 1 01:00:05 E106926 user.info kernel: usbcore: registered new interface driver hub
Jan 1 01:00:05 E106926 user.info kernel: usbcore: registered new device driver usb
Jan 1 01:00:05 E106926 user.info kernel: NET: Registered protocol family 2
Jan 1 01:00:05 E106926 user.debug kernel: Switched to high resolution mode on CPU 0
Jan 1 01:00:05 E106926 user.info kernel: IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
Jan 1 01:00:05 E106926 user.info kernel: TCP established hash table entries: 4096 (order: 3, 32768 bytes)
Jan 1 01:00:05 E106926 user.info kernel: TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
Jan 1 01:00:05 E106926 user.info kernel: TCP: Hash tables configured (established 4096 bind 4096)
Jan 1 01:00:05 E106926 user.info kernel: TCP reno registered
Jan 1 01:00:05 E106926 user.info kernel: NET: Registered protocol family 1
Jan 1 01:00:05 E106926 user.debug kernel: irq: irq 9 on host /soc8349@e0000000/pic@700 mapped to virtual irq 16
Jan 1 01:00:05 E106926 user.debug kernel: irq: irq 10 on host /soc8349@e0000000/pic@700 mapped to virtual irq 17
Jan 1 01:00:05 E106926 user.info kernel: WDT driver for MPC8xxx initialized. mode:reset timeout=65535 (13 seconds)
Jan 1 01:00:05 E106926 user.info kernel: Freescale PowerQUICC MII Bus: probed
Jan 1 01:00:05 E106926 user.info kernel: squashfs: version 4.0 (2009/01/31) Phillip Lougher
Jan 1 01:00:05 E106926 user.warn kernel: Registering mini_fo version $Id$
Jan 1 01:00:05 E106926 user.info kernel: JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
Jan 1 01:00:05 E106926 user.info kernel: msgmni has been set to 246
Jan 1 01:00:05 E106926 user.info kernel: alg: No test for lzma (lzma-generic)
Jan 1 01:00:05 E106926 user.info kernel: alg: No test for stdrng (krng)
Jan 1 01:00:05 E106926 user.info kernel: io scheduler noop registered
Jan 1 01:00:05 E106926 user.info kernel: io scheduler anticipatory registered (default)
Jan 1 01:00:05 E106926 user.info kernel: io scheduler deadline registered
Jan 1 01:00:05 E106926 user.info kernel: io scheduler cfq registered
Jan 1 01:00:05 E106926 user.info kernel: pci_hotplug: PCI Hot Plug PCI Core version: 0.5
Jan 1 01:00:05 E106926 user.info kernel: Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
Jan 1 01:00:05 E106926 user.info kernel: serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
Jan 1 01:00:05 E106926 user.info kernel: console handover: boot [udbg0] -> real [ttyS0]
Jan 1 01:00:05 E106926 user.info kernel: serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A
Jan 1 01:00:05 E106926 user.info kernel: brd: module loaded
Jan 1 01:00:05 E106926 user.info kernel: loop: module loaded
Jan 1 01:00:05 E106926 user.warn kernel: Driver 'sd' needs updating - please use bus_type methods
Jan 1 01:00:05 E106926 user.debug kernel: irq: irq 32 on host /soc8349@e0000000/pic@700 mapped to virtual irq 32
Jan 1 01:00:05 E106926 user.debug kernel: irq: irq 33 on host /soc8349@e0000000/pic@700 mapped to virtual irq 33
Jan 1 01:00:05 E106926 user.debug kernel: irq: irq 34 on host /soc8349@e0000000/pic@700 mapped to virtual irq 34
Jan 1 01:00:05 E106926 user.info kernel: eth0: Gianfar Ethernet Controller Version 1.2, 00:1e:63:00:00:27
Jan 1 01:00:05 E106926 user.info kernel: eth0: Running with NAPI enabled
Jan 1 01:00:05 E106926 user.info kernel: eth0: 256/256 RX/TX BD ring size
Jan 1 01:00:05 E106926 user.debug kernel: irq: irq 35 on host /soc8349@e0000000/pic@700 mapped to virtual irq 35
Jan 1 01:00:05 E106926 user.debug kernel: irq: irq 36 on host /soc8349@e0000000/pic@700 mapped to virtual irq 36
Jan 1 01:00:05 E106926 user.debug kernel: irq: irq 37 on host /soc8349@e0000000/pic@700 mapped to virtual irq 37
Jan 1 01:00:05 E106926 user.info kernel: eth1: Gianfar Ethernet Controller Version 1.2, 00:1e:63:00:00:26
Jan 1 01:00:05 E106926 user.info kernel: eth1: Running with NAPI enabled
Jan 1 01:00:05 E106926 user.info kernel: eth1: 256/256 RX/TX BD ring size
Jan 1 01:00:05 E106926 user.err kernel: Error: Driver 'Marvell 88E1118' is already registered, aborting...
Jan 1 01:00:05 E106926 user.err kernel: Marvell 88E1118: Error -17 in registering driver
Jan 1 01:00:05 E106926 user.warn kernel: UIO: Starting MPC834x GPIO driver
Jan 1 01:00:05 E106926 user.info kernel: fe000000.flash: Found 1 x16 devices at 0x0 in 16-bit bank
Jan 1 01:00:05 E106926 user.warn kernel: Amd/Fujitsu Extended Query Table at 0x0040
Jan 1 01:00:05 E106926 user.warn kernel: fe000000.flash: CFI does not contain boot bank location. Assuming top.
Jan 1 01:00:05 E106926 user.notice kernel: number of CFI chips: 1
Jan 1 01:00:05 E106926 user.notice kernel: cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Jan 1 01:00:05 E106926 user.notice kernel: cmdlinepart partition parsing not available
Jan 1 01:00:05 E106926 user.notice kernel: RedBoot partition parsing not available
Jan 1 01:00:05 E106926 user.notice kernel: Creating 5 MTD partitions on "fe000000.flash":
Jan 1 01:00:05 E106926 user.notice kernel: 0x000000000000-0x000000060000 : "loader"
Jan 1 01:00:05 E106926 user.notice kernel: 0x000000060000-0x000000080000 : "loader_cfg"
Jan 1 01:00:05 E106926 user.notice kernel: 0x000000080000-0x0000000a0000 : "dtb"
Jan 1 01:00:05 E106926 user.notice kernel: 0x0000000a0000-0x0000002a0000 : "kernel"
Jan 1 01:00:05 E106926 user.notice kernel: 0x0000002a0000-0x000002000000 : "rootfs"
Jan 1 01:00:05 E106926 user.notice kernel: mtd: partition "rootfs" set to be root filesystem
Jan 1 01:00:05 E106926 user.info kernel: mtd: partition "rootfs_data" created automatically, ofs=4C0000, len=1B40000
Jan 1 01:00:05 E106926 user.notice kernel: 0x0000004c0000-0x000002000000 : "rootfs_data"
Jan 1 01:00:05 E106926 user.debug kernel: irq: irq 16 on host /soc8349@e0000000/pic@700 mapped to virtual irq 18
Jan 1 01:00:05 E106926 user.info kernel: e0007000.spi: MPC83xx SPI Controller driver at 0x890f8000 (irq = 18)
Jan 1 01:00:05 E106926 user.info kernel: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
Jan 1 01:00:05 E106926 user.info kernel: fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
Jan 1 01:00:05 E106926 user.info kernel: fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
Jan 1 01:00:05 E106926 user.info kernel: fsl-ehci fsl-ehci.0: irq 38, io base 0xe0023000
Jan 1 01:00:05 E106926 user.info kernel: fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
Jan 1 01:00:05 E106926 user.info kernel: usb usb1: configuration #1 chosen from 1 choice
Jan 1 01:00:05 E106926 user.info kernel: hub 1-0:1.0: USB hub found
Jan 1 01:00:05 E106926 user.info kernel: hub 1-0:1.0: 1 port detected
Jan 1 01:00:05 E106926 user.info kernel: ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
Jan 1 01:00:05 E106926 user.info kernel: uhci_hcd: USB Universal Host Controller Interface driver
Jan 1 01:00:05 E106926 user.info kernel: Initializing USB Mass Storage driver...
Jan 1 01:00:05 E106926 user.info kernel: usbcore: registered new interface driver usb-storage
Jan 1 01:00:05 E106926 user.info kernel: USB Mass Storage support registered.
Jan 1 01:00:05 E106926 user.info kernel: i2c /dev entries driver
Jan 1 01:00:05 E106926 user.debug kernel: irq: irq 14 on host /soc8349@e0000000/pic@700 mapped to virtual irq 19
Jan 1 01:00:05 E106926 user.debug kernel: irq: irq 15 on host /soc8349@e0000000/pic@700 mapped to virtual irq 20
Jan 1 01:00:05 E106926 user.info kernel: TCP cubic registered
Jan 1 01:00:05 E106926 user.info kernel: NET: Registered protocol family 17
Jan 1 01:00:05 E106926 user.info kernel: RPC: Registered udp transport module.
Jan 1 01:00:05 E106926 user.info kernel: RPC: Registered tcp transport module.
Jan 1 01:00:05 E106926 user.warn kernel: VFS: Mounted root (squashfs filesystem) readonly on device 31:4.
Jan 1 01:00:05 E106926 user.warn kernel: Freeing unused kernel memory: 168k init
Jan 1 01:00:05 E106926 user.warn kernel: Please be patient, while OpenWrt loads ...
Jan 1 01:00:05 E106926 user.info kernel: mini_fo: using base directory: /
Jan 1 01:00:05 E106926 user.info kernel: mini_fo: using storage directory: /jffs
Jan 1 01:00:05 E106926 user.info sysinit: udhcpc (v1.13.4) started
Jan 1 01:00:05 E106926 user.info sysinit: Sending discover...
Jan 1 01:00:07 E106926 user.info sysinit: Firmware upgrate daemon starting...
Jan 1 01:00:07 E106926 user.info sysinit: SVN revision: 1810
Jan 1 01:00:07 E106926 user.info sysinit: Process is now running as a daemon
Jan 1 01:00:07 E106926 user.info sysinit: /tmp/upgrade successfully created
Jan 1 01:00:07 E106926 user.info sysinit: Working directory successfully changed to /tmp/upgrade
Jan 1 01:00:07 E106926 user.info sysinit: Stream socket (3) successfully created
Jan 1 01:00:07 E106926 user.info sysinit: Stream socket (4) successfully created
Jan 1 01:00:07 E106926 user.info sysinit: Server socket options successfully set
Jan 1 01:00:07 E106926 user.info sysinit: Bind() was successful
Jan 1 01:00:07 E106926 user.info sysinit: Listen on port 50003 was successful
Jan 1 01:00:07 E106926 user.info sysinit: Datagram socket (5) successfully created
Jan 1 01:00:07 E106926 user.info sysinit: Server socket options successfully set
Jan 1 01:00:07 E106926 user.info sysinit: Bind() was successful
Jan 1 01:00:07 E106926 user.info sysinit: BindToDevice (eth0) was successful
Jan 1 01:00:07 E106926 user.info sysinit: Datagram socket (6) successfully created
Jan 1 01:00:07 E106926 user.info sysinit: Server socket options successfully set
Jan 1 01:00:07 E106926 user.info sysinit: Bind() was successful
Jan 1 01:00:07 E106926 user.info sysinit: BindToDevice (eth1) was successful
Jan 1 01:00:07 E106926 user.info sysinit: recv() FAILED: Transport endpoint is not connected
Jan 1 01:00:07 E106926 user.info sysinit: Socket (3) successfully closed
Jan 1 01:00:07 E106926 user.info kernel: PHY: mdio@e0024520:02 - Link is Up - 1000/Full
Jan 1 01:00:08 E106926 daemon.info avahi-daemon[855]: Found user 'nobody' (UID 65534) and group 'nogroup' (GID 65534).
Jan 1 01:00:08 E106926 daemon.info avahi-daemon[855]: Successfully dropped root privileges.
Jan 1 01:00:08 E106926 daemon.info avahi-daemon[855]: avahi-daemon 0.6.23 starting up.
Jan 1 01:00:08 E106926 daemon.warn avahi-daemon[855]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Jan 1 01:00:08 E106926 daemon.info avahi-daemon[855]: Loading service file /etc/avahi/services/http.service.
Jan 1 01:00:08 E106926 daemon.info avahi-daemon[855]: Loading service file /etc/avahi/services/ssh.service.
Jan 1 01:00:08 E106926 daemon.info avahi-daemon[855]: Loading service file /etc/avahi/services/xnp-sysconfig.service.
Jan 1 01:00:08 E106926 daemon.info avahi-daemon[855]: Joining mDNS multicast group on interface eth1.IPv4 with address 10.10.52.195.
Jan 1 01:00:08 E106926 daemon.info avahi-daemon[855]: New relevant interface eth1.IPv4 for mDNS.
Jan 1 01:00:08 E106926 daemon.info avahi-daemon[855]: Network interface enumeration completed.
Jan 1 01:00:08 E106926 daemon.info avahi-daemon[855]: Registering new address record for 10.10.52.195 on eth1.IPv4.
Jan 1 01:00:08 E106926 daemon.info avahi-daemon[855]: Registering HINFO record with values 'PPC'/'LINUX'.
Jan 1 01:00:08 E106926 authpriv.info dropbear[865]: Running in background
Oct 1 08:51:11 E106926 daemon.notice ntpdate[882]: step time server 10.10.2.110 offset 1254379862.219600 sec
Oct 1 08:51:11 E106926 daemon.info avahi-daemon[855]: Server startup complete. Host name is E106926.local. Local service cookie is 3706581384.
Oct 1 08:51:11 E106926 user.info sysinit: Sending discover...
Oct 1 08:51:11 E106926 daemon.notice ntpd[884]: ntpd 4.2.4p7@... Wed Sep 30 10:35:54 UTC 2009 (1)
Oct 1 08:51:11 E106926 daemon.info ntpd[886]: precision = 0.751 usec
Oct 1 08:51:11 E106926 daemon.debug ntpd[886]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
Oct 1 08:51:11 E106926 daemon.info ntpd[886]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Oct 1 08:51:11 E106926 daemon.info ntpd[886]: Listening on interface #1 lo, 127.0.0.1#123 Enabled
Oct 1 08:51:11 E106926 daemon.info ntpd[886]: Listening on interface #2 eth1, 10.10.52.195#123 Enabled
Oct 1 08:51:11 E106926 daemon.info ntpd[886]: kernel time sync status 0040
Oct 1 08:51:11 E106926 user.info sysinit: watchdog: WDIOC_SETTIMEOUT: Inappropriate ioctl for device
Oct 1 08:51:11 E106926 user.info sysinit: sysctl: error: 'net.netfilter.nf_conntrack_checksum' is an unknown key
Oct 1 08:51:11 E106926 user.info sysinit: sysctl: error: 'net.ipv4.netfilter.ip_conntrack_checksum' is an unknown key
Oct 1 08:51:11 E106926 user.info sysinit: sysctl: error: 'net.ipv4.netfilter.ip_conntrack_max' is an unknown key
Oct 1 08:51:11 E106926 user.info sysinit: sysctl: error: 'net.ipv4.netfilter.ip_conntrack_tcp_timeout_established' is an unknown key
Oct 1 08:51:11 E106926 user.info sysinit: sysctl: error: 'net.ipv4.netfilter.ip_conntrack_udp_timeout' is an unknown key
Oct 1 08:51:11 E106926 user.info sysinit: sysctl: error: 'net.ipv4.netfilter.ip_conntrack_udp_timeout_stream' is an unknown key
Oct 1 08:51:11 E106926 daemon.info avahi-daemon[855]: Service "VM XMC16 [E106926]" (/etc/avahi/services/xnp-sysconfig.service) successfully established.
Oct 1 08:51:11 E106926 daemon.info avahi-daemon[855]: Service "Secure Shell on E106926" (/etc/avahi/services/ssh.service) successfully established.
Oct 1 08:51:11 E106926 daemon.info avahi-daemon[855]: Service "Web Server on E106926" (/etc/avahi/services/http.service) successfully established.
Oct 1 08:51:14 E106926 user.info sysinit: Sending discover...
Oct 1 08:51:18 E106926 daemon.info ntpd[886]: synchronized to 10.10.2.110, stratum 5
Oct 1 08:51:18 E106926 daemon.notice ntpd[886]: kernel time sync status change 0001
Oct 1 08:52:18 E106926 daemon.info init: starting pid 673, tty '/dev/ttyS0': '/bin/ash --login'
Oct 1 08:52:32 E106926 authpriv.info dropbear[898]: Child connection from 10.10.21.231:1806
Oct 1 08:52:34 E106926 authpriv.notice dropbear[898]: password auth succeeded for 'root' from 10.10.21.231:1806
root@E106926:~#
_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Re: Find services at localhost

2009-10-03T07:56:00Z

Hi Thomas,

On 01/10/2009, at 4:06 PM, Seng, Thomas wrote:

> Hi,
>
> I'm a avahi beginner.
>
> I do some tests with avahi using the examples. I start the service
> and a
> service browser on the same machine.
> But if no ip-address is assigned to the network adapter(s) the service
> browser doesn't find the published service.
>
> Is there any possibility to find the service in this case? Must the
> service be published in a special way?

Unfortunately this is a limitation of Avahi at the moment.. in theory
we could support lookup on the loopback adapter but that presents a
few issues specifically you will always see duplicate services (same
services on 2 interfaces) for local and ethernet.. which can be
confusing

At the moment this behavior has not been changed.. in theory we can
change it though.

Trent
_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Find services at localhost

2009-10-01T01:06:51Z

Hi,

I'm a avahi beginner.

I do some tests with avahi using the examples. I start the service and a
service browser on the same machine.
But if no ip-address is assigned to the network adapter(s) the service
browser doesn't find the published service.

Is there any possibility to find the service in this case? Must the
service be published in a special way?

Thanks for any help.

THOMAS SENG
Advanced Networking

Harman International
Harman Becker Automotive Systems GmbH
Becker-Goering-Str. 16
76307 Karlsbad, Germany
Phone: +49 7248 71 3649
Fax: +49 7248 71 1216
Email: Thomas.Seng@...
Web: www.harman.com

*******************************************
Harman Becker Automotive Systems GmbH
Management Board: Dr. Klaus Blickle (Chairman), Dr. Udo Huls, Michael Mauser
Chairman of the Supervisory Board: Ansgar Rempp | Domicile: Karlsbad |
Local Court Mannheim: Register No. 361395

*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden.
*******************************************
_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Re: avahi-daemon stops working after undetermined period of time

2009-09-21T06:44:28Z

On 19-Sep-09, at 3:41 PM, Peter Korsgaard wrote:

>>>>>> "Kristian" == Kristian Domke <news@...> writes:
>
> Hi,
>
> Kristian> iface eth0 inet static
> Kristian> address 192.168.150.10
> Kristian> netmask 255.255.255.0
> Kristian> gateway 192.168.150.1
> Kristian> post-up ifconfig eth0 allmulti
>
> Kristian> It is not the one from my system, because I do some complex
> Kristian> routing niceties there (multiple VPN-Connections *sigh), but
> Kristian> it should work.
>
> With what network card is this? It sounds like the driver isn't
> setting
> up the multicast hash table correctly.

Near as I can see - with Ubuntu Hardy it's *all* of them...
For examples -

01:08.0 Ethernet controller: Intel Corporation 82801BA/BAM/CA/CAM
Ethernet Controller (rev 03)
01:0c.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado]
(rev 78)
01:0c.0 Ethernet controller: Intel Corporation 82540EM Gigabit
Ethernet Controller (rev 02)
05:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VM
(LOM) Ethernet Controller (rev 81)

Brian

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

PGP.sig (268 bytes) Download Attachment

Re: avahi-daemon stops working after undetermined period of time

2009-09-19T12:41:34Z

>>>>> "Kristian" == Kristian Domke <news@...> writes:

Hi,

Kristian> iface eth0 inet static
Kristian> address 192.168.150.10
Kristian> netmask 255.255.255.0
Kristian> gateway 192.168.150.1
Kristian> post-up ifconfig eth0 allmulti

Kristian> It is not the one from my system, because I do some complex
Kristian> routing niceties there (multiple VPN-Connections *sigh), but
Kristian> it should work.

With what network card is this? It sounds like the driver isn't setting
up the multicast hash table correctly.

--
Bye, Peter Korsgaard
_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

avahi-daemon stops working after undetermined period of time

2009-09-19T12:34:26Z

For simplicity i post the complete example of the /etc/network/
interfaces:

auto lo eth0

iface lo inet loopback

iface eth0 inet static
address 192.168.150.10
netmask 255.255.255.0
gateway 192.168.150.1
post-up ifconfig eth0 allmulti

It is not the one from my system, because I do some complex routing
niceties there (multiple VPN-Connections *sigh), but it should work.

the whitespace in front of the lines after the iface line are
importand, afaik.

Kristian
_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

Re: avahi-daemon stops working after undetermined period of time

2009-09-18T13:59:27Z

On 18-Sep-09, at 4:19 PM, Kristian Domke wrote:

> OK, answering myself.
>
> I found the problem, at least in my system. Obviously there is
> something wrong with some network cards and multicast in Ubuntu /
> Linux.
>
> I read about it in the german Ubuntu Wiki: http://wiki.ubuntuusers.de/Avahi#Avahi-im-Netzwerk
>
> The solution is a simple
>
> sudo ifconfig eth0 allmulti
>
> To make it restart save add the following in the file /etc/network/
> interfaces in the section for the relevant NIC (take care of
> indentation):
> post-up infconfig eth0 allmulti
>
> Hope that helps

That's interesting!
> sudo ifconfig eth0 allmulti
does so far seem to be working.

Can you show me the way you added that to the interfaces file? I'm
having trouble with the syntax. I've tried several variations.
I suppose I could put it in post-up.d/ but thought the interfaces file
would be better....

Brian

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

PGP.sig (268 bytes) Download Attachment

avahi-daemon stops working after undetermined period of time

2009-09-18T13:19:00Z

OK, answering myself.

I found the problem, at least in my system. Obviously there is
something wrong with some network cards and multicast in Ubuntu / Linux.

I read about it in the german Ubuntu Wiki: http://wiki.ubuntuusers.de/Avahi#Avahi-im-Netzwerk

The solution is a simple

sudo ifconfig eth0 allmulti

To make it restart save add the following in the file /etc/network/
interfaces in the section for the relevant NIC (take care of
indentation):
post-up infconfig eth0 allmulti

Hope that helps

Kristian
_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi

avahi-daemon stops working after undetermined period of time

2009-09-18T11:12:49Z

Hello All,

as I have the same problem and (almost?) the same setup, I will try to
contribute to this thread.

My setup:

MacBook Pro, OS X 10.6.1
Linuxbox: Ubuntu Hardy Heron

Avahi 0.6.22 (Ubuntu original)

Exactly the same problem. After the start of avahi everything is fine,
some (few) minutes later the linuxbox is not found anymore. After
restarting avahi everything is fine again.

I have logged the whole procedure with wireshark. Quite long protocol
(53k on disk). If you want to have a look into it, you find it under http://cl1p.net/mDNS-Avahi-Problem/

I still have the very same capture in original, including the complete
afp traffic an so on. I just limited the Export to the mDNS packages.

Hope that helps you to help me ;-)

regards,

Kristian

_______________________________________________
avahi mailing list
avahi@...
http://lists.freedesktop.org/mailman/listinfo/avahi