<< | Thread Index | >> ]    [ << | Date Index | >> ]

To: CIPE <cipe-l,AT,inka,DOT,de>
Subject: Re: tcpdump - laptop
From: James Knott <james.knott,AT,rogers,DOT,com>
Date: Thu, 11 Sep 2003 22:43:15 -0400
In-reply-to: <008401c378a2$d02c38e0$d620a8c0@pcw_hans.hnsasd.priv>
References: <008401c378a2$d02c38e0$d620a8c0@pcw_hans.hnsasd.priv>

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 <james.knott,AT,rogers,DOT,com>
To: CIPE <cipe-l,AT,inka,DOT,de>
Date: Thursday, September 11, 2003 6:30 PM
Subject: tcpdump - laptop_cipb0 IP 192.168.2.20


<< | Thread Index | >> ]    [ << | Date Index | >> ]