On Sunday 05 January 2003 12:24 pm, FX Fraipont wrote:
Tom Emerson wrote:
netbios-ssn is port 139 -- to see this, do the netstat command with the switch "-an" instead of just "-a"
netstat -an does not reveal anything about port 139
yes it does -- you even pointed it out:
vertigo:/home/fx # netstat -an --inet Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN <<<<<
the number following the colon IS the "port"
To find out [definitavely] what "process" has the port opend, we turn to another command: lsof [list Open Files], with the "-i" switch [show IP related files only -- the command "man lsof" gives full details] [note also you should do this as root]
vertigo:/home/fx # lsof -n -i :139 -i :137 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME smbd 5922 root 10u IPv4 42845 TCP *:netbios-ssn (LISTEN)
Something else: if I stop smbd with rcsmb stop, it stops all right. But rcnmb stop, followed by rcnmb status shows it is still running. Why?
read that carefully again -- your first line says rc-S-mb stop works, but your second line says rc-N-mbd stop followed by status shows it running, so which is it? <S>mb or <N>mb? Either way, are you sure it actually stopped? does the process still show up under the "ps" command? ["ps aux | grep <processname>" is a conventient way to check for just one process -- remember to ignore the "grep" command, since the "command" portion will match itself -- for samba stuff, you can even use "grep mbd" and that will match both <S>mbd and <N>mbd] Also, did you investigate whether this might be handled via inetd/xinetd? If so, these "processes" might get started automagically. [if you REALLY do use inetd, you don't need to stop that service (because doing so messes with "other things") instead, alter the inetd.conf file to exclude the smb/nmb services and issue the command "kill -HUP <pid-of-inetd>" -- this causes inetd to re-read the configuration file and take appropriate steps...]
Plus, I was advised to check my SuSEfirewall2.conf file, and saw that port 139 was not explicitly open, and that broadcasts were not allowed. I duly corrected that, but still no luck.
You did open these to the "internal" network only, correct? It wouldn't do to open this to the "outside" -- after all, that is explicitly what the firewall should be protecting you from... :) But, to stop a moment and take stock of the situation: 1) smbd seems to work -- explicit [manual] connections & file transfers work 2) nmbd reports the error "cannot open port" for port 137 [per nmbd.log] 3) nothing seem to be explicitly using port 137 [port 139, yes] 4) permissions/ownership/execution of the nmbd file appears to be correct [owned & run by root] 5) as best as can be determined, the firewall is not blocking port 137/139 either you've overlooked something or misreported it -- now that you (we) are absolutely sure "nothing is using port 137", does the nmbd.log file still show errors trying to open/allocate port 137 when you start the program? [purge or move the file so a new one gets built -- no point in misleading yourself with old/out-of-date errors]
This is turning into private tuition :-)
You may send a check, for any amount you feel is appropriate for the information you've received, to the following address: Tom Emerson 3541 Fairchild Street La Crescenta, CA 91214 USA