Hey Gary,

Do you think you can send me a complete packet trace (i.e. output
of snoop -o foo.snoop)? It might be interesting to see what service
was utilizing the port in question - it could be something other than
the X server perhaps.

Maybe you could send it to me directly rather than flooding the list
with a large packet trace.

-Bob

Gary Mills wrote:
On Mon, Nov 05, 2007 at 05:02:24PM -0500, Bob Doolittle wrote:
Gary Mills wrote:
On Fri, Nov 02, 2007 at 04:16:14PM -0400, Bob Doolittle wrote:
I didn't see any snoop output. Only an
interpretation that at some point UDP traffic
stopped and you got some ICMP Destination
Unreachables from the *server*. The details of
that ICMP message may be illuminating, as well as
what immediately preceded the problem. Is your X
server dying? It's possible that some process on
the server is dying and hence no app is reading
that port any more.

That's something I certainly should check.  I didn't expect that, but
it's possible that the X server is dying.  There is a black screen on
the Sun Ray immediately after I enter a userid and password on the
dtgreet screen.  Would dtlogin start another one?

Here's the snoop output, in part.  I'm more confused than ever now.
This doesn't look like a NAT problem after all.  This is taken on the
interface to the private network, so it will show traffic after NAT
conversion.

Just before the timeout, there's lots of UDP traffic between my Sun Ray
and the Sun Ray server, over a pseudo-connection.  Here's a sample:

  426 9:12:2.15721 toliman.cc.umanitoba.ca -> 192.168.0.158 UDP D=37969 S=40405 
LEN=776
  427 9:12:2.16197 192.168.0.158 -> toliman.cc.umanitoba.ca UDP D=40405 S=37969 
LEN=48
  428 9:12:2.25569 192.168.0.158 -> toliman.cc.umanitoba.ca UDP D=40405 S=37969 
LEN=64
  429 9:12:2.49271 toliman.cc.umanitoba.ca -> 192.168.0.158 UDP D=37969 S=40405 
LEN=48

After the timeout, my Sun Ray sends UDP, but nothing is listening
on the server:

  431 9:12:3.35094 toliman.cc.umanitoba.ca -> 192.168.0.158 UDP D=37969 S=40405 
LEN=24
  432 9:12:3.35144 192.168.0.158 -> toliman.cc.umanitoba.ca UDP D=40405 S=37969 
LEN=48
  433 9:12:3.37728 toliman.cc.umanitoba.ca -> 192.168.0.158 ICMP Destination 
unreachable (UDP port 40405 unreachable)

After that, all UDP traffic stops.  There's still occasional TCP traffic
but only in one direction, from my Sun Ray to the server.  This stays
the same until the Sun Ray terminal reboots.

It's pretty clear.  Something changed in the most
recent version of the Sun Ray server software to provoke this
behavior.

Or so I thought.  I changed the local DHCP server so that my Sun Ray
would connect to an older Sun Ray server, and got the same result!

Here are some architectural details that might help you
understand SRSS better:
- uttsc doesn't create new connections to the
client. It simply is an X client that connects
to windows using RDP, and uses the existing
client UDP "connections" for X rendering
traffic.

I thought that uttsc was not an X client, which is why it only
works on Sun Ray clients.  In any case, I get the same timeout
and Sun Ray reboot on login, which is simpler to troubleshoot.

- The only exception to this is that the wrapper
starts up a new, dedicated instance of utaudio
to handle the audio stream. utaudio, like the X
server and now device services, uses a special
"CALLME" protocol to handle NAT, where the
existing 7009/tcp connection is used to tell the
client to send a UDP packet in order to initiate
a new "connection", in order to handle punching
through a NAT firewall. Once a UDP packet has
been sent outwards to a particular server port
from a particular client port, the NAT firewall
ought to allow incoming traffic between the same
ports.

That sounds good to me.

I'm using VPN from behind a NAT firewall and
can connect to Windows with uttsc without problems
with SRSS 4.0, so whatever you're experiencing is
not ubiquitous.

It's interesting that it's the server sending the ICMP
packets. That doesn't sound like an obvious NAT
problem with the client.

Yes, I'm mystified now.


_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users

Reply via email to