| Age | Commit message (Collapse) | Author |
|---|
|
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@
|
|
|
|
|
|
pointed out by claudio@
|
|
ifconfig set/unset it.
ok deraadt@ kmos@
|
|
it's hard to balance being understandable without a legend or a big
manpage, and not using a lot of space.
ok deraadt@
|
|
this is useful for diagnosing mismatches between configurations on
sets of ports (and debugging aggr(4)).
|
|
|
|
value < 0. errno is only updated in this case. Change all (most?)
callers of syscalls to follow this better, and let's see if this strictness
helps us in the future.
|
|
sense on "join" lines;
|
|
in ieee80211com's ic_flags because we haven't been paying attention to
them (they're not in the same place in the code and hence easy to miss).
Move them to a dedicated variable to avoid this problem in the future.
Add a new 'stayauth' nwflag which can be set to let net80211 ignore
deauth frames. This can be useful when deauth frames are being
persistently spoofed by an attacker. Idea from beck@
ok beck@ phessler@
|
|
list of ioctls in bridge(4).
OK ccardenas@ kn@ phessler@
|
|
ok krw@, jsg@
|
|
OK deraadt@
|
|
|
|
this complements txprio and should finish support for RFC 2983
ok claudio@
|
|
|
|
These were deprecated with 6.3, but instead of removing them all together,
keep [-]vlan and [-]vlandev as aliases for [-]vnetid and [-]parent.
Alias idea from sthen
OK dlg sthen benno
|
|
|
|
qsfp was originally defined in SFF-8436, but the management interface
now seems to be managed in SFF-8636, so this uses sff8636 as a
prefix for qsfp things. the same spec applies to qsfp+ and probably
qsfp28.
XFP and QSFP share a bunch of offsets for where strings are located,
so this factors out the printing of those strings from the xfp code
and uses it from both the xfp and qsfp handling.
i have a qsfp+ to 4x sfp+ cable that looks like this with the new
code:
transceiver: QSFP+
model: Amphenol 601110005 rev A
serial: CN0HVVVFxxxxxxx date: 2013-04-18
if i ever get a pair of optics i can work on the diags
|
|
xfp uses a different page layout compared to sfp. xfp uses info in
INF-8077, not SFF-8472, and by default provides the info at page
1, not 0.
myx(4) supports xfp modules, but doesn't support i2c writes so it
cannot change the page the chip is looking at. it appears that myx
defaults to page 1 for xfp, so if the first read of page 0 fails
with ENXIO, try to read page 1 instead.
a 10G-PCIE-8A-R myx with the only xfp module i could find lying
around looks like this:
transceiver: XFP
model: Intel Corp TXN181070850X1J rev B3
serial: USC2048M95 date: 2005-04-13
im not sure if it's worth spending much more time on these though..
|
|
|
|
(like media/joinlist do) rather than totally separate; this also allows
"ifconfig -a sff" or "ifconfig ix sff".
tweak display format to make it look closer to the standard lines.
ok deraadt
|
|
because these are the commonly used terminology
ok claudio sthen
|
|
|
|
problem spotted by Hrvoje, thank you!
ok deraadt
|
|
|
|
in less space. Adds wavelength, printing alarm low/high thresholds, and
prints a flag for warning or alarm indications. "i like it" deraadt@
|
|
|
|
this is very basic, and will get cut up a lot by sthen@ soon, but
it was enough to get us started with. at the moment it shows the
type of module, some vendor and products strings, and detects if
the device supports diag and then shows it. qsfp info is structured
very differently, but i'll let sfp support settle before trying to
make it look the same.
so far only ix(4) and some ixl(4) with up to date firmware implement
the backend ioctl for this. no em(4) yet :(
suggestions from mikeb@
ok deraadt@ sthen@
this was started because of a question from rachel roch
|
|
|
|
only two older cards currently attempt to set this, and it
should not be neccessary anyway;
i've added in a some (commented) info to explain this;
discussed with and ok stsp
|
|
disable this), and provide a little more info on "duration";
some driver-specific notes hopefully to follow...
help/ok stsp
|
|
|
|
|
