Conference turris::digital_unix

    Paolo
    
    Do other connections like telnet or rlogin show the same behaviour as
    ftp?
    
    And how is name resolution done?  Is it local, YP, or BIND?
    Look in /etc/svc.conf
    
    Perhaps the delay is because of the time taken to resolve the system
    name into a network address.
    
    Just a guess, hope it helps
    
    	leon

Hi Leon ,

Here are the answers to your questions ....

>> Do other connections like telnet or rlogin show the same behaviour as
>> ftp?

No , both telnet and rlogin work fine ( without any delay).

>> And how is name resolution done?  Is it local, YP, or BIND?
>> Look in /etc/svc.conf

the entry "hosts" of his /etc/svc.conf is the following...

hosts=local,bind,yp

>> Perhaps the delay is because of the time taken to resolve the system
>> name into a network address. 

The customer tried to use FTP on the node that has the problem , that is ,
the node was both "ftp client" and "ftp server" .
Moreover he used the internet address instead of the internet name ....

 #ftp xxx.yyy.zzz.www  

but the behaviour it's the same (there is a delay in presenting the login
request) 

At last he used 0 instead the internet address

 #ftp 0

but he get a delay too .


Do you have any other idea ? 

Many thanks for your cooperation   

Regards ,

Paolo 
(CSC , Milan )
     

    

Paolo

I don't have any more ideas :-(
Perhaps you could try running ftpd
with the -d debug flag to see if that
tells you anything.

	leon
[Posted by WWW Notes gateway]

Using

	# ftp a.b.c.d

instead of

	# ftp ftpserver

doesn't necessarily gain you anything. The server may be trying to a reverse 
name lookup on the socket connection, and thus you get bitten anyway if there's 
a name resolution problem. However, I'm pretty certain telnetd would be doing 
this as well.

Just for kicks, do an nslookup a.b.c.d (or d.c.b.a.in-addr.arpa depending on 
versions) to see if reverse name resolution is working properly.

PJDM

Hi ,

there are no problems with other tcp/ip services ( like TELNET , RLOGIN....),
so I think cannot be a name resolution problem .

I'd like to use tcpdump command to monitor ftp packet to and from the node .
Is the above command applicable in this situation and what could be the syntax
to get ftp packet ? 

Many thanks for your cooperation ,

Regards 

Paolo 
(CSC,Milan)    

    Just run "tcpdump host yourname" and see what comes out.
    You need to run pfconfig +c -a first, to allow monitoring
    your own packets.
    
    John
    

Note 2328 has information about building a kernel with tcpdump
and various useful tcpdump commands.  The man page has a lot
of information too.
[Posted by WWW Notes gateway]

Hi,

reminding the original problem I explained in the note .0 ....

                        *********************

CONFIGURATION :
-------------

SYSTEM_A -> ALPHA 3000/800 , Digital Unix V 3.2g

SYSTEM_B -> ALPHA 3000/800 , Digital Unix V 3.2c

Other Unix systems like AX , HPux.

PROBLEM :
-------

when he use FTP from SYSTEM_A (ftp client) to SYSTEM_B (ftp server)....

  FTP> open SYSTEM_B  .....

It works fine .

but when he use FTP from SYSTEM_B (ftp client) to SYSTEM_A (ftp server) ...

   FTP> open SYSTEM_A

he has to wait at least 1 minute before to receive the login prompt to enter
Username and Password .
The same thing happens if he tries to open SYSTEM_A (via ftp from others no DEC
Unix systems. 

  
                   ***********************

The last test I asked to the customer was ...

1) on the SYSTEM_B (ftp client) he ran the tcpdump utility :

   # pfconfig +c -a

   # tcpdump ip host SYSTEM_B

2) On a second window of the SYSTEM_B he begun the ftp to the SYSTEM_A :

   FTP> open SYSTEM_A
   Connected to system_a.
   
   ... at this point he had to wait to receive the login prompt
       and on the window where he ran tcpdump he could read the following
       packet traces.... 

17:18:57.475985 system_b.xxx.yyy.zzz.1110 > system_a.ftp:
S 1872576000:1872576000(0) win 32768 <mss 1460,nop,[|tcp]> (DF)

17:18:57.477939 system_a.ftp > system_b.xxx.yyy.zzz.1110:
S 1640192000:1640192000(0) ack 1872576001 win 33580 <mss 1460,nop,[|tcp]> (DF)

17:18:57.477939 system_b.xxx.yyy.zzz.1110 > system_a.ftp: . ack 1 win 33580 (DF)

   ...after 1 minute he received the login prompt ...

    220 system_a.xxx.yyy.zzz FTP server (Digital UNIX Version 5.60) ready.
    Name (system_a:user):

   ...and on the window where he ran tcpdump he could read the following
      packet traces


17:18:58.198642 system_a.ftp > system_a.xxx.yyy.zzz.1110:
P 1:71(70) ack 1 win 33580 (DF) [tos 0x10]

17:18:58.301181 system_b.xxx.yyy.zzz.1110 > system_a.ftp:
. ack 71 win 33580 (DF) [tos 0xa0]


At this point we could say that the SYSTEM_A (ftp server) send the packet   
 "17:18:58.198642 system_a.ftp > system_a.xxx.yyy.zzz.1110:
 P 1:71(70) ack 1 win 33580 (DF) [tos 0x10]"
many seconds late .

What does this packet means/does ? ( I can see it's marked as P(push) packet )

Could anyone help me to understand the results of the above test ?

NB : After he get the username request all work ok.

Many thanks in advance 

Regards 

Paolo
(CSC , Milan)

*****************************************************************************
PS
reply to note .4

>>just for kicks, do an nslookup a.b.c.d (or d.c.b.a.in-addr.arpa depending on
>>versions) to see if reverse name resolution is working properly.

doing an nslookup a.b.c.d from SYSTEM_B using tcp/ip address of SYSTEM_A ,
It works.
*****************************************************************************
  

    

    Hi,
    
    it could be better to open an IPMT ?
    
    many thanks in advance 
    
    Regards 
    
    Paolo
    (CSC , Milan)

    Hi,
    
    The problem was that in the file /etc/hosts of the SYSTEM_A (ftp
    server) there was not the entry:
    
    127.0.0.1       localhost
    
    Regards
    
    Paolo
    (CSC, Milan)