nmap and service type "unknown"
 

I'm updating and fine-tuning Slackware on my multi-boot box . Today, suddenly X started acting flaky. The mouse pointer jittered when I moved it across the screen. All was working yesterday. Okay, so what did I do?

I dunno.

The logs prompted me to investigate. I received the following with nmap -v localhost:

(The 1020 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open unknown
139/tcp open unknown
901/tcp open unknown

I toggled to my other Slack box:

(The 1664 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
139/tcp open netbios-ssn
901/tcp open samba-swat

As a friend of mine would say: straaaaaaaanngge.

From Box 2 I ran the nmap test on Box 1, and Box 2 seems to have no problem identifying the service type on Box 1. I ran nmap from Box 1 on Box 2 and Box 1 again spit out "unknown."

Why the "unknown" and why the difference in the number of scanned ports?

I checked /etc/services and file permissions. The files are the same on both boxes. I reinstalled the inetd package and restarted the inetd service. Nada. I even rebooted. Nothing. Same result every time.

The /etc/hosts, host.conf, resolv.conf, etc. files all are the same on both boxes. Box 2 is working great.

I also ran some netstat tests that revealed nothing peculiar to me.

I run samba, sshd, and inetd on both boxes. I'm using Slackware 10.2, nmap 3.93. Other than configuration differences because of hardware, these two boxes are configured the same. Yet, something is snaky on Box 1.

I've been searching the web for an explanation but to no avail. Any advice is appreciated! :confused:

nmap's datadir setting specifies where it gets things like service info from. Have you changed/upgraded your nmap package recently?

I have 2 systems here with nmap. The one compiled from source has its datadir in /usr/local/share/nmap and the one using the nmap-4.11-i486-1 package has its datadir in /usr/share/nmap. These are default locations according to man nmap. The list of files in each directory is the same, but their contents are different.

Do you have the datadir on your system and does nmap-services have all of your services listed?

Thanks for the info. I found a file called nmap-services. As you mentioned I see that nmap does not use /etc/services but its own file. That explains why the terminology is slightly different. One mystery eliminated. :)

Since I posted I got the crazy idea of reinstalling nmap. Crazy, but that solved the problem of the nutty nmap listing of "unknown." Another mystery solved. :)

Along with this escapade, the past several days since updating my box to 10.2 I keep getting error messages in my logs regarding /dev/gpmctl not being found. I know about the Midnight Commander kludge by starting MC with the -d option. I have had that option built into my system aliases for many months. I never saw that problem again until the past several days after updating. So I knew that there was a new problem causing this error message.

Because of this nmap issue I had a close eye on my logs while I troubleshooted and I had a tail -f to watch things. Sure enough the /dev/gpmctl error message reappeared. I was puzzled because I knew I had not touched Midnight Commander. The only thing I had done was open pkgtool to check some info. Hmm. So I again started pkgtool and sure enough, the /dev/gpmctl error message reappeared. You would be correct if you guessed my thoughts were WTF?. ;)

So I did some quick web surfing, found nothing concrete, shrugged, and simply reinstalled the pkgtools and ncurses packages. The /dev/gpmctl error message problem disappeared immediately and another mystery solved. :)

All of this took about two hours. So at that point I thought I was back to square one with the original inexplicable jittery mouse pointer that caused me to notice all of this nonsense in the first place. Well, you guessed correctly if you said I had no more mouse problems. I have no idea what caused that and at this stage I am not going to wonder. All is well.

I think.

And here I'll hijack my own thread---slightly.

I have had to reinstall several packages since updating to 10.2. I do not think my updating went smoothly for whatever reason. When I installed the packages I mounted an ISO image---that was stored on my shared FAT32 partition. I suspect that might have been the root cause of these quirky problems. I suspect that mounting an ISO from a FAT32 might not be a good idea. :confused:

I have tried to use the diff utility to compare all of my bin and sbin directories and now, several days later, all seems synched. But I am unsure. So my current request is this:

Would someone kindly share how to more efficiently use diff to compare two boxes?

I'd be grateful. I need only a brief or superficial comparison of file date/time stamps. Other than the user files and a handful of system configuration files, the boxes should be almost identical and the diff output should be minimal. However, when I run diff I receive "permission denied" responses as diff hits certain files. I suspect the issue is file permissions. I know about the exclude option, but there seems to be too many of these files that stops diff cold. So any help along this line is appreciated. I'm using samba to access files (because one box is multi-boot).

The "problem" box is running right smooth now and I probably have all the bad packages repaired. But I'd like to use diff to make sure. I realize running diff will require some time so I'll find other things to do while diff creates an output report. :)

Thanks for any diff tips!

Warning - I'm interpreting what you're saying in the context of how I check things on my boxes... :)

I don't think diff can be used to compare timestamps. Hopefully the file date isn't as important as whether the contents have changed. If you have 2 file systems to check, say /sbin and /tmp/backup/sbin then you can run:
I run a weekly check of my /etc /usr/local (partial) and /var (partial) directories against a checkout from CVS using this method and it does what I need.

Well that is all I've been using too. I guess the diff command is not too flexible. Any idea how to get around the permission denied errors? The exclude flag seems limited to one file type, but I'm probably missing the big picture, which is why I asked. :)

"Permission denied" is either the permissions, or a messed up filesystem. Try re-running it as root?

There was a post a couple weeks ago that involved checking for changed file permissions that would also check file sizes: http://www.linuxquestions.org/questi...d.php?t=462314

Well, sometimes discussing a problem with another person helps a person realize a solution. Today I noticed in the diff man page that I can create a file exclusion text file. Somehow I noticed the --exclude tag but not the --exclude-from tag. That latter option will resolve the file permissions problem. I'll have to run a few passes of diffing directories and each time diff halts on a file permission problem I'll add that file to my list and run again. Eventually I'll have a dependable list and should have no problems running diff.

I followed the link you provided, which led to a script that could help restore a botched system's file permissions and another to list library dependencies. Although unrelated to this specific problem both scripts are interesting and useful. Thanks.

I'm sorry about that. Thought there was a script that allowed you to verify against the Slackware MANIFEST file. *sticks foot in mouth*

It shouldn't be hard to modify the script to verify permissions instead of changing them.

This has turned into an interesting problem. I receive permission denied messages only from one box. If I diff directories from the other box I receive no error messages.

Concurrently, I have been experiencing file and directory permissions issues with respect to samba, although I do not think samba is the cause. I have some further testing to do, but likely I will shift this thread to a new thread to explore further.