Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Nov 1999 21:26:19 +0100
From:      Eric Masson <e-masson@kisoft-services.com>
To:        Giorgos Keramidas <keramida@ceid.upatras.gr>
Cc:        freebsd-questions@FreeBSD.ORG
Subject:   Re: ktrace/kdump output interpreting, help needed.
Message-ID:  <383AF86B.A0FA3CF3@kisoft-services.com>
References:  <383967E9.E8A2936@kisoft-services.com> <86wvranegk.fsf@localhost.hell.gr>

next in thread | previous in thread | raw e-mail | index | archive | help
Giorgos Keramidas a écrit :
> 
> Eric Masson <e-masson@kisoft-services.com> writes:
> 
> A few comments on the code before the real answer a few lines below ;)
> 
> >   sock_id=rexec(ahost,port,user,password,cmd,&fd2p);
> 
> >From the manual page of rexec(3) we read:
> 
>     The port inport specifies which well-known DARPA Internet port to
>     use for the connection; the call `getservbyname("exec", "tcp")' (see
>     getservent(3))  will return a pointer to a structure, which contains
>     the necessary port.
> 
> In /etc/services we can read that 512 is indeed the rexec port.  So
> you're right on using port 512, but to be as portable as one can be, try
> to follow the manuals more closely.  Don't mind the few extra lines of
> code that are destined to eventually prove very useful when a weird set
> of circumstances comes forth.
> 
> >   buffer = (void *)malloc(BUF_SIZE);
> 
> What if this fails for some obscure reason?  I would really prefer it
> written like:
> 
>     if ((buffer = malloc(BUF_SIZE*sizeof(char))) == NULL)
>         err(0, "whoops! memory exchausted");
> 
> >   while(count = read(sock_id,buffer,BUF_SIZE)) {
> 
> The read() system call can return a negative number too, in case of
> failure, which will pass your while() test, and have the for loop that
> follows it barf on unread and probably broken data.  Try using:
> 
>     while ((count = read(sock_id, buffer, BUF_SIZE)) > 0)
>         ... blah ...
> 
Right, I should have said that this code snippet was intented for test
purposes only :), Thanks for improvements.

> > :
> >
> >    403 rexec    CALL  nanosleep(0xbfbfdb28,0xbfbfdb20)
> >    403 rexec    RET   nanosleep 0
> >    403 rexec    CALL  socket(0x2,0x1,0)
> >    403 rexec    RET   socket 3
> >    403 rexec    CALL  connect(0x3,0xbfbfdb94,0x10)
> >    403 rexec    RET   connect -1 errno 61 Connection refused
> 
> "Connection refused"  this says a lot.  Probably rexec is not allowed
> from your host to the one you're trying to connect to.
> 
> [large snip]
> 
> >    403 rexec    CALL  connect(0x3,0xbfbfdb94,0x10)
> >    403 rexec    RET   connect -1 errno 61 Connection refused
> 
> Ditto.  You are refused the attempted connection.  A few lines below you
> can see your rexec retrying to establish the connection, but you're
> always refused from the destination host.  Finally, the error message is
> very informative of why you failed to get any meaningful output:
> 
> >    403 rexec    CALL  writev(0x2,0xbfbfdb14,0x4)
> >    403 rexec    GIO   fd 2 wrote 60 bytes
> >        "srvas4nanssv.nantes.kisoft-services.com: Connection refused
> >        "
> 
> Regards.
Right, twice. I know rexec says connection is denied, I submitted this
just because when i telnet the host on port 512, it doesn't deny
connection. So I've done the test on my FBSD workstation after i have
enabled rexecd in inetd.conf ( and of course sent a HUP to inetd). Same
result, connection refused. That's why I posted ;).

Regards

Eric

> 
> --
> Giorgos Keramidas, <keramida@ceid.upatras.gr>
> "What we have to learn to do, we learn by doing." [Aristotle]
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-questions" in the body of the message

-- 
Any opinions expressed above  | Murphy's Law Corollary :
are my own, not Kisoft's      | Murphy was an optimist.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?383AF86B.A0FA3CF3>