Date: Thu, 10 Aug 2000 08:18:58 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: arch@FreeBSD.ORG Subject: Interface types defined in if_types.h Message-ID: <00Aug10.081900est.115209@border.alcanet.com.au>
next in thread | raw e-mail | index | archive | help
(This is prompted by a comment by Garrett Wollman in PR kern/19436 - that
FreeBSD needs to define a specific interface type for IEEE 802.1q VLANs).
/sys/net/if_types.h describes itself as:
* Interface types for benefit of parsing media address headers.
* This list is derived from the SNMP list of ifTypes, currently
* documented in RFC1573, now maintained as:
*
* ftp.isi.edu/in-notes/iana/assignments/smi-numbers
The current version of smi-numbers lists 115 ifTypes that don't appear
in if_types.h (including l2vlan (135) for 802.1q). FreeBSD also
defines 4 types (IFT_GIF, IFT_PVC, IFT_FAITH and IFT_STF) that don't
match IANA assignments.
It would seem to be useful to just import the latest ifTypes list,
but the way FreeBSD is using IFT_xxx macros does not perfectly map
onto the SNMP ifType. Two groups of mismatches are readily apparent:
1) FreeBSD uses a single type (IFT_ETHER) to represent all Ethernet-
like interfaces, whilst ifType defines different types for 100baseTX,
100baseFX, 100baseVG, Gigabit Ethernet and 10Mbps Ethernet.
2) IANA define single softwareLoopback (24) and encapsulation (131,
tunnel) interfaces. FreeBSD needs to distinguish between different
softwareLoopback devices (lo(4), tun(4)[1] and faith(4)) as well as
different encapsulation devices (gif(4) and stf(4)).
In the former case, it might be possible to separate out all the
different Ethernet media types, but this would add a degree of
complexity to each ethernet driver (switching between 10Mbps and
100Mbps would entail changing the if_type value, it would also
be necessary to distinguish between the various 100Mbps media
types - which may or may not be possible, depending on the PHY),
for (IMHO) no gain.
In the latter case, FreeBSD must be able to distinguish between
different pseudo devices. If they were all mapped onto a single
if_type, then a different field would be necessary to distinguish
them.
How to proceed? Should all the ifTypes be imported - with the
understanding that some just won't get used. Should we import and use
the ifType name/number where if suits us and ignore the rest? How
should we distinguish different pseudo devices - just make up numbers
and hope we don't clash?
[1] tun(4) currently defines itself as IFT_PPP - whilst this is the
most common use, there does not appear to be anything in the
device that limits it to PPP.
Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00Aug10.081900est.115209>