Bug 428995 - avahi-discover reports out of date information
avahi-discover reports out of date information
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: avahi (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: Orphan Owner
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 428991
  Show dependency treegraph
 
Reported: 2008-01-16 12:21 EST by Cameron Meadors
Modified: 2008-03-26 20:10 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-26 20:10:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Cameron Meadors 2008-01-16 12:21:40 EST
I am using avahi-discover to find a service provided by a NAS device.  The
services are found, but if I turn the device off or change the name of the
service, avahi-discover lags in updating the into.  

It almost seems like it is caching the information for too long, yet I can not
find any cache to remove.  Restarting avahi-discover does not seem to refresh
the data.

Should avahi-discover update are services are found?  If a service changes
should avahi-discover update its info?  Is this a problem with the frequency of
the service announcement?
Comment 1 Lennart Poettering 2008-03-26 20:10:15 EDT
The mDNS spec mandates relatively long cache ttls because the normal way for
having services to disappear is by sending goodbye packets.

Avahi just follows what the spec mandates. If you think that the spec is
misdesigned here (which I -- as someone who implemented it -- do not think) then
please discuss this with the spec authors.

If Avahi doesn't immediately notice renamed services, than this is most likely
an issue on the mDNS implementation on the NAS (i.e. it doesn't send
announcement/goodbye packets properly), because renames should in theory work
properly.

Either way, I do believe Avahi is behaving properly here. I am thus closing this
bug now. If you believe I am not right, feel free to reopen.

Note You need to log in before you can comment on or make changes to this bug.