Re: acme-client(8): preliminary support for HiCA
On Fri, 09 Jun 2023 07:25:04 +0200, Florian Obser wrote: > OK? > > p.s. I'm currently busy writing an ISC licensed bash in rust to safely > support HiCA. So this might take a while... Have you considered implementing wordexp(3) to allow command substitution? It may be necessary to add inline support for IFS to fully support your use case. Also, for full compatibility I think it would be better to choose a User-Agent similar to: Mozilla/5.0 (OpenBSD 7.3; acme-client; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.5112.34 Safari/537.36 obviously you need to substitute in the OpenBSD version and architecture. - todd
Re: acme-client(8): preliminary support for HiCA
Todd C. Miller wrote: > On Fri, 09 Jun 2023 07:25:04 +0200, Florian Obser wrote: > > > OK? > > > > p.s. I'm currently busy writing an ISC licensed bash in rust to safely > > support HiCA. So this might take a while... > > Have you considered implementing wordexp(3) to allow command > substitution? It may be necessary to add inline support for IFS > to fully support your use case. > > Also, for full compatibility I think it would be better to choose > a User-Agent similar to: > > Mozilla/5.0 (OpenBSD 7.3; acme-client; x64) AppleWebKit/537.36 (KHTML, > like Gecko) Chrome/104.0.5112.34 Safari/537.36 > > obviously you need to substitute in the OpenBSD version and architecture. With other change being proposed, it should even be possible and avantageous for HiCA to use SFTP inside their embedded curl sub-operation, including control access using keys in the user's .ssh directory.
Re: vmd issue with network+derived qcow2 on current
Solène Rapenne writes:
> I'm currently playing with derived qcow2 disks using vmd. While my
> setup was working on 7.3 (maybe there is an issue with MAC assignments
> in VMs) so I updated to current, but now VMs don't start at all when
> they are using a derived qcow2 disk + network interface
>
> This setup works: openbsd-template.qcow2 is a regular qcow2 on which I
> installed OpenBSD 7.3 (I tried using current in the VM too)
>
> # 8<
> vm "test" {
> disk /var/openkubsd/templates/openbsd-template.qcow2
> interface locked lladdr 7f:94:fc:e6:2b:25 switch kubes
> }
> switch "kubes" {
> interface bridge0
> }
> # 8<
>
>
> This snippet below won't work, test.qcow2 has been created with:
>
> vmctl create -b /var/openkubsd/templates/openbsd-template.qcow2 \
> /var/openkubsd/derived/test.qcow2
>
> # 8<
> vm "test" {
> disk /var/openkubsd/derived/test.qcow2
> interface locked lladdr 7f:94:fc:e6:2b:25 switch kubes
> # simplifying the interface line doesn't change something
> }
> switch "kubes" {
> interface bridge0
> }
> # 8<
>
> vmd fails with this log in vmd output -vv
>
> # 8<
> config_setvm: vm 1 restarted after 10.638598 seconds, limit 0/3
> vm_opentty: vm test tty /dev/ttyp7 uid 0 gid 4 mode 620
> vm_register: registering vm 1
> vm_priv_ifconfig: interface tap0 description vm1-if0-test
> vm_priv_ifconfig: interface tap0 address 100.64.1.2/31
> test: started vm 1 successfully, tty /dev/ttyp7
> vmm_sighdlr: handling signal 20
> failed to receive vionet: Bad file descriptor
Thanks. This feels like bad fd accounting during the fork/exec dance.
Sounds like the switch definition and usage isn't required for
reproducing?
> vmm_sighdlr: terminated vm test (id 1)
> vm_remove: vmm vmm_sighdlr removing vm 1 from running config
> vm_stop: vmm vmm_sighdlr stopping vm 1
> vm_stop: parent vmd_dispatch_vmm stopping vm 1
> vmd_dispatch_vmm: vm: 1, vm_state: 0x0
> # 8<
>
> However, entirely removing the interface line in vm.conf, like this:
>
> # 8<
> vm "test" {
> disk /var/openkubsd/derived/test.qcow2
> }
> # 8<
>
> allows a successful boot, without network
Re: vmd issue with network+derived qcow2 on current
On Fri, 2023-06-09 at 11:25 -0400, Dave Voutila wrote: > > Thanks. This feels like bad fd accounting during the fork/exec dance. > > Sounds like the switch definition and usage isn't required for > reproducing? indeed, you don't need it, a local interface is enough
ix(4): allocate less memory for tx buffers
Hi,
TSO packets are limited to MAXMCLBYTES (64k). Thus, we don't need to
allocate IXGBE_TSO_SIZE (256k) per packet for the transmit buffers.
This saves 3/4 of the memory and allows me to pack over 8 ix(8) ports
into one machine. Otherwise I run out of devbuf in malloc(9).
ok?
bye,
Jan
Index: dev/pci/if_ix.c
===
RCS file: /cvs/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.197
diff -u -p -r1.197 if_ix.c
--- dev/pci/if_ix.c 1 Jun 2023 09:05:33 - 1.197
+++ dev/pci/if_ix.c 9 Jun 2023 16:01:18 -
@@ -37,6 +37,12 @@
#include
#include
+/*
+ * Our TCP/IP Stack could not handle packets greater then MAXMCLBYTES.
+ * This interface could not handle packets greater then IXGBE_TSO_SIZE.
+ */
+CTASSERT(MAXMCLBYTES < IXGBE_TSO_SIZE);
+
/*
* Driver version
*/
@@ -2263,7 +2269,7 @@ ixgbe_allocate_transmit_buffers(struct t
/* Create the descriptor buffer dma maps */
for (i = 0; i < sc->num_tx_desc; i++) {
txbuf = &txr->tx_buffers[i];
- error = bus_dmamap_create(txr->txdma.dma_tag, IXGBE_TSO_SIZE,
+ error = bus_dmamap_create(txr->txdma.dma_tag, MAXMCLBYTES,
sc->num_segs, PAGE_SIZE, 0,
BUS_DMA_NOWAIT, &txbuf->map);
Re: acme-client(8): preliminary support for HiCA
On Fri, 2023-06-09 at 07:25 +0200, Florian Obser wrote: > > OK? > > p.s. I'm currently busy writing an ISC licensed bash in rust to > safely > support HiCA. So this might take a while... > The HiCA project has been shut down due to some security issues. https://github.com/acmesh-official/acme.sh/issues/4659#issuecomment-1584414218
Re: ix(4): allocate less memory for tx buffers
On Fri, Jun 09, 2023 at 06:11:38PM +0200, Jan Klemkow wrote:
> TSO packets are limited to MAXMCLBYTES (64k). Thus, we don't need to
> allocate IXGBE_TSO_SIZE (256k) per packet for the transmit buffers.
>
> This saves 3/4 of the memory and allows me to pack over 8 ix(8) ports
> into one machine. Otherwise I run out of devbuf in malloc(9).
>
> ok?
fix typo in comment
Index: dev/pci/if_ix.c
===
RCS file: /cvs/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.197
diff -u -p -r1.197 if_ix.c
--- dev/pci/if_ix.c 1 Jun 2023 09:05:33 - 1.197
+++ dev/pci/if_ix.c 9 Jun 2023 16:01:18 -
@@ -37,6 +37,12 @@
#include
#include
+/*
+ * Our TCP/IP Stack could not handle packets greater than MAXMCLBYTES.
+ * This interface could not handle packets greater than IXGBE_TSO_SIZE.
+ */
+CTASSERT(MAXMCLBYTES < IXGBE_TSO_SIZE);
+
/*
* Driver version
*/
@@ -2263,7 +2269,7 @@ ixgbe_allocate_transmit_buffers(struct t
/* Create the descriptor buffer dma maps */
for (i = 0; i < sc->num_tx_desc; i++) {
txbuf = &txr->tx_buffers[i];
- error = bus_dmamap_create(txr->txdma.dma_tag, IXGBE_TSO_SIZE,
+ error = bus_dmamap_create(txr->txdma.dma_tag, MAXMCLBYTES,
sc->num_segs, PAGE_SIZE, 0,
BUS_DMA_NOWAIT, &txbuf->map);
Re: ix(4): allocate less memory for tx buffers
On Fri, Jun 09, 2023 at 06:59:57PM +0200, Jan Klemkow wrote:
> On Fri, Jun 09, 2023 at 06:11:38PM +0200, Jan Klemkow wrote:
> > TSO packets are limited to MAXMCLBYTES (64k). Thus, we don't need to
> > allocate IXGBE_TSO_SIZE (256k) per packet for the transmit buffers.
> >
> > This saves 3/4 of the memory and allows me to pack over 8 ix(8) ports
> > into one machine. Otherwise I run out of devbuf in malloc(9).
>
> fix typo in comment
Use a more precise compare in the CTASSERT condition.
ok?
Index: dev/pci/if_ix.c
===
RCS file: /cvs/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.197
diff -u -p -r1.197 if_ix.c
--- dev/pci/if_ix.c 1 Jun 2023 09:05:33 - 1.197
+++ dev/pci/if_ix.c 9 Jun 2023 16:01:18 -
@@ -37,6 +37,12 @@
#include
#include
+/*
+ * Our TCP/IP Stack could not handle packets greater than MAXMCLBYTES.
+ * This interface could not handle packets greater than IXGBE_TSO_SIZE.
+ */
+CTASSERT(MAXMCLBYTES <= IXGBE_TSO_SIZE);
+
/*
* Driver version
*/
@@ -2263,7 +2269,7 @@ ixgbe_allocate_transmit_buffers(struct t
/* Create the descriptor buffer dma maps */
for (i = 0; i < sc->num_tx_desc; i++) {
txbuf = &txr->tx_buffers[i];
- error = bus_dmamap_create(txr->txdma.dma_tag, IXGBE_TSO_SIZE,
+ error = bus_dmamap_create(txr->txdma.dma_tag, MAXMCLBYTES,
sc->num_segs, PAGE_SIZE, 0,
BUS_DMA_NOWAIT, &txbuf->map);
Diff for evaluation (WACOM tablet)
Good day,
I am currently trying to work on an implementationion
of a driver for the WACOM tablet on openBSD
I am therefore submiting this diff so that it could potentially be evaluated.
Please if you have a moment, could you have a look at this diff?
I have tested it with my Wacom tablet
and it seems to work correctly,
the coding style is normally respected,
but I appologize in advance if my keen eyes have missed out something.
diff --git a/sys/dev/hid/hid.c b/sys/dev/hid/hid.c
index c758764f17a..20c0c501e91 100644
--- a/sys/dev/hid/hid.c
+++ b/sys/dev/hid/hid.c
@@ -657,3 +657,49 @@ hid_is_collection(const void *desc, int size, uint8_t id,
int32_t usage)
hid_end_parse(hd);
return (0);
}
+
+struct hid_data *
+hid_get_collection_data(const void *desc, int size, int32_t usage, uint32_t
collection)
+{
+ struct hid_data *hd;
+ struct hid_item hi;
+
+ hd = hid_start_parse(desc, size, hid_all);
+
+ DPRINTF("%s: usage=0x%x\n", __func__, usage);
+ while (hid_get_item(hd, &hi)) {
+ DPRINTF("%s: kind=%d id=%d usage=0x%x(0x%x)\n", __func__,
+ hi.kind, hi.report_ID, hi.usage, usage);
+ if (hi.kind == hid_collection &&
+ hi.collection == collection && hi.usage == usage){
+ DPRINTF("%s: found\n", __func__);
+ return hd;
+ }
+ }
+ DPRINTF("%s: not found\n", __func__);
+ hid_end_parse(hd);
+ return NULL;
+}
+
+int
+hid_get_id_of_collection(const void *desc, int size, int32_t usage, uint32_t
collection)
+{
+ struct hid_data *hd;
+ struct hid_item hi;
+
+ hd = hid_start_parse(desc, size, hid_all);
+
+ DPRINTF("%s: id=%d usage=0x%x\n", __func__, id, usage);
+ while (hid_get_item(hd, &hi)) {
+ DPRINTF("%s: kind=%d id=%d usage=0x%x(0x%x)\n", __func__,
+ hi.kind, hi.report_ID, hi.usage, usage);
+ if (hi.kind == hid_collection &&
+ hi.collection == collection && hi.usage == usage){
+ DPRINTF("%s: found\n", __func__);
+ return hi.report_ID;
+ }
+ }
+ DPRINTF("%s: not found\n", __func__);
+ hid_end_parse(hd);
+ return 0;
+}
diff --git a/sys/dev/hid/hid.h b/sys/dev/hid/hid.h
index 7400e920bc2..78bc4c403c5 100644
--- a/sys/dev/hid/hid.h
+++ b/sys/dev/hid/hid.h
@@ -93,6 +93,8 @@ int hid_locate(const void *, int, int32_t, uint8_t, enum
hid_kind,
int32_thid_get_data(const uint8_t *buf, int, struct hid_location *);
uint32_t hid_get_udata(const uint8_t *buf, int, struct hid_location *);
int hid_is_collection(const void *, int, uint8_t, int32_t);
+struct hid_data * hid_get_collection_data(const void *, int, int32_t,
uint32_t);
+int hid_get_id_of_collection(const void *desc, int size, int32_t usage,
uint32_t collection);
#endif /* _KERNEL */
@@ -353,6 +355,7 @@ int hid_is_collection(const void *, int, uint8_t, int32_t);
#define HUD_TOUCHSCREEN0x0004
#define HUD_TOUCHPAD 0x0005
#define HUD_CONFIG 0x000e
+#define HUD_STYLUS 0x0020
#define HUD_FINGER 0x0022
#define HUD_TIP_PRESSURE 0x0030
#define HUD_BARREL_PRESSURE 0x0031
@@ -387,6 +390,12 @@ int hid_is_collection(const void *, int, uint8_t,
int32_t);
#define HUD_CONTACT_MAX0x0055
#define HUD_SCAN_TIME0x0056
#define HUD_BUTTON_TYPE0x0059
+#define HUD_SECONDARY_BARREL_SWITCH0x005A
+#define HUD_WACOM_X 0x0130
+#define HUD_WACOM_Y 0x0131
+#define HUD_WACOM_DISTANCE 0x0132
+#define HUD_WACOM_PAD_BUTTONS00 0x0910
+#define HUD_WACOM_BATTERY 0x1013
/* Usages, LED */
#define HUL_NUM_LOCK 0x0001
diff --git a/sys/dev/hid/hidms.c b/sys/dev/hid/hidms.c
index 622d5d9bc33..ec5c8d34d1b 100644
--- a/sys/dev/hid/hidms.c
+++ b/sys/dev/hid/hidms.c
@@ -37,6 +37,7 @@
#include
#include
+#include
#include
#include
#include
@@ -61,6 +62,219 @@ int hidmsdebug = 0;
#define MOUSE_FLAGS_MASK (HIO_CONST | HIO_RELATIVE)
#define NOTMOUSE(f) (((f) & MOUSE_FLAGS_MASK) != HIO_RELATIVE)
+
+int
+stylus_hid_parse(struct hidms *ms, struct hid_data *d, uint32_t *flags) {
+ /* Define stylus reported usages: (maybe macros?) */
+ const uint32_t stylus_usage_tip
+ = HID_USAGE2(HUP_WACOM | HUP_DIGITIZERS, HUD_TIP_SWITCH);
+ const uint32_t stylus_usage_barrel
+ = HID_USAGE2(HUP_WACOM | HUP_DIGITIZERS, HUD_BARREL_SWITCH);
+ const uint32_t stylus_usage_sec_barrel = HID_USAGE2(
+ HUP_WACOM | HUP_DIGITIZERS, HUD_SECONDARY_BARREL_SWITCH);
+ const uint32_t stylus_usage_in_range
+ = HID_USAGE2(HUP_WACOM | HUP_DIGITIZERS, HUD_IN_RANGE);
+ const uint32_t stylus_usage_quality
+ = HID_USAGE2(HUP_WACOM | HUP_DIGITIZERS, HUD_QUALITY);
+ const uint32_t stylus_usage_x
+ = HID_USAGE2(HUP_WACOM | HUP_DIGITIZERS, HUD_WACOM_X);
+ const uint32_t stylus_usage_y
+ = H
