Re: rsh working intermittently

On 2 Feb 2006, in the Usenet newsgroup linux.redhat, in article
<1138902407.808559.263340@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, Tom wrote:

As you suggested I did capture the pockets for relevant sessions. I
filled in the translations in between your explainations of the tcpdump
output ('english' is the last column). I hope you can spot something
interesting.

No, we're missing one. Are you familiar with tcpdump output? Grabbing
the first one as an example:

09:32:30.789017 IP 127.0.0.1.1020 > 127.0.0.1.shell: S 1001125640:1001125640(0)
win 32767 <mss 16396,sackOK,timestamp 234146929 0,nop,wscale 2>
0x0000: 4500 003c 3b79 4000 4006 0141 7f00 0001 E..<;y@.@..A....
0x0010: 7f00 0001

That much is the IP header - nothing unusual (see RFC0791) From the
same packet, we continue

03fc 0202 3bab f708 0000 0000 ........;.......
0x0020: a002 7fff 7c93 0000 0204 400c 0402 080a ....|.....@.....
0x0030: 0df4 cc71 0000 0000 0103 0302 ...q........

That's the TCP header, with this one containing options which is why
the first character at location 0x0020 (here 'a') being the length of
the header in 32 bit words is not the default 5. See RFC0793.

The spot where things seem to go awry is at

09:32:30.791978 IP 127.0.0.1.1020 > 127.0.0.1.shell:

where (clipping the headers) we see

7464 726f 7a64 6100 7464 726f ...qtdrozda.tdro
0x0040: 7a64 6100 6c73 00 zda.ls.

which in English is "tdrozda" (username on client), "00" (null terminator)
"tdrozda" (username on server), "00" (null terminator), and the command
"ls" with a final null terminator. The next packet shown

09:32:30.792004 IP 127.0.0.1.shell > 127.0.0.1.1020:

is an empty ACK of the bits in the preceding packets. THEN the server
sends

0150 6572 6d69 7373 696f 6e20 ...t.Permission.
0x0040: 6465 6e69 6564 2e0a denied..

with is presumably the rshd barfing for an unknown reason. If you still have
these data files, what is in the packet that precedes

09:38:41.554623 IP 127.0.0.1.shell > 127.0.0.1.1023:

This packet is the empty ACK which should correspond to 09:32:30.792004.

09:38:41.554663 IP 127.0.0.1.1023 > 127.0.0.1.shell

is an empty ACK the other way, and

09:38:41.593324 IP 127.0.0.1.shell > 127.0.0.1.1023:

is the desired directory listing. What I'm hoping you'll see in comparing
to 09:32:30.791978 something subtle/stupid/what-ever. If you DON'T see
a difference, then it's got to be something strange going on in the
server, and that's going to be a lot harder to troubleshoot.

Isn't this fun? I haven't had to try to debug a rsh connection
(literally) in _years_!

Indeed it is alot of fun. Unfortunately I am not as versed in the
inner workings of these protocols.

I haven't had to debug rsh since roughly 1997, and we stopped using it
roughly in 2000 after some hand-wringing by a new boss. We were only
using it on the admin subnet which is isolated, but paranoia is part of
the way of life here. I checked my home systems, and it's not even
installed there.

Old guy
.

Relevant Pages

  • Re: rsh working intermittently
    ... No I do not fully know what tcpdump displays. ... First success, then ... That's the TCP header, with this one containing options which is why ... The next packet shown ...
    (linux.redhat)
  • RE: Transfer a sending packet to upper TCP/IP protocol layer in IM
    ... If the IPv6 address can be resolved, ... IPv4 header will be larger than the MTU. ... After prepending IPv4 header and UDP header to the original IPv6 packet, ...
    (microsoft.public.development.device.drivers)
  • Re: sendfile(2) SF_NOPUSH flag proposal
    ... limiting factor to be PCI bus bandwidth first, memory second, ... > in separate packet nevertheless the size of header and of the file. ... So when a retransmit, if any, is necessary, the packet stream ...
    (freebsd-arch)
  • RE: Transfer a sending packet to upper TCP/IP protocol layer in IM
    ... The original MAC header is INVALID because my IM driver will assign a new ... After prepending IPv4 header and UDP header to the original IPv6 packet, ...
    (microsoft.public.development.device.drivers)
  • [EXPL] autoRST - Automated TCP RST Exploit
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... sniff for TCP packets on a network and then sends out a forged RST packet ... * winpcap header files downloaded and paths setup. ... typedef struct mac_address { ...
    (Securiteam)