#141 Some network card can't work well with ndis-bridge

[Anonymous]

"Atheros AR8121/AR8113/AR8114 PCI-E Ethernet Controller", this card is integrated with asus p5q-se motherboard(I have updated to the latest driver), ping between the host and the colinux will hang the host(but arping works well).

I also tested another card "Realtek RTL8168C(P)/8111C(P) PCI-E Gigabit Ethernet NIC", it is integrated with giga ep31 motherboard, but it did not have this problem.

[Henry N.]

What does the problem, if you replace the ndis-bridge with pcap-bridge?
Today the filter rule for ndis-bridge was changed. Perhaps this solves your problem?

[Nobody/Anonymous]

New snapshot 1130 solve the Non-IP packet problem. This time I meet this bug too, my card is Atheros L2.

[Nobody/Anonymous]

After some research, I think the problem is packet forward loop. Filtering out packets from virtual mac to self/broadcast packets seems fix it.

[Nobody/Anonymous]

The real problem is NdisSend() with dest == hostMac, previous comment is wrong.
Drop packet with dest == OID_802_3_CURRENT_ADDRESS fix it, but host & guest can't commucation anymore.

[Nobody/Anonymous]

pcap-bridge did not have this problem. I also upgraded to 1130, this problem still existed.

[Henry N.]

Have a host with same problem. - That's good, so I can trace it.

A ping from coLinux to host freezes the host.
The card is a Realtek RTL8102E Family PCI-E Fast Ethernet NIC.

[Henry N.]

This is hard to debug. I found an error in co_debug now.

All back call handlers, for example SendCompleteHandler=co_conet_proto_send_complete are in "IRQL: DISPATCH_LEVEL", see Requirements on this article http://msdn.microsoft.com/en-us/library/ms797308.aspx

If we call a KeWaitForSingleObject from DISPATCH_LEVEL we risk a BSOD Bug Check 0xB8: ATTEMPTED_SWITCH_FROM_DPC (http://msdn.microsoft.com/en-us/library/ms795832.aspx). Exactly that does co_debug(), so I can not use it.

An interesting article about IRQL I found here: http://ext2fsd.sourceforge.net/documents/irql.htm

For the NdisSend, I assume any of the completion call backs tries NdisAcquireSpinLock, and that can hang on disabled interrupts (DISPATCH_LEVEL = disabled interrupts). NdisAcquireSpinLock is a macro for KeAcquireSpinLock. Should we use NdisDprAcquireSpinLock (alias KeAcquireSpinLockAtDpcLevel) in this call back routines?

For better overview have created function flows graphics from ndis driver:
http://www.henrynestler.com/colinux/codeviz/ndis-bridge/

[Henry N.]

Was a wrong parameter in case of non pending packet after NdisSend.
Found and committed to SVN as revision r1218.