Re: hosts.allow does not resolve names

On Tue, 27 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <slrnfkp0t8.rv.BitTwister@xxxxxxxxxxxxxxx>, 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
.

Relevant Pages

  • Re: r8169 GigE driver problem, locks up 2.4.23 NFS subsystem
    ... from this patchset i extracted and updated the 8169.c diff only. ... for both low level transfers and on filesystem level (NFS). ... however explicit pings work fine and do increment ... If i am coming from below (aka can ping) i can ping with ...
    (Linux-Kernel)
  • Re: solaris 10 iso dvd image
    ... filesystems on my Linux server. ... then ping -s 192.168.1.13 works as expected, ... There is some strangeness in the TCP stack it seems. ... that Solaria 10 NFS doesn't seem to want to talk to Linux NFS server. ...
    (comp.unix.solaris)
  • Re: [opensuse] Cant ping to another computer on local net
    ... Nfs is disabled on c3. ... NFS has nothing to do with ping. ... I haven't done anything at all with the Suse firewall. ... Now I think it's a routing problem associated with dhcp since the switch ...
    (SuSE)
  • Re: [opensuse] Cant ping to another computer on local net
    ... Nfs is disabled on c3. ... how do I enable nfs? ... NFS has nothing to do with ping. ... I haven't done anything at all with the Suse firewall. ...
    (SuSE)