Salut/avahi/meshview issues

[Sjoerd Simons]

On Wed, Jan 30, 2008 at 01:21:29AM -0500, Giannis Galanis wrote:
> The results were:
> 
> 1.  The xmas tree effect is still here.
> i.e. XOs occasionally vanish/reappear in differenent positions.
> This is because of the following:
> When the avahi cache includes several inactive/departed/(reported as failed)
> peers,
> and a new pear arrives,
> then all the inactive peers vanish from the screen instantly. (#5501)
> If their inactivity was temporary, then they will reappear shortly in a
> different location
> If for e.g. 3-4 XOs are (by user internention) moved simultaneously from ch6
> to ch11, and then back to ch6, the icons wont have the time to disappear.
> BUT, the first to return to ch6 will cause the effect/bug to the others,
> which will instantly vanish. Shortly after they will naturally all return
> 1by1 to ch6 and will reappear in different locations.
> There was a patch for this issue(5501), which was included in 678+, but it
> has no effect.

Please. Report your findings in the actual bug report so we can track it. And
also, don't expect things to be fixed in reasonable timeframes if we have to
wait more one month before our changes are actually tested.

> 2. It takes up to 10min for avahi even to detect the inactivity of a peer.
> i.e. If an XOs switches channels, for up to 10min avahi wont even know(it
> used to be 1-2min).

Is this with or without the patch from bug #6162 ? If without, then the time it
takes avahi to discover it should still be 2 mintues. I'd like to how you test
this. Oh and please file a bug, so we can actually track these issues.

> 3. It will take a total of about 30min for the XO to vanish from the mesh
> view(this is tooo long!)

Again, file a bug. Needed info here is if there is a time difference between
when avahi marks something as removed, when salut sends out the removed signal 
and when it actually disappears from the mesh view.

> 4. Avahi/mesh view respond independently.
> The situation used to be that when an entry dissappeared in avahi, it
> disappeared in mesh view, and the same when new peers arrive.
> This relation was very consistent.
> However, now we have the following cases:
> a) an XO will vanish from the mesh view, but remain "indefinitely" in the
> avahi cache as "failed to resolve"
> b) sometimes avahi shows alot less peers than the mesh view. The extra peers
> in the mesh view are definitely active since they properly respond to
> activity joining/sharing.
> c)sometimes avahi included more active peers than the mesh view.
> does anyone know why this is happening?
> Is it a bug?
> I have logs, if needed, that compare avahi-browse with timestamped
> dbus-monitor logs, that indicate the inconsistencies.

Well you all list them as undesired behaviour, so i would say they're bugs.

> 5. An important improvement is that peers will not generally fail alot on
> their own.
> So, if many XOs join a mesh channel, and noone goes away, the will not start
> failing. This used to be a common effect after 4-5 XOs. However, i noticed
> once in 1cc, 61 active XOs in the mesh view!

When you say salut, you actually mean avahi. It would help if you could be
clear on what you mean :) This improvement is probably caused by the fix in
#5501.

> This shows that salut is more capable then we expected.

Well both avahi and salut are quite capable. I'm not sure why it has such a bad
reputation with you. Probably because your only seeing it in a very very
exterme network and because there seems to be a lot of FUD about mdns going
around. MDNS definately isn't an optimal protocol for a mesh, but most of the
issues in big rollouts are actually caused by the wireless firmware not being
good enough to do actual multicast routing.


Anyway for all the bugs you should have filed instead of sending this mail, i
will need tcpdump logs, avahi logs, salut logs and if possible meshview logs
indicating when contacts are removed from the mesh from a machine where you say
the behaviour. Preferably with timestamps

  Sjoerd
-- 
I am what you will be; I was what you are.