#
272461 |
|
02-Oct-2014 |
gjb |
Copy stable/10@r272459 to releng/10.1 as part of the 10.1-RELEASE process.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
256281 |
|
10-Oct-2013 |
gjb |
Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
210936 |
|
06-Aug-2010 |
jhb |
Ethernet vlan(4) interfaces have valid Ethernet link layer addresses but use a different interface type (IFT_L2VLAN vs IFT_ETHER). Treat IFT_L2VLAN interfaces like IFT_ETHER interfaces when handling link layer addresses.
Reviewed by: syrinx (bsnmpd) MFC after: 1 week
|
#
166956 |
|
24-Feb-2007 |
sam |
use getifaddrs from libc instead of private code
Reviewed by: bms MFC after: 1 month
|
#
154401 |
|
15-Jan-2006 |
ru |
Fix an off-by-one bug.
Submitted by: Ulrich Spoerlein
|
#
139494 |
|
31-Dec-2004 |
sam |
Fix special status reporting. Prior to the reorg there was special-purpose code to display status for an interface for state that was not address-oriented. This status reporting was merged in to the address-oriented status reporting but did not work for link address reporting (as discovered with fwip interfaces). Correct this mis-merge and eliminate the bogus kludge that was used for link-level address reporting.
o add an af_other_status method for an address family for reporting status of things like media, vlan, etc. o call the af_other_status methods after reporting address status for an interface o special-case link address status; when reporting all status for an interface invoke it specially prior to reporting af_other_status methods (since it requires the sockaddr_dl that is passed in to status separately from the rtmsg address state) o correct the calling convention for link address status; don't cast types, construct the proper parameter
This fixes ifconfig on fwip interfaces.
|
#
138593 |
|
08-Dec-2004 |
sam |
Overhaul to cleanup some of the tangled logic that's grown over the years.
o break per-address family support out into separate files o modularize per-address family and functional operations using a registration mechanism; this permits configuration according to which files you include (but beware that order of the files is important to insure backwards compatibility) o many cleanups to eliminate incestuous behaviour, global variables, and poor coding practices (still much more to fix)
The original motivation of this work was to support dynamic addition of functionality based on the interface so we can eliminate the various little control programs and so that vendors can distribute ifconfig plugins that support their in-kernel code. That work is still to be completed.
o Update 802.11 support for all the new net80211 functionality; some of these operations (e.g. list *) may be better suited in a different program
|