On Tue, 27 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in article <slrnfkngs1.cog.BitTwister@wb.home.invalid>, 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 Wed, 28 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in article <slrnfkpn2v.4d9.BitTwister@wb.home.invalid>, 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

On Wed, 28 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in article <slrnfkpuk7.5sj.BitTwister@wb.home.invalid>, Bit Twister wrote: >Moe Trin wrote: >> Quick look - is there anything obvious in a packet dump? > >Not to my untrained eye. Here is fail followed by works. >arp reply m2008 is-at 00:a0:cc:e6:de:71 (oui Unknown) [compton ~]$ etherwhois 00:a0:cc 00-A0-CC (hex) LITE-ON COMMUNICATIONS, INC. 00A0CC (base 16) LITE-ON COMMUNICATIONS, INC. 720 S. HILLVIEW DRIVE MILPITAS CA 95035 UNITED STATES [compton ~]$ Your sniffer is old - that OUI has been out there for at least 8 years. [snip 'ALL: .home.invalid' list] Nothing is jumping out at me. Basically, three attempts to connect. >ALL: 192.168.1. No obvious difference in the first conversation, but this continues. Several of the lines look weird, but the stuff is working. (I haven't sniffed NFS in several years - so I'm awfully rusty. Sorry) Old guy