Date: Thu, 12 May 2011 21:44:43 +0000 From: msmorsecode@hush.com To: freebsd-questions@freebsd.org Subject: annoyance; 3c905b-tx-nm silently drops first rx'd packet. Message-ID: <20110512214443.2625C10E2BB@smtp.hushmail.com>
next in thread | raw e-mail | index | archive | help
I have a 3c905b-tx-nm, the "nm" means no power management. I've
had occasion to use it in several pc's. I've tried to avoid using
it
due to this annoyance, but my present pc has a chipset which
doesn't
operate well with any of my other ethernet cards.
The card has a pci-id of (10b7,9055) and uses a 40-0483-00x
asic.
In ifconfig, the media is set for 10base-t half-duplex, no
autodetect.
This has happened in every release I've used since 2003, from
4.8
until now. But I couldn't find anyone else making a bug complaint,
so
I finally decided to ask about it myself.
>From freebsd-
After a cold-boot, or a warm-boot from an OS which didn't
actually
use the ethernet (ie dos), the first rx'd packet will always be
silently
dropped without freebsd ever noticing any packets had been sent to
it.
This appears to apply to any kind of ethernet packet, though in
practice the first rx'd packet is usually either a tcp arp
broadcast,
or an icmp echo (or echo-reply).
It's not a case of the interface being down; "ifconfig" shows
it
as being up, and it can actually send out an icmp echo without
being
able to receive the first echo-reply from that echo.
It's not a terrible problem, the result of the silently dropped
packet usually being some seconds of delay while waiting for a re-
transmit.
But it is annoying.
Disabling Tx & Rx checksumming options makes no difference. The
only workaround I've found so far is to disable rx multicast-
filtering
by using "promisc" in rc.conf's ifconfig line. But that's not a
very
good solution.
If I start the machine with promisc, I can disable the promisc
*after* at least one packet has been received, and then everything
is
ok. But if I disable the promisc before a packet has been received,
then it's the same as if I hadn't used promisc at all- the first
rx'd
packet will still be lost.
For comparison, this doesn't happen in any version of windows,
or when using the card's dos drivers. Also, in linux, it doesn't
happen
if the first rx'd packet was an icmp echo-reply, but does happen if
it
was an icmp echo-request from another machine. Mostly it's a
freebsd
problem.
I have another machine with an original 3c905(a). It has no
such
problems, most likely because the 3c905 doesn't have a multicast
filter
and is always in promiscuous mode.
I'm hoping this is something that can be fixed by some wise and
all-knowing freebsd networking guru providing a driver patch.
Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110512214443.2625C10E2BB>