Ticket #6448 (new defect)

Opened 7 years ago

Last modified 4 years ago

Local Link and access point sharing issue.

Reported by: jg Owned by: Collabora
Priority: normal Milestone: 9.1.0-cancelled
Component: telepathy-salut Version:
Keywords: Cc: gregorio
Action Needed: never set Verified: no
Deployments affected: Blocked By:
Blocking:

Description

I think I saw the following:

1 machine on simple mesh, local link.
1 machine associated with access point.

No jabber server involved.

They could see each other, but not successfully start collaborating.

Change History

in reply to: ↑ description   Changed 7 years ago by sjoerd

Replying to jg:

I think I saw the following:

1 machine on simple mesh, local link.

So this one was purely on a mesh network

1 machine associated with access point.

But this one was both on a mesh _and_ on an infrastructure network

They could see each other, but not successfully start collaborating.

Avahi listens and announces on both interfaces. So both machines announce the presence and the activities on the mesh network.

Clique on the other hand just multicast on one network, the one which is choosen by the kernel routing.. Which means for the machine associated with the AP that it will talk Clique on the infrastructure network..

The end-result being one machine has a has a Clique group on the mesh network, the other one on the infrastructure network. Obviously these don't talk much together.

Now there are multiple issues here. One salut bug is that it announces an activity on all interfaces, while it actually only exists on one.

Even if that's fixed there are some issues left.. For example in your setup, if the node on the AP started the activity the node only on the mesh wouldn't see that activity...

  Changed 6 years ago by morgs

  • component changed from presence-service to telepathy-salut

  Changed 6 years ago by gdesmott

So what we have to do is to announce the Clique and Activity service only on the interface used by Clique. How to find this interface? - Using Clique's socket? - Using kernel routing table? - Another suggestion?

  Changed 6 years ago by gregorio

  • cc gregorio added
  • priority changed from high to normal
  • next_action set to never set
  • milestone changed from 8.1.1 (was Update1.1) to 9.1.0

al users must choose mesh or AP. If some are on one and some on the other they can't see each other.

Let me know if that is not correct. Otherwise I'll put it in the 8.2.0 release notes and we'll review again for 9.1.0.

Greg S

  Changed 6 years ago by gregorio

Hi Jim and/or Collabora,

What do I need to tell users in the release notes so that they do not run in to this bug?

e.g. if your XO connects to a Mesh (AKA another XO) then you must first disconnect from that before connecting to a wireless AP.

Something like that which explains what they can and cannot do.

I could use some details on this ASAP for the release notes.

Thanks,

Greg S

  Changed 6 years ago by gdesmott

The problem is that when you are connected to an AP you have two interfaces up:

* eth0: which has an IP from the AP

* msh0: wich has an auto-ip on the mesh.

Avahi will announce all the services on both interfaces; including the presence and OLPC activity. But the underlying activity protocol can only communicate using *one* interface (usually eth0 as that's the default one in the routing table).

So, if an XO is only connected to the mesh, I'll see the activity but won't be able to collaborate with it.

Question is: do we really want to have the msh0 interface up when we are connected to an AP? What's the rational of this choice?

  Changed 6 years ago by gregorio

Hi Guillaume,

Thanks for the information but I'm still not sure what to tell end users based on this.

I need some explanation for 8.2 based on how it works now.

I think its as simple as saying: if you want to collaborate, make sure your XO is only connected to an AP (and a jabber server) or a Mesh (aka another XO). You should not try to connect to both at the same time.

Is that right?

Thanks,

Greg S

  Changed 6 years ago by gdesmott

Humm not really because this behaviour is not a consequence of an user action, this is done by default. If the user clicks on one of the three simple mesh icons, then it will be only on the mesh and things work fine. But when he is connected to an AP, he is at the same time on the mesh.

Maybe we could say something like that: "When you want to collaborate on a network (so using an AP) be sure to properly connect all your XO's to this network. If they are not they could see the buddies and activities throught the mesh but won't be able to collaborate together."

  Changed 6 years ago by gregorio

Hi Guillaume,

Thanks for the added detail and user level explanation!

I'm with you now that you don't want to connect via Mesh and AP at the same time or collaboration wont work right.

Now I'm trying to understand how you can get in to a state where Mesh and wireless AP are both being used. When would that happen and how would you know that you are in this unstable state?

Maybe you see two icons on the frame one mesh and one AP?

Seems like if I click on a mesh icon when connected to an AP it disconnects from AP and connects to mesh instead. Same with vice versa.

Thanks,

Greg S

  Changed 5 years ago by alivenk

If you’re a dedicated follower of tiffany co like me. Don't miss the tiffany jewelry & co. on sale including pendants, necklace, earrings, bracelets on line. tiffany Jewelry is the one thing that outlasts the cake, champagne and music. links of london jewelry discount , famous for its sweetie and friendship bracelets.

Note: See TracTickets for help on using tickets.