Hmm, did you miss this paragraph? In particular the part about the
?micro-TCP driver/PXE UNDI? and rejecting requests until the network
(drivers) are available?
The bootable iSCSI driver 215 is in the embodiment of the invention shown in
FIG. 2 distinct from a traditional iSCSI driver in its structure, which
includes modules providing specific functions. A multiplexing layer receives
SCSI commands from a SCSI port driver, and determines how to route the
received command. If the operating system network and disk drivers are
loaded and enabled, the normal iSCSI path using the operating system network
drivers is used. If the operating system network drivers are not loaded and
enabled but the PXE UNDI or other network drivers are available, the
micro-iSCSI driver is used along with the micro-TCP driver. If neither
driver is yet loaded, the request is rejected.
And another thing:
I Request you all geeks ?
My kids, wife, and mother can call me that but generally my colleagues &
peers don?t, especially when they want something J. (don?t worry, I am just
kidding!)
As best I can tell from your posts you have got all of the necessary drivers
loaded and have opened an address object on TCP, a connection object on TCP,
and are trying to connect it. You get one of two results;
STATUS_HOST_UNREACHABLE or STATUS_IO_TIMEOUT.
Out of curiosity, do you have some scheme by which you can ?wait? for
TCPIP.SYS to signal via the TDI Client Callbacks that it actually has an
interface bound and assigned an address to over-which your client might
actually be able to perform this connect? Does your TDI client call
TdiRegisterPnPHandlers() or do you just open \Device\Tcp at DriverEntry()
time and expect that TCP/IP is all ready to go then? I would expect that a
callback from TDI/TCPIP at your ClientPnPAddNetAddress() handler would be a
pretty good clue that it was now possible to make a connection.
The other thing that comes to mind to ask you is if you ?retry? the
connection operation some number of times?
And lastly, in the case of when you setup a static IP address on the NIC and
the error changed to STATUS_IO_TIMEOUT, did you by any chance sniff the wire
and see if an ARP exchange occurred and a TCP-SYN packet left your system?
You are expecting a whole lot of the infrastructure to reach a certain stage
of operational capability which involves a bunch of asynchronous activities
converging. Your usage of those facilities needs to be able to wait for
them to become ready.
Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Charansing Rajput
Sent: Monday, September 15, 2008 9:53 AM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] making TDI (tcp) Calls from a scsi miniport at boot
time
Hi All,
I have been trying hell lot of things to get my network volume up using my
scsi miniport with network backend, but its not helping.
I booted off an iSCSI target using MS iSCSI initiator and in this remotely
booted system i installed my scsi miniport. I still get the same error i.e.
STATUS_HOST_UNREACHABLE . I tried to set the dependency on iScsiPrt but it
doesn’t work. I think the problem is mup.sys which loads after my driver.
How do I load mup.sys before my driver? in my inf file i tried to set
Dependencies = Mup as well as in registry i set DependsOnGroup = Network (as
Mup is in Network group) But mup.sys loads just after my driver only.
I tried to give my machine a static IP but then on connection request i get
error STATUS_IO_TIMEOUT.
I also studied the “US Patent 6857069 - Modified operating system boot
sequence for iSCSI device support”, and followed al the steps mentioned in
the document. But its one and the same. I still get STATUS_HOST_UNREACHABLE.
I Request you all geeks to please help me find solution to this problem, as
now i am almost getting frustrated 
On Thu, Sep 11, 2008 at 1:33 PM, Charansing Rajput
wrote:
Hi,
Please see my comments inline…
On Thu, Sep 11, 2008 at 1:03 PM, Mark S. Edwards
wrote:
Getting the TCP stack available for other boot start drivers has always been
a hit and miss affair. In fact it was never a goal of Windows to have the
TCP stack available that early.
How come MS iSCSI boot time initiator work then?
When people did start trying to do it they sometimes succeeded and often
failed when they came across parts of the stack that needed memory paged in
and hit a BSOD.
Considerable effort was put in to hardening the stack with the creation of
the boot version of the iSCSI driver. You say that you have installed this
in the hope that it brings the TCP stack up early. However, my
understanding is that this would only work if you really were booting off a
NIC device.
Great!! This is something I haven’t yet tried. I’ll try this first and let
you know.
In all other cases the bets are off as to the precise point at which the TCP
stack becomes properly initialised. Factors can include whether the IP
information is static or if the DHCP service has to run - have you tried
both ?
The IP is DHCP and DHCP server is running. Do you mean DHCP client service
running on the machine which has my miniport? I dont know rather dont think
if this service can start before the SCSI miniport.
I’ll try static now.
You should look at changing your dependencies to something that you know
also relies on the network stack. If this works, then you could experiment
with trying to find earlier loading dependencies.
I had once set the dependency on iSCSI group but it dint work
Mark.
At 08:02 11/09/2008, Charansing Rajput wrote:
Hi Doron,
Thanks a lot for replying…
below is the devnode output of the NIC miniport, NDIS, tcpip and TDI
drivers…
kd> !devnode 0 1 dc21x4
Dumping IopRootDeviceNode (= 0x83323a88)
DevNode 0x834071a0 for PDO 0x83407b18
InstancePath is
“PCI\VEN_1011&DEV_0009&SUBSYS_21140A00&REV_20\3&267a616a&0&50”
ServiceName is “DC21x4”
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
kd> !devnode 0 1 ndis
Dumping IopRootDeviceNode (= 0x83323a88)
DevNode 0x83322808 for PDO 0x83322958
InstancePath is “Root\LEGACY_NDIS\0000”
ServiceName is “NDIS”
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
kd> !devnode 0 1 tcpip
Dumping IopRootDeviceNode (= 0x83323a88)
DevNode 0x83410c98 for PDO 0x83410de8
InstancePath is “Root\LEGACY_TCPIP\0000”
ServiceName is “Tcpip”
State = DeviceNodeStarted (0x308)
Previous State = DeviceNodeEnumerateCompletion (0x30d)
kd> !devnode 0 1 TDI
Dumping IopRootDeviceNode (= 0x83323a88)
I am not really an expert WinDBG user, i use it for general kernel
debugging, so dont understand what !devnode is trying to say…
Please check and see if there is anything wrong…
Regards,
Charan
On Thu, Sep 11, 2008 at 11:49 AM, Doron Holan <
mailto:xxxxx xxxxx@microsoft.com> wrote:
Just because the driver is loaded, esp for a boot start driver does not mean
that it has been started on a piece of hardware. In your DriverEntry, upon
failure break into the debugger and run
!devnode 0 1 dc21x4
That will tell you the pnp state of the NIC
d
From: xxxxx@lists.osr.com [
mailto:xxxxx
mailto:xxxxx@lists.osr.com] On Behalf Of Charansing Rajput
Sent: Wednesday, September 10, 2008 11:11 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] making TDI (tcp) Calls from a scsi miniport at boot time
Hi,
Thanks a ton for replying 
Below is the windbg verbose output of driver loading. dc21x4.sys is the NIC
miniport which is marked to boot start. And it does start as asked. Which
drivers (apart from the ones which start before SCSI_NBD.sys[my
SCSIMiniport]) do you think should get loaded before my scsi miniport
driver?
ModLoad: f7710000 f7718000 kdcom.dll
ModLoad: f7718000 f7720000 BOOTVID.dll
ModLoad: f743b000 f746f000 ACPI.sys
ModLoad: f7490000 f7499000 WMILIB.SYS
ModLoad: f7425000 f743b000 pci.sys
ModLoad: f74a0000 f74af000 isapnp.sys
ModLoad: f7720000 f7727000 intelide.sys
ModLoad: f74b0000 f74bd000 PCIIDEX.SYS
ModLoad: f74c0000 f74d0000 MountMgr.sys
ModLoad: f73fe000 f7425000 ftdisk.sys
ModLoad: f7728000 f772f000 dmload.sys
ModLoad: f73d2000 f73fe000 dmio.sys
ModLoad: f73a8000 f73d2000 volsnap.sys
ModLoad: f74d0000 f74db000 PartMgr.sys
ModLoad: f7369000 f73a8000 NDIS.sys
ModLoad: f7358000 f7369000 dc21x4.sys
This is the NIC miniport driver
ModLoad: f7332000 f7358000 KSecDD.sys
ModLoad: f74e0000 f74ea000 iscsibp.sys
ModLoad: f7319000 f7332000 ipsec.sys
ModLoad: f74f0000 f74fe000 msgpc.sys
ModLoad: f7500000 f750b000 TDI.SYS
ModLoad: f7289000 f7319000 tcpip.sys
TDI, NDIS, TCPIP get loaded well before my miniport loads
ModLoad: f726c000 f7289000 atapi.sys
ModLoad: f7730000 f7738000 TDIClient.sys
This is my driver which manages network connections
ModLoad: f7510000 f751a000 SCSI_NBD.sys
This is my virtual scsi miniport driver
ModLoad: f724d000 f726c000 SCSIPORT.SYS
ModLoad: f7520000 f7530000 disk.sys
ModLoad: f723a000 f724d000 CLASSPNP.SYS
ModLoad: f7215000 f723a000 fltmgr.sys
ModLoad: f7530000 f753c000 Dfs.sys
ModLoad: f7738000 f773d200 ino_flpy.sys
ModLoad: f7180000 f7215000 Ntfs.sys
ModLoad: f7161000 f7180000 Mup.sys
ModLoad: f7139000 f7161000 msiscsi.sys
ModLoad: f7122000 f7139000 iscsiprt.sys
ModLoad: f7540000 f754a000 crcdisk.sys
SCSI_NBD::DriverEntry:: Done
SCSI_NBD::HwScsiFindAdapter:: The NBDClient Connection with NBDServer
Failed! NtStatus = c000023d Here it fails
You can see that my miniport fails to make TDI_CONNECT above…
Please help…
Thanks and Regards,
----------------------------------------------------------------
Charansing D Deore
Sr. Software Developer,
CalSoft Pvt Ltd.
Baner Road, Pune-411045
Office: +91 20 39853000 Ext: 3055
Cell: +91 9850960550
----------------------------------------------------------------------
Subject: RE: making TDI (tcp) Calls from a scsi miniport at boot time
From: Doron Holan < mailto:xxxxx
xxxxx@microsoft.com>
Date: Wed, 10 Sep 2008 08:51:57 -0700
X-Message-Number: 19
Is your scsi virtual miniport root enumerated? If so, there is no coordinat
between your device starting and the NIC starting. You would have to mark
the NIC’s miniport as boot start and then hope it is started before your
storage miniport driver is.
d
From: xxxxx@lists.osr.com [
mailto:xxxxx
mailto:xxxxx@lists.osr.com] On Behalf Of Charansing Rajput
Sent: Wednesday, September 10, 2008 6:20 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] making TDI (tcp) Calls from a scsi miniport at boot time
Hi,
I have developed a virtual scsi miniport driver with network back-end which
makes TDI calls to read a network block device located on a remote machine.
I am running this driver on windows 2003 server SP3. This is working very
much fine when the OS is UP. I want to load this driver at the boot time
itself. For this i have made some changes in the load order of drivers so
that ndis.sys, tdi.sys, tcpip.sys load before my miniport driver. In my
miniport’s inf file i have set the Dependencies on PNP_TDI, NDIS and TDI.
In FindAdapter, when i try get the device object on \Device\Tci, I get a
valid Device Object pointer, and i can also call IoCallDriver on it. But the
IOCTL TDI_CONNECT fails and gives error STATUS_HOST_UNREACHABLE
(0xC000023D).
The same code works very well when the OS is fully UP.
I also tried the same thing by installing MS boot time iSCSI initiator and
setting my miniport’s dependancy on iScsiPrt, thinking that if iScsiPrt can
make tcpip calls then I should be able to do too. But in vain… I still get
STATUS_HOST_UNREACHABLE.
Please help to find solution to this problem.
Thanks and Regards,
----------------------------------------------------------------
Charansing D Deore
Sr. Software Developer,
CalSoft Pvt Ltd.
Baner Road, Pune-411045
Office: +91 20 39853000 Ext: 3055
Cell: +91 9850960550
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
Thanks and Regards,
----------------------------------------------------------------
Charansing D Deore
Sr. Software Developer,
CalSoft Pvt Ltd.
Baner Road, Pune-411045
Office:+91 20 39853000 Ext: 3055
Cell:+91 9850960550
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
Thanks and Regards,
----------------------------------------------------------------
Charansing D Deore
Sr. Software Developer,
CalSoft Pvt Ltd.
Baner Road, Pune-411045
Office: +91 20 39853000 Ext: 3055
Cell: +91 9850960550
–
Thanks and Regards,
----------------------------------------------------------------
Charansing D Deore
Sr. Software Developer,
CalSoft Pvt Ltd.
Baner Road, Pune-411045
Office: +91 20 39853000 Ext: 3055
Cell: +91 9850960550
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>