> I remember that a while ago there was a thread here talking about the
> development of Frame Relay on Linux. IIRC, there were two people (or two
> groups) developing it separately, and they decided to join their efforts
> ... or something like that.
I only know about comx drivers, developed by Gergely Madarasz
<gorgo@caesar.elte.hu>.
In fact, I've been working on my-own FR implementation for some time.
Currently it's usable with SDL N2 card (this is a "dumb" ISA HDLC board,
which can do flags/checksums/etc in hardware, at 4Mbps+ speeds).
It's possible to use ANSI or CCITT LMI now, and a port can be DTE
or DCE ( = FR network) side. I've also implemented IARP (InARP) handling
- the card would answer IARP queries from remote (but not generate requests
itself - every PVC here is a separate pvcXX network device). I plan to make
my implementation available within days, when all obvious problems are fixed.
However, I'm not sure how to do some things:
- Inverse ARP (RFC2390). This is an extension to standard ARP. It uses
operation code 8 and 9, instead of standard 1 and 2. IARP is used for
letting the other side know our IP (or, say, IPv6 etc) address, when the
DLCI (hardware) address is available (from LMI messages).
Should I move IARP handling to /usr/src/linux/net/ipv4/arp.c (which seems
natural for me), or should it stay in FR layer code?
- Should I allow a dynamic configuration of remote IP address(es) (via IARP
queries)? Or it would be better not to send any IARP requests, and
always configuring both our and remote IPs?
- I assume 'hard_header' routine should be used for filling (skb_push etc)
frame headers, and 'xmit' should just send unmodified frames to the
hardware device. Is that right?
-- Krzysztof Halasa Network Administrator- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/