df(1) - variable width columns

Currently df(1) has fixed width columns. With bigger filesystems the output can become unaligned. On a 100GB filesystem that I have the number of free inodes is over 10,000,000, which breaks alignment. On another filesystem that is 3TB in size the number of available 512-blocks is over

tcpdump: show 802.11 control frames

Currently, tcpdump displays 802.11 control frames as "type#4" and doesn't give more information than that. This diff makes tcpdump show the subtype of such frames, and pretty-print a few subtypes in verbose mode. There are more subtypes but these can be pretty-printed later. This can be tested

Re: sunxi: don't use sxitimer on the sun7i/A20

On Wed, Feb 03, 2016 at 12:31:33PM +1100, Jonathan Gray wrote: > You'll want a kernel with the sxidog patch that was committed earlier today. That's right. Thank you. However, stressing it out a little further, sometimes I still get some pmap-related issues. Maybe something related to U-Boot? I

Re: tcpdump: show 802.11 control frames

On Wed, Feb 03, 2016 at 02:05:29PM +0100, Stefan Sperling wrote: > On Wed, Feb 03, 2016 at 01:36:50PM +0100, Mark Kettenis wrote: > > > Date: Wed, 3 Feb 2016 13:27:50 +0100 > > > From: Stefan Sperling > > > > > > Currently, tcpdump displays 802.11 control frames as "type#4" and >

Re: sunxi: don't use sxitimer on the sun7i/A20

On Wed, Feb 03, 2016 at 01:10:57PM -0200, Daniel Bolgheroni wrote: > On Wed, Feb 03, 2016 at 12:31:33PM +1100, Jonathan Gray wrote: > > You'll want a kernel with the sxidog patch that was committed earlier today. > > That's right. Thank you. However, stressing it out a little further, sometimes >

Typo in FAQ example (faq/pf/example1.html)

The FAQ explains how to set up dnscrypt-proxy (from ports) in conjunction with unbound and pf in order to prevent information leakage. The sample pf rule is currently broken, since the "log" and "in" keywords are switched. Index: faq/pf/example1.html

Re: sunxi: don't use sxitimer on the sun7i/A20

On Tue, Feb 02, 2016 at 10:55:57AM +1100, Jonathan Gray wrote: > > Thanks, both diffs committed. Any chance you could create another to > move the sxitimer_* globals into the softc? I left out moving of sxitimer_iot and sxitimer_ioh on purpose, as it would make reviewing this alot worse. Now if

Re: Typo in FAQ example (faq/pf/example1.html)

On 2016/02/03 15:03, Nils Frohberg wrote: > The FAQ explains how to set up dnscrypt-proxy (from ports) in BTW if you are using dnscrypt-proxy please note I have just committed a security fix to ports. (and my objection which tj already knows about still stands ;)

Re: [PATCH] uname, arch/machine -> %c, %a update in PKG_PATH

I suspect that unless there is a solution that doesn't involve lazy new users to memorize more complicated named mirrors, you are going to run into this problem over and over again. >> Raf Czlonka wrote: >> - ftp.openbsd.org is, AFAIC, overloaded > I haven't been following this thread fully,

Re: [PATCH] uname, arch/machine -> %c, %a update in PKG_PATH

On 2016/02/03 20:48, Luke Small wrote: > I suspect that unless there is a solution that doesn't involve lazy new > users to memorize more complicated named mirrors, you are going to run into > this problem over and over again. Why would they need to memorize them? In most cases the one they

Make iwn(4) pass control frames in monitor mode

This allows tcpdump to see all control frames with iwn(4). Index: if_iwn.c === RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v retrieving revision 1.158 diff -u -p -r1.158 if_iwn.c --- if_iwn.c25 Jan 2016 11:27:11 - 1.158 +++

Re: Make iwn(4) pass control frames in monitor mode

> Date: Wed, 3 Feb 2016 17:03:46 +0100 > From: Stefan Sperling > > This allows tcpdump to see all control frames with iwn(4). Hmm, the code below that does look inside the frame. How do we guarantee it isn't looking at garbage or reading beyond the end of the buffer? > Index:

Re: [PATCH] uname, arch/machine -> %c, %a update in PKG_PATH

I didn't know about the miniroot program that edited installpath until I had a network-assisted upgrade. Every time before, I just did it from disk. I edited PKG_PATH to do that, from what I recall, I used a text editor and to do that, I had to memorize the installpath to manually copy it in the

Re: [PATCH] uname, arch/machine -> %c, %a update in PKG_PATH

Stuart Henderson wrote: > > >> Raf Czlonka wrote: > > >> - ftp.openbsd.org is, AFAIC, overloaded > > Whenever I've checked speeds from ftp.openbsd.org they have been > fairly consistent, this isn't the usual expected behaviour of an > overloaded machine. (not super fast, but they have been

Re: tcpdump: show 802.11 control frames

> Date: Wed, 3 Feb 2016 13:27:50 +0100 > From: Stefan Sperling > > Currently, tcpdump displays 802.11 control frames as "type#4" and > doesn't give more information than that. > > This diff makes tcpdump show the subtype of such frames, and pretty-print > a few subtypes in

Re: tcpdump: show 802.11 control frames

On Wed, Feb 03, 2016 at 01:36:50PM +0100, Mark Kettenis wrote: > > Date: Wed, 3 Feb 2016 13:27:50 +0100 > > From: Stefan Sperling > > > > Currently, tcpdump displays 802.11 control frames as "type#4" and > > doesn't give more information than that. > > > > This diff makes

Re: Signed overflow in ufs i_modrev calculation

Mike Belopuhov wrote: > Any OKs or objections to this diff? This looks solid to me, FWIW. Looks good to me as well. ok stefan@ > On Wed, Jan 27, 2016 at 09:52 +0100, Martin Natano wrote: > > In ufs, the calculation of i_modrev can produce signed overflow on 32 > > bit architectures (found on

tcpdump: fix infinite loop

Fix an infinite loop when printing a country element in a management frame in case we hit channel Tx power limits we can't pretty-print. Also ensure we consume the last item in this list. Index: print-802_11.c === RCS file:

Re: Signed overflow in ufs i_modrev calculation

Any OKs or objections to this diff? This looks solid to me, FWIW. On Wed, Jan 27, 2016 at 09:52 +0100, Martin Natano wrote: > In ufs, the calculation of i_modrev can produce signed overflow on 32 > bit architectures (found on i386). The tv.tv_usec * 4294 calculation is > designed to move the

fix A-MPDU params for iwn/iwm (fixes apple airport AP)

Both drivers forgot to configure some A-MPDU parameters into the firmware and announced the wrong A-MPDU max size in assoc responses. Also announce that we don't support SMPS (signalled in htcaps by a value of 3 rather than zero...) ok? Index: if_iwm.c

Re: tmpfs uiomove() conversion

Martin Natano wrote: > Stefan Kempf wrote: > > I'm a bit uneasy though with passing signed values as-is to uiomove(). > > Can we somehow make it explicit that we know that the uiomove() argument is > > >= 0? > > > > Changing types all over the place would be too much churn though. > > > > I'm

Re: ntfs uiomove() conversion

Martin Natano wrote: > On Tue, Feb 02, 2016 at 07:30:08PM +0100, Stefan Kempf wrote: > > Looks good. I agree with changing left to size_t. One small remark > > though: size_t is defined as unsigned long. Do the DPRINTFs that print > > the value of left have to be changed to use %zu in the format