For unattented system installation and imaging we are using a DOS bootdisk with NDIS2 drivers and TCP/IP-stack with DHCP usage.
We are using the E1000.DOS driver with the signature "Intel(R) Gigabit Network Connection Driver v5.67 111610".
This works fine for the following configurations:
PCI-Vendor-ID PCI-Device-ID PCI-Subsys-ID
8086 1502 833810F7
8086 1502 1495103C
8086 1502 161C103C
Now we just got a new notebook that has the network device VEN_8086\DEV_1502\SUBSYS_179B103C installed onboard.
With this hardware our bootdisk does not work. It times out when asking the DHCP-server for an IP-address.
There is a pre-installed Windows 7 on the notebook. Booting this operating system DHCP works just fine.
So this seems to be a DOS driver issue.
Using the latest DOS-driver with signature "Intel(R) Gigabit Network Connection Driver v5.79 041912" did not change the behaviour.
Capturing the network traffic showed that the ethernet card send a DHCP-request-packet. After this the DHCP-server answered with an DHCP-offer-packet. But the ethernet device seems not to recognize the answer and sends out another DHCP-request after waiting a couple of seconds gets a new DHCP-offer in return and ignores it again. This happens a couple of times before the TCPTSR.EXE-program times out. So everything happens according to the DHCP-specification asides from the ethernet device ignoring the answers.....
Does anybody have an idea what I can do about it?
Intel just released the "Intel Ethernet Connections CD" version 17.4.
There is a DOS-driver with the signature "Intel(C) Gigabit Network Connection Driver v5.81 072012" included.
That is the driver Ulli already mentioned.
I just tried this and it did NOT work for me as well.
Our problem is not even listed in the "known problems"-section of the readme-file.
Hi this is Doug at the factory. We've started a support case on this issue and we will let you know what we figure out. Thanks for your patience and thanks for using Intel Ethernet.
Doug from the factory here with an update on the DOS driver not getting DHCP replies on some systems.
First of all, thanks for everyone's patience and willingness to share details on the issue.
Second, we believe we have root cause. The interrupt environment in the DOS is very old. Lots of DOS components don't like sharing interrupts. In this case, that sharing is causing the issue. On the platforms we tested with, if the LAN was on a separate IRQ from other devices, it would work fine. But if it was shared, that was the when the issue would be seen. There is a device interrupt handler that was not forwarding the interrupt to our driver when the two share the same IRQ line.
That's all the good news. The less good news is that the solution to this needs to be in the BIOS. The driver can't change the IRQ handler chain and if the device that eats our HW interrupt gets before us, we're done. So the BIOS has to set the IRQs separately so everyone can play nice. We've been working with the OEM partner to have an updated BIOS, but things like timing and availability is up to them. Furthermore the release of the solution is up to them, they might not elect to release it on all platforms. So please, if you have this issue, consult with your HW provider, and hopefully soon you'll have a new BIOS that makes this issue go away.
Thanks for using Intel® Ethernet, and if you have questions about this issue, I'll keep my eye on the thread and will post answers when I can.