>True on both accounts. It works great, except it leaves a few blanks
>where it knows the port/proto combination, but can't figure out what
>process it is. Maybe I just have to punt and hardcode in a message that
>says "[maybe kernel-based]" if all else fails? Or do I make dangerous
>and not-portable assumptions about what ports might be what? That'd
>probably be better left in a readme. So maybe something along the lines
>of "[maybe kernel, see docs]". That kind of takes the fun (and the
>functionality) out of it. :-/
You're mixing two different things here.
1. 'user socket' vs. 'kernel socket'
If the socket is not dying (FIN-WAIT et al.) and you can't find a userspace
process which has it open it CAN ONLY BE one of those kernel listening
sockets you're looking for. (At least I think so. Can anyone sanity check
this?)
2. what port is what?
Having a userspace socket on port 21 which is owned by a process
called 'ftpd' makes it quite likely that there's an ftp service there. But
of course I could compile a telnetd which was called ftpd and listens
on port 21. And allowing for 'kernel sockes' makes this no worse.
Anyone could put anything inside his kernel. I could make a kernel
patch which transparently directs incoming port 80 traffic to a
userspace ftp daemon. Then your program will say 'kernel-based
port 80 listener'. Anyone who would see this message would probably
think: "Yes, probably it's a httpd." But then again, maybe it's not. In this
case it's not. Bzzt, wrong. Too bad.
Every project needs some assumptions. This is not inherently evil,
just make sure your assumptions seem reasonable. I think this
assuming port 80 corresponds to an http server process is a
reasonable one which will hold on 'most of the linux boxes out
there'.
Greetings,
Lennert Buytenhek
PS (I'll be off-net for a couple of days)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/