| Age | Commit message (Collapse) | Author |
|---|
|
OK kn@, input from claudio@
|
|
|
|
|
|
OK kettenis@
|
|
i replaced the suggested Cm/Ql mix with simple Dq;
|
|
ifconfig(8)'s TRUNK (LINK AGGREGATION) nicely combines the two drivers, so
omit common stuff from the drives specific manuals.
This aids in the overall design of having options documented in ifconfig(8)
alone unless they're inherently driver specific, e.g. "trunkproto" which
stays in trunk(4).
OK jmc
|
|
Some bridge options allow values bigger than the corresponding datatype
and thus pass overflowed values to the kernel, not all options to range
checks and setting invalid "portno" complains about "portidx" values.
Use the same, simpler strtonum() idiom across all options with consistent
error messages and proper [U]INT*_MAX defines as max values to match the
datatype and all option handlers to be consistent (in less code).
Keep deferring option dependent min/max value checking to the ioctl(2)
interface, i.e. values documented in ifconfig(8) are not duplicated in
strtonum() calls.
OK millert
|
|
|
|
Reminded by jmc
|
|
Add missing TPMR section to ifconfig(8) by moving the commands from the
driver's manual to it (copy/paste) and document the ioctl(2) interface in
tpmr(4).
Indenting tpmr's first EXAMPLE while here; from jmc.
OK jmc
|
|
tpmr is a trivial bridge and has no specific ioctls, so to distinguish
it from the rest we must rely on the interface name; assuming that it
is tpmr because neither is_bridge() nor is_switch() return success is
not possible due to the way ifconfig is designed: it runs all *_status()
commands for all interface types.
OK dlg
|
|
This is to reduce duplicate code and prepare for bridge_status() to cover
all bridge like interfaces: bridge(4), switch(4) and tpmr(4).
OK dlg
|
|
bridge_status() and switch_status() do the regular sanity check with
SIOCGIFFLAGS, but both functions also call is_switch() and bridge_status()
also calls is_bridge().
is_bridge() checks SIOCGIFFLAGS again, then both is_*() helpers finally do
driver specific ioctl(2) calls to test whether the given interface is
indeed a bridge(4) or a switch(4).
SIOCGIFFLAGS serves no purpose here and is taken care of in ifconfig.c's
getinfo(), so remove its calls from brconfig.c entirely.
OK dlg
|
|
Complete the synopsis while here.
Feedback OK jmc
|
|
This is the name the other BSDs use for this, there is no reason to
be different, the IPv6 RFCs call these addresses temporary, and some
software in ports wants to use this as well.
Most recently pointed out for firefox by landry.
OK claudio, sthen
|
|
|
|
|
|
|
|
naddy gave me a pointer in the right direction
ok millert@ deraadt@
looks good to matt dunwoodie
|
|
|
|
|
|
note that this links ifconfig with libcrypto to get at base64
encoding and decoding routines. im looking at an alternative way
to do that, so hopefully this is temporary.
secondly, note that all the wireguard stuff is under ifndef SMALL,
so the special build of ifconfig for install media does include
wireguard support, and also does not need libcrypto.
from Matt Dunwoodie and Jason A. Donenfeld
ok deraadt@
|
|
This flag restricts a wireless driver to MCS0 - MCS7 for both transmission
and reception. It can be set to work around packet loss in 11n mode caused
by unused antenna connectors on a MIMO-capable wireless network device.
man page tweak from tracey@
ok deraadt@
|
|
|
|
though that is not what the user intended, e.g. if an invalid hex SSID
was given on the command line.
ok sthen@
|
|
|
|
ok kevlo@
|
|
ok kevlo@
|
|
ok job@ bluhm@ claudio@
job@ tested with 'telnet -6 towel.blinkenlights.nl' on Fibocom L831-EAU on
IIJ MIO's network (Japan), with 'inet6 autoconf' in /etc/hostname.umb0.
|
|
|
|
ok claudio phessler deraadt sthen
|
|
interpreted only prefixlen. Also accept netmask for IPv6. This
is consistent to our man page and the route(8) command.
OK benno@
|
|
|
|
ok jmc deraadt
|
|
Call the global variable with the name of the interface "ifname".
Do not pass it around, just use it globally. Do not use "ifname"
for anything else.
OK deraadt@
|
|
variables used in multiple .c files into common ifconfig.h. Basically
this renames brconfig.h to ifconfig.h and also uses it for sff.c.
Fix missing prototypes. Global variable name s is bad as it shadows
local variables. Call it sock and use it everywhere.
OK deraadt@
|
|
ok mlarkin
|
|
ifconfig display them in 'scan' output and on the ieee80211 status line if
the failure is applicable to an already selected AP (e.g. wrong WPA key).
This will hopefully reduce the amount of help requests for what often
turn out to be trivial misconfiguration issues that were previously
hard to diagnose without debug mode.
ifconfig must be recompiled with the new ieee80211_ioctl.h to stay in
sync with the kernel. A full 'make build' will do the right thing!
Very helpful input by mpi@ and deraadt@
|
|
|
|
found by deraadt@
|
|
|
|
shrinks some QSFP+ DAC output a bit.
|
|
|
|
qsfp and xfp have remarkably similar layouts, so we can use the
same code to print media for both. sfp and xfp/qsfp generally have
the same fields, just in different register locations and with some
different scales/factors for some values. this change provides a
map of these differences as structs for the sfp and qsfp/xfp layouts.
the big difference between sfp, xfp, and qsfp that still remains
is how they interpret the wavelength field. qsfp stores either optic
wavelength in units of 0.05nm, or a couple of copper cable attenuation
values in dB at different frequencies. sfp stores wavelength in nm
units, but has magic values to blacklist copper cables with. xfp
stores wavelength in 0.05 nm units, so more like like qsfp. right
now the code uses the sfp behaviour, which means qsfp will show a
weird wavelength for copper cables when it shouldnt. i'm still
trying to figure out the least worst way to handle that, but at
least it looks right for optics now.
|
|
this shows the maximum case temperature reported by the chip, and
the low and high alarm ranges for temp and vcc when page 3 is
available and working.
this will hopefully give deraadt@ a better idea about how much
headroom one of his 100g optics has.
|
|
this is a bit rough, but a good start. apart from the media types
and length, qsfp support should be on par with sfp modules now.
|
|
i have some qsfp DACs and a couple of optics, and they're all
terrible, so this is about as far as i can go for now. at least the
code will be robust in the face of terrible modules though.
the DACs are pretty dumb and basically report that they're DACs
with some strings. this code just prints that they're DACs with
strings now.
modules are supposed to be able to report overall temperature and
voltage, and optics can report tx and rx values for the 4 different
signal lanes they're supposed to provide. interestingly the current
values are always reported in the lower page, but thresholds are
reported in page 3, but not all modules support page switching.
devices are supposed to say whether they can switch pages, but i
have one that does say it can switch but then doesn't. anyway, the
take away is that it is therefore possible for a module to report
values without also
reporting thresholds.
this sets the code up to report the values on their own if we can't
query page 3 for any reason.
if the temp sensor value looks bogus (ie, 0x0000 or 0xffff), assume
the monitor values are bogus and bail early.
hopefully i can find a module soon that supports multiple signal
lanes and actually reports their values and thresholds for them.
|
|
OK gerhard@
|
|
for IPv6 link local addresses.
Some hosting and VM providers route customer IPv6 prefixes to link
local addresses derived from ethernet MAC addresses (RFC 2464). This
leads to hard to debug IPv6 connectivity problems and is probably not
worth the effort.
RFC 7721 lists 4 weaknesses:
3.1. Correlation of Activities over Time & 3.2. Location Tracking
These are still possible with RFC 7217 addresses for an adversary
connected to the same layer 2 network (think conference wifi). Since
the link local prefix stays the same (fe80::/64) the link local
addresses do not change between different networks.
An adversary on the same layer 2 network can probably track ethernet
MAC addresses via different means, too.
3.3. Address Scanning & 3.4. Device-Specific Vulnerability Exploitation
These now become possible, however, as noted above a layer 2 adversary
was probably able to do this via different means.
People concerned with these weaknesses are advised to use
ifconfig lladdr random.
OK benno
input & OK kn
|
|
to misread.
as per suggestion by and OK deraadt@
|
