Re: multiple routing tables
Thanks, I've solved this issue by creating another bridge on my router (for LAN) - Tor uses another interface on router in rdomain 2. To make troubleshooting easier, I've installed Tor on OpenBSD VM. The problem now is that I can ping my router from the VM and I can ping the VM from the router. But when I ping 8.8.8.8 from the VM, I get no response. route -T 2 exec ping 8.8.8.8 from the router works fine: # route -T 2 exec ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=49 time=40.113 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=49 time=32.074 ms And I've got in rtable 2: 192.168.12/24 192.168.12.1 UC 1 13 - 4 vether2 192.168.12.1 router_MAC UHLl 0 66 - 1 vether2 192.168.12.13 VM_MAC UHLc 0 15 - 4 vether2 192.168.12.255 192.168.12.1 UHb00 - 1 vether2 Relevant pf.conf on router entries: pass in quick on vether2 inet from 192.168.12.13 to any rtable 2 pass out quick on vether2 rtable 2 pass in quick on vether1 from any to any rtable 2 pass out quick on vether1 from any to any rtable 2 Any ideas here? On 05/15/16 12:10, Stefan Sperling wrote: > On Sat, May 14, 2016 at 10:53:49PM +0200, Piotr Kubaj wrote: >> Hi, >> >> I need help with multiple routing tables, because the tutorials on the >> Internet is pretty much scarce. The router is Ubiquiti EdgeRouter Lite >> running OpenBSD 5.9. >> >> >> I've got two public IP's attached by DHCP - since I don't want to use >> multiple physical NIC's, I use two vether interfaces (with different >> MAC's) in bridge with a physical NIC (cnmac0). >> >> Behind the router, I've got a home server with FreeBSD running multiple >> jails. The server itself and all jails but one are to use the vether0 >> NIC on the router with its IP. One jail (running Tor exit node) is to >> use the vether1 NIC with its IP. >> >> >> That's why two routing tables are necessary. >> >> The whole server is in 192.168.11.0/24 class with Tor jail using >> 192.168.11.13 (other services use other IP's). >> All outgoing and incoming traffic from 192.168.11.13 is to use vether1 >> NIC. Other IP's are to use vether0 for all the traffic. >> When I want to add 192.168.11/24 class to rdomain2, I get: >> # route -T 2 add 192.168.11/24 192.168.11.1 >> route: writing to routing socket: Network is unreachable >> add net 192.168.11/24: gateway 192.168.11.1: Network is unreachable > You cannot reach 192.168.11.1 in rdomain 2 because there is no > interface in rdomain 2 which has an address from 192.168.11/24. > > They key point seems to be that you're trying to route between different > rdomains. I believe you must use pf to route traffic coming from this > IP (which is in rdomain 0) to vether1 (which is in rdomain 2) > > See the pf.conf man page and search for 'rdomain' and 'rtable'.
Re: uvideo patches: Overview [0/4]
On Tue, May 17, 2016 at 05:15:51PM -0700, patrick keshishian wrote: > Greetings, > > I have been looking at uvideo trying to model a new driver I'm > attempting to port over and found a few issues (or what I precive > as issues). > > Since the list likes separate diffs for easier discussion, Here > is my attempt to break them up in four emails. I think, with > exception of one, all should apply and compile individually. > > Here are description of patches in decreasing order of my > confidence in proposing them: > > 1/4: Incorrect enum used for v4l2_buf.flags. > This is a paste error I believe. Very simple diff Yeah, obviously a pasto. It's committed. > 2/4: Assumption on endpoint index to use in uvideo_vs_open() vs > actual saved endpoint address. > > 3/4: In uvideo_vs_set_alt(), according to the comment within > while()-loop searches for an endpoint with requested > bandwidth, or best match. An iterator index (int i) is used > in the while()-loop, and eventually its value is used in > usbd_set_interface(). > > Is the "matched" interface's bAlternateSetting not the > correct value to be used? > > 4/4: I don't believe V4L2_BUF_FLAG_QUEUED and V4L2_BUF_FLAG_DONE > flags are handled correctly in our uvideo driver. I need some more time to look at the rest of the diffs in detail.
Re: LTE umsm
So to just remove the ifaceno check, here's the diff.
This matches u3g behaviour for SIERRA TRUINSTALL devices. There is
still a bit of hardcoded stuff that needs to be reviewed in umsm
for other devices. I think yuo@ was trying to match some of these
style checks when he added support for these devices (but it
does not appear to be necessary to isolate based on ifaceno for
u3g)
Index: umsm.c
===
RCS file: /cvs/src/sys/dev/usb/umsm.c,v
retrieving revision 1.104
diff -u -p -u -r1.104 umsm.c
--- umsm.c 29 Sep 2015 08:34:28 - 1.104
+++ umsm.c 20 May 2016 16:37:08 -
@@ -115,6 +115,7 @@ struct umsm_type {
static const struct umsm_type umsm_devs[] = {
{{ USB_VENDOR_AIRPRIME, USB_PRODUCT_AIRPRIME_PC5220 }, 0},
+ {{ USB_VENDOR_AIRPRIME, USB_PRODUCT_AIRPRIME_AIRCARD_313U }, 0},
{{ USB_VENDOR_ANYDATA, USB_PRODUCT_ANYDATA_A2502 }, 0},
{{ USB_VENDOR_ANYDATA, USB_PRODUCT_ANYDATA_ADU_500A }, 0},
@@ -247,6 +248,7 @@ static const struct umsm_type umsm_devs[
{{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_USB305}, 0},
{{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_TRUINSTALL }, DEV_TRUINSTALL},
{{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_MC8355}, 0},
+ {{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_AIRCARD_770S}, 0},
{{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMASS }, DEV_UMASS3},
{{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMASS_2 }, DEV_UMASS3},
@@ -358,8 +360,7 @@ umsm_attach(struct device *parent, struc
umsm_huawei_changemode(uaa->device);
printf("%s: umass only mode. need to reattach\n",
sc->sc_dev.dv_xname);
- } else if ((sc->sc_flag & DEV_TRUINSTALL) &&
- uaa->ifaceno == 0) {
+ } else if (sc->sc_flag & DEV_TRUINSTALL) {
umsm_truinstall_changemode(uaa->device);
printf("%s: truinstall mode. need to reattach\n",
sc->sc_dev.dv_xname);
Re: iic.9
On Fri, May 20, 2016 at 02:20:30AM +0300, Artturi Alm wrote:
> hi,
>
> this was not mentioned even in the relevant headers under /sys/dev/i2c/,
> non-native and all, i guess someone will come up w/better diff if it is
> seen improving anything.
>
> -Artturi
>
i guess the proper fix is to add a RETURN VALUES section. if it's as
trivial as your diff suggests, that would present no problem (i.e.
effort).
jmc
>
> diff --git a/share/man/man9/iic.9 b/share/man/man9/iic.9
> index 7fd3855..e37b160 100644
> --- a/share/man/man9/iic.9
> +++ b/share/man/man9/iic.9
> @@ -143,8 +143,8 @@ struct i2c_attach_args {
> .Ed
> .El
> .Sh FUNCTIONS
> -The following functions comprise the API provided to drivers of
> -I2C-connected devices:
> +The following functions returning zero on success comprise the API
> +provided to drivers of I2C-connected devices:
> .Bl -tag -width iic_exec
> .It Fn iic_acquire_bus "ic" "flags"
> Acquire an exclusive lock on the I2C bus.
>
Re: LTE umsm
Martin Pieuchot [m...@openbsd.org] wrote: > On 19/05/16(Thu) 19:27, Chris Cappuccio wrote: > > Here is a patch to support some newer LTE umsm devices > > > > Yes, the 313U actually has an SD card slot. And yes, it actually > > changes vendor ID to Airprime after the umsm_truinstall_changemode > > takes place. > > > > Matching ifaceno == 9 for newer USB_PRODUCT_SIERRA_TRUINSTALL devices > > is necessary. They don't show up as 0. (It's possible that Huawei will > > will need the same treatment in umsm_attach if they use newer umsm chips) > > No. Hardcoding interface number is not the way to go. Interfaces > descriptors have a class, subclass and protocol that should be looked > at. > > In 3 months a new device will show up with different interfaces layout and > we will have to hardcode something else? > I agree in principle, however in practice, the goal is to run umsm_truinstall_changemode to get the device to present itself in a useful manner. Before umsm_truinstall_changemode, the class is UICLASS_MASS, subclass UISUBCLASS_SCSI, and protocol UIPROTO_MASS_BBB. That's a USB disk. FreeBSD's u3g driver is similar. We could match FreeBSD behavior by simply removing the ifnaceno check. Then we are just matching on USB_PRODUCT_SIERRA_TRUINSTALL and UICLASS_MASS. Chris
Re: [PATCH] socppc.html typo fix
On Fri, May 20, 2016 at 10:46:27AM +0200, Theo Buehler wrote: > > MicroTik to MikroTik typo correction. > > Thanks, committed, but without this: > > > -N1200 and the http://www.microtik.com";>MicroTik > > +N1200 and the http://www.mikrotik.com";>MickoTik Sorry about that. Thanks for catching that. Too late at night to be submitting patches it appears. Bryan
Re: [libcrypto] fix short ASN1 reads
Brent Cook wrote: > Hi, > > Our errata patch for fixing large memory allocations in > asn1_d2i_read_bio dropped the while (want > 0) loop, causing the > function to only read chunk_max bytes once. This limits the max size > read to 16k. This patch restores the outer loop. Noted on misc@ > > ftp http://ccd.serpro.gov.br/lcr/acserprorfbv3.crl > openssl crl -in acserprorfbv3.crl -inform DER > > ok? shit. yes, let's get this fixed and then think about new patches.
Re: libfuse: null-terminate argv (fuse_opt_insert_arg)
On Thu, 19 May 2016 18:57:50 +0200
Hiltjo Posthuma wrote:
> Hi peoples,
>
> This diff makes sure to NUL-terminate argv when parsing options in libfuse.
> The upstream/other libfuse does it this way. This fixes an issue with the
> sysutils/sshfs port, it uses execvp(3) on the fuse_args argv and this gave
> an error "bad address".
>
>
> Index: fuse_opt.c
> ===
> RCS file: /cvs/src/lib/libfuse/fuse_opt.c,v
> retrieving revision 1.15
> diff -u -p -r1.15 fuse_opt.c
> --- fuse_opt.c19 Oct 2015 17:24:07 - 1.15
> +++ fuse_opt.c19 May 2016 16:50:39 -
> @@ -353,7 +353,7 @@ fuse_opt_insert_arg(struct fuse_args *ar
> if (p < 0 || p > args->argc)
> return (-1);
>
> - av = reallocarray(args->argv, args->argc + 1, sizeof(*av));
> + av = reallocarray(args->argv, args->argc + 2, sizeof(*av));
> if (av == NULL)
> return (-1);
>
> @@ -365,6 +365,7 @@ fuse_opt_insert_arg(struct fuse_args *ar
>
> args->argc++;
> args->argv = av;
> + args->argv[args->argc] = NULL;
> for (i = p; i < args->argc; i++) {
> next_arg = args->argv[i];
> args->argv[i] = this_arg;
>
>
> [0] upstream libfuse fuse_opt_add_arg:
> https://github.com/libfuse/libfuse/blob/master/lib/fuse_opt.c#L62
>
This looks correct, but don't forget about free_argv() and alloc_argv().
Ray
New man page: fuse_opt.3
Here's a man page for fuse_opt.h. It's far from perfect, I mostly tried
to document our existing behavior and avoid copying from libfuse. There
are definitely areas of improvement but I think this goes a long way to
helping debug our fuse implementation.
I'm new to fuse, so please, anyone with more fuse knowledge, feel free
to chime in!
Ray
.\" $OpenBSD$
.\"
.\" Copyright (c) Ray Lai
.\"
.\" 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 FUSE_OPT 3
.Os
.Sh NAME
.Nm FUSE_ARGS_INIT ,
.Nm FUSE_OPT_IS_OPT_KEY ,
.Nm FUSE_OPT_KEY ,
.Nm fuse_opt_add_arg ,
.Nm fuse_opt_insert_arg ,
.Nm fuse_opt_free_args ,
.Nm fuse_opt_add_opt ,
.Nm fuse_opt_add_opt_escaped ,
.Nm fuse_opt_match ,
.Nm fuse_opt_parse
.Nd FUSE options parser
.Sh SYNOPSIS
.In fuse_opt.h
.Ft struct fuse_args
.Fn FUSE_ARGS_INIT "int argc" "char argv**"
.Ft int
.Fn FUSE_OPT_IS_OPT_KEY "fuse_opt *t"
.Ft struct fuse_opt
.Fn FUSE_OPT_KEY "const char *templ" "int key"
.Ft int
.Fn fuse_opt_add_arg "struct fuse_args *args" "const char *arg"
.Ft int
.Fn fuse_opt_insert_arg "struct fuse_args *" "int" "const char *"
.Ft void
.Fn fuse_opt_free_args "struct fuse_args *args"
.Ft int
.Fn fuse_opt_add_opt "char **opts" "const char *opt"
.Ft int
.Fn fuse_opt_add_opt_escaped "char **opts" "const char *opt"
.Ft int
.Fn fuse_opt_match "const struct fuse_opt *opts" "const char *opt"
.Ft int
.Fo fuse_opt_parse
.Fa "struct fuse_args *args"
.Fa "void *data"
.Fa "const struct fuse_opt *opts"
.Fa "fuse_opt_proc_t proc"
.Fc
.Sh DESCRIPTION
.Ft struct fuse_args
holds string options in an array:
.Bd -literal -offset indent
struct fuse_args {
int argc; /* argument count */
char **argv;/* NULL-terminated array of arguments */
int allocated; /* allocated by malloc? */
};
.Ed
.Pp
.Fn FUSE_ARGS_INIT
initializes a
.Ft struct fuse_args
with
.Ar argc
and
.Ar argv ,
which can be from
.Fn main .
.Ar argv
is NULL-terminated, and is suitable for use with
.Xr execvp 3 .
.Ar allocated
is set to 0.
.Pp
.Fn fuse_opt_add_arg
adds a single option to the end of
.Ar args .
On
.Ox ,
if
.Ar args->allocated
is 0,
.Ar args->argv
is copied to the heap and
.Ar args->allocated
is set to a non-zero value.
.Pp
.Fn fuse_opt_insert_arg
inserts a single option at position
.Ar p
into
.Ar args ,
shifting
.Ar args->argv
as needed.
(Shifting is currently unimplemented.)
.Pp
.Fn fuse_opt_free_args
frees all allocated memory in
.Ar args
and initializes everything to 0.
.Pp
.Fn fuse_opt_add_opt
adds an option
.Ar opt
to a pointer to an comma-separated string of options
.Ar opts .
.Ar *opts
can be NULL for adding the first option.
.Fn fuse_opt_add_opt_escaped
escapes any
.Sq ","
and
.Sq "\\"
characters in
.Ar opt
before adding it to
.Ar opts .
.Pp
.Fn fuse_opt_match
checks
.Ar opts
for whether
.Ar opt
is set or not.
.Pp
.Fn fuse_opt_parse
parses options.
.Ar opts
is an array of
.Ft struct fuse_opt ,
each which describes actions for each option:
.Bd -literal -offset indent
struct fuse_opt {
const char *templ; /* template for option */
unsigned long off; /* data offset */
int val;/* key value */
};
.Ed
.Pp
.Fn FUSE_OPT_KEY
returns a
.Ft struct fuse_opt
that matches an option
.Ar templ
with option key
.Ar key .
This function is used as an element in
.Ft struct fuse_opt
arrays.
.Fn FUSE_OPT_IS_OPT_KEY
checks if
.Ar t
is an option key.
.Pp
The last element of the
.Ar opts
.Ft struct fuse_opt
option array must be
.Dv FUSE_OPT_END .
.Pp
.Ar proc
points to a function with the following signature:
.Ft int (*fuse_opt_proc_t)
.Fo proc
.Fa "void *data"
.Fa "const char *arg"
.Fa "int key"
.Fa "struct fuse_args *outargs"
.Fc
.Pp
Special key values:
.Bd -literal -offset indent
FUSE_OPT_KEY_OPT/* no match */
FUSE_OPT_KEY_NONOPT /* non-option */
FUSE_OPT_KEY_KEEP /* don't process; return 1 */
FUSE_OPT_KEY_DISCARD/* don't process; return 0 */
.Ed
.Sh RETURN VALUES
.Fn fuse_opt_add_arg ,
.Fn fuse_opt_insert_arg ,
.Fn fuse_opt_add_opt ,
.Fn fuse_opt_add_opt_escaped ,
and
.Fn fuse_opt_parse
return 0 on success, -1 on error.
.Pp
.Fn fuse_opt_match
returns non-zero on match, 0 if no match.
.Sh EXAMPLES
Generate an empty
.Ft struct fuse_args :
.Bd -literal -offset indent
struct fuse_args args = FUSE_ARGS_INIT(0, NULL);
.Ed
.Pp
Initial
Re: [ntpd] Simultaneously listen on IPv4 and IPv6
On Tue, May 17, 2016 at 2:56 PM, Stuart Henderson wrote: > On 2016/05/17 08:27, Brent Cook wrote: > > This patch came by way of the openntpd github. Linux (and possibly > others) > > will attempt to bind to 0.0.0.0 when binding to '::' and return an error > if > > it can't, unless IPV6_V6ONLY is set. > > Do you see why they're doing this? > > In an OS where IPV6_V6ONLY=0 is the default (i.e. allowing v4 on > v6 sockets), someone binds to :: expecting to pick up all traffic. > > Now another user's process binds to 0.0.0.0. > > I honestly don't think a lot of people realize when IPV6_V6ONLY=0 and when it doesn't. It's a surprising default. Maybe it should actually log a more visible warning. My goal is to make OpenNTPD work as closely as possible on other OSes as it does on OpenBSD. Sometimes this means injecting compatibility layers between the system and the program (it shares LibreSSL's arc4random selection code for instance). I'm probably making it too easy on upstream OSes in the interest of OpenNTPD-portable's direct users, but this seems preferable to having different behavior between OpenBSD and other OSes.
Re: usb: cache vendor, product and serial
Wed, 18 May 2016 19:08:29 +0200 Martin Pieuchot
> On 18/05/16(Wed) 18:28, Patrick Wildt wrote:
> > Hi,
> >
> > I had the pleasure of debugging a USB mass storage device that showed
> > interesting behaviour when used with our stack and in combination with
> > the blink(1) usb device.
> >
> > The blink(1)-tool depends on libusb. Libusb calls ioctl(USB_DEVICEINFO)
> > plenty of times to get a map of the USB tree. Per ioctl, three USB
> > requests are created (to read: vendor, product, serial). This kind of
> > floods all connected USB devices.
> >
> > I have a hotplugd script that waits for usb mass storage devices, reads
> > the disklabel, fscks and tries to mount a partition. Due to the ioctl,
> > one of those calls, which mostly only read from the storage device,
> > freeze until they later time out. The flood of read requests caused
> > by the ioctl seem to make the mass storage halt its operation.
> >
> > The same issue can be reproduced by calling usbdevs(8) in a loop. It
> > uses the same ioctl and "breaks" this usb mass storage.
> >
> > An idea is to cache those three strings, so that the ioctl does not
> > create any requests. NetBSD seems to have implemented a caching
> > mechanism to fix a similar issue. Though they have not enabled the
> > caching for that specific ioctl.
>
> They did this caching because their stack call the function multiple
> times during the attachment of a device.
>
> > The idea of this diff, adapted from NetBSD, is that we read out the
> > strings early on when the device is found, store a copy of those per
> > device. Then whenever it's needed it can be used.
> >
> > ok? Comments?
>
> ok mpi@
>
> I'd also like to see if we can always use the cache. Because it is
> unlikely that a vendor or product name will change.
Should not, but in reality.. especially some non-uniform sneaky USB
devices, are programmable and tinker accessible, often with intent.
Even if rare and/or non std usage, USB ID strings are not immutable.
> > diff --git sys/dev/usb/usb.c sys/dev/usb/usb.c
> > index 732ecfd..c198bf0 100644
> > --- sys/dev/usb/usb.c
> > +++ sys/dev/usb/usb.c
> > @@ -520,7 +520,7 @@ usb_fill_di_task(void *arg)
> > if (dev == NULL)
> > return;
> >
> > - usbd_fill_deviceinfo(dev, di, 1);
> > + usbd_fill_deviceinfo(dev, di, 0);
> > }
> >
> > void
> > diff --git sys/dev/usb/usb_subr.c sys/dev/usb/usb_subr.c
> > index a255793..fef6d52 100644
> > --- sys/dev/usb/usb_subr.c
> > +++ sys/dev/usb/usb_subr.c
> > @@ -63,6 +63,7 @@ usbd_status usbd_set_config(struct usbd_device *,
> > int);
> > void usbd_devinfo(struct usbd_device *, int, char *, size_t);
> > void usbd_devinfo_vp(struct usbd_device *, char *, size_t,
> > char *, size_t, int);
> > +void usbd_get_device_string(struct usbd_device *, uByte,
> > char **);
> > char *usbd_get_string(struct usbd_device *, int, char *,
> > size_t);
> > intusbd_getnewaddr(struct usbd_bus *);
> > intusbd_print(void *, const char *);
> > @@ -212,6 +213,28 @@ usbd_trim_spaces(char *p)
> > }
> >
> > void
> > +usbd_get_device_string(struct usbd_device *dev, uByte index, char **buf)
> > +{
> > + char *b = malloc(USB_MAX_STRING_LEN, M_USB, M_NOWAIT);
> > + if (b != NULL) {
> > + usbd_get_string(dev, index, b, USB_MAX_STRING_LEN);
> > + usbd_trim_spaces(b);
> > + }
> > + *buf = b;
> > +}
> > +
> > +void
> > +usbd_get_device_strings(struct usbd_device *dev)
> > +{
> > + usbd_get_device_string(dev, dev->ddesc.iManufacturer,
> > + &dev->vendor);
> > + usbd_get_device_string(dev, dev->ddesc.iProduct,
> > + &dev->product);
> > + usbd_get_device_string(dev, dev->ddesc.iSerialNumber,
> > + &dev->serial);
> > +}
> > +
> > +void
> > usbd_devinfo_vp(struct usbd_device *dev, char *v, size_t vl,
> > char *p, size_t pl, int usedev)
> > {
> > @@ -232,6 +255,11 @@ usbd_devinfo_vp(struct usbd_device *dev, char *v,
> > size_t vl,
> > usbd_trim_spaces(vendor);
> > product = usbd_get_string(dev, udd->iProduct, p, pl);
> > usbd_trim_spaces(product);
> > + } else {
> > + if (dev->vendor != NULL)
> > + vendor = dev->vendor;
> > + if (dev->product != NULL)
> > + product = dev->product;
> > }
> > #ifdef USBVERBOSE
> > if (vendor == NULL || product == NULL) {
> > @@ -294,7 +322,7 @@ usbd_devinfo(struct usbd_device *dev, int showclass,
> > char *base, size_t len)
> > char *cp = base;
> > int bcdDevice, bcdUSB;
> >
> > - usbd_devinfo_vp(dev, vendor, sizeof vendor, product, sizeof product, 1);
> > + usbd_devinfo_vp(dev, vendor, sizeof vendor, product, sizeof product, 0);
> > snprintf(cp, len, "\"%s %s\"", vendor, product);
> > cp += strlen(cp);
> > if (showclass) {
> > @@ -1188,6 +1216,8 @@ usbd_new_device(struct device *parent, str
Re: net80211: support devices which scan all bands
On Fri, May 20, 2016 at 12:08:19PM +0200, Mark Kettenis wrote:
> > Date: Fri, 20 May 2016 11:19:26 +0200
> > From: Stefan Sperling
> >
> > The new iwm(4) firmware (see [1]) scans 2GHz and 5 GHz bands in one go.
> > [1] http://marc.info/?l=openbsd-tech&m=146356530605833&w=2
> >
> > Our net80211 stack isn't set up to handle this correctly.
> > With the new firmware (and diff from [1]), you'll see no scan results
> > at all if you run:
> >
> > ifconfig iwm0 nwid some-nwid-that-doesnt-exist-on-2ghz
> > ifconfig iwm0 scan
> >
> > This happens because the net80211 stack clears scan results from memory
> > before results are returned to ifconfig, and retries on a different band.
> > The driver however insists that it is already done scanning everything,
> > and does nothing (a SCAN->SCAN transition is a no-op in the driver).
> > So the second scan attempt times out, and ifconfig gets no results.
> >
> > This diff adds a 'scan all bands' capability which the driver can advertise
> > to tell the net80211 layer that it should not retry the scan on a different
> > band. Setting this flag in the iwm(4) driver then fixes the issue.
> >
> > (Note that the comment immediately below refers to a 'next mode' instead of
> > 'next band' because it dates from a time when a mode implied a band, as in
> > 11b -> 2GHz and 11a -> 5 GHz. Nowadays, we have 11n mode uses both bands.)
> >
> > ok?
>
> The name feels a bit wrong. Perhaps IEEE80211_C_SINGLESCAN? Anyway,
> doesn't really matter.
Let's bikeshed the flag name later. We can always change it.
There is a more serious problem with my previous diff. It breaks the
background scanning loop which is supposed to run forever if our
desired essid can't be found.
I'm getting better results with the diff below. ifconfig scan works, and
so does the scanning loop because we keep calling ieee80211_next_mode()
and ieee80211_next_scan() to keep the loop running.
It seems my initial impression that ieee80211_next_mode() clears state
which ifconfig reads was wrong.
Index: ieee80211_node.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_node.c,v
retrieving revision 1.102
diff -u -p -r1.102 ieee80211_node.c
--- ieee80211_node.c18 May 2016 08:15:28 - 1.102
+++ ieee80211_node.c20 May 2016 11:32:08 -
@@ -585,14 +585,17 @@ ieee80211_end_scan(struct ifnet *ifp)
* Scan the next mode if nothing has been found. This
* is necessary if the device supports different
* incompatible modes in the same channel range, like
-* like 11b and "pure" 11G mode. This will loop
-* forever except for user-initiated scans.
+* like 11b and "pure" 11G mode.
+* If the device scans all bands in one fell swoop, return
+* current scan results to userspace regardless of mode.
+* This will loop forever except for user-initiated scans.
*/
- if (ieee80211_next_mode(ifp) == IEEE80211_MODE_AUTO) {
+ if (ieee80211_next_mode(ifp) == IEEE80211_MODE_AUTO ||
+ (ic->ic_caps & IEEE80211_C_SCANALLBAND)) {
if (ic->ic_scan_lock & IEEE80211_SCAN_REQUEST &&
ic->ic_scan_lock & IEEE80211_SCAN_RESUME) {
ic->ic_scan_lock = IEEE80211_SCAN_LOCKED;
- /* Return from an user-initiated scan */
+ /* Return from a user-initiated scan. */
wakeup(&ic->ic_scan_lock);
} else if (ic->ic_scan_lock & IEEE80211_SCAN_REQUEST)
goto wakeup;
@@ -652,7 +655,7 @@ ieee80211_end_scan(struct ifnet *ifp)
wakeup:
if (ic->ic_scan_lock & IEEE80211_SCAN_REQUEST) {
- /* Return from an user-initiated scan */
+ /* Return from a user-initiated scan. */
wakeup(&ic->ic_scan_lock);
}
Index: ieee80211_var.h
===
RCS file: /cvs/src/sys/net80211/ieee80211_var.h,v
retrieving revision 1.71
diff -u -p -r1.71 ieee80211_var.h
--- ieee80211_var.h 25 Jan 2016 11:27:11 - 1.71
+++ ieee80211_var.h 20 May 2016 08:56:14 -
@@ -369,6 +369,7 @@ extern struct ieee80211com_head ieee8021
#define IEEE80211_C_RSN0x1000 /* CAPABILITY: RSN
avail */
#define IEEE80211_C_MFP0x2000 /* CAPABILITY: MFP
avail */
#define IEEE80211_C_RAWCTL 0x4000 /* CAPABILITY: raw ctl */
+#define IEEE80211_C_SCANALLBAND0x8000 /* CAPABILITY: scan all
bands */
/* flags for ieee80211_fix_rate() */
#defineIEEE80211_F_DOSORT 0x0001 /* sort rate list */
[libcrypto] fix short ASN1 reads
Hi,
Our errata patch for fixing large memory allocations in
asn1_d2i_read_bio dropped the while (want > 0) loop, causing the
function to only read chunk_max bytes once. This limits the max size
read to 16k. This patch restores the outer loop. Noted on misc@
ftp http://ccd.serpro.gov.br/lcr/acserprorfbv3.crl
openssl crl -in acserprorfbv3.crl -inform DER
ok?
Index: asn1/a_d2i_fp.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/asn1/a_d2i_fp.c,v
retrieving revision 1.14
diff -u -p -u -p -r1.14 a_d2i_fp.c
--- asn1/a_d2i_fp.c 4 May 2016 14:58:09 - 1.14
+++ asn1/a_d2i_fp.c 20 May 2016 11:21:14 -
@@ -236,36 +236,38 @@ asn1_d2i_read_bio(BIO *in, BUF_MEM **pb)
ASN1_R_TOO_LONG);
goto err;
}
- /*
-* Read content in chunks of increasing size
-* so we can return an error for EOF without
-* having to allocate the entire content length
-* in one go.
-*/
- size_t chunk = want > chunk_max ? chunk_max :
want;
+ while (want > 0) {
+ /*
+* Read content in chunks of increasing
size
+* so we can return an error for EOF
without
+* having to allocate the entire
content length
+* in one go.
+*/
+ size_t chunk = want > chunk_max ?
chunk_max : want;
- if (!BUF_MEM_grow_clean(b, len + chunk)) {
- ASN1err(ASN1_F_ASN1_D2I_READ_BIO,
- ERR_R_MALLOC_FAILURE);
- goto err;
- }
- want -= chunk;
- while (chunk > 0) {
- i = BIO_read(in, &(b->data[len]),
chunk);
- if (i <= 0) {
+ if (!BUF_MEM_grow_clean(b, len +
chunk)) {
ASN1err(ASN1_F_ASN1_D2I_READ_BIO,
- ASN1_R_NOT_ENOUGH_DATA);
+ ERR_R_MALLOC_FAILURE);
goto err;
}
- /*
-* This can't overflow because
|len+want|
-* didn't overflow.
-*/
- len += i;
- chunk -= i;
+ want -= chunk;
+ while (chunk > 0) {
+ i = BIO_read(in,
&(b->data[len]), chunk);
+ if (i <= 0) {
+
ASN1err(ASN1_F_ASN1_D2I_READ_BIO,
+
ASN1_R_NOT_ENOUGH_DATA);
+ goto err;
+ }
+ /*
+* This can't overflow because
|len+want|
+* didn't overflow.
+*/
+ len += i;
+ chunk -= i;
+ }
+ if (chunk_max < INT_MAX/2)
+ chunk_max *= 2;
}
- if (chunk_max < INT_MAX/2)
- chunk_max *= 2;
}
if (off + c.slen < off) {
ASN1err(ASN1_F_ASN1_D2I_READ_BIO,
ASN1_R_TOO_LONG);
Re: net80211: support devices which scan all bands
> Date: Fri, 20 May 2016 11:19:26 +0200 > From: Stefan Sperling > > The new iwm(4) firmware (see [1]) scans 2GHz and 5 GHz bands in one go. > [1] http://marc.info/?l=openbsd-tech&m=146356530605833&w=2 > > Our net80211 stack isn't set up to handle this correctly. > With the new firmware (and diff from [1]), you'll see no scan results > at all if you run: > > ifconfig iwm0 nwid some-nwid-that-doesnt-exist-on-2ghz > ifconfig iwm0 scan > > This happens because the net80211 stack clears scan results from memory > before results are returned to ifconfig, and retries on a different band. > The driver however insists that it is already done scanning everything, > and does nothing (a SCAN->SCAN transition is a no-op in the driver). > So the second scan attempt times out, and ifconfig gets no results. > > This diff adds a 'scan all bands' capability which the driver can advertise > to tell the net80211 layer that it should not retry the scan on a different > band. Setting this flag in the iwm(4) driver then fixes the issue. > > (Note that the comment immediately below refers to a 'next mode' instead of > 'next band' because it dates from a time when a mode implied a band, as in > 11b -> 2GHz and 11a -> 5 GHz. Nowadays, we have 11n mode uses both bands.) > > ok? The name feels a bit wrong. Perhaps IEEE80211_C_SINGLESCAN? Anyway, doesn't really matter. ok kettenis@ > Index: ieee80211_node.c > === > RCS file: /cvs/src/sys/net80211/ieee80211_node.c,v > retrieving revision 1.102 > diff -u -p -r1.102 ieee80211_node.c > --- ieee80211_node.c 18 May 2016 08:15:28 - 1.102 > +++ ieee80211_node.c 20 May 2016 09:05:39 - > @@ -581,6 +581,10 @@ ieee80211_end_scan(struct ifnet *ifp) > goto wakeup; > } > #endif > + /* If the device scans all bands at once, we're done. */ > + if (ic->ic_caps & IEEE80211_C_SCANALLBAND) > + goto wakeup; > + > /* >* Scan the next mode if nothing has been found. This >* is necessary if the device supports different > Index: ieee80211_var.h > === > RCS file: /cvs/src/sys/net80211/ieee80211_var.h,v > retrieving revision 1.71 > diff -u -p -r1.71 ieee80211_var.h > --- ieee80211_var.h 25 Jan 2016 11:27:11 - 1.71 > +++ ieee80211_var.h 20 May 2016 08:56:14 - > @@ -369,6 +369,7 @@ extern struct ieee80211com_head ieee8021 > #define IEEE80211_C_RSN 0x1000 /* CAPABILITY: RSN > avail */ > #define IEEE80211_C_MFP 0x2000 /* CAPABILITY: MFP > avail */ > #define IEEE80211_C_RAWCTL 0x4000 /* CAPABILITY: raw ctl */ > +#define IEEE80211_C_SCANALLBAND 0x8000 /* CAPABILITY: scan all > bands */ > > /* flags for ieee80211_fix_rate() */ > #define IEEE80211_F_DOSORT 0x0001 /* sort rate list */ > >
Re: LTE umsm
On 19/05/16(Thu) 19:27, Chris Cappuccio wrote:
> Here is a patch to support some newer LTE umsm devices
>
> Yes, the 313U actually has an SD card slot. And yes, it actually
> changes vendor ID to Airprime after the umsm_truinstall_changemode
> takes place.
>
> Matching ifaceno == 9 for newer USB_PRODUCT_SIERRA_TRUINSTALL devices
> is necessary. They don't show up as 0. (It's possible that Huawei will
> will need the same treatment in umsm_attach if they use newer umsm chips)
No. Hardcoding interface number is not the way to go. Interfaces
descriptors have a class, subclass and protocol that should be looked
at.
In 3 months a new device will show up with different interfaces layout and
we will have to hardcode something else?
>
> umsm0 at uhub5 port 3 configuration 1 interface 9 "Sierra Wireless,
> Incorporated USB MMC Storage" rev 2.00/0.00 addr 5
> umsm0: truinstall mode. need to reattach
> umsm0 detached
> umsm0 at uhub5 port 3 configuration 1 interface 0 "Sierra Wireless,
> Incorporated AirCard 313U" rev 2.00/0.06 addr 5
> ucom1 at umsm0
> umsm1 at uhub5 port 3 configuration 1 interface 1 "Sierra Wireless,
> Incorporated AirCard 313U" rev 2.00/0.06 addr 5
> ucom2 at umsm1
> umsm2 at uhub5 port 3 configuration 1 interface 2 "Sierra Wireless,
> Incorporated AirCard 313U" rev 2.00/0.06 addr 5
> ucom3 at umsm2
> umsm3 at uhub5 port 3 configuration 1 interface 3 "Sierra Wireless,
> Incorporated AirCard 313U" rev 2.00/0.06 addr 5
> ucom4 at umsm3
> umsm4 at uhub5 port 3 configuration 1 interface 4 "Sierra Wireless,
> Incorporated AirCard 313U" rev 2.00/0.06 addr 5
> ucom5 at umsm4
> umass1 at uhub5 port 3 configuration 1 interface 9 "Sierra Wireless,
> Incorporated AirCard 313U" rev 2.00/0.06 addr 5
> umass1: using SCSI over Bulk-Only
> scsibus3 at umass1: 2 targets, initiator 0
> sd5 at scsibus3 targ 1 lun 0: SCSI2 0/direct removable
> serial.0f3d68aa615000291196
> umsm5 at uhub5 port 3 configuration 1 interface 7 "Sierra Wireless,
> Incorporated AirCard 313U" rev 2.00/0.06 addr 5
> ucom6 at umsm5
>
> Aircard 770S:
>
> umsm0 at uhub5 port 3 configuration 1 interface 9 "NETGEAR, Inc. AirCard
> 770S" rev 2.00/0.06 addr 5
> umsm0: truinstall mode. need to reattach
> umsm0 detached
> umsm0 at uhub5 port 3 configuration 1 interface 3 "NETGEAR, Inc. AirCard
> 770S" rev 2.00/0.06 addr 5
> ucom1 at umsm0
> umsm1 at uhub5 port 3 configuration 1 interface 8 "NETGEAR, Inc. AirCard
> 770S" rev 2.00/0.06 addr 5
> ucom2 at umsm1
> umsm2 at uhub5 port 3 configuration 1 interface 0 "NETGEAR, Inc. AirCard
> 770S" rev 2.00/0.06 addr 5
> ucom3 at umsm2
>
> Index: umsm.c
> ===
> RCS file: /cvs/src/sys/dev/usb/umsm.c,v
> retrieving revision 1.104
> diff -u -p -u -r1.104 umsm.c
> --- umsm.c29 Sep 2015 08:34:28 - 1.104
> +++ umsm.c20 May 2016 02:05:54 -
> @@ -115,6 +115,7 @@ struct umsm_type {
>
> static const struct umsm_type umsm_devs[] = {
> {{ USB_VENDOR_AIRPRIME, USB_PRODUCT_AIRPRIME_PC5220 }, 0},
> + {{ USB_VENDOR_AIRPRIME, USB_PRODUCT_AIRPRIME_AIRCARD_313U }, 0},
>
> {{ USB_VENDOR_ANYDATA, USB_PRODUCT_ANYDATA_A2502 }, 0},
> {{ USB_VENDOR_ANYDATA, USB_PRODUCT_ANYDATA_ADU_500A }, 0},
> @@ -247,6 +248,7 @@ static const struct umsm_type umsm_devs[
> {{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_USB305}, 0},
> {{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_TRUINSTALL }, DEV_TRUINSTALL},
> {{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_MC8355}, 0},
> + {{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_AIRCARD_770S}, 0},
>
> {{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMASS }, DEV_UMASS3},
> {{ USB_VENDOR_TCTMOBILE, USB_PRODUCT_TCTMOBILE_UMASS_2 }, DEV_UMASS3},
> @@ -359,7 +361,7 @@ umsm_attach(struct device *parent, struc
> printf("%s: umass only mode. need to reattach\n",
> sc->sc_dev.dv_xname);
> } else if ((sc->sc_flag & DEV_TRUINSTALL) &&
> - uaa->ifaceno == 0) {
> + (uaa->ifaceno == 0 || uaa->ifaceno == 9)) {
> umsm_truinstall_changemode(uaa->device);
> printf("%s: truinstall mode. need to reattach\n",
> sc->sc_dev.dv_xname);
>
net80211: support devices which scan all bands
The new iwm(4) firmware (see [1]) scans 2GHz and 5 GHz bands in one go. [1] http://marc.info/?l=openbsd-tech&m=146356530605833&w=2 Our net80211 stack isn't set up to handle this correctly. With the new firmware (and diff from [1]), you'll see no scan results at all if you run: ifconfig iwm0 nwid some-nwid-that-doesnt-exist-on-2ghz ifconfig iwm0 scan This happens because the net80211 stack clears scan results from memory before results are returned to ifconfig, and retries on a different band. The driver however insists that it is already done scanning everything, and does nothing (a SCAN->SCAN transition is a no-op in the driver). So the second scan attempt times out, and ifconfig gets no results. This diff adds a 'scan all bands' capability which the driver can advertise to tell the net80211 layer that it should not retry the scan on a different band. Setting this flag in the iwm(4) driver then fixes the issue. (Note that the comment immediately below refers to a 'next mode' instead of 'next band' because it dates from a time when a mode implied a band, as in 11b -> 2GHz and 11a -> 5 GHz. Nowadays, we have 11n mode uses both bands.) ok? Index: ieee80211_node.c === RCS file: /cvs/src/sys/net80211/ieee80211_node.c,v retrieving revision 1.102 diff -u -p -r1.102 ieee80211_node.c --- ieee80211_node.c18 May 2016 08:15:28 - 1.102 +++ ieee80211_node.c20 May 2016 09:05:39 - @@ -581,6 +581,10 @@ ieee80211_end_scan(struct ifnet *ifp) goto wakeup; } #endif + /* If the device scans all bands at once, we're done. */ + if (ic->ic_caps & IEEE80211_C_SCANALLBAND) + goto wakeup; + /* * Scan the next mode if nothing has been found. This * is necessary if the device supports different Index: ieee80211_var.h === RCS file: /cvs/src/sys/net80211/ieee80211_var.h,v retrieving revision 1.71 diff -u -p -r1.71 ieee80211_var.h --- ieee80211_var.h 25 Jan 2016 11:27:11 - 1.71 +++ ieee80211_var.h 20 May 2016 08:56:14 - @@ -369,6 +369,7 @@ extern struct ieee80211com_head ieee8021 #define IEEE80211_C_RSN0x1000 /* CAPABILITY: RSN avail */ #define IEEE80211_C_MFP0x2000 /* CAPABILITY: MFP avail */ #define IEEE80211_C_RAWCTL 0x4000 /* CAPABILITY: raw ctl */ +#define IEEE80211_C_SCANALLBAND0x8000 /* CAPABILITY: scan all bands */ /* flags for ieee80211_fix_rate() */ #defineIEEE80211_F_DOSORT 0x0001 /* sort rate list */
Re: [PATCH] socppc.html typo fix
> MicroTik to MikroTik typo correction. > Thanks, committed, but without this: > -N1200 and the http://www.microtik.com";>MicroTik > +N1200 and the http://www.mikrotik.com";>MickoTik ^^
[PATCH] socppc.html typo fix
MicroTik to MikroTik typo correction. Bryan Index: www/socppc.html === RCS file: /cvs/www/socppc.html,v retrieving revision 1.34 diff -u -p -r1.34 socppc.html --- www/socppc.html 29 Mar 2016 14:58:59 - 1.34 +++ www/socppc.html 20 May 2016 07:35:24 - @@ -26,7 +26,7 @@ OpenBSD/socppc runs on machines based on href="http://www.freescale.com";>Freescale MPC8349E System-on-Chip (SoC) platform that use Das U-Boot or RouterBOOT as a boot loader. So far this platform supports the http://www.thecus.com";>Thecus -N1200 and the http://www.microtik.com";>MicroTik +N1200 and the http://www.mikrotik.com";>MickoTik http://www.routerboard.com";>RouterBOARD RB600A.
