> Have you ever seen a case where the UNDI API does not report the correct
> interrupt number for the UNDI device?
No, it always reported correct number (at least in my tests), the same number reported BIOS at POST. But same interrupt may be shared with other devices, in such case – difficulties are probable (cause it’s needed to chain interrupt to second handler).

> Or have you encountered UNDI implementations that do not trigger
> interrupts when frames are received?
That is possible. In fact, during coding pxe_http I’ve met such problem – in some cases interrupt was not triggered (I don’t remember now, was this situation on virtual machine or on my Intel motherboard). I think problem may be in incorrect End of Interrupt (EOI sending to PICs) handling in my code (although I was writing it practicaly the same as in Intel examples and sample code from related books). But this problem was solved by omitting triggered interrupt check.

It’s possible call PXE API function PXENV_UNDI_ISR with FuncFlag PXENV_UNDI_ISR_IN_PROCESS even if there was no interrupt. In such case you will get PXENV_UNDI_ISR_OUT_DONE or new packet flag if any frame received.

So, you will get small overhead by calling function if there was no interrupt, but code will be correctly working. AFAIK, earlier Etherboot implementation worked similar (call without triggering check), look comments to undi_poll() function at /drivers/net/undi.c.

Hope, this will help you.

Have you ever seen a case where the UNDI API does not report the correct interrupt number for the UNDI device? Or have you encountered UNDI implementations that do not trigger interrupts when frames are received?

Thanks!

This result is enough for this test. Main goal for provided executable – test, if PXE API is called correctly in different implementations. It seems it works, and that’s good. DUP! issue seems result of not very good implementation of ICMP in my code (I’ll check, which is may be origin of this), but it’s unrelated to PXE.

The next test will be related to DNS resolving after I finish doing of UDP and first version of sockets implementation. I tjhink, it’ ll be done at the end of this week.

And the most interested test will be simple telnet client. Main purpose to test TCP implementation. It’s birthdate at the end of Juny/start of July.

And after that – final result.

I’ll drop you some lines after doing new tests.
Once more, thanks for interest.

compaq evo: intel boot agent 4.1.08
can:
pxe arp both gateway and another node on local lan
pxe ping gateway, another node on local lan, and another node on another network when gateway is set manually with pxe route
pxe await and reply to pings from both local node and gateway, however first reply is sent twice for both. ex:
$ ping 192.168.1.8
PING 192.168.1.8 (192.168.1.8): 56 data bytes
64 bytes from 192.168.1.8: icmp_seq=1 ttl=64 time=8.023 ms
64 bytes from 192.168.1.8: icmp_seq=1 ttl=64 time=8.459 ms (DUP!)
64 bytes from 192.168.1.8: icmp_seq=2 ttl=64 time=5.102 ms

if there is anything specific you’d like to have tested, just fire me off an email. I’m anxiously awaiting this project and would like to do anything I can to help

The only thing that is definitly – that protected mode with 32 bit stack is not suppoprted in some UNDI functions. But it’s not said e.g., when PXE! structure fields related to segments selectors are filled if system starts in real mode and my code will start PM. It’s said “filles in by UNDI before any calls are made”. But, how it’ll find selector in my space? Or I must use this selector and load GDT uusing provided values. And etc. It’s a little bit hazy for me.

Thanks for you help suggestion, but as I see in Etherboot and other PXE related projects (pxeboot in FreeBSD), main trick is to go in real mode (to be more correct: virtual 86 mode) before calling PXE and UNDI functions, so I’ll do the same and thus it will not be protected mode problems in working with PXE. At least, I hope for that.