Re: pfinet & ftp & hang, round two (much simpler case)

[Marcus Brinkmann]

Hi,

here a finer analysis of the log, and some conclusions.

Btw, I think it would be very useful to replace newlines in strings by \n.
Same for other special characters.  Do you agree?


On Thu, Jun 07, 2001 at 01:41:51AM +0200, Marcus Brinkmann wrote:
>   90->26013 (65535 256 "
") = 0 
>   90->21013 () = 0 {21 329 0 134737936 0 0 49663 0 0 0 0 0 0 0 0 0 0 512 0 0 
> 0 0 0 0 0 0 0 0 0 0 0 0}
>   90->21009 (335) = 0x4000002d (Operation not supported) 
>   90->21013 () = 0 {21 329 0 134737936 0 0 49663 0 0 0 0 0 0 0 0 0 0 512 0 0 
> 0 0 0 0 0 0 0 0 0 0 0 0}
>   90->21002 (0 1) = 0x4000001d (Illegal seek) 
>   90->21000 ("220 ulysses FTP server (GNU inetutils 1.3.2) ready.

90 is the ftpd.  2100 for example is io_write.

> reply? 102 > 0 
>   90->21001 (-1 512) >  102 ...

ftpd waits for a command.

>   84->21013 () = 0 {21 329 0 134735144 0 0 49663 0 0 0 0 0 0 0 0 0 0 512 0 0 
> 0 0 0 0 0 0 0 0 0 0 0 0}
>   84->21002 (0 1) = 0x4000001d (Illegal seek) 
>   84->21000 ("USER marcus
> " -1)task329-> 2024 (134742016 4096 0 7) = 0 

ftp (84) sends the USER command.

> reply? 102 > 0 "USER marcus
> "

which is received.

>   84->21001 (-1 512)  90->21000 ("331 Password required for marcus.
> " -1) = 0 35

ftp reads. ftpd sends password request.

> reply? 102 > 0 "331 Password required for marcus.
> "

ftp receives it.

>   90->21001 (-1 512)  84->21000 ("PASS XXXXXX

ftpd reads.  We send passwd.

> reply? 102 > 0 "PASS XXXXXX

ftpd receives the passwd.

>   84->21001 (-1 512)  90->21014 (  92);

ftp reads. ftpd reauthenticates with pfinet.

>   72->21000 ("230- 
> " -1)task329-> 3208 (pn{ 52} 1 -1) = 0 

ftpd (now 72) sends first line of text.

> reply? 102 > 0 "230- 
> "

ftp receives it.

>   72->21000 ("230- 
> " -1) = 0 7

ftpd sends another line.

>   84->21001 (-1 512)  72->21000 ("230- Most of the programs included with the 
> Debian GNU/Hurd system are

ftp (still 84) reads.  ftpd sends even more stuff:

> " -1) = 0 72
>   72->21000 ("230- freely redistributable; the exact distribution terms for 
> each program
> " -1) = 0 76
>   72->21000 ("230- are described in the individual files in 
> /usr/share/doc/*/copyright
> " -1) = 0 74
>   72->21000 ("230- 
> " -1) = 0 7
>   72->21000 ("230- Debian GNU/Hurd comes with ABSOLUTELY NO WARRANTY, to the 
> extent
> " -1) = 0 71
>   72->21000 ("230- permitted by applicable law.
> " -1) = 0 35
>   72->21000 ("230 User marcus logged in.
> " -1) = 0 28
>   68->21001 (-1 512)  44->23009 ( task329 4 -1) = 0 

Note two things here:

1. ftp has not received all the lines ftpd sent.  It never got woken up
   (supposedly by tcp_sendmsg? Maybe because several lines came in a rush,
    but not enough to trigger a flush???).
2. The 68->io_read is not ftp (I think), it is ftpd waiting for a new ftp
   command.

The 44->23009 is gdb attaching to the now blocking pfinet.

In particular, there is no difference in the sequence of RPCs that would
explain why pfinet doesn't wake up the blocking read.  Everything is
happening at a finer level than rpctrace can show us, as it seems at the
sendmsg/recvmsg level (rather than select).

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de