[haiku-development] Re: Network Issues. Part II. Yet another tile for the Puzzle ...

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Fri, 20 Nov 2009 12:53:56 +0100

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.


Other related posts: