Re: tcpdump - laptop

Hans Steegers wrote:
> James,
> I'll give it another (last!) try:
> 
> What all those packet dumps tell me is this:
> 
> 1. there was no file transfer at all: all dumps contained only small
> (protocol) packets. conclusion: the SAMBA server didn't even try to transfer
> a file.
> 
> 2. For a 'failing PMTU discovery' problem, we should have seen at least 1
> large packet. Since there are none we have to look further.
> 
> 3. The cipe interface 192.168.2.20 on the notebook informed the server
> 92.168.1.10 that port 138/udp is (blocked or not listening:) unreachable,
> after receiving an NBT UDP PACKET(138) from the server. We can follow the
> NBT packet from server to notebook and the ICMP answer from notebook to
> server. So the server stopped. What tell the Samba logs?
> 
> ** Find the reason why cipe cannot pass on port 138/udp packets to the lo
> interface on the notebook:
> 
> -> Check with 'netstat -lun' on the notebook if listening on ports 137 and
> 138.
> you should see something like:
> ..
> udp        0      0 192.168.2.20:137        0.0.0.0:*
> udp        0      0 0.0.0.0:137             0.0.0.0:*
> udp        0      0 192.168.2.20:138        0.0.0.0:*
> udp        0      0 0.0.0.0:138             0.0.0.0:*

On the notebook, connected via dial up, I get the following:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
udp        0      0 0.0.0.0:32768           0.0.0.0:*
udp        0      0 0.0.0.0:2049            0.0.0.0:*
udp        0      0 0.0.0.0:32769           0.0.0.0:*
udp        0      0 0.0.0.0:32770           0.0.0.0:*
udp        0      0 0.0.0.0:10000           0.0.0.0:*
udp        0      0 0.0.0.0:666             0.0.0.0:*
udp        0      0 209.188.81.204:6969     0.0.0.0:*
ESTABLISHED
udp        0      0 0.0.0.0:7741            0.0.0.0:*
udp        0      0 0.0.0.0:111             0.0.0.0:*
udp        0      0 0.0.0.0:631             0.0.0.0:*

I notice there's no mention of 137 or 138.  However, when I run the same
command on the server, I see reference to both, as shown below.

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
udp        0      0 0.0.0.0:32768           0.0.0.0:*
udp        0      0 0.0.0.0:2049            0.0.0.0:*
udp        0      0 0.0.0.0:32769           0.0.0.0:*
udp        0      0 0.0.0.0:32770           0.0.0.0:*
udp        0      0 192.168.1.10:137        0.0.0.0:*
udp        0      0 0.0.0.0:137             0.0.0.0:*
udp        0      0 192.168.1.10:138        0.0.0.0:*
udp        0      0 0.0.0.0:138             0.0.0.0:*
udp        0      0 0.0.0.0:10000           0.0.0.0:*
udp        0      0 0.0.0.0:788             0.0.0.0:*
udp        0      0 0.0.0.0:7741            0.0.0.0:*
udp        0      0 0.0.0.0:111             0.0.0.0:*
udp        0      0 0.0.0.0:631             0.0.0.0:*


Here's the relevant portion of log.nmdb on the notebook.

[2003/09/11 21:59:45, 0] nmbd/nmbd.c:main(783)
   Netbios nameserver version 2.2.3a started.
   Copyright Andrew Tridgell and the Samba Team 1994-2002
[2003/09/11 21:59:45, 0] nmbd/nmbd_subnetdb.c:create_subnets(240)
   create_subnets: No local interfaces !
[2003/09/11 21:59:45, 0] nmbd/nmbd.c:main(861)
   ERROR: Failed when creating subnet lists. Exiting.

And log.smdb:

[2003/09/11 21:59:45, 0] smbd/server.c:main(698)
   smbd version 2.2.3a started.


The error on the last line of log.nmbd looks interesting.

Here's the last entry for log.nmbd on the server:

[2003/09/11 21:58:10, 0]
nmbd/nmbd_browsesync.c:find_domain_master_name_query_fail(359)
   find_domain_master_name_query_fail:
   Unable to find the Domain Master Browser name HOME<1b> for the
workgroup HOME.
   Unable to sync browse lists in this workgroup.



> ..
> 
> -> Or, there MUST be an overlooked difference between the set-ups for
> connecting via LAN, Wireless or modem, and your notebook firewall IS
> blocking 138/udp traffic between lo and cipcb0 (only) for the modem setup.
> All traffic between lo and cipcb0 must be allowed.

I don't have a firewall running on the notebook.  Also, there is no
difference in set up, that I'm aware of, with the different connection
methods.
> 
> These are -AFAIK (with the info supplied)- the only two possible reasons
> causing the 'port 138/udp unreachable' reply packets.
> 
> 
> Hans Steegers
> 
> -----Original Message-----
> From: James Knott <[email protected]>
> To: CIPE <[email protected]>
> Date: Thursday, September 11, 2003 6:30 PM
> Subject: tcpdump - laptop_cipb0 IP 192.168.2.20



--
Message sent by the [email protected] mailing list.
Unsubscribe: mail [email protected], "unsubscribe cipe-l" in body
Other commands available with "help" in body to the same address.
CIPE info and list archive: <URL:http://sites.inka.de/~bigred/devel/cipe.html>