add reference to veb(4) in ifconfig.8
For the create command in ifconfig, many pseudo devices are listed but the recent veb(4) is not present in the list. ok? Index: ifconfig.8 === RCS file: /home/reposync/src/sbin/ifconfig/ifconfig.8,v retrieving revision 1.373 diff -u -p -r1.373 ifconfig.8 --- ifconfig.8 17 Apr 2021 06:01:49 - 1.373 +++ ifconfig.8 16 Aug 2021 16:37:45 - @@ -206,6 +206,7 @@ At least the following devices can be cr .Xr tpmr 4 , .Xr trunk 4 , .Xr tun 4 , +.Xr veb 4 , .Xr vether 4 , .Xr vlan 4 , .Xr vxlan 4 ,
Unplugging ure(4) during attach
Hi,
when plugging and unplugging an ure(4) adapter continuously, I came
across the following error with URE_DEBUG set:
ure0 at uhub0 port 21 configuration 1 interface 0 "Realtek USB 10/100/1000
LAN" rev 3.00/30.00 addr 4
ure0: RTL8153 (0x5c10)ure_ctl: error 15
ure_ctl: error 15
ure_ctl: error 15
It waits for a timeout over and over again. The problem is that the
device has been unplugged, but the attach handler still issues USB
requests via ure_ctl(). While there is an early abort check with
usbd_is_dying() in that function, it does not work during attach. The
reason is that the attach handler runs from the USB exploration task.
But that task also handles device detach. So while the hardware port
change event has been noticed, it is up to the USB exploration task to
actually detach (and deactivate) the device. But it is still running
the ure(4) attach handler, which now happily waits for each USB request
to time out. And the ure(4) attach handler has a bunch of loops calling
ure_ctl(), which takes a really long time to complete altogether when
it waits for a timeout for each of them. During that time no other USB
device will get attached/detached either.
The following diff helps with debugging. Plug a ure(4) device and
unplug it within 10 seconds.
--- 8< ---
diff --git a/sys/dev/usb/if_ure.c b/sys/dev/usb/if_ure.c
index ea73db00954..93b76b421b3 100644
--- a/sys/dev/usb/if_ure.c
+++ b/sys/dev/usb/if_ure.c
@@ -1702,6 +1704,8 @@ ure_attach(struct device *parent, struct device *self,
void *aux)
break;
}
+ usbd_delay_ms(sc->ure_udev, 1);
+
if (sc->ure_flags & URE_FLAG_8152)
ure_rtl8152_init(sc);
else if (sc->ure_flags & (URE_FLAG_8153B | URE_FLAG_8156))
--- 8< ---
The problem is that most of the callers of ure_ctl() do not check the
error return code, especially during attach. One solution could be to
propagate the error and handle it during attach. OTOH other USB device
drivers have the same problem. So one might argue that the USB stack is
at fault then. If we wanted to fix it in the USB stack, we would need
to decouple how port change events are handled. Maybe we could get away
with sneaking it into usbd_do_request(). But all of that looks rather
fragile and is well beyond me.
The easiest solution is to deactivate the device proactively in
ure_ctl() when we see that error there. Linux's rtl8152 does something
similar and checks if the device is unplugged [1][2].
[1]
https://elixir.bootlin.com/linux/v5.14-rc5/source/drivers/net/usb/r8152.c#L1249
[2]
https://elixir.bootlin.com/linux/v5.14-rc5/source/drivers/net/usb/r8152.c#L1293
Thanks to kevlo@ for helping me debug this.
So long,
- Christian
---
sys/dev/usb/if_ure.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletions(-)
diff --git a/sys/dev/usb/if_ure.c b/sys/dev/usb/if_ure.c
index ef2bc75a7c0..f5e0039648d 100644
--- a/sys/dev/usb/if_ure.c
+++ b/sys/dev/usb/if_ure.c
@@ -223,7 +223,7 @@ ure_ctl(struct ure_softc *sc, uint8_t rw, uint16_t val,
uint16_t index,
usbd_status err;
if (usbd_is_dying(sc->ure_udev))
- return 0;
+ return -1;
if (rw == URE_CTL_WRITE)
req.bmRequestType = UT_WRITE_VENDOR_DEVICE;
@@ -239,6 +239,8 @@ ure_ctl(struct ure_softc *sc, uint8_t rw, uint16_t val,
uint16_t index,
err = usbd_do_request(sc->ure_udev, , buf);
if (err) {
DPRINTF(("ure_ctl: error %d\n", err));
+ if (err == USBD_CANCELLED || err == USBD_TIMEOUT)
+ usbd_deactivate(sc->ure_udev);
return -1;
}
Re: ucc(4): consumer control keyboard device driver
My microsoft sculpt has a bunch of media keys. I tried mute and increment / decrement. They don't seem to have an effect. --- dmesg.boot Wed Aug 18 19:19:07 2021 +++ dmesg.boot.ucc Wed Aug 18 19:19:16 2021 @@ -1,7 +1,7 @@ -OpenBSD 7.0-beta (GENERIC.MP) #131: Wed Aug 18 10:18:06 CEST 2021 +OpenBSD 7.0-beta (GENERIC.MP) #132: Wed Aug 18 13:41:45 CEST 2021 florian@x1:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8266944512 (7883MB) -avail mem = 8000442368 (7629MB) +avail mem = 8000446464 (7629MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets @@ -122,21 +122,21 @@ uhidev1 at uhub0 port 2 configuration 1 interface 1 "Microsoft Microsoft\M-. 2.4GHz Transceiver v9.0" rev 2.00/7.97 addr 2 uhidev1: iclass 3/1, 26 report ids uhid0 at uhidev1 reportid 18: input=0, output=0, feature=1 -uhid1 at uhidev1 reportid 23: input=0, output=0, feature=1 +ucc0 at uhidev1 reportid 23 hid error 6 ums0 at uhidev1 reportid 26: 5 buttons, Z and W dir wsmouse2 at ums0 mux 0 uhidev2 at uhub0 port 2 configuration 1 interface 2 "Microsoft Microsoft\M-. 2.4GHz Transceiver v9.0" rev 2.00/7.97 addr 2 uhidev2: iclass 3/0, 39 report ids -uhid2 at uhidev2 reportid 3: input=1, output=0, feature=0 -uhid3 at uhidev2 reportid 7: input=7, output=0, feature=0 -uhid4 at uhidev2 reportid 32: input=0, output=0, feature=18 -uhid5 at uhidev2 reportid 33: input=2, output=0, feature=0 -uhid6 at uhidev2 reportid 34: input=0, output=0, feature=26 -uhid7 at uhidev2 reportid 35: input=0, output=0, feature=26 -uhid8 at uhidev2 reportid 36: input=0, output=0, feature=31 -uhid9 at uhidev2 reportid 37: input=0, output=0, feature=31 -uhid10 at uhidev2 reportid 38: input=0, output=0, feature=31 -uhid11 at uhidev2 reportid 39: input=31, output=0, feature=0 +uhid1 at uhidev2 reportid 3: input=1, output=0, feature=0 +ucc1 at uhidev2 reportid 7 keys 1, mappings 0 +uhid2 at uhidev2 reportid 32: input=0, output=0, feature=18 +uhid3 at uhidev2 reportid 33: input=2, output=0, feature=0 +uhid4 at uhidev2 reportid 34: input=0, output=0, feature=26 +uhid5 at uhidev2 reportid 35: input=0, output=0, feature=26 +uhid6 at uhidev2 reportid 36: input=0, output=0, feature=31 +uhid7 at uhidev2 reportid 37: input=0, output=0, feature=31 +uhid8 at uhidev2 reportid 38: input=0, output=0, feature=31 +ucc2 at uhidev2 reportid 39 keys 1, mappings 0 umb0 at uhub0 port 4 configuration 1 interface 0 "Sierra Wireless Inc. Sierra Wireless EM7345 4G LTE" rev 2.00/17.29 addr 3 umodem0 at uhub0 port 4 configuration 1 interface 2 "Sierra Wireless Inc. Sierra Wireless EM7345 4G LTE" rev 2.00/17.29 addr 3 umodem0: data interface 3, has no CM over data, has break @@ -145,12 +145,12 @@ uhub2 at uhub1 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" rev 2.00/0.04 addr 2 uhidev3 at uhub2 port 5 configuration 1 interface 0 "ELAN Touchscreen" rev 2.00/0.12 addr 3 uhidev3: iclass 3/0, 68 report ids -uhid12 at uhidev3 reportid 1: input=115, output=0, feature=0 -uhid13 at uhidev3 reportid 2: input=64, output=0, feature=0 -uhid14 at uhidev3 reportid 3: input=0, output=31, feature=0 -uhid15 at uhidev3 reportid 4: input=19, output=0, feature=0 -uhid16 at uhidev3 reportid 10: input=0, output=0, feature=1 -uhid17 at uhidev3 reportid 68: input=0, output=0, feature=255 +uhid9 at uhidev3 reportid 1: input=115, output=0, feature=0 +uhid10 at uhidev3 reportid 2: input=64, output=0, feature=0 +uhid11 at uhidev3 reportid 3: input=0, output=31, feature=0 +uhid12 at uhidev3 reportid 4: input=19, output=0, feature=0 +uhid13 at uhidev3 reportid 10: input=0, output=0, feature=1 +uhid14 at uhidev3 reportid 68: input=0, output=0, feature=255 uvideo0 at uhub2 port 8 configuration 1 interface 0 "Chicony Electronics Co.,Ltd. Integrated Camera" rev 2.00/25.09 addr 4 video0 at uvideo0 vscsi0 at root dmesg.boot.ucc: OpenBSD 7.0-beta (GENERIC.MP) #132: Wed Aug 18 13:41:45 CEST 2021 florian@x1:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8266944512 (7883MB) avail mem = 8000446464 (7629MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdcd3c000 (57 entries) bios0: vendor LENOVO version "GRET40WW (1.17 )" date 09/02/2014 bios0: LENOVO 20A7006VUS acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC ASF! DBGP ECDT HPET APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT UEFI MSDM BATB FPDT UEFI DMAR acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 1995.71 MHz, 06-45-01 cpu0:
Re: ucc(4): consumer control keyboard device driver
On Wed, 18 Aug 2021, Stuart Henderson wrote: > On 2021/08/18 18:48, Martin Pieuchot wrote: > > Regarding the introduction of a separate wskbd(4) this can be seen as an > > intermediate step. Having this logic in ukbd(4) implies revisiting the > > way reportID are mapped to USB drivers, which is still a bit of a hack > > when it comes to supporting multiple of them. > > Talking of this, paco@ (cc'd) should send the lsusb from his USB-C dock... This is the output of lsusb with the USB-C that sthen is talking about attached. Dmesg also for convenience. https://e1e0.net/paste/lsusb.txt https://e1e0.net/paste/dmesg_p14s.txt For the record, the HDMI output works if an actual monitor is attached and is shown on xrandr as "DisplayPort-1". Display Port is not recognized, nor is the network interface or the audio interface. The USB hub(s) work ok. I can do some tests if you want. Just send patches my way and I can provide the output you need. Cheers, -- Paco Esteban. 0x5818130B8A6DBC03
Re: ucc(4): consumer control keyboard device driver
On Wed, 18 Aug 2021 at 18:48:45 +0200, Martin Pieuchot wrote: > Regarding the introduction of a separate wskbd(4) this can be seen as an > intermediate step. Having this logic in ukbd(4) implies revisiting the > way reportID are mapped to USB drivers, which is still a bit of a hack > when it comes to supporting multiple of them. Having a simpler driver > like ucc(4) can help us figure out out to support more "special" keys > without having to deal with the HID logic at the same time. > > It would be great if users of usbhidaction(1) could tell us if this > introduce any regression and/or if other keys could be supported. I used usbhidaction for a Bluetooth audio device that supported passing button presses through. https://jcs.org/2020/11/18/openbsd_btaudio#responding-to-headphone-buttons $ cat .usbhidaction.conf Consumer:Play/Pause 1 ~/bin/music playpause Due to the lack of an XF86Audio* keysym that is both "play/pause", ucc can only map it to just XF86AudioPlay. It's no big deal for me to adapt though, and I'm happy to see a driver do all of this automatically. Though it would be nice to find a way to pass any unsupported buttons through, even if they are just no-named keysyms that would at least allow a program to bind/react to them.
Re: ucc(4): consumer control keyboard device driver
On 2021/08/18 18:48, Martin Pieuchot wrote: > Regarding the introduction of a separate wskbd(4) this can be seen as an > intermediate step. Having this logic in ukbd(4) implies revisiting the > way reportID are mapped to USB drivers, which is still a bit of a hack > when it comes to supporting multiple of them. Talking of this, paco@ (cc'd) should send the lsusb from his USB-C dock...
Re: ucc(4): consumer control keyboard device driver
On 18/08/21(Wed) 17:50, Mark Kettenis wrote: > > Date: Tue, 17 Aug 2021 20:13:41 +0200 > > From: Anton Lindqvist > > > > Hi, > > > > Here's a new driver for USB HID Consumer Control keyboards. Such > > keyboard is a pseudo device which is used to expose audio and > > application launch keys. My prime motivation is to get the volume mute, > > increment and decrement keys to just work on my keyboard without the > > need to use usbhidaction(1). > > > > ucc(4) attaches a wskbd(4) keyboard "on top" making it appear like an > > ordinary keyboard, which also makes it possible to inject key > > press/release input. It supports both translating and raw mode making it > > compatible with the ordinary console and X11. > > > > My keyboard for instance exposes 42 keys in its input report. I only > > care about the volume and audio related ones and therefore only added > > mappings for those. Additional mappings should be trivial to add if > > desired. > > > > Testing would be much appreciated. > > > > Comments? OK? > > So the downside of this is that you get a separate wskbd(4) device for > these. This will be transparent for most users thanks to wsmux(4), > but it does mean that doing a multi-seat wscons setup becomes a little > bit more involved. That's fine with me as I don't think that's an > important use case for OpenBSD. > > This looks reasonable to me. I agree. I am also very happy to see a kernel driver that makes things work out-of-the-box. Regarding the introduction of a separate wskbd(4) this can be seen as an intermediate step. Having this logic in ukbd(4) implies revisiting the way reportID are mapped to USB drivers, which is still a bit of a hack when it comes to supporting multiple of them. Having a simpler driver like ucc(4) can help us figure out out to support more "special" keys without having to deal with the HID logic at the same time. It would be great if users of usbhidaction(1) could tell us if this introduce any regression and/or if other keys could be supported. I'm definitively ok with this direction. > > diff --git share/man/man4/Makefile share/man/man4/Makefile > > index 6a0ecb20653..63b33660159 100644 > > --- share/man/man4/Makefile > > +++ share/man/man4/Makefile > > @@ -84,7 +84,7 @@ MAN= aac.4 abcrtc.4 abl.4 ac97.4 acphy.4 acrtc.4 \ > > tlphy.4 thmc.4 tpm.4 tpmr.4 tqphy.4 trm.4 trunk.4 tsl.4 tty.4 \ > > tun.4 tap.4 twe.4 \ > > txp.4 txphy.4 uaudio.4 uark.4 uath.4 ubcmtp.4 uberry.4 ubsa.4 \ > > - ubsec.4 ucom.4 uchcom.4 ucrcom.4 ucycom.4 ukspan.4 uslhcom.4 \ > > + ubsec.4 ucc.4 ucom.4 uchcom.4 ucrcom.4 ucycom.4 ukspan.4 uslhcom.4 \ > > udav.4 udcf.4 udl.4 udp.4 udsbr.4 \ > > uftdi.4 ugen.4 ugl.4 ugold.4 uguru.4 uhci.4 uhid.4 uhidev.4 uhidpp.4 \ > > uipaq.4 ujoy.4 uk.4 ukbd.4 \ > > diff --git share/man/man4/ucc.4 share/man/man4/ucc.4 > > new file mode 100644 > > index 000..413c88aa6af > > --- /dev/null > > +++ share/man/man4/ucc.4 > > @@ -0,0 +1,45 @@ > > +.\"$OpenBSD$ > > +.\" > > +.\" Copyright (c) 2021 Anton Lindqvist > > +.\" > > +.\" Permission to use, copy, modify, and distribute this software for any > > +.\" purpose with or without fee is hereby granted, provided that the above > > +.\" copyright notice and this permission notice appear in all copies. > > +.\" > > +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL > > WARRANTIES > > +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > > +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > > +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > > +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > > +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > > +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > > +.\" > > +.Dd $Mdocdate$ > > +.Dt UCC 4 > > +.Os > > +.Sh NAME > > +.Nm ucc > > +.Nd Consumer Control keyboards > > +.Sh SYNOPSIS > > +.Cd "ucc* at uhidev?" > > +.Cd "wsbkd* at ucc? mux 1" > > +.Sh DESCRIPTION > > +The > > +.Nm > > +driver provides support for Consumer Control pseudo keyboards, often used > > to > > +expose audio and application launch keys. > > +.Sh SEE ALSO > > +.Xr intro 4 , > > +.Xr uhidev 4 , > > +.Xr usb 4 , > > +.Xr wskbd 4 > > +.Sh HISTORY > > +The > > +.Nm > > +driver first appeared in > > +.Ox 7.0 . > > +.Sh AUTHORS > > +The > > +.Nm > > +driver was written by > > +.An Anton Lindqvist Aq Mt an...@openbsd.org . > > diff --git share/man/man4/uhidev.4 share/man/man4/uhidev.4 > > index 02252789a3f..d398c564bd5 100644 > > --- share/man/man4/uhidev.4 > > +++ share/man/man4/uhidev.4 > > @@ -37,6 +37,7 @@ > > .Sh SYNOPSIS > > .Cd "uhidev* at uhub?" > > .Cd "fido*at uhidev?" > > +.Cd "ucc* at uhidev?" > > .Cd "ucycom* at uhidev?" > > .Cd "ugold* at uhidev?" > > .Cd "uhid*at uhidev?" > > @@ -72,6 +73,7 @@ only dispatches data to them based on the report id. > > .Sh SEE
Re: ucc(4): consumer control keyboard device driver
> Date: Tue, 17 Aug 2021 20:13:41 +0200 > From: Anton Lindqvist > > Hi, > > Here's a new driver for USB HID Consumer Control keyboards. Such > keyboard is a pseudo device which is used to expose audio and > application launch keys. My prime motivation is to get the volume mute, > increment and decrement keys to just work on my keyboard without the > need to use usbhidaction(1). > > ucc(4) attaches a wskbd(4) keyboard "on top" making it appear like an > ordinary keyboard, which also makes it possible to inject key > press/release input. It supports both translating and raw mode making it > compatible with the ordinary console and X11. > > My keyboard for instance exposes 42 keys in its input report. I only > care about the volume and audio related ones and therefore only added > mappings for those. Additional mappings should be trivial to add if > desired. > > Testing would be much appreciated. > > Comments? OK? So the downside of this is that you get a separate wskbd(4) device for these. This will be transparent for most users thanks to wsmux(4), but it does mean that doing a multi-seat wscons setup becomes a little bit more involved. That's fine with me as I don't think that's an important use case for OpenBSD. This looks reasonable to me. > diff --git share/man/man4/Makefile share/man/man4/Makefile > index 6a0ecb20653..63b33660159 100644 > --- share/man/man4/Makefile > +++ share/man/man4/Makefile > @@ -84,7 +84,7 @@ MAN=aac.4 abcrtc.4 abl.4 ac97.4 acphy.4 acrtc.4 \ > tlphy.4 thmc.4 tpm.4 tpmr.4 tqphy.4 trm.4 trunk.4 tsl.4 tty.4 \ > tun.4 tap.4 twe.4 \ > txp.4 txphy.4 uaudio.4 uark.4 uath.4 ubcmtp.4 uberry.4 ubsa.4 \ > - ubsec.4 ucom.4 uchcom.4 ucrcom.4 ucycom.4 ukspan.4 uslhcom.4 \ > + ubsec.4 ucc.4 ucom.4 uchcom.4 ucrcom.4 ucycom.4 ukspan.4 uslhcom.4 \ > udav.4 udcf.4 udl.4 udp.4 udsbr.4 \ > uftdi.4 ugen.4 ugl.4 ugold.4 uguru.4 uhci.4 uhid.4 uhidev.4 uhidpp.4 \ > uipaq.4 ujoy.4 uk.4 ukbd.4 \ > diff --git share/man/man4/ucc.4 share/man/man4/ucc.4 > new file mode 100644 > index 000..413c88aa6af > --- /dev/null > +++ share/man/man4/ucc.4 > @@ -0,0 +1,45 @@ > +.\" $OpenBSD$ > +.\" > +.\" Copyright (c) 2021 Anton Lindqvist > +.\" > +.\" Permission to use, copy, modify, and distribute this software for any > +.\" purpose with or without fee is hereby granted, provided that the above > +.\" copyright notice and this permission notice appear in all copies. > +.\" > +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > +.\" > +.Dd $Mdocdate$ > +.Dt UCC 4 > +.Os > +.Sh NAME > +.Nm ucc > +.Nd Consumer Control keyboards > +.Sh SYNOPSIS > +.Cd "ucc* at uhidev?" > +.Cd "wsbkd* at ucc? mux 1" > +.Sh DESCRIPTION > +The > +.Nm > +driver provides support for Consumer Control pseudo keyboards, often used to > +expose audio and application launch keys. > +.Sh SEE ALSO > +.Xr intro 4 , > +.Xr uhidev 4 , > +.Xr usb 4 , > +.Xr wskbd 4 > +.Sh HISTORY > +The > +.Nm > +driver first appeared in > +.Ox 7.0 . > +.Sh AUTHORS > +The > +.Nm > +driver was written by > +.An Anton Lindqvist Aq Mt an...@openbsd.org . > diff --git share/man/man4/uhidev.4 share/man/man4/uhidev.4 > index 02252789a3f..d398c564bd5 100644 > --- share/man/man4/uhidev.4 > +++ share/man/man4/uhidev.4 > @@ -37,6 +37,7 @@ > .Sh SYNOPSIS > .Cd "uhidev* at uhub?" > .Cd "fido*at uhidev?" > +.Cd "ucc* at uhidev?" > .Cd "ucycom* at uhidev?" > .Cd "ugold* at uhidev?" > .Cd "uhid*at uhidev?" > @@ -72,6 +73,7 @@ only dispatches data to them based on the report id. > .Sh SEE ALSO > .Xr fido 4 , > .Xr intro 4 , > +.Xr ucc 4 , > .Xr ucycom 4 , > .Xr ugold 4 , > .Xr uhid 4 , > diff --git share/man/man4/usb.4 share/man/man4/usb.4 > index dad3d3a97d9..d159d8b27f3 100644 > --- share/man/man4/usb.4 > +++ share/man/man4/usb.4 > @@ -249,6 +249,8 @@ D-Link DSB-R100 USB radio device > FIDO/U2F security keys > .It Xr ubcmtp 4 > Broadcom trackpad mouse > +.It Xr ucc 4 > +USB Consumer Control keyboards > .It Xr ugold 4 > TEMPer gold HID thermometer and hygrometer > .It Xr uhid 4 > diff --git sys/arch/alpha/conf/GENERIC sys/arch/alpha/conf/GENERIC > index 8af652ce301..54d4a45cd4e 100644 > --- sys/arch/alpha/conf/GENERIC > +++ sys/arch/alpha/conf/GENERIC > @@ -107,6 +107,8 @@ uslhcom* at uhidev? # Silicon Labs > CP2110 USB HID UART > ucom*at uslhcom? > uhid*at uhidev? # USB generic HID support > fido*at uhidev? #
Re: netstart routing domain loopback
On Wed, Aug 18, 2021 at 08:35:16AM -0600, Theo de Raadt wrote:
> If you change the evaluation order in netstart, something similar
> may be needed in the install script emulation of netstart.
If I understand install.sub correctly, this is not necessary.
/etc/netstart creates all pseudo interfaces up front in vifscreate().
For each interface it creates it again in ifstart().
install.sub creates the interface in ifstart().
My change skips lo1, ... in up front creation. This up front
creation does not exist in the installer.
bluhm
> Alexander Bluhm wrote:
>
> > Hi,
> >
> > I want to create an enc1 interface for routing domain 1 and set
> > additional addresses on lo1. So my net config looks like this.
> >
> > ==> /etc/hostname.enc1 <==
> > rdomain 1
> >
> > ==> /etc/hostname.lo1 <==
> > rdomain 1
> > inet alias 10.188.10.74 255.255.255.255
> > ...
> >
> > /etc/netstart creates enc1 in routing domain 0, but does not place
> > it into rdomain 1 due to this error:
> > starting network
> > ifconfig: SIOCSIFRDOMAIN: Invalid argument
> >
> > With some additional debug output netstart does this:
> > { ifconfig enc1 || ifconfig enc1 create; }
> > { ifconfig lo0 || ifconfig lo0 create; }
> > { ifconfig lo1 || ifconfig lo1 create; }
> > { ifconfig enc1 || ifconfig enc1 create; }
> > ifconfig enc1 rdomain 1
> > ...
> > { ifconfig lo1 || ifconfig lo1 create; }
> > ifconfig lo1 rdomain 1
> > ifconfig lo1 inet alias 10.188.10.74 netmask 255.255.255.255
> >
> > ifconfig enc1 rdomain 1 fails as lo1 exists, but is still in routing
> > domain 0.
> >
> > To fix this, I think lo1, lo2, ... should not be created upfront.
> > Also more debug output for /etc/netstart -n is necessary to understand
> > what is going on.
> >
> > ok?
> >
> > bluhm
> >
> > Index: netstart
> > ===
> > RCS file: /data/mirror/openbsd/cvs/src/etc/netstart,v
> > retrieving revision 1.214
> > diff -u -p -r1.214 netstart
> > --- netstart6 Aug 2021 07:06:35 - 1.214
> > +++ netstart18 Aug 2021 14:13:01 -
> > @@ -86,7 +86,11 @@ parse_hn_line() {
> > ifcreate() {
> > local _if=$1
> >
> > - { ifconfig $_if || ifconfig $_if create; } >/dev/null 2>&1
> > + if $PRINT_ONLY; then
> > + print -r -- "{ ifconfig $_if || ifconfig $_if create; }"
> > + else
> > + { ifconfig $_if || ifconfig $_if create; } >/dev/null 2>&1
> > + fi
> > }
> >
> > # Create interfaces for network pseudo-devices referred to by hostname.if
> > files.
> > @@ -99,6 +103,9 @@ vifscreate() {
> > [[ -f $_hn ]] || continue
> > _if=${_hn#/etc/hostname.}
> >
> > + # loopback for routing domain is created by kernel
> > + [[ -n "${_if##lo[1-9]*}" ]] || continue
> > +
> > if ! ifcreate $_if; then
> > print -u2 "${0##*/}: create for '$_if' failed."
> > fi
> > @@ -130,9 +137,7 @@ ifstart() {
> > fi
> >
> > # Check for ifconfig'able interface, except if -n option is specified.
> > - if ! $PRINT_ONLY; then
> > - ifcreate $_if || return
> > - fi
> > + ifcreate $_if || return
> >
> > # Parse the hostname.if(5) file and fill _cmds array with interface
> > # configuration commands.
> > @@ -232,9 +237,6 @@ while getopts ":n" opt; do
> > esac
> > done
> > shift $((OPTIND-1))
> > -
> > -# Option -n is only supported if interface names are specified as
> > parameters.
> > -$PRINT_ONLY && (($# == 0)) && usage
> >
> > # Load key material for the generation of IPv6 Semantically Opaque
> > Interface
> > # Identifiers (SOII) used for link local and SLAAC addresses.
> >
Re: netstart routing domain loopback
If you change the evaluation order in netstart, something similar
may be needed in the install script emulation of netstart.
Alexander Bluhm wrote:
> Hi,
>
> I want to create an enc1 interface for routing domain 1 and set
> additional addresses on lo1. So my net config looks like this.
>
> ==> /etc/hostname.enc1 <==
> rdomain 1
>
> ==> /etc/hostname.lo1 <==
> rdomain 1
> inet alias 10.188.10.74 255.255.255.255
> ...
>
> /etc/netstart creates enc1 in routing domain 0, but does not place
> it into rdomain 1 due to this error:
> starting network
> ifconfig: SIOCSIFRDOMAIN: Invalid argument
>
> With some additional debug output netstart does this:
> { ifconfig enc1 || ifconfig enc1 create; }
> { ifconfig lo0 || ifconfig lo0 create; }
> { ifconfig lo1 || ifconfig lo1 create; }
> { ifconfig enc1 || ifconfig enc1 create; }
> ifconfig enc1 rdomain 1
> ...
> { ifconfig lo1 || ifconfig lo1 create; }
> ifconfig lo1 rdomain 1
> ifconfig lo1 inet alias 10.188.10.74 netmask 255.255.255.255
>
> ifconfig enc1 rdomain 1 fails as lo1 exists, but is still in routing
> domain 0.
>
> To fix this, I think lo1, lo2, ... should not be created upfront.
> Also more debug output for /etc/netstart -n is necessary to understand
> what is going on.
>
> ok?
>
> bluhm
>
> Index: netstart
> ===
> RCS file: /data/mirror/openbsd/cvs/src/etc/netstart,v
> retrieving revision 1.214
> diff -u -p -r1.214 netstart
> --- netstart 6 Aug 2021 07:06:35 - 1.214
> +++ netstart 18 Aug 2021 14:13:01 -
> @@ -86,7 +86,11 @@ parse_hn_line() {
> ifcreate() {
> local _if=$1
>
> - { ifconfig $_if || ifconfig $_if create; } >/dev/null 2>&1
> + if $PRINT_ONLY; then
> + print -r -- "{ ifconfig $_if || ifconfig $_if create; }"
> + else
> + { ifconfig $_if || ifconfig $_if create; } >/dev/null 2>&1
> + fi
> }
>
> # Create interfaces for network pseudo-devices referred to by hostname.if
> files.
> @@ -99,6 +103,9 @@ vifscreate() {
> [[ -f $_hn ]] || continue
> _if=${_hn#/etc/hostname.}
>
> + # loopback for routing domain is created by kernel
> + [[ -n "${_if##lo[1-9]*}" ]] || continue
> +
> if ! ifcreate $_if; then
> print -u2 "${0##*/}: create for '$_if' failed."
> fi
> @@ -130,9 +137,7 @@ ifstart() {
> fi
>
> # Check for ifconfig'able interface, except if -n option is specified.
> - if ! $PRINT_ONLY; then
> - ifcreate $_if || return
> - fi
> + ifcreate $_if || return
>
> # Parse the hostname.if(5) file and fill _cmds array with interface
> # configuration commands.
> @@ -232,9 +237,6 @@ while getopts ":n" opt; do
> esac
> done
> shift $((OPTIND-1))
> -
> -# Option -n is only supported if interface names are specified as parameters.
> -$PRINT_ONLY && (($# == 0)) && usage
>
> # Load key material for the generation of IPv6 Semantically Opaque Interface
> # Identifiers (SOII) used for link local and SLAAC addresses.
>
netstart routing domain loopback
Hi,
I want to create an enc1 interface for routing domain 1 and set
additional addresses on lo1. So my net config looks like this.
==> /etc/hostname.enc1 <==
rdomain 1
==> /etc/hostname.lo1 <==
rdomain 1
inet alias 10.188.10.74 255.255.255.255
...
/etc/netstart creates enc1 in routing domain 0, but does not place
it into rdomain 1 due to this error:
starting network
ifconfig: SIOCSIFRDOMAIN: Invalid argument
With some additional debug output netstart does this:
{ ifconfig enc1 || ifconfig enc1 create; }
{ ifconfig lo0 || ifconfig lo0 create; }
{ ifconfig lo1 || ifconfig lo1 create; }
{ ifconfig enc1 || ifconfig enc1 create; }
ifconfig enc1 rdomain 1
...
{ ifconfig lo1 || ifconfig lo1 create; }
ifconfig lo1 rdomain 1
ifconfig lo1 inet alias 10.188.10.74 netmask 255.255.255.255
ifconfig enc1 rdomain 1 fails as lo1 exists, but is still in routing
domain 0.
To fix this, I think lo1, lo2, ... should not be created upfront.
Also more debug output for /etc/netstart -n is necessary to understand
what is going on.
ok?
bluhm
Index: netstart
===
RCS file: /data/mirror/openbsd/cvs/src/etc/netstart,v
retrieving revision 1.214
diff -u -p -r1.214 netstart
--- netstart6 Aug 2021 07:06:35 - 1.214
+++ netstart18 Aug 2021 14:13:01 -
@@ -86,7 +86,11 @@ parse_hn_line() {
ifcreate() {
local _if=$1
- { ifconfig $_if || ifconfig $_if create; } >/dev/null 2>&1
+ if $PRINT_ONLY; then
+ print -r -- "{ ifconfig $_if || ifconfig $_if create; }"
+ else
+ { ifconfig $_if || ifconfig $_if create; } >/dev/null 2>&1
+ fi
}
# Create interfaces for network pseudo-devices referred to by hostname.if
files.
@@ -99,6 +103,9 @@ vifscreate() {
[[ -f $_hn ]] || continue
_if=${_hn#/etc/hostname.}
+ # loopback for routing domain is created by kernel
+ [[ -n "${_if##lo[1-9]*}" ]] || continue
+
if ! ifcreate $_if; then
print -u2 "${0##*/}: create for '$_if' failed."
fi
@@ -130,9 +137,7 @@ ifstart() {
fi
# Check for ifconfig'able interface, except if -n option is specified.
- if ! $PRINT_ONLY; then
- ifcreate $_if || return
- fi
+ ifcreate $_if || return
# Parse the hostname.if(5) file and fill _cmds array with interface
# configuration commands.
@@ -232,9 +237,6 @@ while getopts ":n" opt; do
esac
done
shift $((OPTIND-1))
-
-# Option -n is only supported if interface names are specified as parameters.
-$PRINT_ONLY && (($# == 0)) && usage
# Load key material for the generation of IPv6 Semantically Opaque Interface
# Identifiers (SOII) used for link local and SLAAC addresses.
Re: bgpd MRT RFC8050 support (add-path for mrt dumps)
On Mon, Aug 09, 2021 at 12:17:47PM +0200, Claudio Jeker wrote:
> This diff adds the bits needed to support add-path in MRT dumps.
> The problem here is that MRT as a stateless protocol has no chance
> to know what kind of encoding (add-path or not) is used for the NLRI in
> message dumps. And for table dumps there is a need to add an extra field
> to the dumps to show the path-id.
>
> There are two issues:
> - for message dumps: it is necessary to peek into UPDATE messages to
> figure out if that update is using add-path or not. This comes from the
> fact that the add-path RFC allows to set the option per AFI/SAFI and
> also per direction. This is a major pain in bgpd since UPDATE messages
> are actually parsed in the RDE and not in the SE. The SE just does the
> basic lenght checks (header size, total length). So this peak into the
> packet needs to be done with some care (especialy for MP encoded
> UPDATEs).
>
> - for table dumps the RFC did a major fobar and defined a extra special
> encoding for non-IPv4/IPv6 prefixes. In the general encoding the path-id
> is not part of the rib entries sub-struct but is instead part of the
> NLRI. This encoding is to complex to build into the bgpd codebase and it
> seems the only other BGP implementation supporting RIB_GENERIC_ADDPATH,
> gobgp, is also not implementing it according to the RFC but instead is
> using the same encoding as for the other _ADDPATH types. OpenBGPD will
> do the same.
>
> This seems to work for me and results in the right output in bgpctl.
>
> Please review mrt_bgp_guess_aid() and check if all checks are correct to
> ensure we don't run off the rails.
Ping
--
:wq Claudio
Index: mrt.c
===
RCS file: /cvs/src/usr.sbin/bgpd/mrt.c,v
retrieving revision 1.104
diff -u -p -r1.104 mrt.c
--- mrt.c 24 Jun 2021 10:04:05 - 1.104
+++ mrt.c 9 Aug 2021 10:13:43 -
@@ -91,23 +91,128 @@ int mrt_open(struct mrt *, time_t);
x == MRT_TABLE_DUMP_V2) ? RDEIDX : SEIDX\
)
-void
-mrt_dump_bgp_msg(struct mrt *mrt, void *pkg, u_int16_t pkglen,
-struct peer *peer)
+static u_int8_t
+mrt_bgp_guess_aid(u_int8_t *pkg, u_int16_t pkglen)
+{
+ u_int16_t wlen, alen, len, afi;
+ u_int8_t type, aid;
+
+ pkg += MSGSIZE_HEADER;
+ pkglen -= MSGSIZE_HEADER;
+
+ if (pkglen < 4)
+ goto bad;
+
+ memcpy(, pkg, 2);
+ wlen = ntohs(wlen);
+ pkg += 2;
+ pkglen -= 2;
+
+ memcpy(, pkg, 2);
+ alen = ntohs(alen);
+ pkg += 2;
+ pkglen -= 2;
+
+ if (wlen > 0 || alen < pkglen || (wlen == 0 && alen == 0)) {
+ /* UPDATE has withdraw or NLRI prefixes or IPv4 EoR */
+ return AID_INET;
+ }
+
+ /* bad attribute length */
+ if (alen > pkglen)
+ goto bad;
+
+ /* try to extract AFI/SAFI from the MP attributes */
+ while (alen > 0) {
+ if (alen < 3)
+ goto bad;
+ type = pkg[1];
+ if (pkg[0] & ATTR_EXTLEN) {
+ if (alen < 4)
+ goto bad;
+ memcpy(, pkg + 2, 2);
+ len = ntohs(len);
+ pkg += 4;
+ alen -= 4;
+ } else {
+ len = pkg[2];
+ pkg += 3;
+ alen -= 3;
+ }
+ if (len > alen)
+ goto bad;
+
+ if (type == ATTR_MP_REACH_NLRI ||
+ type == ATTR_MP_UNREACH_NLRI) {
+ if (alen < 3)
+ goto bad;
+ memcpy(, pkg, 2);
+ afi = ntohs(afi);
+ if (afi2aid(afi, pkg[2], ) == -1)
+ goto bad;
+ return aid;
+ }
+
+ pkg += len;
+ alen -= len;
+ }
+
+bad:
+ return AID_UNSPEC;
+}
+
+static u_int16_t
+mrt_bgp_msg_subtype(struct mrt *mrt, void *pkg, u_int16_t pkglen,
+struct peer *peer, enum msg_type msgtype, int in)
{
- struct ibuf *buf;
- int incoming = 0;
u_int16_tsubtype = BGP4MP_MESSAGE;
+ u_int8_t aid, mask;
if (peer->capa.neg.as4byte)
subtype = BGP4MP_MESSAGE_AS4;
+ if (msgtype != UPDATE)
+ return subtype;
+
+ /*
+* RFC8050 adjust types for add-path enabled sessions.
+* It is necessary to extract the AID from UPDATES to decide
+* if the add-path types are needed or not. The ADDPATH
+* subtypes only matter for BGP UPDATES.
+*/
+
+ mask = in ? CAPA_AP_RECV : CAPA_AP_SEND;
+ /* only guess if add-path could be active */
+ if
iwn/iwm/iwx: hide firmware error dump by default again
Detailed firmware error reports from Intel wifi drivers are quite
noisy so it makes sense to hide them by default, especially on
systems running -release.
When Tx agg support was added to iwn and iwm it was important to
see detailed firmware error reports. These were hidden behind the
IWN_DEBUG/IWM_DEBUG compile-time switch which is inconvenient for
people who don't build their own kernels. Hence detailed reports
are currently enabled by default in -current.
I think we should have a run-time toggle for this so that the
drivers aren't noisy by default but people who want to provide
detailed reports can do so without having to rebuild the kernel.
With this patch the drivers will report "fatal firmware error"
on a single line by default and provide the full trace only if
debugging has been enabled with 'ifconfig iwm0 debug'. Firmware
error traces turned out to be mostly useless without the extra
debugging context anyway.
ok?
diff 8623942bf7ff67cae8f933fb97da088c2c7046a4
0b24590fd0d5395719c4562567e6ab8f7d826463
blob - 00212d2924e3225700ec971e9a3b371cdbe8e034
blob + c52b45ddf739e2e18847f355ca13e79bb12a2a7c
--- sys/dev/pci/if_iwm.c
+++ sys/dev/pci/if_iwm.c
@@ -517,12 +517,10 @@ void iwm_start(struct ifnet *);
void iwm_stop(struct ifnet *);
void iwm_watchdog(struct ifnet *);
intiwm_ioctl(struct ifnet *, u_long, caddr_t);
-#if 1
const char *iwm_desc_lookup(uint32_t);
void iwm_nic_error(struct iwm_softc *);
void iwm_dump_driver_status(struct iwm_softc *);
void iwm_nic_umac_error(struct iwm_softc *);
-#endif
void iwm_rx_mpdu(struct iwm_softc *, struct mbuf *, void *, size_t,
struct mbuf_list *);
void iwm_flip_address(uint8_t *);
@@ -9933,10 +9931,10 @@ iwm_watchdog(struct ifnet *ifp)
if (sc->sc_tx_timer > 0) {
if (--sc->sc_tx_timer == 0) {
printf("%s: device timeout\n", DEVNAME(sc));
-#if 1
- iwm_nic_error(sc);
- iwm_dump_driver_status(sc);
-#endif
+ if (ifp->if_flags & IFF_DEBUG) {
+ iwm_nic_error(sc);
+ iwm_dump_driver_status(sc);
+ }
if ((sc->sc_flags & IWM_FLAG_SHUTDOWN) == 0)
task_add(systq, >init_task);
ifp->if_oerrors++;
@@ -10001,7 +,6 @@ iwm_ioctl(struct ifnet *ifp, u_long cmd, caddr_t data)
return err;
}
-#if 1
/*
* Note: This structure is read from the device with IO accesses,
* and the reading already does the endian conversion. As it is
@@ -10268,7 +10265,6 @@ iwm_dump_driver_status(struct iwm_softc *sc)
printf(" 802.11 state %s\n",
ieee80211_state_name[sc->sc_ic.ic_state]);
}
-#endif
#define SYNC_RESP_STRUCT(_var_, _pkt_) \
do { \
@@ -10701,6 +10697,8 @@ int
iwm_intr(void *arg)
{
struct iwm_softc *sc = arg;
+ struct ieee80211com *ic = >sc_ic;
+ struct ifnet *ifp = IC2IFP(ic);
int handled = 0;
int rv = 0;
uint32_t r1, r2;
@@ -10763,11 +10761,10 @@ iwm_intr(void *arg)
}
if (r1 & IWM_CSR_INT_BIT_SW_ERR) {
-#if 1
- iwm_nic_error(sc);
- iwm_dump_driver_status(sc);
-#endif
-
+ if (ifp->if_flags & IFF_DEBUG) {
+ iwm_nic_error(sc);
+ iwm_dump_driver_status(sc);
+ }
printf("%s: fatal firmware error\n", DEVNAME(sc));
if ((sc->sc_flags & IWM_FLAG_SHUTDOWN) == 0)
task_add(systq, >init_task);
@@ -10836,6 +10833,8 @@ int
iwm_intr_msix(void *arg)
{
struct iwm_softc *sc = arg;
+ struct ieee80211com *ic = >sc_ic;
+ struct ifnet *ifp = IC2IFP(ic);
uint32_t inta_fh, inta_hw;
int vector = 0;
@@ -10860,11 +10859,10 @@ iwm_intr_msix(void *arg)
if ((inta_fh & IWM_MSIX_FH_INT_CAUSES_FH_ERR) ||
(inta_hw & IWM_MSIX_HW_INT_CAUSES_REG_SW_ERR) ||
(inta_hw & IWM_MSIX_HW_INT_CAUSES_REG_SW_ERR_V2)) {
-#if 1
- iwm_nic_error(sc);
- iwm_dump_driver_status(sc);
-#endif
-
+ if (ifp->if_flags & IFF_DEBUG) {
+ iwm_nic_error(sc);
+ iwm_dump_driver_status(sc);
+ }
printf("%s: fatal firmware error\n", DEVNAME(sc));
if ((sc->sc_flags & IWM_FLAG_SHUTDOWN) == 0)
task_add(systq, >init_task);
blob - a5a78bfcf86b73174a5d3c9b01c703d60405dae3
blob + a9b3cd06166fb9573bfb2ff780808230cc205b9b
--- sys/dev/pci/if_iwn.c
+++ sys/dev/pci/if_iwn.c
@@ -904,8 +904,6 @@ iwn_mem_write_2(struct iwn_softc *sc, uint32_t addr, u
iwn_mem_write(sc, addr & ~3, tmp);
}
-#ifdef IWN_DEBUG
-
static __inline void
iwn_mem_read_region_4(struct iwn_softc *sc,
