synergy-1.3.1-4ubuntu1 (intrepid) fails to connect
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
synergy (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bug Description
Binary package hint: synergy
A synergy_
A dump with Wireshark shows that the -4ubuntu1 client fails to complete the synergy handshake with the server. I'll attach a .pcap file showing the failed connection attempt. I've looked at the traffic from both sides, and it's identical, i.e. the server sees what the client sends, and vice versa. The last two packets in the dump are sent after sending the client SIGQUIT (with Ctrl-\) and the two before it are from occur after the connection times out. Before hitting Ctrl-\, netstat(8) on the client shows the connection in CLOSE_WAIT.
The Ubuntu-specific changes to the upstream 1.3.1-4 package seem pretty innocuous, so this is strange. I tried to rebuild the Debian source package against intrepid, but the build failed due to Werror stuff -- I need to hunker down and try to make it build, but it's not gonna happen today. If anyone can provide any information on why the same source builds on Debian, and not on Ubuntu, that would be useful.
I'll also attach the output of `synergyc -f -d DEBUG2 {server.name} and an strace of the client when it fails to connect. The strace and top(1)'s WCHAN field agree that the client is stuck in futex_wait.
So, lots of info; hopefully some of it's useful. What can I do to help get this fixed?
Thanks.
Related branches
Changed in synergy: | |
status: | New → Confirmed |
Changed in synergy: | |
assignee: | nobody → richard-connon |
Changed in synergy: | |
assignee: | richard-connon → nobody |
Okay, it looks like the .pcap I attached doesn't include the last two packets I described in the original report -- i.e. the last two packets are from the connection timing out, and the two packets I once saw after Ctrl-\'ing the client aren't in there. Maybe they weren't sent this time (though I saw them before) and maybe it's PEBKAC on my part.
The last two packets *not* here, IIRC, are a packet from the client with FIN set, and a response from the server that has ACK or RST set, depending on how long it had been since the server tried to close the connection.
Sorry about that.