#16 Common Link Layer for ethernet ARP/DHCP APIs
The current LANceGS ethernet link layer implements
ARP.
A link layer to support any other ethernet device would
also need to implement ARP.
There is a proposal to encourage separation of the APIs
that support ethernet (e.g. ARP/DHCP) from the lower
level device specific stuff that deals with "how to talk to
device xyz".
e.g. (from Init/I.DISPATCH.S)
|-------------|
| Link1 | ---> Device driver (SLIP, PPP etc.) "LINK"
prefix
|-------------|
|
|-------------|
| Link0 | ---> Interface card / port
|-------------|
This RFE is for the implementation of Link1 for ethernet
to become a MOSP deliverable.
The implementation of Link0 will be device specific and
will not become a MOSP deliverable unless the
implementer makes this available to MOSP under the
terms of the LGPL.
Logged In: YES
user_id=257705
Geoff Weiss comments on the functionality of an ethernet
Link1:
It is up the link layer developer to engineer the best solution.
One possible method is for a heartbeat to be started by the
link layer within the LinkStartup function and removed with the
LinkShutdown function. This Link Layer heartbeat is
completely independent of Marinetti and not associated with
Marinetti's polling. The Link Layer is completely responsible
for the enabling, running, and disabling of the heartbeat. The
heartbeat routine is not accessable by Marinetti--Marinetti
does not care if a heartbeat exists or not.
When the heartbeat runs, it calls LinkGetDatagram.
LinkGetDatagram has to handle ARP requests (by returning
an ARP response). If DHCP is implemented,
LinkGetDatagram would have to watch and handle DHCP
specific requests coming from the DHCP server (i.e. respond
to "Are you alive"). LinkGetDatagram knows only to return IP
packets. So if the heartbeat sees that LinkGetDatagram
returned a packet, it passes the packet to the Marinetti
IPNotify function (Proposed in RFE [1172545] Support packet
notification from Link Layer).
Logged In: YES
user_id=257705
Geoff Weiss provided references that may assist in
determinng what could make up the API between Link1 and
Link0:
In terms of the Linux API, here are a bunch of relevent links:
Linux kernal networking sockets:
http://kernelnewbies.org/documents/kdoc/kernel-
api/netcore.html
Linux kernel ethernet device support:
http://kernelnewbies.org/documents/kdoc/kernel-
api/netdev.html
SMSC device driver:
http://www.x86-64.org/cgi-
bin/cvsweb.cgi/linux/drivers/net/smc9194.c?rev=1.8&content-
type=text/x-cvsweb-markup
Based on this information, there is no specific ARP functions
handled by the kernel. I will have to assume that this means
it is an internal function of the Linux ethernet link layer
(between the IP socket and device driver layers).
and Geoff comments further on what this Link1 should do:
This layer will take care of handling the routing to different
network interfaces, ARP, and handling the functions
associated with an ifconfig front-end (enabling/disabling
interfaces, allowing multicast, etc.).
I would like to see hooks in place so third party software can
snoop and insert packets. I want to see this completely user
configurable (i.e. users can resize the ARP cache, specify
the ARP timeout, etc.). I don't care if there are any user tools
written to change values, but these parameters need to be in
a config file of some sort (not a resource fork) which can be
easily modified if needed. It should be noted that multiple
ethernet cards be supported at this layer.
Marinetti will only use one IP address from a link layer. This
means that if someone puts multiple ethernet cards in a IIgs,
only one is accessable by Marinetti at this time. Also, DHCP
can be implmented in the ethernet layer for greater network
compatibility.
Logged In: YES
user_id=257705
More detail on the ARP functions that should be supported by
this layer:
a) Needs to maintain an ARP cache
b) Needs to respond if the incoming packet is an ARP query
and build an approriate response (including adding to the
ARP cache).
c) Needs to determine if the source address of an incoming
IP packet is in the ARP cache if not then add it
d) If an address in the outgoing packet is on the same subnet
then a lookup needs to be done into the ARP cache. If not
found then the MAC address needs to be determined by
broadcasting an ARP request and then filling the table in with
the ARP reply
e) Needs to age out older entries in the arp cache or have
some mechanism to overwrite older entries as needed
Logged In: YES
user_id=257705
Glenn Jones' Uthernet LL has drawn on MagerValps ip65 code
for ARP routines and other things. This is source code
licenced under BSD.
Once the Uthernet LL has been implemented, the next goal
is to define what is Uthernet specific and what can be
made into a generic Link1 driver.