Salut: Sharing activities not working

[erikos]

Tested at: Fedora 11 and Soas (F11)

Machines are connected using link local. The buddies appear fine in the mesh view. when sharing an activity tit appears in the mesh view of the sharer but not of the other machines. Sometimes it does but when one join no data is transmitted.

#927 does prevent me from getting useful logs at the moment.

Using gabble (jabber.sugarlabs.org) does work fine (only once with a shared activity the content was not transferred).

Reproducible: Always for me on several machines, and different networks.

[gdesmott]

Which telepathy-salut are you using? I just tried with 0.3.9 using sugar-jhbuild and it worked fine.

[erikos]

Yes 0.3.9 ​http://koji.fedoraproject.org/koji/buildinfo?buildID=96418

[erikos]

Salut logs on machine A

[erikos]

Salut logs on machine B

[erikos]

PS logs on machine B

[erikos]

PS logs on machine A

[erikos]

Sugar-jhbuild has the same symptoms for me. I have attached some logs for sharing an activity from machine A and then one from machine B.

[erikos]

Looks like another firewall issue on Fedora. I turned off the Firewall and sharing does work. Need to find out what ports are the one to open, and what change was introduced to cause this.

[erikos]

I took these two out of the iptables to get it to work with the firewall enabled:

-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited

[erikos]

Ok, on soas I disabled the firewall. I am testing between two machines. Very often when machine A shares an activity it is not shown in the mesh view of machine B. The buddy does get another position though. The presence-service log on machine B does not show any registration for that new shared activity. However, when I share an activity from machine B then it gets registered by machine A fine and I can collaborate.

This is not bound to a specific machine, I have seen it happening on machine A and B.

[erikos]

Two issues here:

a) on Fedora 11: when the Firewall is enabled sharing of activities does not work - when clicking on the shared instance it is resumed but not joined (a timeout), this is true in Fedora 11 install, Soas and jhbuild on Fedora.

b) on Soas only: Very often when machine A shares an activity it is not shown in the mesh view of machine B. The buddy does get another position though. The presence-service log on machine B does not show any registration for that new shared activity. However, when I share an activity from machine B then it gets registered by machine A fine and I can collaborate. This is not bound to a specific machine, I have seen it happening on machine A and B. The firewall is turned off. This is only true in Soas - it does not happen in plain Fedora or jhbuild on Fedora.

[tomeu]

Replying to erikos:

b) on Soas only: Very often when machine A shares an activity it is not shown in the mesh view of machine B...

Didn't managed to reproduce here between two soas machines here, after disabling iptables.

[Jose Icaza]

Did reproduce it using Classmate Convertible netbooks and Dell and Toshiba laptops, all on Strawberry SoaS USB and all sharing the same wireless AP:

• Between the two Classmates, once SoaS had installed the proper driver for the RT3070 wireless chip: the bug appears. On each classmate, the other user is visible in neighborhood view; however when "Sharing to neighborhood" any activity (tried with Write and Turtle), the activity is not shown on the other user's machine neighborhood view.

• But it does work when the Classmate is sharing to the Dell laptop. But not vice-versa

• And the two laptops have no problem sharing to neighborhood.

We'll next try turning off the firewall or the IP table stuff...

We really need this to work for the ​OLPC Chiapas SoaS deployment. Any help much appreciated.

[Jose Icaza]

Turning off the firewall did not help. Two machines (laptops or classmates) with SoaS strawberry, conected to wired or wireless local networks with *no* internet (so, no jabber server) and with Fedora's firewall disabled:

• Either user is visible in the other's neighborhood
• Unpredictably, either A can share activities to B but B can't to A or viceversa. We have been unable to reproduce the bug reliably, but keep trying...
• Once one of them can't share, it never will again unless Sugar restarted. Then the restarted one can share but the other can't...

No problem with sharing activities when the two machines are connected to sugar labs jabber server. Unfortunately that won't work for us, because we will initially have no internet in our Chiapas deployment; just a local net.

What should we do to help debugging this?

[gdesmott]

From my understanding of this bug, the logs attached by Erikos were because of A (firewall issue); right?

Jose: When you say "can't share", what do you mean exactly? The shared activity doesn't appear in the peer's mesh view? It appears but when trying to join it nothing happen (data are not exchanged between the 2 laptops)?

Is this problem specific to a set of laptops (classmate?)? That could be a network driver issue (buggy multicast implementation).
Did you observe this bug only on SoaS or did you reproduce it using sugar-jhbuild as well (using the same hardware in both cases)?

Could you reproduce this issue and attach telepathy-salut log when it happens? ​http://wiki.laptop.org/go/Telepathy-debug uses to contain instructions about how to enable Telepathy debugging but I don't know if that still apply for SoaS. Sugar guys would probably be able to help you for this.

[CarolineM]

I saw this behavior in VT with Dell laptops.

In my test when a Student shared an activity it showed up in on their neighborhood but not on the other students neighborhood. The XO icon was on the neighborhood.

Another weird thing I noticed which may or may not be helpful.
We were connected to the Internet through an AP. Jabber sharing was being flacky so I took out the network settings on two of the students laptop to try local.
Expected behavior: Those students would only see each other in the neighborhood
Actual behavior: All students in the room showed up on the neighborhood, even those that still had their network set to the sl jabber server.

Not reporting this as a bug, it doesn't matter right now, just reporting it in case it gives any insight.

[gregorio]

Can we reproduce this and isolate it further.

Salut sharing seemed to work fine at GPA on a wired network.

Who has the next move to close this? Looks like Jose is ready to help and Guy has asked some questions.

Maybe Jose is not on the CC? Does anyone know how to add him? I see his name listed but no Trac ID so not sure how to CC him....

Jose,

Can you address Guy's questions?

Me gustaria visitar Chiapas para verlo personalmente pero no puedo ahora :-(

Bueno suerte!

Thanks,

Greg S

[erikos]

Make sure that the default gateway is set (route -n), and check avahi (avahi-browse).

[erikos]

My findings from Fedora 11 are: I had to allow all multicast traffic: "-A INPUT -p udp --dst 224.0.0.0/4 -j ACCEPT"

Sjoerd explained to me that clique picks a random port and random multicast address per activity.

I tested so far with Browse and Chat, I still have issues with Memorize but that might be another issue.

[Jose Icaza]

Very sorry to reply this late - somehow comments to this ticket did not get to my gmail address, when other ticket's comments did.

Replying to gdesmott:

From my understanding of this bug, the logs attached by Erikos were because of A (firewall issue); right?

Yes I think so; but turning off the firewall did not work for us.

Jose: When you say "can't share", what do you mean exactly? The shared activity doesn't appear in the peer's mesh view? It appears but when trying to join it nothing happen (data are not exchanged between the 2 laptops)?

Correct, the shared activity does not appear in neighborhood view of the other machine... sometimes! Couldn't reproduce bug reliably

Is this problem specific to a set of laptops (classmate?)? That could be a network driver issue (buggy multicast implementation).

Perhaps... It didn't happen between an older model Dell laptop and a Toshiba. But it did happen between two Dells for Caroline...

Did you observe this bug only on SoaS or did you reproduce it using sugar-jhbuild as well (using the same hardware in both cases)?

Just with plain Strawberry. Should try it with jhbuild

Could you reproduce this issue and attach telepathy-salut log when it happens? ​http://wiki.laptop.org/go/Telepathy-debug uses to contain instructions about how to enable Telepathy debugging but I don't know if that still apply for SoaS. Sugar guys would probably be able to help you for this.

Sure, I will... For the moment we have solved the problem by installing a local ejabberd server running Xubuntu on a Classmate serving as server. The student classmates are addressed to the local IP of the jabber server. But in some other deployment without server (just an access point to set up the wireless net) the problem will likely appear.

[Jose Icaza]

Replying to erikos:

My findings from Fedora 11 are: I had to allow all multicast traffic: "-A INPUT -p udp --dst 224.0.0.0/4 -j ACCEPT"

Thanks Erikos -we'll try that and let you know.

[erikos]

As a follow up on the shared issue with Memorize: Version 32 does work fine, version 33 not. The sharing issue is activity specific.

[dnarvaez]

Milestone 0.86 deleted