On Thu, Oct 06, 2005 at 09:40:21AM +0200, Guus Sliepen <[EMAIL PROTECTED]>
wrote:
> On Thu, Oct 06, 2005 at 06:15:43AM +0200, Marc Lehmann wrote:
> > Replacing rsh-redone-server by rsh-server fixes this problem completely.
>
> I'll have a look at the difference between rsh-server and
> rsh-redone-server. I guess it is because rsh-redone-server lets some
> sockets linger longer than rsh-server...
Could be the underlying reason, but I run into problems even with ~20 quick
rsh connections, and I'd think it should be easy to come up with 20 free
sockets.
> > Sometimes I get this message in the syslog:
> >
> > Oct 6 06:02:47 (none) in.rshd: Connection from cerebro on illegal port 0.
>
> This is about the primary connection, not the stderr connection.
Interesting, as I wouldn't even know how to create such a connection
(it doesn't seem possible to do that under linux, which is what the the
machine doing rsh uses).
> > Sometime this:
> >
> > Oct 6 06:02:43 (none) in.rshd: Error while receiving stderr port number
> > from cerebro: Success
>
> That can only be if read() returns 0, which means the other end closed
> the connection. I should indeed change the error message.
Indeed, errno could have about any value when read returns 0 (not under
glibc, though).
It seems something more fishy is going on than misparsing the port number, as
connections on port 0 cannot be created, and rsh should not immediately close
the connections.
Seems as if, at the time when in.rshd gets to the getsockname and (later?)
to read, the connection was already gone, or never existed.
> > Incidentaly, port 0 is a valid stderr port number in the protocol, so this
> > should be supported.
>
> It accepts port 0 as a stderr port without errors, but will not set up a
> socket in that case.
That is then correct behaviour.
> > I will likely not be able to test this further, as the other
> > incompatibilities of rsh-redone finally forced me to uninstall it
> > everywhere, but the above should makme it possible at least to fix the
> > stderr-port-is-0 bug.
>
> Thanks for the bugreport. By the way, how many rsh connections per
> second do you get?
Correct ones? No idea, it seems that the time range is longer, as in "n
connections per minute", which would support the lingering sockets theory,
although it's hard to explain with that.
> And if you run netstat, do you see sockets in
> TIME_WAIT (or other _WAIT) states?
I don't have any rsh-redone-server machine readily availble for such
testing, but will set up one and check more on that. Now that its clear
that it isn't some simple port-number-bug I can watch out for differences
in behaviour with regads to which side closes first and wether we end up
in time_wait or some other state.
--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ [EMAIL PROTECTED]
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
