hosts.allow does not resolve names

hosts.allow does not work with network names.
Would some kind soul tell me why it does not work?

/etc/hosts.allow fails with
ALL: .home.invalid
but ALL: 192.168.1.0/255.255.255.0 works.


$ hostname --domain
home.invalid

$ grep hosts: /etc/nsswitch.conf
hosts: files dns

$ cat /etc/host.conf
order hosts,bind
multi on
nospoof on
spoofalert on

$ head -4 /etc/hosts
127.0.0.1 localhost
192.168.1.213 m2008.home.invalid m2008
192.168.1.11 fw.home.invalid fw
192.168.1.130 wb.home.invalid wb

Running Mandriva Linux release 2008.0

Not running named/bind, NIS, YP. avahi*, tmdns

Tried tcpdchk but Mandirva runs xinetd instead of inetd so it fails.

On Tue, 27 Nov 2007 07:13:05 GMT, Bit Twister wrote:
> hosts.allow does not work with network names.
> Would some kind soul tell me why it does not work?
>
> /etc/hosts.allow fails with
> ALL: .home.invalid
> but ALL: 192.168.1.0/255.255.255.0 works.

Sorry, forgot the error messages.

From /var/log/messages I would get
Nov 26 18:56:24 m2008 portmap[5640]: connect from 192.168.1.130 \
to getport(nfs): request from unauthorized host

when using ALL: .home.invalid
I would get the NFS mount with ALL: 192.168.1.0/255.255.255.0



Hosts.deny mails me this message

TCP Wrappers: Connection Refused
By: m2008.home.invalid
Process: portmap (pid 3676)

User: unknown
Host: 192.168.1.130
Date: Mon Nov 26 18:56:23 CST 2007

On Tue, 27 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <(E-Mail Removed)>, Bit Twister wrote:

>hosts.allow does not work with network names.

OPINION: I don't like to use hostnames, as they are subject to spoofing.
IP addresses are harder to spoof. Yes, in this case, it shouldn't be
a major concern, but I go for blanket solutions.

>Would some kind soul tell me why it does not work?
>
>/etc/hosts.allow fails with
> ALL: .home.invalid
>but ALL: 192.168.1.0/255.255.255.0 works.

OK - syntax looks correct. No errant space or anything?

> hostname --domain
>home.invalid
>
>$ grep hosts: /etc/nsswitch.conf
>hosts: files dns
>
>$ cat /etc/host.conf
>order hosts,bind
>multi on
>nospoof on
>spoofalert on

If you drop the last two, does it work?

>$ head -4 /etc/hosts

OK. Assumption is no other lines containing those IP addresses.

>Not running named/bind, NIS, YP. avahi*, tmdns

If you do a 'strings | grep host /path/to/tcpd' you will see that it's
using a standard 'gethostbyaddr' and 'gethostbyname' library calls, so
if you can 'ping -c 1 m2008.home.invalid' then tcpd _should_ work. You
may want to up the log level, because this same 'strings' command shows

can't verify hostname: gethostbyname(%s) failed

as one of the error messages. In your followup, you show tcpd logging
the full name, so I _believe_ it is resolving the name (otherwise, it
would be logging the IP), or am I mis-interpreting your mail snip?

>Tried tcpdchk but Mandirva runs xinetd instead of inetd so it fails.

That's a problem. Wietse Venema hasn't been maintaining the application
for many years (7.6 is from March 1997), while xinetd was introduced in
late 2000. You might try an 'strace' of xinitd but that sounds kind of
messy.

Old guy

On Tue, 27 Nov 2007 13:26:08 -0600, Moe Trin wrote:
> article <(E-Mail Removed)>, Bit Twister wrote:
>
> OPINION: I don't like to use hostnames, as they are subject to spoofing.
> IP addresses are harder to spoof. Yes, in this case, it shouldn't be
> a major concern, but I go for blanket solutions.

I hear where you are comming from. Was just trying to keep maintenance
down while changing LAN ip values. Last resort is to script the LAN ip change.

>>/etc/hosts.allow fails with
>> ALL: .home.invalid
>>but ALL: 192.168.1.0/255.255.255.0 works.
>
> OK - syntax looks correct. No errant space or anything?

Nope, latest test
ALL: 192.168.1.
works,

ALL: .home.invalid
fails. So does ALL: wb.home.invalid, m2008.home.invalid


>>$ cat /etc/host.conf
>>order hosts,bind
>>multi on
>>nospoof on
>>spoofalert on
>
> If you drop the last two, does it work?

No, and changing last two to off did not work either.


>>$ head -4 /etc/hosts
>
> OK. Assumption is no other lines containing those IP addresses.

No,
$ grep 213 /etc/hosts
192.168.1.213 m2008.home.invalid m2008

$ grep m2008 /etc/hosts
192.168.1.213 m2008.home.invalid m2008


> If you do a 'strings | grep host /path/to/tcpd' you will see that it's
> using a standard 'gethostbyaddr' and 'gethostbyname' library calls, so
> if you can 'ping -c 1 m2008.home.invalid' then tcpd _should_ work.

Dang it, pings work, but NFS mount still fails with ALL: .home.invalid
Nov 27 13:57:33 m2008 portmap[4702]: connect from 192.168.1.130 \
to getport(nfs): request from unauthorized host

$ cat /etc/exports
/local wb(rw,no_root_squash,sync)

$ ping -c 1 wb
PING wb.home.invalid (192.168.1.130) 56(84) bytes of data.
64 bytes from wb.home.invalid (192.168.1.130): icmp_seq=1 ttl=64 time=0.185 ms

--- wb.home.invalid ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.185/0.185/0.185/0.000 ms


> as one of the error messages. In your followup, you show tcpd logging
> the full name, so I _believe_ it is resolving the name (otherwise, it
> would be logging the IP), or am I mis-interpreting your mail snip?

It would be misleading

$ cat /etc/hosts.deny

ALL: ALL:\
spawn ( \
/bin/echo -e "\n\
TCP Wrappers\: Connection Refused\n\
By\: $(uname -n)\n\
Process\: %d (pid %p)\n\
\n\
User\: %u\n\
Host\: %c\n\
Date\: $(date)\n\
" | /bin/mail -s \"$(uname -n)\" root ) & : DENY

#****************** end hosts.deny ************


but system is resolving correctly

$ ping -c 1 $(uname -n)
PING m2008.home.invalid (192.168.1.213) 56(84) bytes of data.
64 bytes from m2008.home.invalid (192.168.1.213) icmp_seq=1 ttl=64 time=0.075 ms

--- m2008.home.invalid ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.075/0.075/0.075/0.000 ms


> That's a problem. Wietse Venema hasn't been maintaining the application
> for many years (7.6 is from March 1997), while xinetd was introduced in
> late 2000. You might try an 'strace' of xinitd but that sounds kind of
> messy.

Yes, that would be a bit of tracing since I am trying to make an NFS
mount from wb.home.invalid

Open/no firewalls on both systems makes no difference.


Thank you for your time.

On Nov 26, 11:13 pm, Bit Twister <BitTwis...@mouse-potato.com> wrote:
> hosts.allow does not work with network names.
> Would some kind soul tell me why it does not work?

How would it know the host name? How do you imagine it works?

DS

On Tue, 27 Nov 2007 16:46:31 -0800 (PST), David Schwartz wrote:
>
> How would it know the host name?

It would look up the name in /etc/hosts

> How do you imagine it works?

I imagined it would work like man hosts.allow indicates

The access control language implements the following patterns:

· A string that begins with a ‘.´ character. A host name is
matched if the last components of its name match the specified
pattern. For example, the pattern ‘.tue.nl´ matches the host
name ‘wzv.win.tue.nl´.

then looking through man -s 5 hosts_access the example

/etc/hosts.allow:
ALL: LOCAL @some_netgroup
ALL: .foobar.edu EXCEPT terminalserver.foobar.edu


would suggest it should work. :-D

Feel free to look through the rest of the thread for more info.

On Tue, 27 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <(E-Mail Removed)>, Bit Twister wrote:

>Moe Trin wrote:

>> OPINION: I don't like to use hostnames, as they are subject to spoofing.
>> IP addresses are harder to spoof. Yes, in this case, it shouldn't be
>> a major concern, but I go for blanket solutions.
>
>I hear where you are comming from. Was just trying to keep maintenance
>down while changing LAN ip values.

Very simple solution. Two lines - one with the old range, one with the
new. The assumption is that your perimeter firewall is doing RFC2827
or RFC3704 filtering ("internal" IP addresses can't be coming in as
sources on the "external" interface), so having

ALL: 192.168.1.
ALL: 192.168.231.

isn't going to be opening a massive hole.

>ALL: .home.invalid
>fails. So does ALL: wb.home.invalid, m2008.home.invalid

OK - that rules out the space problem (hate to say how many times that
has caught people.

>>>$ cat /etc/host.conf

>> If you drop the last two, does it work?
>
>No, and changing last two to off did not work either.

OK

>> OK. Assumption is no other lines containing those IP addresses.
>
>No,
>$ grep 213 /etc/hosts
>192.168.1.213 m2008.home.invalid m2008
>
>$ grep m2008 /etc/hosts
>192.168.1.213 m2008.home.invalid m2008

OK - that's another one that trips people.

>> if you can 'ping -c 1 m2008.home.invalid' then tcpd _should_ work.
>
>Dang it, pings work, but NFS mount still fails with ALL: .home.invalid

NFS... Something is back there, and I can't think what. Have you got
any other daemon that is running out of xinetd? Because,

>Nov 27 13:57:33 m2008 portmap[4702]: connect from 192.168.1.130 \
> to getport(nfs): request from unauthorized host

that's portmap bitching, not tcpd or xinetd.

>$ cat /etc/exports
>/local wb(rw,no_root_squash,sync)
>
>$ ping -c 1 wb
>PING wb.home.invalid (192.168.1.130) 56(84) bytes of data.

OK - gethostbyname is working

>> or am I mis-interpreting your mail snip?
>
>It would be misleading

Got it. I'm not used to that format. The %c being only the IP, it's not
resolving for tcpd. Quick look - is there anything obvious in a packet
dump? By that, I mean who is trying to talk to who - port numbers, etc.
Rejections? Ignores? I'd be more trying to compare the packets
between hosts.allow set with IPs verses net-names.

>Open/no firewalls on both systems makes no difference.

No, this is something else, and I can't think what it might be. There
is something ringing an alarm bell for me, and it's related to NFS, not
tcpd. But WHAT is it? At thing point, I don't know.

Old guy

On Tue, 27 Nov 2007 20:23:26 -0600, Moe Trin wrote:
> article <(E-Mail Removed)>, Bit Twister wrote:
>
> Very simple solution. Two lines - one with the old range, one with the
> new.

Yes, but I really wanted the names to work.

It's kinda like doing the math problems which have the answers in the
back of the book. I could work the ones with answers and could not
work out the answer of the ones without the answers.


> NFS... Something is back there, and I can't think what. Have you got
> any other daemon that is running out of xinetd? Because,

Nope.
xinetd based services:
cups-lpd: off
cvs: off
proftpd-xinetd: off
rexec: off
rlogin: off
rsh: off
rsync: off
sshd-xinetd: off


>
>>Nov 27 13:57:33 m2008 portmap[4702]: connect from 192.168.1.130 \
>> to getport(nfs): request from unauthorized host
>
> that's portmap bitching, not tcpd or xinetd.

Yes, but hosts.allow changes is what is keeping portmap from allowing
the nfs request.


> Quick look - is there anything obvious in a packet
> dump? By that, I mean who is trying to talk to who - port numbers, etc.
> Rejections? Ignores? I'd be more trying to compare the packets
> between hosts.allow set with IPs verses net-names.

I'll get a packet dump tomorrow.


>>Open/no firewalls on both systems makes no difference.

It was a quick check, I was wondering if auth needed access and wanted
to rule it out.


> No, this is something else, and I can't think what it might be. There
> is something ringing an alarm bell for me, and it's related to NFS, not
> tcpd. But WHAT is it? At thing point, I don't know.

Only other thing I thought of was:
Three different versions of the NFS protocol are supported by the Linux
NFS client: NFS version 2, NFS version 3, and NFS version 4. To mount
via NFS version 2, use the nfs file system type and specify nfsvers=2.
To mount via NFS version 3, use the nfs file system type and specify
nfsvers=3. Version 3 is the default protocol version for the nfs file
system type when nfsvers= is not specified on the mount command and
both client and server support it. To mount via NFS version 4, use the
nfs4 file system type. The nfsvers= keyword is not supported for the
nfs4 file system type.

That is why I went with
[bittwister@wb ~]$ grep m2008 /etc/fstab
m2008:/local /mlocal nfs rsize=32768,wsize=32768,timeo=14,intr 0 0

Did not want to get buried in Kerberos and whatnot.

On Tue, 27 Nov 2007 20:23:26 -0600, Moe Trin wrote:
> article <(E-Mail Removed)>, Bit Twister wrote:

> Quick look - is there anything obvious in a packet dump?

Not to my untrained eye. Here is fail followed by works.

$ cat /etc/hosts.allow
ALL: .home.invalid


arp who-has m2008 tell wb
arp reply m2008 is-at 00:a0:cc:e6:de:71 (oui Unknown)
IP wb.57491 > m2008.sunrpc: S 1265898696:1265898696(0) win 5840 <mss 1460,sackOK,timestamp 97857955 0,nop,wscale 6>
IP m2008.sunrpc > wb.57491: S 301091153:301091153(0) ack 1265898697 win 5792 <mss 1460,sackOK,timestamp 4295895 97857955,nop,wscale 6>
IP wb.57491 > m2008.sunrpc: . ack 1 win 92 <nop,nop,timestamp 97857956 4295895>
IP wb.57491 > m2008.sunrpc: P 1:61(60) ack 1 win 92 <nop,nop,timestamp 97857956 4295895>
IP m2008.sunrpc > wb.57491: . ack 61 win 91 <nop,nop,timestamp 4295895 97857956>
IP m2008.sunrpc > wb.57491: P 1:33(32) ack 61 win 91 <nop,nop,timestamp 4295943 97857956>
IP wb.57491 > m2008.sunrpc: . ack 33 win 92 <nop,nop,timestamp 97858004 4295943>
IP wb.57491 > m2008.sunrpc: F 61:61(0) ack 33 win 92 <nop,nop,timestamp 97858004 4295943>
IP wb.34026 > m2008.sunrpc: UDP, length 56
IP m2008.sunrpc > wb.57491: . ack 62 win 91 <nop,nop,timestamp 4295983 97858004>
IP m2008.sunrpc > wb.34026: UDP, length 28
IP wb.39341 > m2008.sunrpc: S 1390155097:1390155097(0) win 5840 <mss 1460,sackOK,timestamp 97858075 0,nop,wscale 6>
IP m2008.sunrpc > wb.39341: S 429023936:429023936(0) ack 1390155098 win 5792 <mss 1460,sackOK,timestamp 4296014 97858075,nop,wscale 6>
IP wb.39341 > m2008.sunrpc: . ack 1 win 92 <nop,nop,timestamp 97858075 4296014>
IP wb.39341 > m2008.sunrpc: P 1:61(60) ack 1 win 92 <nop,nop,timestamp 97858075 4296014>
IP m2008.sunrpc > wb.39341: . ack 61 win 91 <nop,nop,timestamp 4296014 97858075>
IP m2008.sunrpc > wb.39341: P 1:33(32) ack 61 win 91 <nop,nop,timestamp 4296097 97858075>
IP wb.39341 > m2008.sunrpc: . ack 33 win 92 <nop,nop,timestamp 97858158 4296097>
IP wb.39341 > m2008.sunrpc: F 61:61(0) ack 33 win 92 <nop,nop,timestamp 97858158 4296097>
IP wb.34026 > m2008.sunrpc: UDP, length 56
IP m2008.sunrpc > wb.39341: . ack 62 win 91 <nop,nop,timestamp 4296137 97858158>
IP m2008.sunrpc > wb.34026: UDP, length 28
IP wb.47852 > m2008.sunrpc: S 1545191974:1545191974(0) win 5840 <mss 1460,sackOK,timestamp 97858243 0,nop,wscale 6>
IP m2008.sunrpc > wb.47852: S 599734652:599734652(0) ack 1545191975 win 5792 <mss 1460,sackOK,timestamp 4296182 97858243,nop,wscale 6>
IP wb.47852 > m2008.sunrpc: . ack 1 win 92 <nop,nop,timestamp 97858243 4296182>
IP wb.47852 > m2008.sunrpc: P 1:61(60) ack 1 win 92 <nop,nop,timestamp 97858243 4296182>
IP m2008.sunrpc > wb.47852: . ack 61 win 91 <nop,nop,timestamp 4296182 97858243>
IP m2008.sunrpc > wb.57491: F 33:33(0) ack 62 win 91 <nop,nop,timestamp 4296209 97858004>
IP wb.57491 > m2008.sunrpc: . ack 34 win 92 <nop,nop,timestamp 97858271 4296209>
IP m2008.sunrpc > wb.47852: P 1:33(32) ack 61 win 91 <nop,nop,timestamp 4296282 97858243>
IP wb.47852 > m2008.sunrpc: . ack 33 win 92 <nop,nop,timestamp 97858343 4296282>
IP wb.47852 > m2008.sunrpc: F 61:61(0) ack 33 win 92 <nop,nop,timestamp 97858343 4296282>
IP wb.34026 > m2008.sunrpc: UDP, length 56
IP m2008.sunrpc > wb.47852: . ack 62 win 91 <nop,nop,timestamp 4296322 97858343>
IP m2008.sunrpc > wb.34026: UDP, length 28
IP wb.54466 > m2008.sunrpc: S 1789680568:1789680568(0) win 5840 <mss 1460,sackOK,timestamp 97858482 0,nop,wscale 6>
IP m2008.sunrpc > wb.54466: S 834056044:834056044(0) ack 1789680569 win 5792 <mss 1460,sackOK,timestamp 4296421 97858482,nop,wscale 6>
IP wb.54466 > m2008.sunrpc: . ack 1 win 92 <nop,nop,timestamp 97858482 4296421>
IP wb.54466 > m2008.sunrpc: P 1:61(60) ack 1 win 92 <nop,nop,timestamp 97858483 4296421>
IP m2008.sunrpc > wb.54466: . ack 61 win 91 <nop,nop,timestamp 4296421 97858483>
IP m2008.sunrpc > wb.39341: F 33:33(0) ack 62 win 91 <nop,nop,timestamp 4296480 97858158>
IP wb.39341 > m2008.sunrpc: . ack 34 win 92 <nop,nop,timestamp 97858542 4296480>
IP m2008.sunrpc > wb.54466: P 1:33(32) ack 61 win 91 <nop,nop,timestamp 4296542 97858483>
IP wb.54466 > m2008.sunrpc: . ack 33 win 92 <nop,nop,timestamp 97858603 4296542>
IP wb.54466 > m2008.sunrpc: F 61:61(0) ack 33 win 92 <nop,nop,timestamp 97858603 4296542>
IP wb.34026 > m2008.sunrpc: UDP, length 56
IP m2008.sunrpc > wb.54466: . ack 62 win 91 <nop,nop,timestamp 4296582 97858603>
IP m2008.sunrpc > wb.34026: UDP, length 28
IP wb.40955 > m2008.sunrpc: S 2032104255:2032104255(0) win 5840 <mss 1460,sackOK,timestamp 97858726 0,nop,wscale 6>
IP m2008.sunrpc > wb.40955: S 1073076948:1073076948(0) ack 2032104256 win 5792 <mss 1460,sackOK,timestamp 4296665 97858726,nop,wscale 6>
IP wb.40955 > m2008.sunrpc: . ack 1 win 92 <nop,nop,timestamp 97858727 4296665>
IP wb.40955 > m2008.sunrpc: P 1:61(60) ack 1 win 92 <nop,nop,timestamp 97858727 4296665>
IP m2008.sunrpc > wb.40955: . ack 61 win 91 <nop,nop,timestamp 4296665 97858727>
IP m2008.sunrpc > wb.47852: F 33:33(0) ack 62 win 91 <nop,nop,timestamp 4296719 97858343>
IP wb.47852 > m2008.sunrpc: . ack 34 win 92 <nop,nop,timestamp 97858781 4296719>
IP m2008.sunrpc > wb.40955: P 1:33(32) ack 61 win 91 <nop,nop,timestamp 4296789 97858727>
IP wb.40955 > m2008.sunrpc: . ack 33 win 92 <nop,nop,timestamp 97858850 4296789>
IP wb.40955 > m2008.sunrpc: F 61:61(0) ack 33 win 92 <nop,nop,timestamp 97858850 4296789>
IP wb.34026 > m2008.sunrpc: UDP, length 56
IP m2008.sunrpc > wb.40955: . ack 62 win 91 <nop,nop,timestamp 4296829 97858850>
IP m2008.sunrpc > wb.34026: UDP, length 28
IP wb.43448 > m2008.sunrpc: S 2282608407:2282608407(0) win 5840 <mss 1460,sackOK,timestamp 97858980 0,nop,wscale 6>
IP m2008.sunrpc > wb.43448: S 1321319375:1321319375(0) ack 2282608408 win 5792 <mss 1460,sackOK,timestamp 4296919 97858980,nop,wscale 6>
IP wb.43448 > m2008.sunrpc: . ack 1 win 92 <nop,nop,timestamp 97858981 4296919>
IP wb.43448 > m2008.sunrpc: P 1:61(60) ack 1 win 92 <nop,nop,timestamp 97858981 4296919>
IP m2008.sunrpc > wb.43448: . ack 61 win 91 <nop,nop,timestamp 4296919 97858981>
IP m2008.sunrpc > wb.54466: F 33:33(0) ack 62 win 91 <nop,nop,timestamp 4297003 97858603>
IP wb.54466 > m2008.sunrpc: . ack 34 win 92 <nop,nop,timestamp 97859065 4297003>
IP m2008.sunrpc > wb.43448: P 1:33(32) ack 61 win 91 <nop,nop,timestamp 4297043 97858981>
IP wb.43448 > m2008.sunrpc: . ack 33 win 92 <nop,nop,timestamp 97859104 4297043>
IP wb.43448 > m2008.sunrpc: F 61:61(0) ack 33 win 92 <nop,nop,timestamp 97859104 4297043>
IP wb.34026 > m2008.sunrpc: UDP, length 56
IP m2008.sunrpc > wb.43448: . ack 62 win 91 <nop,nop,timestamp 4297083 97859104>
IP m2008.sunrpc > wb.34026: UDP, length 28
IP m2008.sunrpc > wb.40955: F 33:33(0) ack 62 win 91 <nop,nop,timestamp 4297274 97858850>
IP wb.40955 > m2008.sunrpc: . ack 34 win 92 <nop,nop,timestamp 97859336 4297274>
IP m2008.sunrpc > wb.43448: F 33:33(0) ack 62 win 91 <nop,nop,timestamp 4297622 97859104>
IP wb.43448 > m2008.sunrpc: . ack 34 win 92 <nop,nop,timestamp 97859684 4297622>
IP wb.47215 > m2008.sunrpc: S 2720007308:2720007308(0) win 5840 <mss 1460,sackOK,timestamp 97928135 0,nop,wscale 6>


$ cat /etc/hosts.allow
ALL: 192.168.1.

IP wb.47215 > m2008.sunrpc: S 2720007308:2720007308(0) win 5840 <mss 1460,sackOK,timestamp 97928135 0,nop,wscale 6>
IP m2008.sunrpc > wb.47215: S 1756948559:1756948559(0) ack 2720007309 win 5792 <mss 1460,sackOK,timestamp 4366062 97928135,nop,wscale 6>
IP wb.47215 > m2008.sunrpc: . ack 1 win 92 <nop,nop,timestamp 97928135 4366062>
IP wb.47215 > m2008.sunrpc: P 1:61(60) ack 1 win 92 <nop,nop,timestamp 97928135 4366062>
IP m2008.sunrpc > wb.47215: . ack 61 win 91 <nop,nop,timestamp 4366062 97928135>
IP m2008.sunrpc > wb.47215: P 1:33(32) ack 61 win 91 <nop,nop,timestamp 4366069 97928135>
IP wb.47215 > m2008.sunrpc: . ack 33 win 92 <nop,nop,timestamp 97928142 4366069>
IP wb.47215 > m2008.sunrpc: F 61:61(0) ack 33 win 92 <nop,nop,timestamp 97928142 4366069>
IP wb.0 > m2008.nfs: 0 null
IP m2008.nfs > wb.0: reply ok 0 null
IP wb.57085 > m2008.nfs: . ack 1754567466 win 92 <nop,nop,timestamp 97928142 4366069>
IP wb.730893333 > m2008.nfs: 44 null
IP m2008.nfs > wb.57085: . ack 44 win 91 <nop,nop,timestamp 4366069 97928142>
IP m2008.sunrpc > wb.47215: F 33:33(0) ack 62 win 91 <nop,nop,timestamp 4366073 97928142>
IP wb.47215 > m2008.sunrpc: . ack 34 win 92 <nop,nop,timestamp 97928146 4366073>
IP m2008.nfs > wb.730893333: reply ok 28 null
IP wb.57085 > m2008.nfs: . ack 29 win 92 <nop,nop,timestamp 97928158 4366085>
IP wb.57085 > m2008.nfs: F 44:44(0) ack 29 win 92 <nop,nop,timestamp 97928158 4366085>
IP wb.34026 > m2008.sunrpc: UDP, length 56
IP m2008.nfs > wb.57085: F 29:29(0) ack 45 win 91 <nop,nop,timestamp 4366085 97928158>
IP wb.57085 > m2008.nfs: . ack 30 win 92 <nop,nop,timestamp 97928158 4366085>
IP m2008.sunrpc > wb.34026: UDP, length 28
IP wb.34026 > m2008.32771: UDP, length 40
IP m2008.32771 > wb.34026: UDP, length 24
IP wb.919 > m2008.32771: UDP, length 96
IP m2008.32771 > wb.919: UDP, length 76
IP wb.3286482372 > m2008.nfs: 0 null
IP m2008.nfs > wb.3286482372: reply Unknown rpc response code=2333925260 0
IP wb.940 > m2008.nfs: . ack 1805589363 win 92 <nop,nop,timestamp 97928190 4366116>
IP wb.2198275900 > m2008.nfs: 44 null
IP m2008.nfs > wb.940: . ack 44 win 91 <nop,nop,timestamp 4366117 97928190>
IP m2008.nfs > wb.2198275900: reply ok 28 null
IP wb.940 > m2008.nfs: . ack 29 win 92 <nop,nop,timestamp 97928190 4366117>
IP wb.2215053116 > m2008.nfs: 44 null
IP m2008.nfs > wb.2215053116: reply ok 28 null
IP wb.2231830332 > m2008.nfs: 112 fsinfo fh Unknown/01000600C3E3BDC4312611D78B1CDF8C4D8D30D30000000000 00000000000000
IP m2008.nfs > wb.2231830332: reply ok 84 fsinfo rtmax 131072 rtpref 131072 wtmax 131072 wtpref 131072 dtpref 4096
IP wb.2248607548 > m2008.nfs: 112 getattr fh Unknown/01000600C3E3BDC4312611D78B1CDF8C4D8D30D30000000000 00000000000000
IP m2008.nfs > wb.2248607548: reply ok 116 getattr DIR 40755 ids 0/0 sz 4096
IP wb.2265384764 > m2008.nfs: 112 fsinfo fh Unknown/01000600C3E3BDC4312611D78B1CDF8C4D8D30D30000000000 00000000000000
IP m2008.nfs > wb.2265384764: reply ok 84 fsinfo rtmax 131072 rtpref 131072 wtmax 131072 wtpref 131072 dtpref 4096
IP wb.2282161980 > m2008.nfs: 112 getattr fh Unknown/01000600C3E3BDC4312611D78B1CDF8C4D8D30D30000000000 00000000000000
IP m2008.nfs > wb.2282161980: reply ok 116 getattr DIR 40755 ids 0/0 sz 4096
IP wb.940 > m2008.nfs: . ack 457 win 92 <nop,nop,timestamp 97928234 4366121>

On Wed, 28 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <(E-Mail Removed)>, Bit Twister wrote:

>Moe Trin wrote:

>> Very simple solution. Two lines - one with the old range, one with the
>> new.
>
>Yes, but I really wanted the names to work.

Well, they should. Your syntax appears (to me) to be correct.

>It's kinda like doing the math problems which have the answers in the
>back of the book. I could work the ones with answers and could not
>work out the answer of the ones without the answers.

By the time I got to that stage, the problems were quite complex, and
there's the answer, but how the heck did they get that? ;-)

>> Have you got any other daemon that is running out of xinetd?

>Nope.
>xinetd based services:
> cups-lpd: off
> cvs: off
> proftpd-xinetd: off
> rexec: off
> rlogin: off
> rsh: off

You wonder why they even include the Berkeley 'r' commands any more. If
you are on an isolated network that is fully trusted, they're OK, (and
exceptionally convenient), but they are _so_ easy to abuse.

>> that's portmap bitching, not tcpd or xinetd.
>
>Yes, but hosts.allow changes is what is keeping portmap from allowing
>the nfs request.

The thought was to try another xinetd service to see if the reactions
were the same. I could be wrong, but just enabling the service in
xinetd EVEN IF THE SERVER ISN'T INSTALLED should allow testing of tcpd.
This would show up in the server xinetd logs.

>Only other thing I thought of was:
> Three different versions of the NFS protocol are supported by the
> Linux NFS client:

I don't _think_ so.

>That is why I went with
>[bittwister@wb ~]$ grep m2008 /etc/fstab
>m2008:/local /mlocal nfs rsize=32768,wsize=32768,timeo=14,intr 0 0

Not sure about the timeo option, but that's not the problem we're seeing.

>Did not want to get buried in Kerberos and whatnot.

I don't know why ;-)

Old guy