Connecting to a modern Xserver with an old client

[Grant Taylor]

On 7/22/23 3:47 PM, Michael K wrote:
> 
> To answer Grant's question. Yes, I had added the X ports but I've now turned 
> off the firewall just to be sure.

ACK

I generally don't like disabling the firewall.  --  I'm currently 
tilting at RPC for NFS to get it to work through a firewall.

But sometimes disabling the firewall, or better pin-holing the pair of 
communicating systems, is the better part of valor or at least sanity 
preserving during troubleshooting.

> Here is the wireshark conversation.

Thank you.

> I'm not knowledgeable enough to recognize the issue..

I don't remember the last time I looked at X11 traffic with a sniffer. 
So, I could be completely off my rocker with my analysis (below).

N.B. I've tried to tweak the white space so that columns line up in a 
way that I think is slightly better.

> 1     0.000000000    192.168.1.16    192.168.1.1    TCP    60    6915 → 6001 [SYN] Seq=0 Win=0 Len=0 MSS=1416
> 2     0.000165997    192.168.1.1    192.168.1.16    TCP    58    6001 → 6915 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460
> 3     0.005196101    192.168.1.16    192.168.1.1    TCP    60    6915 → 6001 [ACK] Seq=1 Ack=1 Win=1416 Len=0

This looks like a standard TCP 3-way handshake to me.

> 4     0.008854195    192.168.1.16    192.168.1.1    X11    66                Initial connection request

This looks like a message from the sniffer saying that X11 protocol is 
starting.

> 5     0.008914324    192.168.1.1    192.168.1.16    TCP    54    6001 → 6915 [ACK] Seq=1 Ack=13 Win=64228 Len=0
> 6     0.009029932    192.168.1.1    192.168.1.16    TCP    62    6001 → 6915 [PSH, ACK] Seq=1 Ack=13 Win=64228 Len=8 [TCP segment of a reassembled PDU]

I assume that's X11 application protocol traffic.

Maybe turning up verbosity would show more details.  Though I don't know 
that such is warranted.  (See comments below the packet capture.)

> 7     0.009086172    192.168.1.1    192.168.1.16    X11    110               Initial connection reply
> 8     0.009149782    192.168.1.1    192.168.1.16    TCP    54    6001 → 6915 [FIN, ACK] Seq=65 Ack=13 Win=64228 Len=0
> 9     0.017057921    192.168.1.16    192.168.1.1    TCP    60                [TCP ZeroWindow] 6915 → 6001 [ACK] Seq=13 Ack=66 Win=0 Len=0
> 10    0.019632130    192.168.1.16    192.168.1.1    TCP    60                [TCP ZeroWindow] 6915 → 6001 [ACK] Seq=13 Ack=66 Win=0 Len=0
> 11    0.023341315    192.168.1.16    192.168.1.1    TCP    60                [TCP ZeroWindow] 6915 → 6001 [ACK] Seq=13 Ack=66 Win=0 Len=0

I assume that's X11 application protocol traffic.

> 12    0.083569102    192.168.1.16    192.168.1.1    TCP    60    6915 → 6001 [FIN, PSH, ACK] Seq=13 Ack=66 Win=0 Len=0
> 13    0.083647415    192.168.1.1    192.168.1.16    TCP    54    6001 → 6915 [ACK] Seq=66 Ack=14 Win=64228 Len=0

This looks like the start, but incomplete capture, of a normal TCP 4-way 
connection terminating.  ...16 tells ...1 that it wants to terminate the 
TCP connection via the FIN flag.  ...1 replies acknowledging ...16's FIN.

> Also, yes the X display is 1 on this server.

This packet capture makes it obvious to me that the X11 client 
(application) is successfully initiating a TCP connection and talking 
the X11 protocol to the X11 (display) server.  This means that:

1)  The firewall is not interfering.
2)  X11 display :1 is the proper display.
3)  There do not appear to be any network / IP / TCP issues with the 
communication.
4)  This seems to be an X11 protocol level problem.
5)  This seems to NOT be a networking problem.

Turning up the verbosity on the capture /may/ provide more details.  Or 
seeing if the network sniffer has the ability to produce more details 
about the actual X11 protocol.  Wireshark / Tshark can be extremely 
impressive.

I think I would be inclined to make sure that I had the *X11* /console/ 
showing to see if any errors shed some light on things.

I'd also look to see if any additional logging could be enabled for the 
X11 (display) server and / or X11 client (application) to see if it's 
possible to get either of them to provide any additional diagnostic data.

Aside:  It's my understanding that there are a couple of common TCP 
connection termination methods:

1)  Each end sends it's own FIN and receives an ACK from the other end.

       L ---FIN------> R
       L <------ACK--- R
       L <--FIN------- R
       L -------ACK--> R

2)  One end sends it's FIN to the other end, the other end ACKs the 
first's FIN /and/ sends it's own FIN at the same time, and then the 
first end ACKs the second end's FIN.

       L ---FIN------> R
       L <--FIN,ACK--- R
       L -------ACK--> R



Grant. . . .