Siarzhuk Zharski <zharik@xxxxxx> wrote: > On Fri, 20 Nov 2009 09:42:41 +0100, "Axel Dörfler" > <axeld@xxxxxxxxxxxxxxxx> > wrote: > >> 2) Which error code should I return form the Write IOCTL call in > > > case > >> the link is not active? > > Maybe ENETUNREACH? I dunno, I guess other drivers just eat this > > packet, > > or maybe they put it in their queue waiting to get a link. The > > stack > > needs to ignore the link status, as some drivers have some problems > > reporting the right one. > OK, I'll try ENETUNREACH and, probably, will play with returning B_OK > too. > ;-) If I understand your problem correctly, blocking would be the correct solution. > > I don't understand you - what write are you talking about? > I meant the Write IOCTL handling. OK, let me do some "historical" > explanation. Early version of my driver doesn't check for link state > during > sending data to the network. In this case DHCP auto-configuration > work in > circa 25% of the system reboots. Than I saw in the syslog, that first > attempt to send something to network is performed before the initial > negotiation is finished and link become active. That's because the stack doesn't care about the link yet; it will prefer routes with a linked interface, but will choose one without a link else. So if you know your driver won't be able to send a certain packet because the auto-negotiation is still in progress, you should block until it is done. That would also explain the driver dependency you saw. > By the way, what you decide to do with broadcast flag in DHCP > discover/request messages? I think we should not set it by default, but rather fix receiving packets on unconfigured interfaces. Bye, Axel.