In article <Pine.NEB.4.61.0504071419140.17689@fw.selonen.org>,
Arto Selonen  <arto+dated+1112874166.37d209edfebf9005@selonen.org> wrote:
>Hi!
>
>On Thu, 7 Apr 2005, Tom Ivar Helbekkmo wrote:
>
>> I'm running 3.99.1 on an i386 laptop, with a wm0 network interface.
>
>Only one 3.99.x (x=3) system currently available with one wm NIC.
>Logged into the system over the network using SSH, started
>'tcpdump -i wm0' as root, and then started pinging the system over
>the network. Stopped the tcpdump, and then stopped the ping:
>
>158 packets transmitted, 155 packets received, 1.9% packet loss
>round-trip min/avg/max/stddev = 0.185/0.377/2.179/0.269 ms
>
>> After I stopped the tethereal run, connectivity came back.  This is
>> completely repeatable, using either tethereal or tcpdump.
>
>Could be related to the way some NICs were doing (not doing?) resets
>on the NIC when starting/stopping tcpdump. At least I think I remember
>some work being done on several drivers a month a few back (maybe Jan/Feb, 
>though I can't remember/find if those covered wm).
>
>Or, it could be related to something else. I'm seeing wm-related problems
>with 3.99.3 as well: kern/29903. In any case, wm has been a pain, lately.

Artsi is probably right. If you are connected on a vlan switch, and you
don't have fast convergence (what is the cisco term for that?), then when
NetBSD erroneously brings down and up the interface to set promiscuous
mode, the switch restarts the vlan negotiation and that can take up to
a minute. The solution is to fix the drivers to do the minimal work to
enter/exit promiscuous mode where possible without affecting link state.

christos