[clug-talk] nasty problem

Gustin Johnson gustin at echostar.ca
Wed May 17 23:20:31 PDT 2006

Hash: SHA1

Robert Lewko wrote:
> This application has taken some time to develop and last friday when i
> was on his site, actually his truck where the application runs, the
> application was able to recover from lack of satellite signal.  The
> typical period where the satellite is out of range is about 10 minutes.
> What is happening this afternoon is that the signal meter on the modem
> is showing strong signal and there is no data getting back.  Like I said
> before the packets are getting to the server but not being returned to
> the client.
> Usually when I lose packets there may be one or two per minute, but the
> client side of this application is designed that the client is in
> control of the communication and it will retransmit until it receives
> the ack from the server.  Actually I got the design from Stevens "Unix
> Network Programming" the chapter that discusses advanced UDP.
> So to sum up I think that something upstream is blocking the packets on
> the return trip.  Again this is the first time that I have seen the
> network act like this for an extended period of time.  My guess is that
> some admin set something somewhere so that these packets are getting
> lost. I just don't know what to do in this case.
> I repeat.  My code is working when the packets get through.

Why are you using UDP instead of TCP?  Since your app is going over
satellite, and latency is not as much of an issue as reliability, TCP
seems better suited.  If a UDP packet is lost on the wire, there is no
mechanism to help you isolate the problem.  It is possible that your app
is being filtered.  You could try to change the port, but I would
seriously consider TCP.  Keep in mind I am a network admin and not a
developer, you may have a valid reason for using UDP, it is just S.E.P.
from my point of view.

If  you really must use UDP, the following is designed to send and log
UDP packets (linux only btw).  It does not have a lot of documentation
but can be useful:

You may also find nemesis (packaged in Debian, so likely in most
distros) and Scapy (http://www.secdev.org/projects/scapy/) helpful.

Of course you need control at both ends to do effective troubleshooting
of the cloud in the middle.  Most help desks are not that useful until
you have something specific for them to escalate.

> On 5/17/06, *Aaron J. Seigo* <aseigo at kde.org <mailto:aseigo at kde.org>>
> wrote:
>     On Wednesday 17 May 2006 19:02, Robert Lewko wrote:
>     > I am using UDP because the client is using a satellite modem.  The
>     server
>     > uses UDP port 9608.  When the server gets a packet it just gets
>     the source
>     > address and returns the response packet to the sender.  Like I
>     said I have
>     > had no problem with that port both while I have been developing
>     the code
>     > and for the last week until this afternoon.
>     as you know, udp has no guarantee of delivery (or ordering for that
>     matter).
>     so if there are any network issues whatsoever you can lose udp
>     packets pretty
>     easily; tcp packets will resend when they aren't ack'd. if you need
>     guarantees with udp you usually end up setting up some sort of
>     ack-on-failure
>     (as opposed to tcp's ack on success which suppresses a resend).
>     welcome to
>     udp =)
>     --
>     Aaron J. Seigo
>     GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>     Full time KDE developer sponsored by Trolltech
>     (http://www.trolltech.com <http://www.trolltech.com>)
>     _______________________________________________
>     clug-talk mailing list
>     clug-talk at clug.ca <mailto:clug-talk at clug.ca>
>     http://clug.ca/mailman/listinfo/clug-talk_clug.ca
>     <http://clug.ca/mailman/listinfo/clug-talk_clug.ca>
>     Mailing List Guidelines (http://clug.ca/ml_guidelines.php)
>     **Please remove these lines when replying
> ------------------------------------------------------------------------
> _______________________________________________
> clug-talk mailing list
> clug-talk at clug.ca
> http://clug.ca/mailman/listinfo/clug-talk_clug.ca
> Mailing List Guidelines (http://clug.ca/ml_guidelines.php)
> **Please remove these lines when replying
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the clug-talk mailing list