#4193 HIGH Update.: Two XOs were connected to an access point and were still running salut

[Zarro Boogs per Child]

#4193: Two XOs were connected to an access point and were still running salut
-------------------------------+--------------------------------------------
  Reporter:  yani              |       Owner:  smcv    
      Type:  defect            |      Status:  new     
  Priority:  high              |   Milestone:  Update.2
 Component:  presence-service  |     Version:          
Resolution:                    |    Keywords:          
  Verified:  0                 |  
-------------------------------+--------------------------------------------

Comment(by smcv):

 I think you've labelled cases 1 and 2 backwards - case 1 looks more like
 an AP - but they're basically the same anyway.

 Case 1:

 * PS received an IP address change event from NM (a Media Lab 18.x
 address)
 * PS asked Gabble to connect to the server (Connect() was called and
 succeeded - this means the connection attempt is in progress and will
 proceed asynchronously)
 * Loudmouth (the XMPP library Gabble uses) failed to connect with IPv6,
 retried using IPv4, and succeeded (18.85.46.41 port 5222)
 * At the point when the logs were taken, Gabble had sent the XML headers
 for the beginning of the XMPP stream to the server, but had not yet
 received the equivalent headers from the server
 * As a result, Gabble never told PS that it had finished connecting (side
 note: when Telepathy connection managers signal status CONNECTED, it
 actually means they've done some initial setup on the new connection too,
 so that all of our API ready to use)

 Diagnosis: wait a bit longer? I can't see how long you waited - we should
 patch Gabble to put timestamps in its log, I think there's a patch
 floating around somewhere to do this.

 Case 2:

 * PS received an IP address change event from NM (172.x)
 * Once again, it asked Gabble to try connecting
 * Once again, IPv6 failed but IPv4 succeeded
 * Once again, we never got any data back from the server, so didn't get
 any closer to signalling CONNECTED

 Diagnosis: the same

 Case 3:

 * PS received a change to a 172.x address from NM
 * It asked Gabble to try connecting
 * The IPv4 address signalled by network-manager became invalid ("IP4
 address now None"), so PS asked Gabble to disconnect
 * PS received a change to a 169.x link-local address from NM
 * It tried telling Gabble to connect again (probably we shouldn't even try
 this, because with a 169.x address and no nameserver or default gateway
 you won't get far...)
 * Unsurprisingly, Connect() failed because DNS resolution of
 jabber.laptop.org failed
 * PS received a change to 172.x from NM and told Gabble to connect again
 * DNS still failed, so still no connection
 * It appears the retry timer wasn't reached, so by the time you gave up,
 PS hadn't retried

 Diagnosis: your network isn't stable enough for Gabble to get a connection

 Situations where Gabble can't possibly connect, so it can't be considered
 a PS or Gabble bug that it fails to do so:

 * Can't reach DNS or can't resolve server hostname (to test: "getent hosts
 jabber.laptop.org", replacing hostname if necessary)
 * Can't get IP to the server (to test: "ping jabber.laptop.org")
 * Can't get bidirectional TCP to the server (to test: "telnet
 jabber.laptop.org 5222", type "hello" and press Enter, you should get a
 response containing "xml-not-well-formed" and your connection should get
 closed by the remote host)

-- 
Ticket URL: <https://dev.laptop.org/ticket/4193#comment:8>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system