USB/NDIS: Hot PnP with TCP/IP
Ryan
I'm writing a USB/NDIS miniport for connecting two PC stations directly over
USB using a special Host-to-Host USB ASIC. The miniport is strongly based on
Microsoft's KB article Q224784 (NDIS with USB and 1394).
The miniport is almost done, but I have a nagging problem with hot PnP when I
bind only TCP/IP. (When I bind NetBEUI and IPX/SPX, I do not have any hot PNP
or other problems.)
TCP/IP: If the ASIC is connected to both PCs when the PCs are booted, then
everything works fine: PING, Network Neighborhood, file transfers, net games,
etc. all work properly. However, if I unplug and replug one station (at the
USB connection) the stations can still PING each other, but Network
Neighborhood on the other station will forever display: "The remote computer
is not available" (which is error 51: ERROR_REM_NOT_LIST [Remote Not
Listening]]).
Going a little deeper... Running NBTSTAT -n with TCP/IP shows that the browser
service is lost after a PnP event. In other words, the following line is
missing from NBTSTAT -n after I unplug and replug the USB device:
MYGROUP <1E> GROUP Registered
The "<1E> GROUP" translates to the Browser Service.
This problem is quite similar to MS KB Q220586 "Computer with Plug and Play
Network Adapter Is Not Found on Network", but there are differences. (Mostly
that I what I see is a HOT PnP problem...) The similarities really have me
wondering if this is a 'high-level' problem that is way above my miniport...?
I can list other hints and clues, but rather than going into excruciating
detail, I'd like to ask if any of you have seen anything like this, or if you
might have any insights, questions, or...?
Bits and pieces:
- Two PC stations are directly networked via custom USB-to-USB ASIC
- Miniport emulates 802.3 ethernet
- Each host sees only two USB endpoints (one BULK IN, one BULK OUT)
- Miniport based on NE2000, E100BEX and BULUSB samples from DDK
- Applied MS KB's:
- Q224784 (USB and 1394 with NDIS)
- Q214455 (IM vs. deserialized miniports)
- OS Platforms: Win98, Win98-SE
Any help you can provide would be great! (Please CC your reply directly to
me.)
Thanks,
Ryan
/*************************************
Ryan Augustin, Computer Engineering
ry...@NOSPAM.cruzio.com <Remove NOSPAM>
**************************************\
Andy Moreton
>Fellow USB/NDIS driver writers;
>
>I'm writing a USB/NDIS miniport for connecting two PC stations directly over
>USB using a special Host-to-Host USB ASIC. The miniport is strongly based on
>Microsoft's KB article Q224784 (NDIS with USB and 1394).
>
>The miniport is almost done, but I have a nagging problem with hot PnP when I
>bind only TCP/IP. (When I bind NetBEUI and IPX/SPX, I do not have any hot PNP
>or other problems.)
>
I've seen simlar problems with an NDIS/USB/ATM driver. TCP/IP works fine with
hot PnP on Win2000 but gives the same problems you describe on Win98.
Please feel free to email me to discuss this offline.
AndyM
--
Andy Moreton
Virata Ltd http://www.virata.com/
Mount Pleasant House, Huntingdon Road, Cambridge CB3 0BL, UK
Tel: +44 1223 566919 Fax: +44 1223 566915
Prabhashankar
I am not alone!!! I am facing the same problem with out a solution!
Don't know if it's a bug in my driver or it's the TCP/IP. Please keep
posting/e-mailing the updates.
-Prabhu
In article <8214u...@enews3.newsguy.com>,
ry...@NOSPAM.cruzio.com (Ryan) wrote:
> Fellow USB/NDIS driver writers;
>
> I'm writing a USB/NDIS miniport for connecting two PC stations
directly over
> USB using a special Host-to-Host USB ASIC. The miniport is strongly
based on
> Microsoft's KB article Q224784 (NDIS with USB and 1394).
>
> The miniport is almost done, but I have a nagging problem with hot PnP
when I
> bind only TCP/IP. (When I bind NetBEUI and IPX/SPX, I do not have any
hot PNP
> or other problems.)
>
Sent via Deja.com http://www.deja.com/
Before you buy.
Ryan
(With any luck, the NDIS folks at Microsoft [or anybody who's solved this
problem] will see this article and point us in the right direction. [ -- Well
we can dream, can't we?])
Review (in case MS is watching): Our USB/NDIS miniports, based on MS KB
Q224784 (NDIS with USB and 1394) bound with TCP/IP, work fine, but only if the
USB devices are plugged in when the PC stations are booted. If one station is
hot unplugged/replugged, the network browser (i.e. Network Neighborhood) on
the other station(s) can no longer see that station. Oddly, the station that
got PnP'd can still see the other stations. Other protocols (IPX/SPX, NetBEUI)
do not exhibit this problem.
For any interested readers: The easiest test to see if this specific problem
applies to your miniport, run NBTSTAT -n (on the station you will be
unplugging/replugging) before and after PnP, and see if you lose the:
MYGROUP <1E> GROUP Registered
line after PnP. You can also try NET VIEW, but that doesn't really nail
anything down...
Ok, Andy and Prabhu, let's get on with it...
I used HookPeek.EXE from http://www.pcausa.com/ to log NDIS traffic for boot
vs. PnP conditions. I won't even pretend to understand all the packet content
(BTW, NetBIOS documents RFC1001 and 1002 describes a lot of packet content,
like all that funny "FEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF" stuff) but it is quite
clear that at boot time, a broadcast packet for a "Master Browser"
(NetBIOSName[15] == 0x1d) containing a browser path ("\MAILSLOT\BROWSE") is
sent, but that at PnP, time, no such packet is sent. I think (well I'm
guessing, really) that this packet, and others like it, must be sent after
replug in order for other stations to learn how to browse the PnP'd station.
What's interesting to me is that these symptoms are similar (but not an exact
match) to MS KB Q220586 (PnP NIC is not found on network). This article
says... "Your computer also does not internally register or export server or
browser names to the network." Which is exactly what we see... Perhaps it's
the same problem, but for TCP/IP/NetBIOS, and hot PnP...?
All:
- I apologize for the all this text, but please, let's contribute to this
thread 'til we figure this thing out! (It's been the biggest problem in my
project.)
- If any reader has a contact with the MS NDIS folks, please CC this article
to them (Walter? Eliyas?)
See also:
-
http://technet.microsoft.
com/cdonline/content/complete/windows/win2000/win2ksrv/technote/tcpipimp.htm
- MS KB Q224784 (NDIS with USB and 1394)
- MS KB Q220586 (PnP NIC not found on network)
Big thanks to:
- Thomas Divine <tdi...@pcausa.com> for HookPeek.EXE.
- Udo Eberhardt <Udo.Eb...@thesycon.de> for pointing me to RFC1001
RFC1002 and *LOTS* of other stuff.
Best regards,
Ryan
Following up to article <824q6...@enews4.newsguy.com>,
ry...@NOSPAM.cruzio.com (Ryan) wrote:
>
>I used HookPeek.EXE from http://www.pcausa.com/ to log NDIS traffic for boot
>vs. PnP conditions. I won't even pretend to understand all the packet content
>(BTW, NetBIOS documents RFC1001 and 1002 describes a lot of packet content,
>like all that funny "FEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF" stuff) but it is quite
>clear that at boot time, a broadcast packet for a "Master Browser"
>(NetBIOSName[15] == 0x1d) containing a browser path ("\MAILSLOT\BROWSE") is
>sent, but that at PnP, time, no such packet is sent. I think (well I'm
>guessing, really) that this packet, and others like it, must be sent after
>replug in order for other stations to learn how to browse the PnP'd station.
Another critical packet, I think, is the NetBIOS Group Name packet, with
NetBIOSName[15] == 0x1E. This packet is sent at boot time, but not at PnP
time. The '1E' packets are group "Browser Service Elections" packets. I'm
guessing these packets are necessary in order for another station to browse a
PnP'd station.
Thinking about it a little more, it seems that a station's internal NetBIOS
Names database may be as (or more) important than the NetBIOS Name packets
actually sent over the wire. To wit:
- When I run NBTSTAT -n after booting:
I see a full name list, including the 1E (Browser Service Elections)
- When I run NBTSTAT -n after unplug:
The name list becomes empty
- When I run NBTSTAT -n after re-plugging:
I see a partial name list, that does NOT include the 1E entry (!!!)
So what we need is a way to coax NetBIOS to completely update it's
internal name list, and issue a Browser Service Elections packet at PnP time.
(Easy, eh?) (NBTSTAT -RR does not appear to work, but then -RR is a WINS
thing, I think.)
Please contribute!
Best regards
Ryan
See also:
- MS KB Q163409 "NetBIOS Suffixes (16th Character of the NetBIOS Name)"
- MS KB Q188598 "Renewing Wins Client Registrations with NBTSTAT -RR"
- http://msdn.microsoft.com/library/winresource/dnwinnt/S7790.HTM for
various TCP/IP utilities
eli...@microsoft.com
folks are working on a fix.
-Eliyas
Ryan
I think we're on the right track: With W2000, hot PnP with TCP/IP works. (That
is, when the USB network device on W2000 is hot PnP'd, other stations can
still browse a W2000 station.) I believe Andy said W2000 worked with his
miniport too...
Detailing the differences, I see that at PnP time, W2000:
- Updates it's name table with the 1E (Browser Service Elections) entry
(Determined using NBTSTAT -n)
- Broadcasts a 1E (Browser Service Elections) packet
(Determined by examining packet traffic with HookPeek.EXE)
Neither of these events occur when a USB network device is hot PnP'd on a
Win98 or Win98SE station.
So, now what?
- Is there a way to tickle NetBIOS to update the name table and broadcast
the 1E (Browser Service Elections) packet?
- Can NetBIOS be dumped for some other mechanism (It seems like MS is trying
to phase out NetBIOS.)
Anybody that understands this NetBIOS stuff, feel free to jump in!
Regards,
Ryan
In article <826kv...@enews3.newsguy.com>, ry...@NOSPAM.cruzio.com (Ryan)
wrote:
Andy Moreton
>I checked around and found out that this is a known problem and MS
>folks are working on a fix.
>
>-Eliyas
>
Thanks for the info Eliyas - could you post something here when they come up
with an answer ?
Ryan
>I checked around and found out that this is a known problem and MS
>folks are working on a fix.
>
>-Eliyas
Thank you!
At the risk of sounding pushy, do you think the MS network folks could be a
bit more forthcoming? Such as:
- Details about what exactly they are fixing
- Status of the fix
- Scope of the problem (Is it just NetBIOS?)
- Workaround options (Can we tickle NetBIOS to make it fix itself?)
- Is there a way for developers to be kept up-to-date?
And even more important:
- When can USB/NDIS developers get a sample fix (Days? Weeks? Months?)
- When can we expect a publicly available fix
- How will the fix be implemented (Shipping a fix with the product is OK, but
forcing end-customers to do an entire system update over the net is not.)
All of us USB/NDIS developers that built miniports based on MS KB Q224784 are
now stuck with good products and good drivers that we can't ship until this
situation is resolved.
BTW, not only did I base my miniport on MS KB Q224784, but I've also
recommended it to several others as an excellent USB/NDIS miniport model. Now
I have no choice but to eat my words and recommend against it.
We have options to MS KB Q224784 but the only choices are in the exact
opposite direction of the spirit of PnP driver technology. (Not to mention a
significant code re-write that is chock full of PnP/BSOD pitfalls and customer
complaints.)
Anyway, thanks for all you've done - I know your just the messenger...
Regards,
Ryan
Ryan
IPX/SPX protocol!
IPX/SPX works fine. And it even works with hot PnP BUT... If another NIC is
installed (say, a PCI ethernet NIC) and it is also bound with IPX/SPX, then
after USB hot PnP, the station will not be available to other stations on the
USB network.
At first this seemed too bizarre, like something unrelated to this thread was
going on. Then, using HookPeek to analyze packet content, it became apparent
that IPX/SPX has the same PnP problem that NetBIOS has, but in this case it
only appears when there's another NIC in the system. Weird.
More than you want to know: At PnP time, IPX/SPX sends a bunch of packets to
the miniport via NDIS, but what's missing are the all-important packets that
identify the browser path (\MAILSLOT\BROWSE) and other stuff so that other
stations can see the station. These packets appear at boot time, or at PnP
time, if the other NIC is not installed.
Can anybody confirm (or deny) the basic "USB/NDIS: Hot PnP fails with
IPX/SPX if another NIC installed" behavior I experienced?
Thanks,
Ryan