Re: Fw: Link Triggers on Linux

Hi,

Sounds similar to Win2k's ability to notify user-space processes of the link
going up/down on Ethernet interfaces. But that's nothing that can't be
achieved by polling the appropriate ifioctl.

On Sat, Sep 28, 2002 at 05:30:20PM +0200, Marco Molteni wrote:
>     WLAN events :
>     o SIOCGIWAP(addr) : Successfully registered to Access Point
> with address 'addr'. If 'addr' is NULL, it means that we could not
> find any Access Point suitable (out of range). This is generated at
> the end of the link layer handoff.
>     o IWEVTXDROP(addr) : Packet sent to 'addr' was dropped due to
> excessive retries.
>     o SNR : this is not an event, but you can poll the SNR for
> each peer through iwspy (updated on Rx'd packets).

I think knotes might be most appropriate. Specifically, adding messages
to those which would be handled by PF_ROUTE, and having the socket
bound to a kqueue, so that asynchronous notification can take place.

For the third, have a look at /usr/ports/net/wmwave.

>     IrNET events :
>     o Disconnected(addr) : IrDA stack closed the link connection
> to peer 'addr'. May be due to link failure (12s timeout) or explicit
> disconnection from one end. At this point, the IP interface is going
> to be destroyed.
>     o Link-Blocked(addr) : Peer 'addr' failed to turnaround the
> link layer. We have not heard from the peer for one second (max link
> turn around time in IrDA is 500ms). However, the connection to the
> peer still has not timed out.

FreeBSD doesn't grok IrDA. Last I heard, someone was planning on porting
a userspace IrDA stack to NetBSD.

Many OEM motherboards have IrDA headers, but not the LEDs. I managed to
sniff out a retail supplier of OEM backplates with the LEDs in the UK. If
anyone's up for it, suggest we club together and buy them as a group.

> 5) Where do events go
> ---------------------
>     Some people have suggested that those events should go up the
> IP stack. I personally don't think that this is the best approach,
> because this is not where those events are needed. And also I don't
> want to polute the TCP/IP higher layer interfaces with link specific
> stuff (this is about layer separation).

See above.

BMS

To Unsubscribe: send mail to [email protected]
with "unsubscribe freebsd-mobile" in the body of the message