Re: [patch] Disklabel message tweak

2015-07-16 Thread Theo de Raadt
>This is another trivial patch, but I've always found the disklabel
>message "No label changes" confusing. For example, if you print (p), add
>a label (a), write (w), print to check your changes (p), and then quit
>(q), it seems odd to be told "No label changes". 
>
>
>
>Index: sbin/disklabel/editor.c
>===
>RCS file: /cvs/src/sbin/disklabel/editor.c,v
>retrieving revision 1.295
>diff -u -p -r1.295 editor.c
>--- sbin/disklabel/editor.c8 May 2015 12:15:50 -   1.295
>+++ sbin/disklabel/editor.c17 Jul 2015 02:54:59 -
>@@ -373,7 +373,7 @@ editor(int f)
>*/
>   if (!dflag && !aflag &&
>   memcmp(&lab, &newlab, sizeof(newlab)) == 0) {
>-  puts("No label changes.");
>+  puts("No further label changes.");
>   /* Save mountpoint info. */
>   mpsave(&newlab);
>   goto done;

The phrase "No label changes." was selected because it is true
(there is nothing to save).  I don't see what "further" adds to
make this more accurate or understandable.



Re: Ask for password for failed commands

2015-07-16 Thread David Gwynne

> On 17 Jul 2015, at 16:18, Bob Beck  wrote:
> 
> I concur.  Vadim I like the basic idea, but I do not like that in the
> bogus case we still run all the priviledged user auth code.

sudo also has the -l flag, which lists what commands you're allowed to run.

however, it looks like if you arent allowed to run anything on the local 
machine sudo -l will make it look like you're entering your password 
incorrectly rather than report that you cant run anything. so a similar problem 
but different. or i cant type my password good today. 

dlg

> 
> 
> On Thu, Jul 16, 2015 at 4:30 PM, Ted Unangst  wrote:
>> Vadim Zhukov wrote:
>>> Ask for a password when we're going to fail() anyway, to avoid
>>> leaking information about available commands. The sudo(8) behaves
>>> the same way, FWIW.
>> 
>> Let's say no for now. I'm not too concerned about this leak. I'm not sure 
>> what
>> a user would hope to discover. Hasn't the sysadmin told them what commands
>> they can run?
>> 
>> On the other hand, running more auth code seems riskier.
>> 
> 




Re: Ask for password for failed commands

2015-07-16 Thread Bob Beck
I concur.  Vadim I like the basic idea, but I do not like that in the
bogus case we still run all the priviledged user auth code.


On Thu, Jul 16, 2015 at 4:30 PM, Ted Unangst  wrote:
> Vadim Zhukov wrote:
>> Ask for a password when we're going to fail() anyway, to avoid
>> leaking information about available commands. The sudo(8) behaves
>> the same way, FWIW.
>
> Let's say no for now. I'm not too concerned about this leak. I'm not sure what
> a user would hope to discover. Hasn't the sysadmin told them what commands
> they can run?
>
> On the other hand, running more auth code seems riskier.
>



Re: [patch] Disklabel message tweak

2015-07-16 Thread Miod Vallat
> This is another trivial patch, but I've always found the disklabel
> message "No label changes" confusing. For example, if you print (p), add
> a label (a), write (w), print to check your changes (p), and then quit
> (q), it seems odd to be told "No label changes". 

Well, the current message makes sense. You've written the label with the
`w' command, and there have been no changes since then.

Miod



[patch] Disklabel message tweak

2015-07-16 Thread Michael McConville
This is another trivial patch, but I've always found the disklabel
message "No label changes" confusing. For example, if you print (p), add
a label (a), write (w), print to check your changes (p), and then quit
(q), it seems odd to be told "No label changes". 



Index: sbin/disklabel/editor.c
===
RCS file: /cvs/src/sbin/disklabel/editor.c,v
retrieving revision 1.295
diff -u -p -r1.295 editor.c
--- sbin/disklabel/editor.c 8 May 2015 12:15:50 -   1.295
+++ sbin/disklabel/editor.c 17 Jul 2015 02:54:59 -
@@ -373,7 +373,7 @@ editor(int f)
 */
if (!dflag && !aflag &&
memcmp(&lab, &newlab, sizeof(newlab)) == 0) {
-   puts("No label changes.");
+   puts("No further label changes.");
/* Save mountpoint info. */
mpsave(&newlab);
goto done;



Re: tcpdump: decode 802.11 country element

2015-07-16 Thread Vadim Zhukov
2015-07-17 2:53 GMT+03:00 Stefan Sperling :
> On Fri, Jul 17, 2015 at 02:26:29AM +0300, Vadim Zhukov wrote:
>> 2015-07-17 1:49 GMT+03:00 Stefan Sperling :
>> > On Fri, Jul 17, 2015 at 01:23:54AM +0300, Vadim Zhukov wrote:
>> >> > +   printf(", channels %d", first_chan);
>> >> > +   for (i = first_chan + 1; i < nchan; i++)
>> >> > +   printf(" %i", i);
>> >>
>> >> It looks like you simply enumerate from first_chan till nchan; why not
>> >
>> > Indeed, this is what the channel data means.
>> >
>> >> to just print "channels %d-%d" then? Also, with this for loop, in case
>> >> of invalid data (nchan < first_chan) you won't have any data printed
>> >> at all.
>> >
>> > Good catch.
>> >
>> > My previous diff also didn't properly loop over the channel/tx power list.
>> >
>> > New diff. Tested in hackroom, where e.g. on 5GHz I see:
>> >
>> >  country 'CA ', channels 52-55 max TX power 24dB, channels 132-134 max TX 
>> > power 24dB
>>
>> Looks nice for me, but two more nits are inline below.
>>
>> > Index: print-802_11.c
>> > ===
>> > RCS file: /cvs/src/usr.sbin/tcpdump/print-802_11.c,v
>> > retrieving revision 1.19
>> > diff -u -p -r1.19 print-802_11.c
>> > --- print-802_11.c  16 Jul 2015 20:57:13 -  1.19
>> > +++ print-802_11.c  16 Jul 2015 22:45:51 -
>> > @@ -78,6 +78,7 @@ intieee80211_hdr(struct ieee80211_fram
>> >  int ieee80211_data(struct ieee80211_frame *, u_int);
>> >  voidieee80211_print_element(u_int8_t *, u_int);
>> >  voidieee80211_print_essid(u_int8_t *, u_int);
>> > +voidieee80211_print_country(u_int8_t *, u_int);
>> >  voidieee80211_print_htcaps(u_int8_t *, u_int);
>> >  int ieee80211_elements(struct ieee80211_frame *, u_int);
>> >  int ieee80211_frame(struct ieee80211_frame *, u_int);
>> > @@ -233,6 +234,43 @@ ieee80211_print_essid(u_int8_t *essid, u
>> >
>> >  /* Caller checks len */
>> >  void
>> > +ieee80211_print_country(u_int8_t *data, u_int len)
>> > +{
>> > +   u_int8_t first_chan, nchan, maxpower;
>> > +
>> > +   if (len < 6)
>>
>> Shouldn't this be "len < 3" here?
>
> No. The element must contain one first_chan/nchan/tx power triplet.
>
> The 801.22-2012 standard says: "The minimum length of the element is 8 
> octets."
> This includes the elemend id (1 byte), length (1 byte), and data (6 bytes).
>
>> > +   return;
>> > +
>> > +   /* country string */
>> > +   printf(" '%c%c%c'", data[0], data[1], data[2]);
>> > +
>> > +   len -= 3;
>> > +   data += 3;
>> > +
>> > +   /* channels and corresponding TX power limits */
>> > +   while (len > 0) {
>> > +   if (len < 6)
>
> The above, however, needs to be len < 3 since we're just checking
> the length of the triplet here. And the += 6 increment at the end
> of the loop was wrong, too.
>
>> > +   break;
>> > +
>> > +   /* ignore operating extension Id (values >= 201) for now */
>> > +   if (data[3] >= 201 || data[4] >= 201)
>> > +   continue;
>> > +
>
> Sigh... And these indices were wrong, too:
>
>> > +   first_chan = data[3];
>> > +   nchan = data[4];
>> > +   maxpower = data[5];
>
>> Hm, what if we have received nchan==0, maybe some warning should be
>> printed?
>
> I don't think we should bother with invalid data. If it's not valid,
> we should silently skip it. Else tcpdump would have to print all sorts
> of warnings.

Well, it depends. I've just picked print-tcp.c for example:

if (length < sizeof(*tp)) {
(void)printf("truncated-tcp %d", length);
return;
}

Or:

datalen = len - 2;
if ((datalen % TCPOLEN_SACK) != 0 ||
!(flags & TH_ACK)) {
 (void)printf("malformed sack ");
 (void)printf("[len %d] ", datalen);
 break;
}

So at least in some cases warnings (some sort of) are welcome in tcpdump.

I don't insist on explicit warning ("invalid nchan" or something like
that), no. But, IMHO, we should display data we gathered without
mangling; otherwise, we'll fool the user that nchan is 1 when it's 0
actually. It's like gdb printing "1" for int x when x is actually 0.
That's why I insist on "nchan != 1" instead of "nchan > 1", or some
equivalent tweak like always printing the raw values - this is how
some flags fields are already printed in tcpdump code:

03:58:28.236794 802.1d RSTP config flags=3c ...

>> > +   len -= 6;
>> > +   data += 6;
>> > +   }
>> > +}
>
> New diff which produces the following output in my testing:
>
>  country 'CA ', channels 36-39 17dB, channels 52-55 24dB, channels 100-104 
> 24dB, channels

Re: Fix socketpair(2) handling of unix datagram sockets using cloexec/nonblock

2015-07-16 Thread Philip Guenther
On Thu, Jul 16, 2015 at 4:54 PM, Jeremy Evans  wrote:
> Fix socketpair(2) on Unix datagram sockets that use SOCK_CLOEXEC or
> SOCK_NONBLOCK.
>
> This fixes a failure in the ruby test suite.
>
> OK?

No, that'll have false positives on SOCK_RAW sockets.  You need to
mask things, perhaps a diff like this:

--- sys/socket.h21 Jan 2015 02:23:14 -  1.87
+++ sys/socket.h17 Jul 2015 00:03:48 -
@@ -68,6 +68,9 @@ typedef   __sa_family_t   sa_family_t;/* so
 #defineSOCK_RAW3   /* raw-protocol interface */
 #defineSOCK_RDM4   /* reliably-delivered message */
 #defineSOCK_SEQPACKET  5   /* sequenced packet stream */
+#ifdef _KERNEL
+#defineSOCK_TYPE_MASK  0x000F  /* mask that covers the above */
+#endif

 /*
  * Socket creation flags
Index: kern/uipc_syscalls.c
===
RCS file: /data/src/openbsd/src/sys/kern/uipc_syscalls.c,v
retrieving revision 1.102
diff -u -p -r1.102 uipc_syscalls.c
--- kern/uipc_syscalls.c21 May 2015 13:35:15 -  1.102
+++ kern/uipc_syscalls.c17 Jul 2015 00:04:02 -
@@ -403,7 +403,7 @@ sys_socketpair(struct proc *p, void *v,
}
if ((error = soconnect2(so1, so2)) != 0)
goto free4;
-   if (SCARG(uap, type) == SOCK_DGRAM) {
+   if ((SCARG(uap, type) & SOCK_TYPE_MASK) == SOCK_DGRAM) {
/*
 * Datagram socket connection is asymmetric.
 */



Re: sa_family_t is not always equal to u_int8_t

2015-07-16 Thread Martin Pieuchot
On 17/07/15(Fri) 01:41, Alexandr Nedvedicky wrote:
> On Thu, Jul 16, 2015 at 11:10:06PM +, Miod Vallat wrote:
> > > cvs diff -p output:
> > 
> > Please send unified diffs (diff -u). The easiest way is to have a
> >   diff -up
> > line in your ~/.cvsrc file. Or "diff -uNp" if you want cvs diff to show
> > new files as well.
> > 
> > Miod
> 
> 
> Sorry, now I got it..
> regards
> sasha

ok mpi@

> 
> Index: pfvar.h
> ===
> RCS file: /cvs/src/sys/net/pfvar.h,v
> retrieving revision 1.416
> diff -u -p -r1.416 pfvar.h
> --- pfvar.h 16 Jul 2015 21:14:21 -  1.416
> +++ pfvar.h 16 Jul 2015 23:39:21 -
> @@ -1791,7 +1791,7 @@ extern void
> pf_print_flags(u_int8_t);
>  extern struct ifnet*sync_ifp;
>  extern struct pf_rule   pf_default_rule;
>  extern void pf_addrcpy(struct pf_addr *, struct pf_addr 
> *,
> -   u_int8_t);
> +   sa_family_t);
>  voidpf_rm_rule(struct pf_rulequeue *,
> struct pf_rule *);
>  voidpf_purge_rule(struct pf_ruleset *,
> @@ -1984,7 +1984,7 @@ struct pf_os_fingerprint *
> pf_osfp_validate(void);
> 
>  #ifdef _KERNEL
> -voidpf_print_host(struct pf_addr *, u_int16_t, u_int8_t);
> +voidpf_print_host(struct pf_addr *, u_int16_t, 
> sa_family_t);
> 
>  int pf_get_transaddr(struct pf_rule *, struct pf_pdesc *,
> struct pf_src_node **, struct pf_rule **);
> 



Fix socketpair(2) handling of unix datagram sockets using cloexec/nonblock

2015-07-16 Thread Jeremy Evans
Fix socketpair(2) on Unix datagram sockets that use SOCK_CLOEXEC or
SOCK_NONBLOCK.

This fixes a failure in the ruby test suite.

OK?

Thanks,
Jeremy

Index: kern/uipc_syscalls.c
===
RCS file: /cvs/src/sys/kern/uipc_syscalls.c,v
retrieving revision 1.97
diff -u -p -r1.97 uipc_syscalls.c
--- kern/uipc_syscalls.c13 Dec 2014 21:05:33 -  1.97
+++ kern/uipc_syscalls.c16 Jul 2015 23:29:40 -
@@ -406,7 +406,7 @@ sys_socketpair(struct proc *p, void *v, 
}
if ((error = soconnect2(so1, so2)) != 0)
goto free4;
-   if (SCARG(uap, type) == SOCK_DGRAM) {
+   if (SCARG(uap, type) & SOCK_DGRAM) {
/*
 * Datagram socket connection is asymmetric.
 */



Re: tcpdump: decode 802.11 country element

2015-07-16 Thread Stefan Sperling
On Fri, Jul 17, 2015 at 02:26:29AM +0300, Vadim Zhukov wrote:
> 2015-07-17 1:49 GMT+03:00 Stefan Sperling :
> > On Fri, Jul 17, 2015 at 01:23:54AM +0300, Vadim Zhukov wrote:
> >> > +   printf(", channels %d", first_chan);
> >> > +   for (i = first_chan + 1; i < nchan; i++)
> >> > +   printf(" %i", i);
> >>
> >> It looks like you simply enumerate from first_chan till nchan; why not
> >
> > Indeed, this is what the channel data means.
> >
> >> to just print "channels %d-%d" then? Also, with this for loop, in case
> >> of invalid data (nchan < first_chan) you won't have any data printed
> >> at all.
> >
> > Good catch.
> >
> > My previous diff also didn't properly loop over the channel/tx power list.
> >
> > New diff. Tested in hackroom, where e.g. on 5GHz I see:
> >
> >  country 'CA ', channels 52-55 max TX power 24dB, channels 132-134 max TX 
> > power 24dB
> 
> Looks nice for me, but two more nits are inline below.
> 
> > Index: print-802_11.c
> > ===
> > RCS file: /cvs/src/usr.sbin/tcpdump/print-802_11.c,v
> > retrieving revision 1.19
> > diff -u -p -r1.19 print-802_11.c
> > --- print-802_11.c  16 Jul 2015 20:57:13 -  1.19
> > +++ print-802_11.c  16 Jul 2015 22:45:51 -
> > @@ -78,6 +78,7 @@ intieee80211_hdr(struct ieee80211_fram
> >  int ieee80211_data(struct ieee80211_frame *, u_int);
> >  voidieee80211_print_element(u_int8_t *, u_int);
> >  voidieee80211_print_essid(u_int8_t *, u_int);
> > +voidieee80211_print_country(u_int8_t *, u_int);
> >  voidieee80211_print_htcaps(u_int8_t *, u_int);
> >  int ieee80211_elements(struct ieee80211_frame *, u_int);
> >  int ieee80211_frame(struct ieee80211_frame *, u_int);
> > @@ -233,6 +234,43 @@ ieee80211_print_essid(u_int8_t *essid, u
> >
> >  /* Caller checks len */
> >  void
> > +ieee80211_print_country(u_int8_t *data, u_int len)
> > +{
> > +   u_int8_t first_chan, nchan, maxpower;
> > +
> > +   if (len < 6)
> 
> Shouldn't this be "len < 3" here?

No. The element must contain one first_chan/nchan/tx power triplet.

The 801.22-2012 standard says: "The minimum length of the element is 8 octets."
This includes the elemend id (1 byte), length (1 byte), and data (6 bytes).

> > +   return;
> > +
> > +   /* country string */
> > +   printf(" '%c%c%c'", data[0], data[1], data[2]);
> > +
> > +   len -= 3;
> > +   data += 3;
> > +
> > +   /* channels and corresponding TX power limits */
> > +   while (len > 0) {
> > +   if (len < 6)

The above, however, needs to be len < 3 since we're just checking
the length of the triplet here. And the += 6 increment at the end
of the loop was wrong, too.

> > +   break;
> > +
> > +   /* ignore operating extension Id (values >= 201) for now */
> > +   if (data[3] >= 201 || data[4] >= 201)
> > +   continue;
> > +

Sigh... And these indices were wrong, too:

> > +   first_chan = data[3];
> > +   nchan = data[4];
> > +   maxpower = data[5];

> Hm, what if we have received nchan==0, maybe some warning should be
> printed?

I don't think we should bother with invalid data. If it's not valid,
we should silently skip it. Else tcpdump would have to print all sorts
of warnings.

> > +   len -= 6;
> > +   data += 6;
> > +   }
> > +}

New diff which produces the following output in my testing:

 country 'CA ', channels 36-39 17dB, channels 52-55 24dB, channels 100-104 
24dB, channels 132-134 24dB, channels 149-153 30dB

Index: print-802_11.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/print-802_11.c,v
retrieving revision 1.19
diff -u -p -r1.19 print-802_11.c
--- print-802_11.c  16 Jul 2015 20:57:13 -  1.19
+++ print-802_11.c  16 Jul 2015 23:49:40 -
@@ -78,6 +78,7 @@ intieee80211_hdr(struct ieee80211_fram
 int ieee80211_data(struct ieee80211_frame *, u_int);
 voidieee80211_print_element(u_int8_t *, u_int);
 voidieee80211_print_essid(u_int8_t *, u_int);
+voidieee80211_print_country(u_int8_t *, u_int);
 voidieee80211_print_htcaps(u_int8_t *, u_int);
 int ieee80211_elements(struct ieee80211_frame *, u_int);
 int ieee80211_frame(struct ieee80211_frame *, u_int);
@@ -233,6 +234,43 @@ ieee80211_print_essid(u_int8_t *essid, u
 
 /* Caller checks len */
 void
+ieee80211_print_country(u_int8_t *data, u_int len)
+{
+   u_int8_t first_chan, nchan, maxpower;
+
+   if (len < 6)
+   return;
+
+   /* country string */
+   printf(" '%c%c%c'", data[0], data[1], data[2]);
+
+   len -= 3;
+   data += 3;
+
+   /* channels and corresponding TX power limits */
+   while (len > 0) {
+   if (len < 3)
+   break;
+   
+   /* igno

bridge(4) and etherip fix

2015-07-16 Thread Martin Pieuchot
goda@ found a regression due to the recent M_PROTO1 change.  Apparently
gif(4) is using this flag to know that a packet comes from bridge(4) and
wants etherip encapsulation.

Instead of hiding another layer-violation (yeah for bridge!) make it
obvious.  Diff below, any ok?

Index: net/if_bridge.c
===
RCS file: /cvs/src/sys/net/if_bridge.c,v
retrieving revision 1.254
diff -u -p -r1.254 if_bridge.c
--- net/if_bridge.c 16 Jul 2015 21:14:21 -  1.254
+++ net/if_bridge.c 16 Jul 2015 23:13:33 -
@@ -91,6 +91,10 @@
 #include 
 #endif
 
+#if NGIF > 0
+#include 
+#endif
+
 #include 
 
 /*
@@ -1355,6 +1359,7 @@ bridge_input(struct ifnet *ifp, struct m
IF_ENQUEUE(&sc->sc_if.if_snd, mc);
splx(s);
schednetisr(NETISR_BRIDGE);
+#if NGIF > 0
if (ifp->if_type == IFT_GIF) {
TAILQ_FOREACH(ifl, &sc->sc_iflist, next) {
if (ifl->ifp->if_type != IFT_ETHER)
@@ -1366,6 +1371,7 @@ bridge_input(struct ifnet *ifp, struct m
return (NULL);
}
}
+#endif /* NGIF */
return (m);
}
 
@@ -2556,8 +2562,12 @@ bridge_ifenqueue(struct bridge_softc *sc
/* Count packets input into the gif from outside */
ifp->if_ipackets++;
ifp->if_ibytes += m->m_pkthdr.len;
+
+   error = gif_encap(ifp, &m, AF_LINK);
+   if (error)
+   return (error);
}
-#endif
+#endif /* NGIF */
len = m->m_pkthdr.len;
 
error = if_enqueue(ifp, m);
Index: net/if_gif.c
===
RCS file: /cvs/src/sys/net/if_gif.c,v
retrieving revision 1.76
diff -u -p -r1.76 if_gif.c
--- net/if_gif.c16 Jul 2015 21:21:49 -  1.76
+++ net/if_gif.c16 Jul 2015 23:09:57 -
@@ -169,39 +169,6 @@ gif_start(struct ifnet *ifp)
continue;
}
 
-   /*
-* Check if the packet is coming via bridge and needs
-* etherip encapsulation or not. bridge(4) directly calls
-* the start function and bypasses the if_output function
-* so we need to do the encap here.
-*/
-   if (ifp->if_bridgeport && (m->m_flags & M_PROTO1)) {
-   int error = 0;
-   /*
-* Remove multicast and broadcast flags or encapsulated
-* packet ends up as multicast or broadcast packet.
-*/
-   m->m_flags &= ~(M_BCAST|M_MCAST);
-   switch (sc->gif_psrc->sa_family) {
-   case AF_INET:
-   error = in_gif_output(ifp, AF_LINK, &m);
-   break;
-#ifdef INET6
-   case AF_INET6:
-   error = in6_gif_output(ifp, AF_LINK, &m);
-   break;
-#endif
-   default:
-   error = EAFNOSUPPORT;
-   m_freem(m);
-   break;
-   }
-   if (error)
-   continue;
-   if (gif_checkloop(ifp, m))
-   continue;
-   }
-
 #if NBPFILTER > 0
if (ifp->if_bpf) {
int offset;
@@ -279,48 +246,58 @@ gif_start(struct ifnet *ifp)
 }
 
 int
-gif_output(struct ifnet *ifp, struct mbuf *m, struct sockaddr *dst,
-struct rtentry *rt)
+gif_encap(struct ifnet *ifp, struct mbuf **mp, sa_family_t af)
 {
struct gif_softc *sc = (struct gif_softc*)ifp;
int error = 0;
-
-   if (!(ifp->if_flags & IFF_UP) ||
-   sc->gif_psrc == NULL || sc->gif_pdst == NULL ||
-   sc->gif_psrc->sa_family != sc->gif_pdst->sa_family) {
-   m_freem(m);
-   error = ENETDOWN;
-   goto end;
-   }
-
/*
 * Remove multicast and broadcast flags or encapsulated packet
 * ends up as multicast or broadcast packet.
 */
-   m->m_flags &= ~(M_BCAST|M_MCAST);
+   (*mp)->m_flags &= ~(M_BCAST|M_MCAST);
 
/*
 * Encapsulate packet. Add IP or IP6 header depending on tunnel AF.
 */
switch (sc->gif_psrc->sa_family) {
case AF_INET:
-   error = in_gif_output(ifp, dst->sa_family, &m);
+   error = in_gif_output(ifp, af, mp);
break;
 #ifdef INET6
case AF_INET6:
-   error = in6_gif_output(ifp, dst->sa_family, &m);
+   error = in6_gif_output(ifp, af, mp);
break;
 #endif
default:
-   m_freem(m);
+   

Re: sa_family_t is not always equal to u_int8_t

2015-07-16 Thread Alexandr Nedvedicky
On Thu, Jul 16, 2015 at 11:10:06PM +, Miod Vallat wrote:
> > cvs diff -p output:
> 
> Please send unified diffs (diff -u). The easiest way is to have a
>   diff -up
> line in your ~/.cvsrc file. Or "diff -uNp" if you want cvs diff to show
> new files as well.
> 
> Miod


Sorry, now I got it..
regards
sasha

Index: pfvar.h
===
RCS file: /cvs/src/sys/net/pfvar.h,v
retrieving revision 1.416
diff -u -p -r1.416 pfvar.h
--- pfvar.h 16 Jul 2015 21:14:21 -  1.416
+++ pfvar.h 16 Jul 2015 23:39:21 -
@@ -1791,7 +1791,7 @@ extern void
pf_print_flags(u_int8_t);
 extern struct ifnet*sync_ifp;
 extern struct pf_rule   pf_default_rule;
 extern void pf_addrcpy(struct pf_addr *, struct pf_addr *,
-   u_int8_t);
+   sa_family_t);
 voidpf_rm_rule(struct pf_rulequeue *,
struct pf_rule *);
 voidpf_purge_rule(struct pf_ruleset *,
@@ -1984,7 +1984,7 @@ struct pf_os_fingerprint *
pf_osfp_validate(void);

 #ifdef _KERNEL
-voidpf_print_host(struct pf_addr *, u_int16_t, u_int8_t);
+voidpf_print_host(struct pf_addr *, u_int16_t, 
sa_family_t);

 int pf_get_transaddr(struct pf_rule *, struct pf_pdesc *,
struct pf_src_node **, struct pf_rule **);



potential memory leak in SIOCADDRULE

2015-07-16 Thread Alexandr Nedvedicky
Hello,

PF can leak memory in DIOCADDRULE code path in case something goes wrong with
rule creation.

Our story begins when we do pf_rule_copyin():

1070 if ((error = pf_rule_copyin(&pr->rule, rule, 
ruleset))) {
1071 pool_put(&pf_rule_pl, rule);
1072 break;
1073 }
1074 rule->cuid = p->p_ucred->cr_ruid;


Note pf_rule_copyin() takes couple of references to various PF objects:

2362 if (pf_kif_setup(to->ifname, &to->kif))
2363 return (EINVAL);
2364 if (pf_kif_setup(to->rcv_ifname, &to->rcv_kif))
2365 return (EINVAL);
2366 if (to->overload_tblname[0]) {
2367 if ((to->overload_tbl = pfr_attach_table(ruleset,
2368 to->overload_tblname, 0)) == NULL)
2369 return (EINVAL);

those references are never released if PF uses pool_put() to release rule
at 1071. We must tell PF to use pf_rm_rule(NULL, rule). Patch is further
below.

regards
sasha

8<---

Index: pf_ioctl.c
===
RCS file: /cvs/src/sys/net/pf_ioctl.c,v
retrieving revision 1.285
diff -u -p -r1.285 pf_ioctl.c
--- pf_ioctl.c  11 Apr 2015 13:00:12 -  1.285
+++ pf_ioctl.c  16 Jul 2015 23:21:48 -
@@ -1068,7 +1068,8 @@ pfioctl(dev_t dev, u_long cmd, caddr_t a
break;
}
if ((error = pf_rule_copyin(&pr->rule, rule, ruleset))) {
-   pool_put(&pf_rule_pl, rule);
+   pf_rm_rule(NULL, rule);
+   rule = NULL;
break;
}
rule->cuid = p->p_ucred->cr_ruid;
@@ -1084,7 +1085,8 @@ pfioctl(dev_t dev, u_long cmd, caddr_t a
break;
 #endif /* INET6 */
default:
-   pool_put(&pf_rule_pl, rule);
+   pf_rm_rule(NULL, rule);
+   rule = NULL;
error = EAFNOSUPPORT;
goto fail;
}






update kroute.c to follow bgpd/kroute.c

2015-07-16 Thread Claudio Jeker
So mpi@ fixed a problem with connected routes in bgpd. It is time to
update all the other kroute.c implementations as well.

ospfd, ospf6d, ripd, ldpd and snmpd (which I'm unsure about)

Please test
-- 
:wq Claudio

Index: kroute.c
===
RCS file: /cvs/src/usr.sbin/ospfd/kroute.c,v
retrieving revision 1.98
diff -u -p -r1.98 kroute.c
--- kroute.c11 Feb 2015 05:57:44 -  1.98
+++ kroute.c16 Jul 2015 23:19:24 -
@@ -1373,7 +1373,9 @@ rtmsg_process(char *buf, size_t len)
if ((sa = rti_info[RTAX_DST]) == NULL)
continue;
 
-   if (rtm->rtm_flags & RTF_LLINFO)/* arp cache */
+   /* Skip ARP/ND cache and local routes. */
+   if (rtm->rtm_flags &
+   (RTF_LLINFO|RTF_LOCAL|RTF_BROADCAST))
continue;
 
if (rtm->rtm_flags & RTF_MPATH)
@@ -1414,10 +1416,18 @@ rtmsg_process(char *buf, size_t len)
if ((sa = rti_info[RTAX_GATEWAY]) != NULL) {
switch (sa->sa_family) {
case AF_INET:
+   if (rtm->rtm_flags & RTF_CONNECTED) {
+   flags |= F_CONNECTED;
+   break;
+   }
+
nexthop.s_addr = ((struct
sockaddr_in *)sa)->sin_addr.s_addr;
break;
case AF_LINK:
+   /*
+* Traditional BSD connected routes 
have * a gateway of type AF_LINK.
+*/
flags |= F_CONNECTED;
break;
}
Index: kroute.c
===
RCS file: /cvs/src/usr.sbin/ospf6d/kroute.c,v
retrieving revision 1.47
diff -u -p -r1.47 kroute.c
--- kroute.c11 Feb 2015 05:58:57 -  1.47
+++ kroute.c16 Jul 2015 23:17:27 -
@@ -1092,7 +1092,8 @@ fetchtable(void)
if ((sa = rti_info[RTAX_DST]) == NULL)
continue;
 
-   if (rtm->rtm_flags & RTF_LLINFO)/* arp cache */
+   /* Skip ARP/ND cache and local routes. */
+   if (rtm->rtm_flags & (RTF_LLINFO|RTF_LOCAL|RTF_BROADCAST))
continue;
 
if ((kr = calloc(1, sizeof(struct kroute_node))) == NULL) {
@@ -1137,6 +1138,11 @@ fetchtable(void)
if ((sa = rti_info[RTAX_GATEWAY]) != NULL)
switch (sa->sa_family) {
case AF_INET6:
+   if (rtm->rtm_flags & RTF_CONNECTED) {
+   kr->r.flags |= F_CONNECTED;
+   break;
+   }
+
sa_in6 = (struct sockaddr_in6 *)sa;
/*
 * XXX The kernel provides the scope via the
@@ -1147,6 +1153,10 @@ fetchtable(void)
kr->r.scope = sa_in6->sin6_scope_id;
break;
case AF_LINK:
+   /*
+* Traditional BSD connected routes have
+* a gateway of type AF_LINK.
+*/
kr->r.flags |= F_CONNECTED;
break;
}
@@ -1298,7 +1308,9 @@ dispatch_rtmsg(void)
if (rtm->rtm_errno) /* failed attempts... */
continue;
 
-   if (rtm->rtm_flags & RTF_LLINFO)/* arp cache */
+   /* Skip ARP/ND cache and local routes. */
+   if (rtm->rtm_flags &
+   (RTF_LLINFO|RTF_LOCAL|RTF_BROADCAST))
continue;
 
 #ifdef RTF_MPATH
Index: kroute.c
===
RCS file: /cvs/src/usr.sbin/ripd/kroute.c,v
retrieving revision 1.29
diff -u -p -r1.29 kroute.c
--- kroute.c11 Feb 2015 05:58:08 -  1.29
+++ kroute.c16 Jul 2015 23:18:22 -
@@ -849,7 +849,8 @@ fetchtable(void)
if ((sa = rti_info[RTAX_DST]) == NULL)
continue;
 
-   if (rtm->rtm_flags & RTF_LLINFO)/* arp cache */
+   /* Skip ARP/ND cache and local routes. */
+   if (rtm->rtm_fla

Re: tcpdump: decode 802.11 country element

2015-07-16 Thread Vadim Zhukov
2015-07-17 1:49 GMT+03:00 Stefan Sperling :
> On Fri, Jul 17, 2015 at 01:23:54AM +0300, Vadim Zhukov wrote:
>> > +   printf(", channels %d", first_chan);
>> > +   for (i = first_chan + 1; i < nchan; i++)
>> > +   printf(" %i", i);
>>
>> It looks like you simply enumerate from first_chan till nchan; why not
>
> Indeed, this is what the channel data means.
>
>> to just print "channels %d-%d" then? Also, with this for loop, in case
>> of invalid data (nchan < first_chan) you won't have any data printed
>> at all.
>
> Good catch.
>
> My previous diff also didn't properly loop over the channel/tx power list.
>
> New diff. Tested in hackroom, where e.g. on 5GHz I see:
>
>  country 'CA ', channels 52-55 max TX power 24dB, channels 132-134 max TX 
> power 24dB

Looks nice for me, but two more nits are inline below.

> Index: print-802_11.c
> ===
> RCS file: /cvs/src/usr.sbin/tcpdump/print-802_11.c,v
> retrieving revision 1.19
> diff -u -p -r1.19 print-802_11.c
> --- print-802_11.c  16 Jul 2015 20:57:13 -  1.19
> +++ print-802_11.c  16 Jul 2015 22:45:51 -
> @@ -78,6 +78,7 @@ intieee80211_hdr(struct ieee80211_fram
>  int ieee80211_data(struct ieee80211_frame *, u_int);
>  voidieee80211_print_element(u_int8_t *, u_int);
>  voidieee80211_print_essid(u_int8_t *, u_int);
> +voidieee80211_print_country(u_int8_t *, u_int);
>  voidieee80211_print_htcaps(u_int8_t *, u_int);
>  int ieee80211_elements(struct ieee80211_frame *, u_int);
>  int ieee80211_frame(struct ieee80211_frame *, u_int);
> @@ -233,6 +234,43 @@ ieee80211_print_essid(u_int8_t *essid, u
>
>  /* Caller checks len */
>  void
> +ieee80211_print_country(u_int8_t *data, u_int len)
> +{
> +   u_int8_t first_chan, nchan, maxpower;
> +
> +   if (len < 6)

Shouldn't this be "len < 3" here?

> +   return;
> +
> +   /* country string */
> +   printf(" '%c%c%c'", data[0], data[1], data[2]);
> +
> +   len -= 3;
> +   data += 3;
> +
> +   /* channels and corresponding TX power limits */
> +   while (len > 0) {
> +   if (len < 6)
> +   break;
> +
> +   /* ignore operating extension Id (values >= 201) for now */
> +   if (data[3] >= 201 || data[4] >= 201)
> +   continue;
> +
> +   first_chan = data[3];
> +   nchan = data[4];
> +   maxpower = data[5];
> +
> +   printf(", channel%s %d", nchan > 1 ? "s" : "", first_chan);
> +   if (nchan > 1)
> +   printf("-%d", first_chan + nchan - 1);
> +   printf(" max TX power %ddB", maxpower);

Hm, what if we have received nchan==0, maybe some warning should be
printed? Otherwise, it won't be possible to distinguish from nchan==1
case. I'd suggest checking "nchan != 1" instead of "nchan > 1", then
we'll see strange "channels" part in case of nchan==0, and detect data
error.

> +   len -= 6;
> +   data += 6;
> +   }
> +}
> +/* Caller checks len */
> +void
>  ieee80211_print_htcaps(u_int8_t *data, u_int len)
>  {
> u_int16_t htcaps;
> @@ -392,8 +430,7 @@ ieee80211_elements(struct ieee80211_fram
> break;
> case IEEE80211_ELEMID_COUNTRY:
> printf(", country");
> -   for (i = len; i > 0; i--, data++)
> -   printf(" %u", data[0]);
> +   ieee80211_print_country(data, len);
> break;
> case IEEE80211_ELEMID_CHALLENGE:
> printf(", challenge");
> @@ -436,6 +473,9 @@ ieee80211_elements(struct ieee80211_fram
> printf(", htcaps");
> if (vflag)
> ieee80211_print_htcaps(data, len);
> +   break;
> +   case IEEE80211_ELEMID_POWER_CONSTRAINT:
> +   printf(", power constraint %udB", data[0]);
> break;
> case IEEE80211_ELEMID_VENDOR:
> printf(", vendor");

--
  WBR,
  Vadim Zhukov



potential memory leak when pf_create_state() fails

2015-07-16 Thread Alexandr Nedvedicky
Hello,

It seems to me PF might leak rule items when pf_create_state() fails to create
state for matching packet.

The scenario is as follows:

packet matches couple of 'match' rules before it hits a 'pass' rule
match rules are kept in `rules` single list, which is a local variable
of pf_test_rule()

3238 if (r->action == PF_MATCH) {
3239 if ((ri = pool_get(&pf_rule_item_pl,
3240 PR_NOWAIT)) == NULL) {
3241 REASON_SET(&reason, PFRES_MEMORY);
3242 goto cleanup;
3243 }
3244 ri->r = r;
3245 /* order is irrelevant */
3246 SLIST_INSERT_HEAD(&rules, ri, entry);
3247 pf_rule_to_actions(r, &act);


as soon as pf_test_rule() is done with rules it proceeds to state creation,
we are passing the `rules` as arg9

3373 
3374 action = pf_create_state(pd, r, a, nr, &skw, &sks, 
&rewrite,
3375 sm, tag, &rules, &act, sns);
3376 
3377 if (action != PF_PASS)
3378 return (action);
3379 if (sks != skw) {

note we are doing return at line 3378, when pf_create_state() fails to 
create
state and does not return PF_PASS. pf_create_state() assumes `rules` are 
either
bound to state or released by pf_create_state().

So let's see what happens in pf_create_state():

3451 s = pool_get(&pf_state_pl, PR_NOWAIT | PR_ZERO);
3452 if (s == NULL) {
3453 REASON_SET(&reason, PFRES_MEMORY);
3454 goto csfailed;
3455 }
3456 s->rule.ptr = r;
3457 s->anchor.ptr = a;
3458 s->natrule.ptr = nr;
3459 memcpy(&s->match_rules, rules, sizeof(s->match_rules));

if we fail to allocate state we jump right to csfailed returning PF_DROP

3614 csfailed:
3615 if (s) {
3616 pf_normalize_tcp_cleanup(s);/* safe even w/o init */
3617 pf_src_tree_remove_state(s);
3618 pool_put(&pf_state_pl, s);
3619 }
3620 
3621 for (i = 0; i < PF_SN_MAX; i++)
3622 if (sns[i] != NULL)
3623 pf_remove_src_node(sns[i]);
3624 
3625 return (PF_DROP);

without releasing `rules` (list of pf_rule_item)

The easiest way to fix it is to make sure pf_test_rule() releases `rules` 
whenever
pf_create_state() fails. Patches (-p, -u) are attached.

regards
sasha


? create_state.diff
? meleak.diff-p
? meleak.diff-u
? pbr-ipv6-reass.diff-p
? pbr-ipv6-reass.diff-u
? pf.c.diff
? pf.c.patch
? sa_family_t.diff
? sa_family_t.diff-p
Index: pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.924
diff -p -r1.924 pf.c
*** pf.c16 Jul 2015 21:14:21 -  1.924
--- pf.c16 Jul 2015 22:56:17 -
*** pf_test_rule(struct pf_pdesc *pd, struct
*** 3055,3060 
--- 3055,3061 
int  state_icmp = 0, icmp_dir = 0;
u_int16_tvirtual_type, virtual_id;
u_int8_t icmptype = 0, icmpcode = 0;
+   int  action = PF_DROP;
  
bzero(&act, sizeof(act));
bzero(sns, sizeof(sns));
*** pf_test_rule(struct pf_pdesc *pd, struct
*** 3330,3336 
  
if (pd->virtual_proto != PF_VPROTO_FRAGMENT
&& !state_icmp && r->keep_state) {
-   int action;
  
if (r->rule_flag & PFRULE_SRCTRACK &&
pf_insert_src_node(&sns[PF_SN_NONE], r, PF_SN_NONE, pd->af,
--- 3331,3336 
*** pf_test_rule(struct pf_pdesc *pd, struct
*** 3349,3355 
sm, tag, &rules, &act, sns);
  
if (action != PF_PASS)
!   return (action);
if (sks != skw) {
struct pf_state_key *sk;
  
--- 3349,3355 
sm, tag, &rules, &act, sns);
  
if (action != PF_PASS)
!   goto cleanup;
if (sks != skw) {
struct pf_state_key *sk;
  
*** cleanup:
*** 3407,3413 
pool_put(&pf_rule_item_pl, ri);
}
  
!   return (PF_DROP);
  }
  
  static __inline int
--- 3407,3413 
pool_put(&pf_rule_item_pl, ri);
}
  
!   return (action);
  }
  
  static __inline int
*** pf_create_state(struct pf_pdesc *pd, str
*** 3430,3436 
s->rule.ptr = r;
s->anchor.ptr = a;
s->natrule.ptr = nr;
-   memcpy(&s->match_rules, rules, sizeof(s->match_rules));
if (r->allow_opts)
s->state_flags |= PFSTATE_ALLOWOPTS;
   

sa_family_t is not always equal to u_int8_t

2015-07-16 Thread Alexandr Nedvedicky
Hello,

we hit this problem while building PF on Solaris, where sizeof(sa_family_t) == 2
patch below fixes the problem for Solaris.

regards
sasha

cvs diff -p output:

--8<--8<--8<--

Index: pfvar.h
===
RCS file: /cvs/src/sys/net/pfvar.h,v
retrieving revision 1.416
diff -p -r1.416 pfvar.h
*** pfvar.h 16 Jul 2015 21:14:21 -  1.416
--- pfvar.h 16 Jul 2015 22:10:10 -
*** extern void  pf_print_flags(u_int8_t);
*** 1791,1797 
  extern struct ifnet   *sync_ifp;
  extern struct pf_rule  pf_default_rule;
  extern voidpf_addrcpy(struct pf_addr *, struct pf_addr *,
!   u_int8_t);
  void   pf_rm_rule(struct pf_rulequeue *,
struct pf_rule *);
  void   pf_purge_rule(struct pf_ruleset *,
--- 1791,1797 
  extern struct ifnet   *sync_ifp;
  extern struct pf_rule  pf_default_rule;
  extern voidpf_addrcpy(struct pf_addr *, struct pf_addr *,
!   sa_family_t);
  void   pf_rm_rule(struct pf_rulequeue *,
struct pf_rule *);
  void   pf_purge_rule(struct pf_ruleset *,
*** struct pf_os_fingerprint *
*** 1984,1990 
pf_osfp_validate(void);
  
  #ifdef _KERNEL
! void   pf_print_host(struct pf_addr *, u_int16_t, u_int8_t);
  
  intpf_get_transaddr(struct pf_rule *, struct pf_pdesc *,
struct pf_src_node **, struct pf_rule **);
--- 1984,1990 
pf_osfp_validate(void);
  
  #ifdef _KERNEL
! void   pf_print_host(struct pf_addr *, u_int16_t, 
sa_family_t);
  
  intpf_get_transaddr(struct pf_rule *, struct pf_pdesc *,
struct pf_src_node **, struct pf_rule **);



Re: tcpdump: decode 802.11 country element

2015-07-16 Thread Stefan Sperling
On Fri, Jul 17, 2015 at 01:23:54AM +0300, Vadim Zhukov wrote:
> > +   printf(", channels %d", first_chan);
> > +   for (i = first_chan + 1; i < nchan; i++)
> > +   printf(" %i", i);
> 
> It looks like you simply enumerate from first_chan till nchan; why not

Indeed, this is what the channel data means.

> to just print "channels %d-%d" then? Also, with this for loop, in case
> of invalid data (nchan < first_chan) you won't have any data printed
> at all.

Good catch.

My previous diff also didn't properly loop over the channel/tx power list.

New diff. Tested in hackroom, where e.g. on 5GHz I see:

 country 'CA ', channels 52-55 max TX power 24dB, channels 132-134 max TX power 
24dB

Index: print-802_11.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/print-802_11.c,v
retrieving revision 1.19
diff -u -p -r1.19 print-802_11.c
--- print-802_11.c  16 Jul 2015 20:57:13 -  1.19
+++ print-802_11.c  16 Jul 2015 22:45:51 -
@@ -78,6 +78,7 @@ intieee80211_hdr(struct ieee80211_fram
 int ieee80211_data(struct ieee80211_frame *, u_int);
 voidieee80211_print_element(u_int8_t *, u_int);
 voidieee80211_print_essid(u_int8_t *, u_int);
+voidieee80211_print_country(u_int8_t *, u_int);
 voidieee80211_print_htcaps(u_int8_t *, u_int);
 int ieee80211_elements(struct ieee80211_frame *, u_int);
 int ieee80211_frame(struct ieee80211_frame *, u_int);
@@ -233,6 +234,43 @@ ieee80211_print_essid(u_int8_t *essid, u
 
 /* Caller checks len */
 void
+ieee80211_print_country(u_int8_t *data, u_int len)
+{
+   u_int8_t first_chan, nchan, maxpower;
+
+   if (len < 6)
+   return;
+
+   /* country string */
+   printf(" '%c%c%c'", data[0], data[1], data[2]);
+
+   len -= 3;
+   data += 3;
+
+   /* channels and corresponding TX power limits */
+   while (len > 0) {
+   if (len < 6)
+   break;
+   
+   /* ignore operating extension Id (values >= 201) for now */
+   if (data[3] >= 201 || data[4] >= 201)
+   continue;
+
+   first_chan = data[3];
+   nchan = data[4];
+   maxpower = data[5];
+
+   printf(", channel%s %d", nchan > 1 ? "s" : "", first_chan);
+   if (nchan > 1)
+   printf("-%d", first_chan + nchan - 1);
+   printf(" max TX power %ddB", maxpower);
+
+   len -= 6;
+   data += 6;
+   }
+}
+/* Caller checks len */
+void
 ieee80211_print_htcaps(u_int8_t *data, u_int len)
 {
u_int16_t htcaps;
@@ -392,8 +430,7 @@ ieee80211_elements(struct ieee80211_fram
break;
case IEEE80211_ELEMID_COUNTRY:
printf(", country");
-   for (i = len; i > 0; i--, data++)
-   printf(" %u", data[0]);
+   ieee80211_print_country(data, len);
break;
case IEEE80211_ELEMID_CHALLENGE:
printf(", challenge");
@@ -436,6 +473,9 @@ ieee80211_elements(struct ieee80211_fram
printf(", htcaps");
if (vflag)
ieee80211_print_htcaps(data, len);
+   break;
+   case IEEE80211_ELEMID_POWER_CONSTRAINT:
+   printf(", power constraint %udB", data[0]);
break;
case IEEE80211_ELEMID_VENDOR:
printf(", vendor");



tcpdump: show 802.11 bss load

2015-07-16 Thread Stefan Sperling
With this diff, if management frames contain information about the load
of the BSS, tcpdump displays it. Tested in the calgary hackroom:

  6 stations, 10% utilization, admission capacity 732us/s

Only so few people on 5GHz? ;)

The meaning of 'adminission capacity' is a bit cryptic.
It helps STAs select a good AP when roaming.

--- print-802_11.c.orig Fri Jul 17 00:27:24 2015
+++ print-802_11.c  Fri Jul 17 00:26:24 2015
@@ -470,6 +470,14 @@
case IEEE80211_ELEMID_POWER_CONSTRAINT:
printf(", power constraint %udB", data[0]);
break;
+   case IEEE80211_ELEMID_QBSS_LOAD:
+   ELEM_CHECK(5);
+   printf(", %u stations, %d%% utilization, "
+   "admission capacity %uus/s",
+   (data[0] | data[1] << 8),
+   (data[2] * 100) / 255,
+   (data[3] | data[4] << 8) / 32);
+   break;
case IEEE80211_ELEMID_VENDOR:
printf(", vendor");
if (vflag)



Re: Ask for password for failed commands

2015-07-16 Thread Ted Unangst
Vadim Zhukov wrote:
> Ask for a password when we're going to fail() anyway, to avoid
> leaking information about available commands. The sudo(8) behaves
> the same way, FWIW.

Let's say no for now. I'm not too concerned about this leak. I'm not sure what
a user would hope to discover. Hasn't the sysadmin told them what commands
they can run?

On the other hand, running more auth code seems riskier.



Re: words splitting in doas

2015-07-16 Thread Ted Unangst
Vadim Zhukov wrote:
> 2015-07-17 1:02 GMT+03:00 Ted Unangst :
> > Vadim Zhukov wrote:
> >> The manpage recommends using absolute paths for commands, but those
> >> won't work. :) This patch makes everything not in a list of special
> >> characters to be a part of word; this way you can easily put
> >> the following in doas.conf:
> >>
> >>   permit :somepeople cmd /usr/bin/mail viva+d...@openbsd.org
> >
> > I don't think this works even so, since there's no argv[1] checking.
> 
> R-r-r-right. But at least the "/usr/bin/mail" part will work now. And
> I do know where to steal arguments handling code...

ah, you know what, go ahead. ok.



Re: tcpdump: decode 802.11 country element

2015-07-16 Thread Vadim Zhukov
2015-07-17 1:04 GMT+03:00 Stefan Sperling :
> tcpdump currently prints country elements in 802.11 mgmt frames in hex:
>
>country 67 65 32 1 11 30,
>
> This diff makes tcpdump display the decoded form instead:
>
>country 'CA ', channels 1 2 3 4 5 6 7 8 9 10, max TX power 30dB
>
> Also show the power constraint which needs to be subtraced from
> max TX power to get the actual allowed TX power value.
>
> ok?
>
> Index: print-802_11.c
> ===
> RCS file: /cvs/src/usr.sbin/tcpdump/print-802_11.c,v
> retrieving revision 1.19
> diff -u -p -r1.19 print-802_11.c
> --- print-802_11.c  16 Jul 2015 20:57:13 -  1.19
> +++ print-802_11.c  16 Jul 2015 21:52:07 -
> @@ -78,6 +78,7 @@ intieee80211_hdr(struct ieee80211_fram
>  int ieee80211_data(struct ieee80211_frame *, u_int);
>  voidieee80211_print_element(u_int8_t *, u_int);
>  voidieee80211_print_essid(u_int8_t *, u_int);
> +voidieee80211_print_country(u_int8_t *, u_int);
>  voidieee80211_print_htcaps(u_int8_t *, u_int);
>  int ieee80211_elements(struct ieee80211_frame *, u_int);
>  int ieee80211_frame(struct ieee80211_frame *, u_int);
> @@ -233,6 +234,36 @@ ieee80211_print_essid(u_int8_t *essid, u
>
>  /* Caller checks len */
>  void
> +ieee80211_print_country(u_int8_t *data, u_int len)
> +{
> +   u_int8_t first_chan, nchan, maxpower;
> +   int i;
> +
> +   while (len > 0) {
> +   if (len < 6)
> +   break;
> +
> +   /* ignore operating extension Id (values >= 201) */
> +   if (data[3] >= 201 || data[4] >= 201)
> +   continue;
> +
> +   /* country string */
> +   printf(" '%c%c%c'", data[0], data[1], data[2]);
> +
> +   first_chan = data[3];
> +   nchan = data[4];
> +   maxpower = data[5];
> +
> +   printf(", channels %d", first_chan);
> +   for (i = first_chan + 1; i < nchan; i++)
> +   printf(" %i", i);

It looks like you simply enumerate from first_chan till nchan; why not
to just print "channels %d-%d" then? Also, with this for loop, in case
of invalid data (nchan < first_chan) you won't have any data printed
at all.

> +   printf(", max TX power %ddB", maxpower);
> +
> +   len -= 6;
> +   }
> +}
> +/* Caller checks len */
> +void
>  ieee80211_print_htcaps(u_int8_t *data, u_int len)
>  {
> u_int16_t htcaps;
> @@ -392,8 +423,7 @@ ieee80211_elements(struct ieee80211_fram
> break;
> case IEEE80211_ELEMID_COUNTRY:
> printf(", country");
> -   for (i = len; i > 0; i--, data++)
> -   printf(" %u", data[0]);
> +   ieee80211_print_country(data, len);
> break;
> case IEEE80211_ELEMID_CHALLENGE:
> printf(", challenge");
> @@ -436,6 +466,9 @@ ieee80211_elements(struct ieee80211_fram
> printf(", htcaps");
> if (vflag)
> ieee80211_print_htcaps(data, len);
> +   break;
> +   case IEEE80211_ELEMID_POWER_CONSTRAINT:
> +   printf(", power constraint %udB", data[0]);
> break;
> case IEEE80211_ELEMID_VENDOR:
> printf(", vendor");
>

--
  WBR,
  Vadim Zhukov



Re: Bump LIBRESSL_VERSION defines

2015-07-16 Thread Bob Beck
ok beck@

after much discusison :)

On Thu, Jul 16, 2015 at 4:08 PM, Brent Cook  wrote:
> Up to now, we have only bumped the LIBRESSL_VERSION_TEXT for each
> portable release in the portable tree, and the VERSION_NUMBER has never
> incremented.
>
> This change establishes a policy of bumping the number for each portable
> release, and syncs the version string between the portable and in-tree
> releases. This is the simplest way to allow software not using
> auto-configuration mechanisms to determine what LibreSSL version is in
> use without breaking backward compatibility.
>
> Index: src/crypto/opensslv.h
> ===
> RCS file: /cvs/src/lib/libssl/src/crypto/opensslv.h,v
> retrieving revision 1.29
> diff -u -p -u -p -r1.29 opensslv.h
> --- src/crypto/opensslv.h   23 May 2015 21:09:46 -  1.29
> +++ src/crypto/opensslv.h   16 Jul 2015 22:00:18 -
> @@ -2,9 +2,13 @@
>  #ifndef HEADER_OPENSSLV_H
>  #define HEADER_OPENSSLV_H
>
> -#define LIBRESSL_VERSION_NUMBER0x2000L
> +/* These will change with each release of LibreSSL-portable */
> +#define LIBRESSL_VERSION_NUMBER0x20020002L
> +#define LIBRESSL_VERSION_TEXT  "LibreSSL 2.2.2"
> +
> +/* These will never change */
>  #define OPENSSL_VERSION_NUMBER 0x2000L
> -#define OPENSSL_VERSION_TEXT   "LibreSSL 2.2"
> +#define OPENSSL_VERSION_TEXT   LIBRESSL_VERSION_TEXT
>  #define OPENSSL_VERSION_PTEXT  " part of " OPENSSL_VERSION_TEXT
>
>  #define SHLIB_VERSION_HISTORY ""
>



Re: words splitting in doas

2015-07-16 Thread Ted Unangst
Vadim Zhukov wrote:
> 2015-07-17 1:02 GMT+03:00 Ted Unangst :
> > Vadim Zhukov wrote:
> >> The manpage recommends using absolute paths for commands, but those
> >> won't work. :) This patch makes everything not in a list of special
> >> characters to be a part of word; this way you can easily put
> >> the following in doas.conf:
> >>
> >>   permit :somepeople cmd /usr/bin/mail viva+d...@openbsd.org
> >
> > I don't think this works even so, since there's no argv[1] checking.
> 
> R-r-r-right. But at least the "/usr/bin/mail" part will work now. And
> I do know where to steal arguments handling code...

So what I'm asking is whether we need to add '/' to the allowed set instead,
or as the diff does, and make everything ok except for a few exceptions.

I think it can be weird to parse usernames like "tedu/+banana+" etc.



Re: Ask for password for failed commands

2015-07-16 Thread Ted Unangst
Vadim Zhukov wrote:
> Ask for a password when we're going to fail() anyway, to avoid
> leaking information about available commands. The sudo(8) behaves
> the same way, FWIW.
> 
> okay?

i need to think about this for a bit. there's a strange interaction where if
the nopasswd option is used, you've now created the opposite problem. maybe.

also, we may want to create a fake password prompt without running through all
the user auth machinery, but it gets harder then because you have to run
bcrypt the right number of times, etc., etc.

so maybe ok, but not right away?



Re: words splitting in doas

2015-07-16 Thread Vadim Zhukov
2015-07-17 1:02 GMT+03:00 Ted Unangst :
> Vadim Zhukov wrote:
>> The manpage recommends using absolute paths for commands, but those
>> won't work. :) This patch makes everything not in a list of special
>> characters to be a part of word; this way you can easily put
>> the following in doas.conf:
>>
>>   permit :somepeople cmd /usr/bin/mail viva+d...@openbsd.org
>
> I don't think this works even so, since there's no argv[1] checking.

R-r-r-right. But at least the "/usr/bin/mail" part will work now. And
I do know where to steal arguments handling code...

>> The next step will be quotes support, I think?
>>
>> --
>> WBR,
>>   Vadim Zhukov
>>
>>
>> Index: parse.y
>> ===
>> RCS file: /cvs/src/usr.bin/doas/parse.y,v
>> retrieving revision 1.1
>> diff -u -p -r1.1 parse.y
>> --- parse.y   16 Jul 2015 20:44:21 -  1.1
>> +++ parse.y   16 Jul 2015 21:52:46 -
>> @@ -183,19 +183,24 @@ yylex(void)
>>   return c;
>>   case EOF:
>>   return 0;
>> - case ':':
>> - *p++ = c;
>> - c = getc(yyfp);
>> - break;
>> - default:
>> - break;
>>   }
>> - while (isalnum(c)) {
>> + while (1) {
>> + switch (c) {
>> + case '\n':
>> + case '{':
>> + case '}':
>> + case '#':
>> + case ' ':
>> + case '\t':
>> + case EOF:
>> + goto eow;
>> + }
>>   *p++ = c;
>>   if (p == ebuf)
>>   yyerror("too much stuff");
>>   c = getc(yyfp);
>>   }
>> +eow:
>>   *p = 0;
>>   if (c != EOF)
>>   ungetc(c, yyfp);
>>

--
  WBR,
  Vadim Zhukov



Bump LIBRESSL_VERSION defines

2015-07-16 Thread Brent Cook
Up to now, we have only bumped the LIBRESSL_VERSION_TEXT for each
portable release in the portable tree, and the VERSION_NUMBER has never
incremented.

This change establishes a policy of bumping the number for each portable
release, and syncs the version string between the portable and in-tree
releases. This is the simplest way to allow software not using
auto-configuration mechanisms to determine what LibreSSL version is in
use without breaking backward compatibility.

Index: src/crypto/opensslv.h
===
RCS file: /cvs/src/lib/libssl/src/crypto/opensslv.h,v
retrieving revision 1.29
diff -u -p -u -p -r1.29 opensslv.h
--- src/crypto/opensslv.h   23 May 2015 21:09:46 -  1.29
+++ src/crypto/opensslv.h   16 Jul 2015 22:00:18 -
@@ -2,9 +2,13 @@
 #ifndef HEADER_OPENSSLV_H
 #define HEADER_OPENSSLV_H

-#define LIBRESSL_VERSION_NUMBER0x2000L
+/* These will change with each release of LibreSSL-portable */
+#define LIBRESSL_VERSION_NUMBER0x20020002L
+#define LIBRESSL_VERSION_TEXT  "LibreSSL 2.2.2"
+
+/* These will never change */
 #define OPENSSL_VERSION_NUMBER 0x2000L
-#define OPENSSL_VERSION_TEXT   "LibreSSL 2.2"
+#define OPENSSL_VERSION_TEXT   LIBRESSL_VERSION_TEXT
 #define OPENSSL_VERSION_PTEXT  " part of " OPENSSL_VERSION_TEXT

 #define SHLIB_VERSION_HISTORY ""



Ask for password for failed commands

2015-07-16 Thread Vadim Zhukov
Ask for a password when we're going to fail() anyway, to avoid
leaking information about available commands. The sudo(8) behaves
the same way, FWIW.

okay?

--
WBR,
  Vadim Zhukov


Index: doas.c
===
RCS file: /cvs/src/usr.bin/doas/doas.c,v
retrieving revision 1.2
diff -u -p -r1.2 doas.c
--- doas.c  16 Jul 2015 21:00:59 -  1.2
+++ doas.c  16 Jul 2015 22:05:44 -
@@ -249,7 +249,7 @@ main(int argc, char **argv, char **envp)
char myname[32];
uid_t uid, target = 0;
gid_t groups[NGROUPS_MAX + 1];
-   int ngroups;
+   int ngroups, permitted;
struct passwd *pw;
struct rule *rule;
const char *cmd;
@@ -292,17 +292,17 @@ main(int argc, char **argv, char **envp)
err(1, "can't get groups");
groups[ngroups++] = getgid();
 
-   if (!permit(uid, groups, ngroups, &rule, target, cmd)) {
+   permitted = permit(uid, groups, ngroups, &rule, target, cmd);
+   if (!permitted)
syslog(LOG_AUTHPRIV | LOG_NOTICE, "failed command for %s: %s", 
myname, cmdline);
-   fail();
-   }
-
-   if (!(rule->options & NOPASS)) {
+   if (!permitted || !(rule->options & NOPASS)) {
if (!auth_userokay(myname, NULL, NULL, NULL)) {
syslog(LOG_AUTHPRIV | LOG_NOTICE, "failed password for 
%s", myname);
fail();
}
}
+   if (!permitted)
+   fail();
envp = copyenv((const char **)envp, rule);
 
pw = getpwuid(target);



tcpdump: decode 802.11 country element

2015-07-16 Thread Stefan Sperling
tcpdump currently prints country elements in 802.11 mgmt frames in hex:

   country 67 65 32 1 11 30,

This diff makes tcpdump display the decoded form instead:

   country 'CA ', channels 1 2 3 4 5 6 7 8 9 10, max TX power 30dB

Also show the power constraint which needs to be subtraced from
max TX power to get the actual allowed TX power value.

ok?

Index: print-802_11.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/print-802_11.c,v
retrieving revision 1.19
diff -u -p -r1.19 print-802_11.c
--- print-802_11.c  16 Jul 2015 20:57:13 -  1.19
+++ print-802_11.c  16 Jul 2015 21:52:07 -
@@ -78,6 +78,7 @@ intieee80211_hdr(struct ieee80211_fram
 int ieee80211_data(struct ieee80211_frame *, u_int);
 voidieee80211_print_element(u_int8_t *, u_int);
 voidieee80211_print_essid(u_int8_t *, u_int);
+voidieee80211_print_country(u_int8_t *, u_int);
 voidieee80211_print_htcaps(u_int8_t *, u_int);
 int ieee80211_elements(struct ieee80211_frame *, u_int);
 int ieee80211_frame(struct ieee80211_frame *, u_int);
@@ -233,6 +234,36 @@ ieee80211_print_essid(u_int8_t *essid, u
 
 /* Caller checks len */
 void
+ieee80211_print_country(u_int8_t *data, u_int len)
+{
+   u_int8_t first_chan, nchan, maxpower;
+   int i;
+
+   while (len > 0) {
+   if (len < 6)
+   break;
+
+   /* ignore operating extension Id (values >= 201) */
+   if (data[3] >= 201 || data[4] >= 201)
+   continue;
+
+   /* country string */
+   printf(" '%c%c%c'", data[0], data[1], data[2]);
+
+   first_chan = data[3];
+   nchan = data[4];
+   maxpower = data[5];
+
+   printf(", channels %d", first_chan);
+   for (i = first_chan + 1; i < nchan; i++)
+   printf(" %i", i);
+   printf(", max TX power %ddB", maxpower);
+
+   len -= 6;
+   }
+}
+/* Caller checks len */
+void
 ieee80211_print_htcaps(u_int8_t *data, u_int len)
 {
u_int16_t htcaps;
@@ -392,8 +423,7 @@ ieee80211_elements(struct ieee80211_fram
break;
case IEEE80211_ELEMID_COUNTRY:
printf(", country");
-   for (i = len; i > 0; i--, data++)
-   printf(" %u", data[0]);
+   ieee80211_print_country(data, len);
break;
case IEEE80211_ELEMID_CHALLENGE:
printf(", challenge");
@@ -436,6 +466,9 @@ ieee80211_elements(struct ieee80211_fram
printf(", htcaps");
if (vflag)
ieee80211_print_htcaps(data, len);
+   break;
+   case IEEE80211_ELEMID_POWER_CONSTRAINT:
+   printf(", power constraint %udB", data[0]);
break;
case IEEE80211_ELEMID_VENDOR:
printf(", vendor");



Re: words splitting in doas

2015-07-16 Thread Ted Unangst
Vadim Zhukov wrote:
> The manpage recommends using absolute paths for commands, but those
> won't work. :) This patch makes everything not in a list of special
> characters to be a part of word; this way you can easily put
> the following in doas.conf:
> 
>   permit :somepeople cmd /usr/bin/mail viva+d...@openbsd.org

I don't think this works even so, since there's no argv[1] checking.

> 
> The next step will be quotes support, I think?
> 
> --
> WBR,
>   Vadim Zhukov
> 
> 
> Index: parse.y
> ===
> RCS file: /cvs/src/usr.bin/doas/parse.y,v
> retrieving revision 1.1
> diff -u -p -r1.1 parse.y
> --- parse.y   16 Jul 2015 20:44:21 -  1.1
> +++ parse.y   16 Jul 2015 21:52:46 -
> @@ -183,19 +183,24 @@ yylex(void)
>   return c;
>   case EOF:
>   return 0;
> - case ':':
> - *p++ = c;
> - c = getc(yyfp);
> - break;
> - default:
> - break;
>   }
> - while (isalnum(c)) {
> + while (1) {
> + switch (c) {
> + case '\n':
> + case '{':
> + case '}':
> + case '#':
> + case ' ':
> + case '\t':
> + case EOF:
> + goto eow;
> + }
>   *p++ = c;
>   if (p == ebuf)
>   yyerror("too much stuff");
>   c = getc(yyfp);
>   }
> +eow:
>   *p = 0;
>   if (c != EOF)
>   ungetc(c, yyfp);
> 



words splitting in doas

2015-07-16 Thread Vadim Zhukov
The manpage recommends using absolute paths for commands, but those
won't work. :) This patch makes everything not in a list of special
characters to be a part of word; this way you can easily put
the following in doas.conf:

  permit :somepeople cmd /usr/bin/mail viva+d...@openbsd.org

The next step will be quotes support, I think?

--
WBR,
  Vadim Zhukov


Index: parse.y
===
RCS file: /cvs/src/usr.bin/doas/parse.y,v
retrieving revision 1.1
diff -u -p -r1.1 parse.y
--- parse.y 16 Jul 2015 20:44:21 -  1.1
+++ parse.y 16 Jul 2015 21:52:46 -
@@ -183,19 +183,24 @@ yylex(void)
return c;
case EOF:
return 0;
-   case ':':
-   *p++ = c;
-   c = getc(yyfp);
-   break;
-   default:
-   break;
}
-   while (isalnum(c)) {
+   while (1) {
+   switch (c) {
+   case '\n':
+   case '{':
+   case '}':
+   case '#':
+   case ' ':
+   case '\t':
+   case EOF:
+   goto eow;
+   }
*p++ = c;
if (p == ebuf)
yyerror("too much stuff");
c = getc(yyfp);
}
+eow:
*p = 0;
if (c != EOF)
ungetc(c, yyfp);



Re: Xen still failing with recent v1.41 vector.S

2015-07-16 Thread Mike Belopuhov
On 16 July 2015 at 19:42, Joel  wrote:
> Hello,
>
> I was excited to see Xen mentioned in a recent commit log.
> Unfortunately, there are still some issues when going multiprocessor.
>
> The dom0 machine was an Ubuntu server running 10.04.2 with a Xen version
> of 4.4.1 (refer to file xen.info).
>
> The original (mp.57) tests were using a base 5.7 system.  To test the
> latest changes, I did a cvs up yesterday (mp.current).  I confirmed the
> vector.S file was updated and compiled a GENERIC.MP kernel from there.
>
> I was able to capture 1 cpu and 4 cpu versions of each boot, but I was
> unable to capture any xl dmesg output.
>
> Attached are the captures.
>
> --Joel
>

Joel, as I've told you before you should use a snapshot:
ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/
We simply cannot support users with custom OpenBSD
kernels esp. made out of current and stable.  Please
use a clean 5.8-beta installation.

I have also asked you for the VM configuration as in
OpenBSD VM configuration file.  I'm not sure how this
xen.info file is supposed to help us.

Make sure that you've got your console configured as a
serial device and you're capturing all of the output.

Regards,
Mike



Re: Rational behind split struct in uvideo.h

2015-07-16 Thread ludovic coues
2015-07-16 21:45 GMT+02:00 Martin Pieuchot :
> On 16/07/15(Thu) 16:24, ludovic coues wrote:
>> But I don't know why this code is done this way. As it haven't been
>> touched since version 1.4 in 2008, I assume it's an old way of doing
>> things or a short term solution. If that the case, I'll go ahead and
>> change it.
>> Other possibility I think of is compiler on some architecture who
>> don't like struct ending with array of arbitrary size or that the
>> preferred way of doing things.
>
> Well you have a counter-example in the same file
> "struct usb_video_vc_processing_desc"
>
> M
>

struct usb_video_vc_processing_desc is a structure with an array of
fixed size. I want to introduce a structure with an array of arbitrary
size as last field.
I've been told that the compiler used ~ 8 years ago on half platforms
wouldn't have accepted that. Now, it should only cause problem on vax
and that platform don't have USB.

I'm working on the patch.

-- 

Cordialement, Coues Ludovic
+336 148 743 42



Re: Rational behind split struct in uvideo.h

2015-07-16 Thread Martin Pieuchot
On 16/07/15(Thu) 16:24, ludovic coues wrote:
> I am looking for some insight about some choice in the code.
> 
> In the file /sys/dev/usb/uvideo.h, the structure usb_video_header_desc
> store a part of an USB descriptor. The entire descriptor is stored in
> usb_video_header_desc_all which consist of fix, a pointer to the
> former struct and baInterfaceNR, a pointer to uByte.
> 
> I'm willing to replace that construction by merging the two struct.
> The field fix would disappear and baInterfaceNR would be array of size
> 1 at the end of the struct.

Please send a diff that implements that.  If uvideo(4) works with it and
that makes the header closer to the specification I don't see a reason
not to integrate it.

> But I don't know why this code is done this way. As it haven't been
> touched since version 1.4 in 2008, I assume it's an old way of doing
> things or a short term solution. If that the case, I'll go ahead and
> change it.
> Other possibility I think of is compiler on some architecture who
> don't like struct ending with array of arbitrary size or that the
> preferred way of doing things.

Well you have a counter-example in the same file
"struct usb_video_vc_processing_desc"

M



Re: tcpdump 11n HT capabilities

2015-07-16 Thread Vadim Zhukov
2015-07-16 22:05 GMT+03:00 Stefan Sperling :
> Make tcpdump show 11n HT capabilities.
>
> OK?
>
> Index: print-802_11.c
> ===
> RCS file: /cvs/src/usr.sbin/tcpdump/print-802_11.c,v
> retrieving revision 1.18
> diff -u -p -r1.18 print-802_11.c
> --- print-802_11.c  15 Jul 2015 03:05:00 -  1.18
> +++ print-802_11.c  16 Jul 2015 19:02:12 -
> @@ -78,6 +78,7 @@ intieee80211_hdr(struct ieee80211_fram
>  int ieee80211_data(struct ieee80211_frame *, u_int);
>  voidieee80211_print_element(u_int8_t *, u_int);
>  voidieee80211_print_essid(u_int8_t *, u_int);
> +voidieee80211_print_htcaps(u_int8_t *, u_int);
>  int ieee80211_elements(struct ieee80211_frame *, u_int);
>  int ieee80211_frame(struct ieee80211_frame *, u_int);
>  int ieee80211_print(struct ieee80211_frame *, u_int);
> @@ -230,6 +231,82 @@ ieee80211_print_essid(u_int8_t *essid, u
> ieee80211_print_element(essid, len);
>  }
>
> +/* Caller checks len */
> +void
> +ieee80211_print_htcaps(u_int8_t *data, u_int len)
> +{
> +   u_int16_t htcaps;
> +   int smps, rxstbc;
> +
> +   if (len < 2) {
> +   ieee80211_print_element(data, len);
> +   return;
> +   }
> +
> +   htcaps = (data[0]) | (data[1] << 8);
> +   printf("=<");
> +
> +   /* channel width */
> +   if (htcaps & IEEE80211_HTCAP_CBW20_40)
> +   printf("20/40MHz");
> +   else
> +   printf("20MHz");
> +
> +   /* LDPC coding */
> +   if (htcaps & IEEE80211_HTCAP_LDPC)
> +   printf(",LDPC");
> +
> +   /* spacial mulitplexing power save mode */
> +   smps = (htcaps & IEEE80211_HTCAP_SMPS_MASK)
> +   >> IEEE80211_HTCAP_SMPS_SHIFT;
> +   if (smps == 0)
> +   printf(",SMPS static");
> +   else if (smps == 1)
> +   printf(",SMPS dynamic");
> +
> +   /* 11n greenfield mode */
> +   if (htcaps & IEEE80211_HTCAP_GF)
> +   printf(",greenfield");
> +
> +   /* short guard interval */
> +   if (htcaps & IEEE80211_HTCAP_SGI20)
> +   printf(",SGI@20MHz");
> +   if (htcaps & IEEE80211_HTCAP_SGI40)
> +   printf(",SGI@40MHz");
> +
> +   /* space-time block coding */
> +   if (htcaps & IEEE80211_HTCAP_TXSTBC)
> +   printf(",TXSTBC");
> +   rxstbc = (htcaps & IEEE80211_HTCAP_RXSTBC_MASK)
> +   >> IEEE80211_HTCAP_RXSTBC_SHIFT;
> +   if (rxstbc > 0 && rxstbc < 4)
> +   printf(",RXSTBC %d stream", rxstbc);
> +
> +   /* delayed block-ack */
> +   if (htcaps & IEEE80211_HTCAP_DELAYEDBA)
> +   printf(",delayed BA");
> +
> +   /* max A-MSDU length */
> +   if (htcaps & IEEE80211_HTCAP_AMSDU7935)
> +   printf(",A-MSDU 7935");
> +   else
> +   printf(",A-MSDU 3839");
> +
> +   /* DSSS/CCK in 40MHz mode */
> +   if (htcaps & IEEE80211_HTCAP_DSSSCCK40)
> +   printf(",DSSS/CCK@40MHz");
> +
> +   /* 40MHz intolerant */
> +   if (htcaps & IEEE80211_HTCAP_40INTOLERANT)
> +   printf(",40MHz intolerant");
> +
> +   /* L-SIG TXOP protection */
> +   if (htcaps & IEEE80211_HTCAP_LSIGTXOPPROT)
> +   printf(",L-SIG TXOP prot");
> +
> +   printf(">");
> +}
> +
>  int
>  ieee80211_elements(struct ieee80211_frame *wh, u_int flen)
>  {
> @@ -354,6 +431,11 @@ ieee80211_elements(struct ieee80211_fram
> printf(", tpcrequest");
> if (vflag)
> ieee80211_print_element(data, len);
> +   break;
> +   case IEEE80211_ELEMID_HTCAPS:
> +   printf(", htcaps");
> +   if (vflag)
> +   ieee80211_print_htcaps(data, len);
> break;
> case IEEE80211_ELEMID_VENDOR:
> printf(", vendor");


Works for me:

22:36:15.013854 802.11 flags=0<>: beacon, timestamp 611060224384,
interval 100, caps=2061,
ssid (Net), rates 1M 2M 5M 11M 6M 9M 12M 18M, ds (chan 4), tim
0x00010010, erp 0x00, htcaps=<20/40MHz,SGI@20MHz,SGI@40MHz,A-MSDU
3839,DSSS/CCK@40MHz>, rsn
0x010fac04020fac04000fac02010fac02000f, xrates 24M 36M 48M
54M, 

okay zhuk@
--
  WBR,
  Vadim Zhukov



tcpdump 11n HT capabilities

2015-07-16 Thread Stefan Sperling
Make tcpdump show 11n HT capabilities.

OK?

Index: print-802_11.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/print-802_11.c,v
retrieving revision 1.18
diff -u -p -r1.18 print-802_11.c
--- print-802_11.c  15 Jul 2015 03:05:00 -  1.18
+++ print-802_11.c  16 Jul 2015 19:02:12 -
@@ -78,6 +78,7 @@ intieee80211_hdr(struct ieee80211_fram
 int ieee80211_data(struct ieee80211_frame *, u_int);
 voidieee80211_print_element(u_int8_t *, u_int);
 voidieee80211_print_essid(u_int8_t *, u_int);
+voidieee80211_print_htcaps(u_int8_t *, u_int);
 int ieee80211_elements(struct ieee80211_frame *, u_int);
 int ieee80211_frame(struct ieee80211_frame *, u_int);
 int ieee80211_print(struct ieee80211_frame *, u_int);
@@ -230,6 +231,82 @@ ieee80211_print_essid(u_int8_t *essid, u
ieee80211_print_element(essid, len);
 }
 
+/* Caller checks len */
+void
+ieee80211_print_htcaps(u_int8_t *data, u_int len)
+{
+   u_int16_t htcaps;
+   int smps, rxstbc;
+
+   if (len < 2) {
+   ieee80211_print_element(data, len);
+   return;
+   }
+
+   htcaps = (data[0]) | (data[1] << 8);
+   printf("=<");
+
+   /* channel width */
+   if (htcaps & IEEE80211_HTCAP_CBW20_40)
+   printf("20/40MHz");
+   else
+   printf("20MHz");
+
+   /* LDPC coding */
+   if (htcaps & IEEE80211_HTCAP_LDPC)
+   printf(",LDPC");
+
+   /* spacial mulitplexing power save mode */
+   smps = (htcaps & IEEE80211_HTCAP_SMPS_MASK)
+   >> IEEE80211_HTCAP_SMPS_SHIFT;
+   if (smps == 0)
+   printf(",SMPS static");
+   else if (smps == 1)
+   printf(",SMPS dynamic");
+
+   /* 11n greenfield mode */
+   if (htcaps & IEEE80211_HTCAP_GF)
+   printf(",greenfield");
+
+   /* short guard interval */
+   if (htcaps & IEEE80211_HTCAP_SGI20)
+   printf(",SGI@20MHz");
+   if (htcaps & IEEE80211_HTCAP_SGI40)
+   printf(",SGI@40MHz");
+
+   /* space-time block coding */
+   if (htcaps & IEEE80211_HTCAP_TXSTBC)
+   printf(",TXSTBC");
+   rxstbc = (htcaps & IEEE80211_HTCAP_RXSTBC_MASK)
+   >> IEEE80211_HTCAP_RXSTBC_SHIFT;
+   if (rxstbc > 0 && rxstbc < 4)
+   printf(",RXSTBC %d stream", rxstbc);
+
+   /* delayed block-ack */
+   if (htcaps & IEEE80211_HTCAP_DELAYEDBA)
+   printf(",delayed BA");
+
+   /* max A-MSDU length */
+   if (htcaps & IEEE80211_HTCAP_AMSDU7935)
+   printf(",A-MSDU 7935");
+   else
+   printf(",A-MSDU 3839");
+
+   /* DSSS/CCK in 40MHz mode */
+   if (htcaps & IEEE80211_HTCAP_DSSSCCK40)
+   printf(",DSSS/CCK@40MHz");
+
+   /* 40MHz intolerant */
+   if (htcaps & IEEE80211_HTCAP_40INTOLERANT)
+   printf(",40MHz intolerant");
+
+   /* L-SIG TXOP protection */
+   if (htcaps & IEEE80211_HTCAP_LSIGTXOPPROT)
+   printf(",L-SIG TXOP prot");
+
+   printf(">");
+}
+
 int
 ieee80211_elements(struct ieee80211_frame *wh, u_int flen)
 {
@@ -354,6 +431,11 @@ ieee80211_elements(struct ieee80211_fram
printf(", tpcrequest");
if (vflag)
ieee80211_print_element(data, len);
+   break;
+   case IEEE80211_ELEMID_HTCAPS:
+   printf(", htcaps");
+   if (vflag)
+   ieee80211_print_htcaps(data, len);
break;
case IEEE80211_ELEMID_VENDOR:
printf(", vendor");



Xen still failing with recent v1.41 vector.S

2015-07-16 Thread Joel
Hello,

I was excited to see Xen mentioned in a recent commit log.
Unfortunately, there are still some issues when going multiprocessor.

The dom0 machine was an Ubuntu server running 10.04.2 with a Xen version
of 4.4.1 (refer to file xen.info).

The original (mp.57) tests were using a base 5.7 system.  To test the
latest changes, I did a cvs up yesterday (mp.current).  I confirmed the
vector.S file was updated and compiled a GENERIC.MP kernel from there.

I was able to capture 1 cpu and 4 cpu versions of each boot, but I was
unable to capture any xl dmesg output.

Attached are the captures.

--Joel



xen.info
Description: application/info


openbsd.mp.57.1vcpu
Description: Binary data


openbsd.mp.57.4vcpu
Description: Binary data


openbsd.mp.current.1vcpu
Description: Binary data


openbsd.mp.current.4vcpu
Description: Binary data


nsd update

2015-07-16 Thread Stuart Henderson
Highlights: reallocarray, various fixes for zone file parsing. I haven't
added the compat file for reallocarray as we don't need it (we can remove
most other compat files but that's not part of this diff).

Comments, OK?


NSD 4.1.3:

Features

nsd-control addzones and delzones read list of zones from stdin.
hmac sha224, sha384 and sha512 support, patch from David Gwynne.
max-interfaces raised to 32.

Bugfixes

Fix #665: when removing subdomain, nsd does not reparse parent zone.
Fix task and zonestat files to be stored in a subdirectory in tmp to stop 
privilege elevation.
Fix crash in zone parser for relative dname after error in origin.
Fix that formerrors are ratelimited.

NSD 4.1.2:

Features

Incoming notifies have serial number logged (at verbosity 1).

Bugfixes

Remove some duplicate header includes (from Brad Smith).
Fix tcp waiting list for zone transfers where the bind and connect calls 
fail.
Fix segfault in zone reader on invalid input. (thanks John Van de 
Meulebrouck Brendgard)
Fix segfault on double origin in zone reader (thanks John Van de 
Meulebrouck Brendgard).
Fix b64pton out of bounds error on invalid zonefile input. (thanks John Van 
de Meulebrouck Brendgard)
Fix origin directive from unused old value and subdomain parser failure, 
reported by John Van de Meulebrouck Brendgard.
Fix use after free after zonefile syntax error followed by ttl or origin 
directive, reported by John Van de Meulebrouck Brendgard.
Fix syntax error followed by too many TXT elements parse crash reported by 
John Van de Meulebrouck Brendgard.
Fix buffer overflow in config parse of domain name, reported by John Van de 
Meulebrouck Brendgard.
Use reallocarray for integer overflow protection, patch submitted by 
Loganaden Velvindron.
Fix allocation integer overflow checks.
Fix #654: Fix contradiction in notify logging verbosity level.
Fix #655: Fix contradiction in verbosity for zone transfers.
Made log message more consistent, changed 'axfr refused' log message to be 
more consistent with other messages. Also notify refused.
verbosity 2 logs axfr refused and notify refused. verbosity 1 contains less 
log messages.


Index: Makefile.in
===
RCS file: /cvs/src/usr.sbin/nsd/Makefile.in,v
retrieving revision 1.16
diff -u -p -r1.16 Makefile.in
--- Makefile.in 16 Sep 2014 17:01:38 -  1.16
+++ Makefile.in 16 Jul 2015 16:34:43 -
@@ -228,6 +228,9 @@ malloc.o:   $(srcdir)/compat/malloc.c
 pselect.o: $(srcdir)/compat/pselect.c
$(COMPILE) -c $(srcdir)/compat/pselect.c
 
+reallocarray.o:$(srcdir)/compat/reallocarray.c
+   $(COMPILE) -c $(srcdir)/compat/reallocarray.c
+
 fake-rfc2553.o:$(srcdir)/compat/fake-rfc2553.c
$(COMPILE) -c $(srcdir)/compat/fake-rfc2553.c
 
@@ -373,7 +376,7 @@ namedb.o: $(srcdir)/namedb.c config.h $(
  $(srcdir)/util.h $(srcdir)/dns.h $(srcdir)/radtree.h $(srcdir)/rbtree.h 
$(srcdir)/nsec3.h
 netio.o: $(srcdir)/netio.c config.h $(srcdir)/netio.h 
$(srcdir)/region-allocator.h $(srcdir)/util.h
 nsd.o: $(srcdir)/nsd.c config.h $(srcdir)/nsd.h $(srcdir)/dns.h 
$(srcdir)/edns.h $(srcdir)/buffer.h $(srcdir)/region-allocator.h \
- $(srcdir)/util.h $(srcdir)/options.h $(srcdir)/rbtree.h $(srcdir)/tsig.h 
$(srcdir)/dname.h $(srcdir)/remote.h
+ $(srcdir)/util.h $(srcdir)/options.h $(srcdir)/rbtree.h $(srcdir)/tsig.h 
$(srcdir)/dname.h $(srcdir)/remote.h $(srcdir)/xfrd-disk.h
 nsd-checkconf.o: $(srcdir)/nsd-checkconf.c config.h $(srcdir)/tsig.h 
$(srcdir)/buffer.h \
  $(srcdir)/region-allocator.h $(srcdir)/util.h $(srcdir)/dname.h 
$(srcdir)/options.h $(srcdir)/rbtree.h $(srcdir)/rrl.h $(srcdir)/query.h \
  $(srcdir)/namedb.h $(srcdir)/dns.h $(srcdir)/radtree.h $(srcdir)/nsd.h 
$(srcdir)/edns.h $(srcdir)/packet.h
@@ -456,6 +459,7 @@ malloc.o: $(srcdir)/compat/malloc.c
 memcmp.o: $(srcdir)/compat/memcmp.c config.h
 memmove.o: $(srcdir)/compat/memmove.c config.h
 pselect.o: $(srcdir)/compat/pselect.c config.h
+reallocarray.o: $(srcdir)/compat/reallocarray.c config.h
 snprintf.o: $(srcdir)/compat/snprintf.c config.h
 strlcat.o: $(srcdir)/compat/strlcat.c config.h
 strlcpy.o: $(srcdir)/compat/strlcpy.c config.h
Index: acx_nlnetlabs.m4
===
RCS file: /cvs/src/usr.sbin/nsd/acx_nlnetlabs.m4,v
retrieving revision 1.1.1.8
diff -u -p -r1.1.1.8 acx_nlnetlabs.m4
--- acx_nlnetlabs.m426 Nov 2013 12:50:23 -  1.1.1.8
+++ acx_nlnetlabs.m416 Jul 2015 16:34:43 -
@@ -2,7 +2,8 @@
 # Copyright 2009, Wouter Wijngaards, NLnet Labs.   
 # BSD licensed.
 #
-# Version 26
+# Version 27
+# 2015-03-17 AHX_CONFIG_REALLOCARRAY added
 # 2013-09-19 FLTO help text improved.
 # 2013-07-18 Enable ACX_CHECK_COMPILER_FLAG to test for -Wstrict-prototypes
 # 2013-06-25 FLTO has --disable-flto option.
@@ -1210,6 +1211,16 @@ AC_DEFUN([AHX_CONFIG_GMTIME_R],
 #ifndef HAVE_G

Rational behind split struct in uvideo.h

2015-07-16 Thread ludovic coues
I am looking for some insight about some choice in the code.

In the file /sys/dev/usb/uvideo.h, the structure usb_video_header_desc
store a part of an USB descriptor. The entire descriptor is stored in
usb_video_header_desc_all which consist of fix, a pointer to the
former struct and baInterfaceNR, a pointer to uByte.

I'm willing to replace that construction by merging the two struct.
The field fix would disappear and baInterfaceNR would be array of size
1 at the end of the struct.

But I don't know why this code is done this way. As it haven't been
touched since version 1.4 in 2008, I assume it's an old way of doing
things or a short term solution. If that the case, I'll go ahead and
change it.
Other possibility I think of is compiler on some architecture who
don't like struct ending with array of arbitrary size or that the
preferred way of doing things.


-- 

Cordialement, Coues Ludovic
+336 148 743 42



Re: sndiod hangs

2015-07-16 Thread Alexandre Ratchov
On Mon, Jul 13, 2015 at 12:52:14PM +0200, Alexandre Ratchov wrote:
> On Sat, Jul 11, 2015 at 02:23:03PM +0200, Mark Kettenis wrote:
> > Every now and then sndiod hangs on me.  Usually I discover this as
> > mplayer hangs while playing a video or hangs while opening the audio
> > device on startup.  Restarting sndiod using the /etc/rc.d/sndiod
> > script doesn't work; it blocks trying to stop the running sndiod.  I
> > have to use kill -9 to get rid of it.
> > 
> > Happened again last night and I investigated a bit.  This was after I
> > tried restarting it using /etc/rc.d/sndiod, but before resorting to
> > kill -9.  Attaching with gdb revealed that it was stuck in poll(2)
> > with the 2nd argument being 0 and the last argument being -1.  Since
> > no file descriptors are being monitored and the timeout is infinite,
> > the process just blocks forevere.
> 
> noemally it gets periodic SIGALRM which interrupt poll(2) with
> EINTR.

I managed to reproduce this few times by enabling the intel driver
in Xorg and switching VTs. Basically sndiod stops getting signals
with no reason. It doesn't tweak the signal mask (except during
initialization).

It can't be terminated with SIGTERM, which suggests the problem is
not specific to the periodic timer posting SIGALRM but rather to
all signals (corrupted process signal mask?).