Port 800

Port 800

Post by Ken Harringto » Sat, 17 Feb 2001 06:58:40



I was looking at the output of "netstat -tupan", and it has an entry

udp        0      0   0.0.0.0:800    0.0.0.0:*         -

(Note the lack of process ID and service name)

The list of ports I carefully compiled identifies port 800 as
"mdbs_daemon", but that means nothing to me.  Anybody have any clues?

This is on a RedHat 7.0  machine

The firewall wouldn't allow any connections to this port, but I would
like to stop whatever is listening, if possible.

TIA
Ken Harrington

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

 
 
 

Port 800

Post by Manfred Bart » Sat, 17 Feb 2001 07:53:34



> I was looking at the output of "netstat -tupan", and it has an entry

> udp        0      0   0.0.0.0:800    0.0.0.0:*         -

> (Note the lack of process ID and service name)

These are often RPC processes or RPC child processes.

Quote:> The list of ports I carefully compiled identifies port 800 as
> "mdbs_daemon", but that means nothing to me.  Anybody have any clues?

Well, /etc/services (or the IANA assignments) just map port numbers to
names, it make no claim for correctness or completeness.  There is a
company called ``Micro Data Base Systems, Inc'', but you would know it
if you were using one of their products.

More likely, this is a port dynamically assigned to a RPC related
process.

The only way I have found to discover what program the port belongs to
is by systematically unmounting remote NFS partitions and by killing
rpc daemons one by one and checking again with ``netstat -upan''.

The usual suspects are: rpc.statd, lockd, rpciod.  These are all NFS-
client related.

Let us know what you found.

Cheers   :)
--
Manfred
---------------------------------------------------------------
ipchainsLogAnalyzer, NetCalc, whois at: <http://logi.cc/linux/>

 
 
 

Port 800

Post by Tim Hayne » Sat, 17 Feb 2001 08:11:45




> > I was looking at the output of "netstat -tupan", and it has an entry

> > udp        0      0   0.0.0.0:800    0.0.0.0:*         -

> > (Note the lack of process ID and service name)

> These are often RPC processes or RPC child processes.

Ah, goodie, you beat me to it ;)

Quote:> The only way I have found to discover what program the port belongs to is
> by systematically unmounting remote NFS partitions and by killing rpc
> daemons one by one and checking again with ``netstat -upan''.

> The usual suspects are: rpc.statd, lockd, rpciod. These are all NFS-
> client related.

Just a wondering... what about fuser and lsof? It might be possible to get
something out of them, although stuff being kernel processes doesn't help
much.

~Tim
--

with their secret weapon.                    |http://spodzone.org.uk/

 
 
 

Port 800

Post by Ken Harringto » Sat, 17 Feb 2001 08:46:59





> > > I was looking at the output of "netstat -tupan", and it has an entry

> > > udp        0      0   0.0.0.0:800    0.0.0.0:*         -

> > > (Note the lack of process ID and service name)

> > These are often RPC processes or RPC child processes.

> Ah, goodie, you beat me to it ;)

> > The only way I have found to discover what program the port belongs to is
> > by systematically unmounting remote NFS partitions and by killing rpc
> > daemons one by one and checking again with ``netstat -upan''.

> > The usual suspects are: rpc.statd, lockd, rpciod. These are all NFS-
> > client related.

> Just a wondering... what about fuser and lsof? It might be possible to get
> something out of them, although stuff being kernel processes doesn't help
> much.

> ~Tim
> --

Thanks for the replies.  I haven't used fuser or lsof very much, but
here goes:

fuser -n udp 800,,
(Gives no output.  trying port 53 shows a PID, so I assume this means
fuser can't tell what process?)


(also gives no output)

I unmount the only NFS mount that was present, and this line was no
longer present in the netstat output.  Thanks for the help.

Is there a range of ports "normally" used for these rpc connections?

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

 
 
 

Port 800

Post by Manfred Bart » Sat, 17 Feb 2001 09:37:32


Hi Tim,


> > The only way I have found to discover what program the port
> > belongs to is by systematically unmounting remote NFS partitions
> > and by killing rpc daemons one by one and checking again with
> > ``netstat -upan''.

> > The usual suspects are: rpc.statd, lockd, rpciod. These are all
> > NFS- client related.

> Just a wondering... what about fuser and lsof? It might be possible
> to get something out of them, ...

``lsof -i'' does not even show those ports on my system.  Neither does
rpcinfo (well it can't if those processes don't belong to rpc servers).
fuser seems to rely on the same information as the other programs,
e.g. they all use info from /proc

I did a bit of digging in /proc myself, but I always hit a dead end.
To me it looks like kernel support is needed to go any further.
Unless you have got some other suggestion?

Quote:> ... although stuff being kernel processes doesn't help much.

Huh?  Are there different kinds of processes?  AFAIK, the kernel is
not even multithreading although they are working on it.  Maybe you
mean the trick used by NFS where it starts off as a user space program
(nfsd) to get a PID and then calls the kernel's NFS support from where
it never returns (unless you kill it).

Cheers
--
Manfred
---------------------------------------------------------------
ipchainsLogAnalyzer, NetCalc, whois at: <http://logi.cc/linux/>

 
 
 

Port 800

Post by Manfred Bart » Sat, 17 Feb 2001 09:54:13



> Thanks for the replies.  I haven't used fuser or lsof very much, but
> here goes:

> fuser -n udp 800,,
> (Gives no output.  trying port 53 shows a PID, so I assume this means
> fuser can't tell what process?)

Looks like none of the progs can extract the information for port 800.
Presumably they all rely on info extracted from /proc


> (also gives no output)

host is supposed to be a valid hostname, or just leave it out:

# lsof -ni udp:53
COMMAND    PID USER   FD   TYPE DEVICE SIZE NODE NAME
tinydns   6372 root    3u  IPv4  11895       UDP 192.168.1.2:domain
dnscache 18780 root    3u  IPv4  65408       UDP 192.168.1.1:domain

Quote:> I unmount the only NFS mount that was present, and this line was no
> longer present in the netstat output.  Thanks for the help.

Oh, good.  Then it must have been rpc.lockd & Co.

Quote:> Is there a range of ports "normally" used for these rpc connections?

Hmm, it seems that under Linux, rpc.lockd starts at 800 and works its
way down.  Presumably it would start elsewhere if 800 were already in
use.  I wouldn't count on it using the same ports everytime.  In your
firewall, just block all access to ports below 1024 (TCP and UDP) and
selectively open only what you really want to open (if anything).

Cheers
--
Manfred
---------------------------------------------------------------
ipchainsLogAnalyzer, NetCalc, whois at: <http://logi.cc/linux/>

 
 
 

Port 800

Post by craw.. » Sat, 17 Feb 2001 11:31:20




> > Thanks for the replies.  I haven't used fuser or lsof very much, but
> > here goes:

> > fuser -n udp 800,,
> > (Gives no output.  trying port 53 shows a PID, so I assume this means
> > fuser can't tell what process?)

> Looks like none of the progs can extract the information for port 800.
> Presumably they all rely on info extracted from /proc


> > (also gives no output)

> host is supposed to be a valid hostname, or just leave it out:

> # lsof -ni udp:53
> COMMAND    PID USER   FD   TYPE DEVICE SIZE NODE NAME
> tinydns   6372 root    3u  IPv4  11895       UDP 192.168.1.2:domain
> dnscache 18780 root    3u  IPv4  65408       UDP 192.168.1.1:domain

> > I unmount the only NFS mount that was present, and this line was no
> > longer present in the netstat output.  Thanks for the help.

> Oh, good.  Then it must have been rpc.lockd & Co.

> > Is there a range of ports "normally" used for these rpc connections?

> Hmm, it seems that under Linux, rpc.lockd starts at 800 and works its
> way down.  Presumably it would start elsewhere if 800 were already in
> use.  I wouldn't count on it using the same ports everytime.  In your
> firewall, just block all access to ports below 1024 (TCP and UDP) and
> selectively open only what you really want to open (if anything).

> Cheers
> --
> Manfred
> ---------------------------------------------------------------
> ipchainsLogAnalyzer, NetCalc, whois at: <http://logi.cc/linux/>

I've had some problems at work configuring client firewalls to handle
rpc.xxx, and especially the ports assigned by the portmapper. I want to
implement a better (i.e., real not client) firewall, but I'm not the
person in charge of this. A VMS "expert" is in charge. No further
comments needed.

I'm not sure what port will be used except to say that to expect a
relatively schizo selection. Tough to block specific ports when using
the portmapper. To me that is the major problems with things that rely
on the portmapper. Of course other problems do exist.:-)

And please don't bombard me with comments about other more secure ways
to handle cross-mounted file systems. If I could, I would.

Clyde

 
 
 

Port 800

Post by Tim Hayne » Sat, 17 Feb 2001 10:02:53



> > Just a wondering... what about fuser and lsof? It might be possible to
> > get something out of them, ...

> ``lsof -i'' does not even show those ports on my system. Neither does
> rpcinfo (well it can't if those processes don't belong to rpc servers).
> fuser seems to rely on the same information as the other programs, e.g.
> they all use info from /proc

... that's the other angle of attack, to dig around in /proc. Not that
that's particularly easy, or any more guaranteed to produce anything.

Quote:> > ... although stuff being kernel processes doesn't help much.

> Huh? Are there different kinds of processes? AFAIK, the kernel is not
> even multithreading although they are working on it. Maybe you mean the
> trick used by NFS where it starts off as a user space program (nfsd) to
> get a PID and then calls the kernel's NFS support from where it never
> returns (unless you kill it).

No, I meant kernel processes. As in, what kswapd, kupdate, kpiod, khttpd,
kflushd are. Hint: 0 bytes resident, 0 bytes total, 0 bytes shared, not
occupying any CPU percentage?
If you stumble on one of those in your netstat output you'll see you get a
pid but no process name. At least, normally so, anyway. That's why I was
wondering about a kernel process being responsible for this port 800 thing.

(What's this I hear about kernel- v user-space NFS? Does it make any
difference to use the other one?)

~Tim
--
   12:58am  up 53 days,  3:05, 11 users,  load average: 0.32, 0.50, 0.62

http://piglet.is.dreaming.org     |(seen during a recent, >y2000, installation)

 
 
 

1. UDP port 800 on Linux 2.2.17 NFS client

Does anyone know what causes netstat to show UDP port 800
as active on a Linux NFS client when an NFS filesystem is
mounted?

Using Debian Linux 2.2 with Kernel 2.2.17 with one NFS filesystem
mounted, I see the following:


   Active Internet connections (servers and established)
   Proto Recv-Q Send-Q Local Address           Foreign Address
   udp        0      0 0.0.0.0:800             0.0.0.0:*

If I unmount the NFS Filesystem, the udp port disappears.

"lsof -i" doesn't show this port belonging to any process, and
the "-p" option to netstat doesn't show any process info either.
I assume that this means that it's a kernel thing rather than
a process level thing.

A network sniff while mounting and umounting the NFS filesystem
doesn't show any traffic on UDP port 800 - I just see portmapper,
mountd and nfs.

Does anyone know what this is?

--
Roy Hills                         +44 1634 721855
NTA Monitor Ltd       http://www.nta-monitor.com/

Sent via Deja.com http://www.deja.com/
Before you buy.

2. ASUS Video

3. what is port 800 ?

4. route.c hash table problems in 2.4.19 kernel

5. UDP port 800 on Linux 2.2 NFS client

6. Linux is printing blank pages

7. Iomega Ditto 800 Easy Parallel Port Version

8. automounter

9. Iomega Ditto 800 parallel port

10. Iomega Ditto 800 (parallel port)

11. epson stylus color 800 | parallel port problem

12. Anyone got Iomega Ditto Easy 800 (parallel port) to work w/ Linux?

13. Iomega Ditto Easy 800 (Parallel Port) Tape under Linux?