route monitor & RTM_IFINFO mtu

[Jeremie Courreges-Anglas]

Since setting the MTU of an interface now sends an RTM_IFINFO message,
it would make sense to also print the new interface MTU in monitor mode.

ok?


Index: route.c
===
RCS file: /d/cvs/src/sbin/route/route.c,v
retrieving revision 1.193
diff -u -p -p -u -r1.193 route.c
--- route.c 13 Dec 2016 08:40:54 -  1.193
+++ route.c 20 Dec 2016 14:57:43 -
@@ -1318,9 +1318,10 @@ print_rtmsg(struct rt_msghdr *rtm, int m
(void) printf(", if# %d, ", ifm->ifm_index);
if (if_indextoname(ifm->ifm_index, ifname) != NULL)
printf("name: %s, ", ifname);
-   printf("link: %s, flags:",
+   printf("link: %s, mtu: %u, flags:",
get_linkstate(ifm->ifm_data.ifi_type,
-   ifm->ifm_data.ifi_link_state));
+   ifm->ifm_data.ifi_link_state),
+   ifm->ifm_data.ifi_mtu);
bprintf(stdout, ifm->ifm_flags, ifnetflags);
pmsg_addrs((char *)ifm + ifm->ifm_hdrlen, ifm->ifm_addrs);
break;

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

missing malloc() return check in athn(4)

[Stefan Sperling]

I added this bug recently...

Index: athn.c
===
RCS file: /cvs/src/sys/dev/ic/athn.c,v
retrieving revision 1.95
diff -u -p -r1.95 athn.c
--- athn.c  12 Jan 2017 18:06:57 -  1.95
+++ athn.c  17 Jan 2017 19:33:31 -
@@ -2337,7 +2337,7 @@ athn_node_alloc(struct ieee80211com *ic)
struct athn_node *an;
 
an = malloc(sizeof(struct athn_node), M_DEVBUF, M_NOWAIT | M_ZERO);
-   if (ic->ic_flags & IEEE80211_F_HTON)
+   if (an && (ic->ic_flags & IEEE80211_F_HTON))
ieee80211_mira_node_init(>mn);
return (struct ieee80211_node *)an;
 }

net80211: enable tkip with 'ifconfig wpaprotos wpa1,wpa2'

[Stefan Sperling]

The recommended way to enable WPA1/TKIP support is:
  ifconfig iwm0 wpaprotos wpa1,wpa2

pirofti@ noticed that 'ifconfig iwm0 wpaprotos wpa1,wpa2' is not enough
to connect to a WPA1-only AP. A list of pairwise ciphers must also be
provided: "ifconfig iwm0 wpaciphers tkip,ccmp"

Because I forgot to enable pairwise TKIP if WPA1 is enabled and no
specific ciphers are provided. Fix below.

ok?

Index: ieee80211_ioctl.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_ioctl.c,v
retrieving revision 1.47
diff -u -p -r1.47 ieee80211_ioctl.c
--- ieee80211_ioctl.c   31 Dec 2016 17:51:44 -  1.47
+++ ieee80211_ioctl.c   17 Jan 2017 19:56:15 -
@@ -305,8 +305,11 @@ ieee80211_ioctl_setwpaparms(struct ieee8
ic->ic_rsnciphers |= IEEE80211_CIPHER_CCMP;
if (wpa->i_ciphers & IEEE80211_WPA_CIPHER_USEGROUP)
ic->ic_rsnciphers = IEEE80211_CIPHER_USEGROUP;
-   if (ic->ic_rsnciphers == 0) /* set to default (CCMP) */
+   if (ic->ic_rsnciphers == 0) { /* set to default (CCMP, TKIP if WPA1) */
ic->ic_rsnciphers = IEEE80211_CIPHER_CCMP;
+   if (ic->ic_rsnprotos & IEEE80211_PROTO_WPA)
+   ic->ic_rsnciphers |= IEEE80211_CIPHER_TKIP;
+   }
 
ic->ic_flags |= IEEE80211_F_RSNON;
 

iwm: fix a timeout race

[Stefan Sperling]

I managed to trigger the following uvm fault by continously switching an
iwm(4) client between two APs on different channels, i.e. a loop that runs:
ifconfig iwm0 chan X; sleep 10; ifconfig iwm chan Y; sleep 10;

 uvm_fault(0x819614a0, 0x7, 0, 2) -> e
 kernel: page fault trap, code=0
 Stopped atsoftclock+0x32: movq %rdx,0x8(%rax)

This diff seems to fix the problem. It cancels mira timeouts from
interrupt context where a state change is scheduled, instead of
cancelling mira timeouts from the process context which performs
the actual state change.

Also, cancel mira timeouts when the interface is brought down in
iwm_stop() because this code path does not go through iwm_newstate().

ok?

Note that unless we are in RUN state the timeouts have not been initialized
so timeout_del() inside mira_cancel_timeouts() would panic if we called it.
This can't be done in a different way since mira state can only be
initialized once the node for our AP (ic->ic_bss) is available.

Index: if_iwm.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
retrieving revision 1.156
diff -u -p -r1.156 if_iwm.c
--- if_iwm.c12 Jan 2017 18:06:57 -  1.156
+++ if_iwm.c17 Jan 2017 18:59:20 -
@@ -5496,10 +5496,8 @@ iwm_newstate_task(void *psc)
if (ostate == IEEE80211_S_SCAN && nstate != ostate)
iwm_led_blink_stop(sc);
 
-   if (ostate == IEEE80211_S_RUN && nstate != ostate) {
+   if (ostate == IEEE80211_S_RUN && nstate != ostate)
iwm_disable_beacon_filter(sc);
-   ieee80211_mira_cancel_timeouts(>in_mn);
-   }
 
/* Reset the device if moving out of AUTH, ASSOC, or RUN. */
/* XXX Is there a way to switch states without a full reset? */
@@ -5632,8 +5630,11 @@ iwm_newstate(struct ieee80211com *ic, en
 {
struct ifnet *ifp = IC2IFP(ic);
struct iwm_softc *sc = ifp->if_softc;
+   struct iwm_node *in = (void *)ic->ic_bss;
 
timeout_del(>sc_calib_to);
+   if (ic->ic_state == IEEE80211_S_RUN)
+   ieee80211_mira_cancel_timeouts(>in_mn);
 
sc->ns_nstate = nstate;
sc->ns_arg = arg;
@@ -6116,6 +6117,8 @@ iwm_stop(struct ifnet *ifp, int disable)
ifq_clr_oactive(>if_snd);
 
in->in_phyctxt = NULL;
+   if (ic->ic_state == IEEE80211_S_RUN)
+   ieee80211_mira_cancel_timeouts(>in_mn);
 
task_del(systq, >init_task);
task_del(sc->sc_nswq, >newstate_task);

Document the RI_CLEARMARGINS flag in rasops.9

[Frederic Cambus]

Hi tech@,

The RI_CLEARMARGINS flag is used on sparc64 but isn't documented in the
rasops man page.

Comments? OK?

Index: share/man/man9/rasops.9
===
RCS file: /cvs/src/share/man/man9/rasops.9,v
retrieving revision 1.16
diff -u -p -r1.16 rasops.9
--- share/man/man9/rasops.9 7 Sep 2015 18:43:54 -   1.16
+++ share/man/man9/rasops.9 17 Jan 2017 22:28:09 -
@@ -130,7 +130,7 @@ The value of the
 .Em ri_flg
 member is formed by OR'ing the following values:
 .Pp
-.Bl -tag -offset indent -width RI_CURSORCLIP -compact
+.Bl -tag -offset indent -width RI_CLEARMARGINS -compact
 .It RI_FULLCLEAR
 Force eraserows() to clear the whole screen instead of only text lines,
 when invoked with an
@@ -144,6 +144,8 @@ Specifies that the frame buffer endianne
 Set when the text cursor is enabled.
 .It RI_CLEAR
 Clear the display upon initialization.
+.It RI_CLEARMARGINS
+Clear display margins upon initialization.
 .It RI_CENTER
 Center the text area.
 .\" Only honoured if option RASOPS_CLIPPING which we don't use.

Re: xenocara fontconfig: make slight hinting the default

[Nils Reuße]

> Matthieu Herrb  hat am 16. Januar 2017 um 23:42 
> geschrieben:
> 
> 
> On Sun, Jan 15, 2017 at 10:37:20AM +0100, Nils Reuße wrote:
> > On 01/04/2017 01:19 PM, Nils Reuße wrote:
> > > Dear all,
> > > 
> > > fontconfig made slight hinting the default in version 2.11.95 (see commit 
> > > at [1]).
> > > 
> > > xenocara currently ships, but does not install the new hinting conf files:
> > > 
> > >   $ cd /usr/xenocara/dist/fontconfig/conf.d/
> > >   $ for file in *conf; do if ! test -f /etc/fonts/conf.avail/$file; then 
> > > echo "$file not found"; fi; done
> > >   10-hinting-full.conf not found
> > >   10-hinting-medium.conf not found
> > >   10-hinting-none.conf not found
> > >   10-hinting-slight.conf not found
> > > 
> > > The patch below installs the missing files and makes slight hinting the 
> > > default.
> > > 
> > > Any comments?
> 
> Hmm right, I forgot to add the new files.
> I'm committing the diff that installs them to conf.avail.
> I'll wait a bit until more people have tried the new default 'slight'
> anti-aliasing do decide if OpenBSD wants this as a default or not.
> 
> Most developpers are quite conservative and don't like the
> anti-aliased fonts...
> 

Hi Matthieu,

thanks for looking into it.  FWIW, the meaning of slight hinting changed as 
well [1]:

  In the past, setting ‘slight’ hinting via FontConfig or configuration GUIs 
meant that native hints within a font were ignored; FreeType’s auto-hinter 
would analyze the font on the fly and automatically do what the font designer 
would have to do at least semi-manually.
  [..]
  Setting ‘slight’ hinting usually leads to FT_LOAD_TARGET_LIGHT. This mode 
implied the auto-hinter before and has now been changed to mean “Use native 
vertical-grid-only-snapping if driver and font supports it and 
vertical-grid-only auto-hinter otherwise”. Right now, only the OpenType/CFF 
driver is supported. In the future, this will hopefully include the TrueType 
engine once full support for ClearType arrives.

(ClearType is available since 2.7)


Bitmap fonts are unaffected, of course.

[1] https://www.freetype.org/freetype2/docs/text-rendering-general.html

> > > 
> > > Kind regards
> > > Nils
> > > 
> > > [1] 
> > > https://cgit.freedesktop.org/fontconfig/commit/?id=98434b3392172233094cac25ade7225c93da9f1c
> > > 
> > > 
> > > Index: distrib/sets/lists/xetc/mi
> > > ===
> > > RCS file: /cvs/xenocara/distrib/sets/lists/xetc/mi,v
> > > retrieving revision 1.31
> > > diff -u -p -u -r1.31 mi
> > > --- distrib/sets/lists/xetc/mi  28 Oct 2015 00:46:31 -  1.31
> > > +++ distrib/sets/lists/xetc/mi  4 Jan 2017 11:21:03 -
> > > @@ -12,6 +12,7 @@
> > >  ./etc/X11/xdm/xdm-config
> > >  ./etc/X11/xinit/xinitrc
> > >  ./etc/X11/xsm/system.xsm
> > > +./etc/fonts/conf.d/10-hinting-slight.conf
> > >  ./etc/fonts/conf.d/10-scale-bitmap-fonts.conf
> > >  ./etc/fonts/conf.d/20-unhint-small-dejavu-sans-mono.conf
> > >  ./etc/fonts/conf.d/20-unhint-small-dejavu-sans.conf
> > > Index: lib/fontconfig/conf.d/Makefile
> > > ===
> > > RCS file: /cvs/xenocara/lib/fontconfig/conf.d/Makefile,v
> > > retrieving revision 1.10
> > > diff -u -p -u -r1.10 Makefile
> > > --- lib/fontconfig/conf.d/Makefile  19 Nov 2016 08:45:51 -  1.10
> > > +++ lib/fontconfig/conf.d/Makefile  4 Jan 2017 11:21:03 -
> > > @@ -9,6 +9,7 @@ DOC_FILES= \
> > > README
> > > 
> > >  CONF_LINKS = \
> > > +   10-hinting-slight.conf \
> > > 10-scale-bitmap-fonts.conf \
> > > 20-unhint-small-vera.conf \
> > > 30-lucida-aliases.conf \
> > > @@ -29,6 +30,10 @@ CONF_LINKS = \
> > > 
> > >  AVAIL_FILES =  \
> > > 10-autohint.conf\
> > > +   10-hinting-full.conf\
> > > +   10-hinting-medium.conf  \
> > > +   10-hinting-none.conf\
> > > +   10-hinting-slight.conf  \
> > > 10-no-sub-pixel.conf\
> > > 10-scale-bitmap-fonts.conf  \
> > > 10-sub-pixel-bgr.conf   \
> > > 
> > 
> > Any comment?
> 
> -- 
> Matthieu Herrb

Re: 11n support for athn(4)

[Stefan Sperling]

On Tue, Jan 17, 2017 at 10:19:39AM +, Peter Kay wrote:
> From: s...@stsp.name
> Sent: 17 January 2017 10:00 a.m.
> To: syllops...@syllopsium.co.uk
> Cc: tech@openbsd.org
> Subject: Re: 11n support for athn(4)
> 
> On Mon, Jan 16, 2017 at 11:58:51PM +, Peter Kay wrote:
> >> 
> >> Three, yes, but note that unless the antennas have been unreasonably
> >> disturbed during the snapshot upgrade nothing has changed. Also, it
> >> takes a day or so for the access point to start failing, so I'm
> >> suspecting a software issue.
> 
> >Fair enough. But I can't see anything in your reports >that would guide me
> >where to look for bugs in the code. Let me know if >you find out more.
> 
> What diagnostics are available to narrow down the cause of this issue?

The best you could give me is a way to reproduce your problem independently
in my own environment. Right now, I cannot reproduce it. My athn APs (and
those of several other people) seem to be working just fine.

Without more details, all I can do is guess.
I made one guess already (antennas) and sadly I guessed wrong.

If you are unable to narrow down the problem without a lot of handholding,
please ask an expert you know for additional help, or just use 11g mode.
I don't have enough time right now to guide you through all the details.

If there is a real problem, someone else will eventually also run into it.
Then we might learn more.

Re: 11n support for athn(4)

[Stefan Sperling]

On Tue, Jan 17, 2017 at 11:56:09AM +0100, Stefan Sperling wrote:
> Without more details, all I can do is guess.
> I made one guess already (antennas) and sadly I guessed wrong.

Another thing where your setup differs from mine is that you are
using a device with 3 antennas, whereas my devices only have 2.

I have already ordered a 3 antenna device two days ago so I should
have one to test with soon. Perhaps I will see a problem then.

Is anyone else reading this list using a 3 antenna device?
Please let us know whether it works.

Re: 11n support for athn(4)

[Peter Kay]

  Original Message  
From: s...@stsp.name
Sent: 17 January 2017 12:25 p.m.
To: syllops...@syllopsium.co.uk; tech@openbsd.org
Subject: Re: 11n support for athn(4)

On Tue, Jan 17, 2017 at 11:56:09AM +0100, Stefan Sperling wrote:
>> Without more details, all I can do is guess.
>> I made one guess already (antennas) and sadly I >guessed wrong.

>Another thing where your setup differs from mine is >that you are
>using a device with 3 antennas, whereas my devices >only have 2.

>I have already ordered a 3 antenna device two days >ago so I should
>have one to test with soon. Perhaps I will see a >problem then.

>Is anyone else reading this list using a 3 antenna >device?
>Please let us know whether it works.
Assuming my firewall hangs again tonight, I'll revert to 11g and see if the 
issue persists. Would ssh access help to diagnose the problem? I can put other 
hardware in to do firewall duties and swap my current box out

Re: 11n support for athn(4)

[Stefan Sperling]

On Mon, Jan 16, 2017 at 11:58:51PM +, Peter Kay wrote:
> On 16 January 2017 at 23:30, Stefan Sperling  wrote:
> > Do you have 2 antennas properly connected to the athn card?
> 
> Three, yes, but note that unless the antennas have been unreasonably
> disturbed during the snapshot upgrade nothing has changed. Also, it
> takes a day or so for the access point to start failing, so I'm
> suspecting a software issue.

Fair enough. But I can't see anything in your reports that would guide me
where to look for bugs in the code. Let me know if you find out more.

Re: wsfont.c: remove sony8x16 and sony12x24?

[Frederic Cambus]

On Thu, Jan 12, 2017 at 01:39:47PM +0100, Frederic Cambus wrote:

> Most fonts in wsfont are not compiled in by default, and while some are
> worth keeping and using, I would like to propose deleting some of them
> in order to make space for larger sized fonts.
> 
> The Sony fonts are Serif, which doesn't work very well for monospaced
> bitmap fonts intended for console use, are not very readable, and have
> no slashed or dotted zeros. Delete them?
> 
> For obvious reasons, I didn't run cvs rm on sony8x16.h and sony12x24.h
> before generating the diff.
> 
> Comments? OK?

It's been five days and so far nobody objected. Got one OK privately,
however I would prefer having more feedback before committing this.

If there are no objections I'm going to commit in the following days.

Any more OKs? Any objections?

Re: 11n support for athn(4)

[Peter Kay]

  Original Message  
From: s...@stsp.name
Sent: 17 January 2017 10:00 a.m.
To: syllops...@syllopsium.co.uk
Cc: tech@openbsd.org
Subject: Re: 11n support for athn(4)

On Mon, Jan 16, 2017 at 11:58:51PM +, Peter Kay wrote:
>> 
>> Three, yes, but note that unless the antennas have been unreasonably
>> disturbed during the snapshot upgrade nothing has changed. Also, it
>> takes a day or so for the access point to start failing, so I'm
>> suspecting a software issue.

>Fair enough. But I can't see anything in your reports >that would guide me
>where to look for bugs in the code. Let me know if >you find out more.

What diagnostics are available to narrow down the cause of this issue?