3a3adc2a   
   From: barmar@alum.mit.edu   
      
   In article   
   ,   
    feenberg  wrote:   
      
   > We have fortran program that we wish to use as a network service under   
   > xinetd. The program reads a line from standard in, then writes 1 or 4   
   > lines to standard out, like a filter. We use various versions of   
   > netcat to send data, and for small input files this always works. But   
   > once we get above a 100 or so lines of input, it is likely to hang. It   
   > doesn't always hang, and the behavior seems in no way data dependent.   
   > (Called directly from the command line it never hangs). We have been   
   > tearing out our hair trying to debug the problem, but changing the   
   > client netcat, the server OS and the fortran compiler in no way affect   
   > the outcome. We added a "flush" command to flush the standard output   
   > after each output record, to no avail.   
   >   
   > I fired up tcpdump on the server without knowing much about   
   > interpreting the output and noticed that while the program was   
   > running, the recognizable data and output was in the tcpdump output.   
   > Once the client hangs, the following is shown every minute or two:   
   >   
   > 09:45:42.466915 IP (tos 0x0, ttl 64, id 10888, offset 0, flags [DF],   
   > proto TCP (6), length 53) nber16.nber.org.taxsim > nber3.nber.org.   
   > 54628: ., cksum 0x16ec (incorrect (-> 0x505f), 0:1(1) ack 1 win 0   
   >    
   > E..5*.@.@..vB.H.B.HI...d...................8....3..   
   >   
   > and stops when the client netcat is killed. I notice that the chksum   
   > is always incorrect on these packets. Does this indicate something   
   > wrong with the client? Or is it just a "keepalive" that uses the   
   > incorrect checksum to avoid tickling the server?   
      
   Are these the only packets with the incorrect checksum?  If not, it's   
   probably because your system offloads checksum processing to the NIC, as   
   many modern systems do, and unrelated to your problem.   
      
   The packet looks like a zero-window probe.  Has the client closed the   
   window?   
      
   >   
   > Any help much appreciated.   
   >   
   > Here is our  xinetd configuration file:   
   >   
   > service taxsim   
   > {   
   >         disable = no   
   >         socket_type     = stream   
   >         wait            = no   
   >         user            = nobody   
   >         server          = /usr/local/bin/taxsim   
   >         port = 1040   
   > }   
   >   
   > BTW, the program calculates US federal and state income tax liabilites   
   > from basic data likely to be available in surveys - hence using port   
   > 1040.. We have versions for Linux, Solaris and FreeBSD.   
   >   
   > Daniel Feenberg   
   > feenberg isat nber dotte org   
   > 617-588-0343   
      
   --   
   Barry Margolin, barmar@alum.mit.edu   
   Arlington, MA   
   *** PLEASE don't copy me on replies, I'll read them in the group ***   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)