disconnection of network not noticed

[quozl]

With the IRC activity downloaded from activities.sugarlabs.org, whatever current version is presented to XO laptops running Sugar 0.84, the client does not notice disconnection of the network link to the server, and continues to present the user with a connected experience. The user types messages, the messages are rendered on screen, but the TCP packets are not acknowledged.

[tomeu]

NetworkManager has a signal and a method for knowing when we are online or not.

[quozl]

Such a signal or method would not be useful if the IRC server was on localhost, or if the system's network connection was not provided by NetworkManager.

Checked the code of all activities in the current OLPC builds. Speak contains code as part of 0install that checks the org.freedesktop.NetworkManager method state. No other activity does.

However this would not have solved the problem in this case, since the disconnection of the network link to the server was not caused by disconnection of network service to the system running the activity. The NetworkManager state did not change.

[fran]

Hmm. It looks like the server tab and all channel tabs do display "Disconnected" when the connection with the server is reset or times out. Quozl, if in the situation described above you let the software sit for several minutes to let the connection time out, is there still no feedback?

If connectivity to the server is lost, it may normally take a little while for the connection to time out. In my experience using standard IRC clients over unreliable WiFi connections, this can be a good thing, because if you lose connectivity for a minute or two, when you regain connectivity you may likely still be connected to the server and be able to pick up where you left off. However, this may be unintuitive to non-techies, who will instead wonder why IRC messages have stopped coming in - perhaps displaying a warning on-screen along the lines of "connection may have been lost," possibly governed by NetworkManager's state, would be the way to go.

[quozl]

G'day Fran.

I remember the event clearly, and I had gathered technical information at the time. The Sugar Neighbourhood View showed that the wireless network connection was still operational. The IRC activity did not show disconnected or timed out, and never did, although it was left for at least half an hour. tcpdump on the root console of the laptop showed TCP packets for port 6667 were leaving the laptop, but none were returning. All other connections made by the laptop, such as by Browse, were working fine.

The root cause of the event was momentary loss of power to last mile equipment, such as an ADSL router, or in my case an HSDPA wireless broadband service. This caused the public IP address to be changed. This caused the existing IRC TCP session on port 6667 to go silent; in that no packets were returned to the laptop, not even TCP RST, or ICMP. This configuration and event is not unusual.

Under these circumstances there is no way for the client to detect a problem except by detecting a lack of data from the server.

Other IRC clients cover this possibility by enforcing a local timeout on the connection. If no data is received, the connection is timed out at the local host. Other activities that use TCP connections, such as Browse, have similar logic.

The situation can be simulated by installing a local ircd, connecting to it with the IRC activity, and then sending a SIGSTOP signal to the ircd. The connection will behave the same way as I observed, with the addition of TCP ACK packets.

The NetworkManager state on the laptop had not changed, and so any solution relating to NetworkManager state is inappropriate and unjustified. It might well be a good idea to do something with state notification, but not for solving this problem.

Hope that helps!

[fran]

Right now, the IRC activity pings the server (via an IRC PING request) every two minutes. If it doesn't receive a response to this ping within four minutes, the error "The server seems to have stopped talking to us" appears on all tabs and the connection closes.

I've tested the latest version from ASLO (IRC-8) on an XO-1.5 running os355. I let it run for a bit, then disconnected the network; about six minutes later, the error appeared as expected.

Waiting four minutes for a ping response seems awfully long - I imagine the timeout should probably be shorter than the two minute ping interval, at least. But the timeout mechanism does appear to be working. Quozl, can you recreate the situation again and attach the org.sugarlabs.IRC-*.log logs from the Log activity?