Messages in this thread | | | Subject | Re: Frame Relay on Linux | From | Krzysztof Halasa <> | Date | 24 Aug 1999 18:21:42 +0200 |
| |
Linux Lists <lists@cyclades.com> writes:
> 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/
| |