Re: Ralink (MediaTek) MT7650 / MT7610 usb stick problem with run(4) driver

[Denis]

It detects as MT7650 by OpenBSD 6.0  after some code modification, not
MT7601U. Many sources like WikiDevi says that TP-LINK Archer T2UH has
MT7610U and somewhere I found that is equivalent to RT2860, but OpenBSD
detects is as MT7650. I haven't opened the stick to check the model
exactly. Going to do so soon.

Denis

On 25.03.2017 1:54, Juan Francisco Cantero Hurtado wrote:
> On Sat, Mar 25, 2017 at 12:47:47AM +0900, Stefan Sperling wrote:
>> On Thu, Mar 23, 2017 at 07:42:13PM +0300, Denis wrote:
>>> Having trouble with TP-LINK AC600 Archer T2UH based on Ralink's MT7650
>>> chipset with run driver on OpenBSD 6.0-stable with all the latest source
>>> tree patches installed.
>> Our run(4) driver does not yet support this chipset. Additional changes are
>> needed to make it work. If you can figure out what else is needed and manage
>> to make it work, please send a patch.
>>
> I've an adapter with the same chipset and it's quite good.
>
> Linux has an independent driver only for the MT7601U, so the changes to
> run(4) is not going to be just a few lines. Denis, for reference:
>
> https://github.com/torvalds/linux/tree/master/drivers/net/wireless/mediatek/mt7601u
>
>

Re: Ralink (MediaTek) MT7650 / MT7610 usb stick problem with run(4) driver

[Juan Francisco Cantero Hurtado]

On Sat, Mar 25, 2017 at 12:47:47AM +0900, Stefan Sperling wrote:
> On Thu, Mar 23, 2017 at 07:42:13PM +0300, Denis wrote:
> > Having trouble with TP-LINK AC600 Archer T2UH based on Ralink's MT7650
> > chipset with run driver on OpenBSD 6.0-stable with all the latest source
> > tree patches installed.
> 
> Our run(4) driver does not yet support this chipset. Additional changes are
> needed to make it work. If you can figure out what else is needed and manage
> to make it work, please send a patch.
> 

I've an adapter with the same chipset and it's quite good.

Linux has an independent driver only for the MT7601U, so the changes to
run(4) is not going to be just a few lines. Denis, for reference:

https://github.com/torvalds/linux/tree/master/drivers/net/wireless/mediatek/mt7601u


-- 
Juan Francisco Cantero Hurtado http://juanfra.info

Re: regarding OpenSSL License change

[Steffen Nurpmeso]

"Michael W. Lucas"  wrote:
 |On Fri, Mar 24, 2017 at 02:37:58PM +0100, Sebastian Benoit wrote:
 |> It's about "You cannot change the licence without consent of the \
 |> author" and
 |> "We just assume that you say yes to this because we dont care about your
 |> rights", which is morally and legally wrong.
 |
 |It's very simple. Four words.
 |
 |"Silence is not consent."
 |
 |Not in contracts. Not in sex. And not in licensing.

You can say this word.  This is funny now, .. that you say this.
No no, no.  I fail to respond to that that is to say.

--steffen

Re: regarding OpenSSL License change

[Steffen Nurpmeso]

Sebastian Benoit  wrote:
 |Steffen Nurpmeso(stef...@sdaoden.eu) on 2017.03.24 14:03:45 +0100:
 |> Bob Beck  wrote:
 ...
 |> According to [1] the chosen license is however the "best" academic
 |> license, and the only one which allows patent protection.  Best in
 |> sofar as all tested items are green.  The Mozilla license was
 |> surely not possible?
 |> 
 |>   [1] http://www.osscc.net/en/licenses.html#compatibility
 ...
 |>|thats really not cool
 |> 
 |> As far as i understand it, using the Apache license gives more
 |> protection to end users than the current license does, at least if
 |> patents get involved.
 |> 
 |>   ..
 |>|> Apparently lawyers are being paid to help them push this through.  Is
 |>|> that being paid for by donations people gave after Heartbleed?  Is
 |>|> this why people donated?
 |> 
 |> The license is even better for end-users as the current license?
 |
 |But it's not about "this licence is better than that licence".

Of course it is, even not being personally involved looking at the
file headers it would be a wonderful cleanup if this jungle could
be replaced with a single copyright header.

 |The code has a licence and they dont respect that.
 |It's about "You cannot change the licence without consent of the author" \

Like it is stated in the file header.

 |and
 |"We just assume that you say yes to this because we dont care about your
 |rights", which is morally and legally wrong.

That is, the way you say it, absurd.  Morally wrong is, with 58
percent loss of life since 1971, to fly 4 kilometres for three
days of hacking or a week of holiday including soiling of historic
sites and stealing towels and anything else which fits into the
suitcase from the hotel.  Buying a new car or a new phone so-and-so
often, because of the same reason.

Or eating meat more than once a week, or at all in fast food
restaurants, at least if you live in Germany, like you do?,
because this is why the rainforests die, and the animals live
under terrible conditions, without sun light, without any space for
living, and without that word that cannot be used on an american
list, but anyway cows will never feel the ton of a hot steaming
bull body but instead the plastic glove of a Volkswagen driver,
up to the shoulder.  But even if you don't care about the animals,
it is still morally wrong because we first world people no longer
eat ears, heads, feets, and all that is shipped for a ridiculous
amount of money to Africa, were thousand year old traditions die
since decades due to that, because Farmers cannot afford this price,
and if they do they soil the acres, and if they don't they leave
their land and go to the cities, where they need more water than the
land can offer, and so you loose-loose and the deserts grow further,
and this goes on since decades.  And not talking at all about the
growing resistance of bacteria for antibiotics, also since decades.

Or having never cared for details but going on like a zombie and
voting the next demagogue that comes along and promises whatever.
Or, worse, even doing this on purpose because the human heart
never gets enough.

So this and much more is morally wrong, but asking all
contributors for a license change, a free license that seems to be
the "best license" for freedom, as has been verified, for the
massively and growing more massively still material world, where
some money-backed lawyers could enforce a shutdown of services if
some patent would be violated, for example, the word "morally
wrong" should be carefully chosen in my opinion.

I also sometimes have the impression that OpenSSL has become
a heavy truck that blindly rolls over the little flowers, though.
On the other hand i have received even two messages for different
addresses for contributions so marginal that it is almost
laughable that someone asks me at all.  The thing is, if i, with
these contributions, would really be allowed to veto the entire
switchover, then the world will stand still, because there are, in
fact, many little pissers all around us.  And this as an European.
I for one think like this, but of course other contributions are
of much more value than mine, and if there would be a "no" from
such a contributor, things may or even will be different.

--steffen

Typo in faq1.html

[Zachary Maurer]

Fixes typo in spelling of "attachment".


Index: faq4.html
===
RCS file: /cvs/www/faq/faq4.html,v
retrieving revision 1.503
diff -u -p -r1.503 faq4.html
--- faq4.html 16 Mar 2017 19:56:07 - 1.503
+++ faq4.html 24 Mar 2017 17:08:52 -
@@ -357,7 +357,7 @@ $ (dmesg; sysctl hw.sensors) > ~/dmes

 Please configure your email client to use plain text.
 In particular, do not use HTML formatting or forced line breaks.
-Put the dmesg into the body of the mail, not as an attachement.
+Put the dmesg into the body of the mail, not as an attachment.

 The ramdisk kernel (bsd.rd)

J-core MMU and OpenBSD/landisk

[Antonio Pollioni]

For individuals who are unaware, I wanted to point out the J-core project.

 http://www.j-core.org

It's a "clean-room open source" re-implementation of the SuperH instruction 
set.  They're currently debating what sort of MMU they should use

 http://lists.j-core.org/pipermail/j-core/2017-March/000566.html

Although they're mainly interested in feedback from Linux kernel developers, I 
imagine that feedback from OpenBSD developers might also be welcome, especially 
since the OpenBSD/landisk platform already supports the SuperH instruction set.

Re: ipcomp bcopy -> mem*

[Alexander Bluhm]

On Fri, Mar 24, 2017 at 12:58:29PM -0400, David Hill wrote:
> This diff converts the existing three bcopy's to memcpy or memmove.
> The memcpy's are on freshly malloc'd memory so no overlap.

As tc and tdb are properly aligned malloc(9)ed data and tc_dst and
tdb_dst are sockaddr_union fields contained in this storage, I think
we can just say "tc->tc_dst = tdb->tdb_dst" and the compiler knows
what to do.

> OK?

OK bluhm@ for memmove(9)ing the mbuf data.

> Index: netinet/ip_ipcomp.c
> ===
> RCS file: /cvs/src/sys/netinet/ip_ipcomp.c,v
> retrieving revision 1.55
> diff -u -p -r1.55 ip_ipcomp.c
> --- netinet/ip_ipcomp.c   17 Feb 2017 14:49:03 -  1.55
> +++ netinet/ip_ipcomp.c   24 Mar 2017 16:54:37 -
> @@ -181,7 +181,7 @@ ipcomp_input(struct mbuf *m, struct tdb 
>   tc->tc_spi = tdb->tdb_spi;
>   tc->tc_proto = IPPROTO_IPCOMP;
>   tc->tc_rdomain = tdb->tdb_rdomain;
> - bcopy(>tdb_dst, >tc_dst, sizeof(union sockaddr_union));
> + memcpy(>tc_dst, >tdb_dst, sizeof(union sockaddr_union));
>  
>   return crypto_dispatch(crp);
>  }
> @@ -317,8 +317,8 @@ ipcomp_input_cb(struct cryptop *crp)
>   /* Finally, let's relink */
>   m1->m_next = mo;
>   } else {
> - bcopy(mtod(m1, u_char *) + roff + hlen,
> - mtod(m1, u_char *) + roff,
> + memmove(mtod(m1, u_char *) + roff,
> + mtod(m1, u_char *) + roff + hlen,
>   m1->m_len - (roff + hlen));
>   m1->m_len -= hlen;
>   m->m_pkthdr.len -= hlen;
> @@ -501,7 +501,7 @@ ipcomp_output(struct mbuf *m, struct tdb
>   tc->tc_proto = tdb->tdb_sproto;
>   tc->tc_skip = skip;
>   tc->tc_rdomain = tdb->tdb_rdomain;
> - bcopy(>tdb_dst, >tc_dst, sizeof(union sockaddr_union));
> + memcpy(>tc_dst, >tdb_dst, sizeof(union sockaddr_union));
>  
>   /* Crypto operation descriptor */
>   crp->crp_ilen = m->m_pkthdr.len;/* Total input length */

Re: regarding OpenSSL License change

[Gilles Chehade]

On Fri, Mar 24, 2017 at 11:55:10AM -0400, Michael W. Lucas wrote:
> On Fri, Mar 24, 2017 at 02:37:58PM +0100, Sebastian Benoit wrote:
> > It's about "You cannot change the licence without consent of the author" and
> > "We just assume that you say yes to this because we dont care about your
> > rights", which is morally and legally wrong.
> 
> 
> It's very simple. Four words.
> 
> "Silence is not consent."
> 
> Not in contracts. Not in sex. And not in licensing.
> 

This is the clearest description of the situation.
Sadly, "clear" is something the OpenSSL folks are unfamiliar with...

-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

[Patch] (www) Updated Copyright on CVS Page

[Elijah Abney]

Just updating the copyright to 2017 for the anoncvs page.

Index: anoncvs.html.head
===
RCS file: /cvs/www/build/mirrors/anoncvs.html.head,v
retrieving revision 1.61
diff -u -p -r1.61 anoncvs.html.head
--- anoncvs.html.head22 Oct 2016 17:30:35 -1.61
+++ anoncvs.html.head24 Mar 2017 17:19:01 -
@@ -7,7 +7,8 @@
 OpenBSD Anonymous CVS
 
 
-
+
 
 
 https://www.openbsd.org/anoncvs.html;>

"PF - Introduction to Open BSD" Edit

[Griffin Melnick]

Added the appropriate hyphens in “32 bit” and “64 bit” under “Hardware Support”

 

 

Index: faq1.html

===

RCS file: /cvs/www/faq/faq1.html,v

retrieving revision 1.213

diff -u -p -r1.213 faq1.html

--- faq1.html 12 Mar 2017 20:45:24 -    1.213

+++ faq1.html 24 Mar 2017 16:18:43 -

@@ -150,7 +150,7 @@ People sometimes ask why we support so m

 The short answer is "because we want to."

 If enough skilled people (and sometimes "enough" is only one really skilled

 person!) wish to maintain support for a platform, it will be supported.

-The OpenBSD platforms include 32 bit and 64 bit processors, little and big

+The OpenBSD platforms include 32-bit and 64-bit processors, little and big

 endian machines and many different designs.

 Supporting unusual platforms has helped produce a higher-quality code base.

 

 

Thank you.

 

 

---

Griffin Melnick

Computer Science and Mathematics

Rensselaer Polytechnic Institute, 2019

 

C: (678) 982-8666

E: mel...@rpi.edu

 

“I think we consider too much the good luck of the early bird and not enough 
the bad luck of the early worm.”

-- Franklin D. Roosevelt



melnig-fix.diff
Description: Binary data

relayd.conf.5: X-Forwarded-By $REMOTE_ADDR typo

[Hiltjo Posthuma]

Hey,

I think there is a typo in relayd.conf(5).

X-Forwarded-By should be the server $SERVER_ADDR instead of the client
$REMOTE_ADDR.

X-Forwarded-For is the client (correct).

diff --git a/usr.sbin/relayd/relayd.conf.5 b/usr.sbin/relayd/relayd.conf.5
index 8bed93efa1f..5f3eb0b2f9a 100644
--- a/usr.sbin/relayd/relayd.conf.5
+++ b/usr.sbin/relayd/relayd.conf.5
@@ -1470,7 +1470,7 @@ http protocol "https" {
match header append "X-Forwarded-For" \e
value "$REMOTE_ADDR"
match header append "X-Forwarded-By" \e
-   value "$REMOTE_ADDR:$SERVER_PORT"
+   value "$SERVER_ADDR:$SERVER_PORT"
match header set "Keep-Alive" value "$TIMEOUT"
 
match query hash "sessid"

-- 
Kind regards,
Hiltjo

ipcomp bcopy -> mem*

[David Hill]

Hello -

This diff converts the existing three bcopy's to memcpy or memmove.
The memcpy's are on freshly malloc'd memory so no overlap.

OK?
 
Index: netinet/ip_ipcomp.c
===
RCS file: /cvs/src/sys/netinet/ip_ipcomp.c,v
retrieving revision 1.55
diff -u -p -r1.55 ip_ipcomp.c
--- netinet/ip_ipcomp.c 17 Feb 2017 14:49:03 -  1.55
+++ netinet/ip_ipcomp.c 24 Mar 2017 16:54:37 -
@@ -181,7 +181,7 @@ ipcomp_input(struct mbuf *m, struct tdb 
tc->tc_spi = tdb->tdb_spi;
tc->tc_proto = IPPROTO_IPCOMP;
tc->tc_rdomain = tdb->tdb_rdomain;
-   bcopy(>tdb_dst, >tc_dst, sizeof(union sockaddr_union));
+   memcpy(>tc_dst, >tdb_dst, sizeof(union sockaddr_union));
 
return crypto_dispatch(crp);
 }
@@ -317,8 +317,8 @@ ipcomp_input_cb(struct cryptop *crp)
/* Finally, let's relink */
m1->m_next = mo;
} else {
-   bcopy(mtod(m1, u_char *) + roff + hlen,
-   mtod(m1, u_char *) + roff,
+   memmove(mtod(m1, u_char *) + roff,
+   mtod(m1, u_char *) + roff + hlen,
m1->m_len - (roff + hlen));
m1->m_len -= hlen;
m->m_pkthdr.len -= hlen;
@@ -501,7 +501,7 @@ ipcomp_output(struct mbuf *m, struct tdb
tc->tc_proto = tdb->tdb_sproto;
tc->tc_skip = skip;
tc->tc_rdomain = tdb->tdb_rdomain;
-   bcopy(>tdb_dst, >tc_dst, sizeof(union sockaddr_union));
+   memcpy(>tc_dst, >tdb_dst, sizeof(union sockaddr_union));
 
/* Crypto operation descriptor */
crp->crp_ilen = m->m_pkthdr.len;/* Total input length */

sendsyslog file race

[Alexander Bluhm]

Hi,

There is a race in dosendsyslog() which resulted in a crash on a
5.9 system.  sosend(syslogf->f_data, ...) was called with a NULL
pointer.  So syslogf is not NULL, f_data is NULL and f_count is 1.

The file structure is ref counted, but the global variable syslogf
is not protected.  So it may change during sleep and dosendsyslog()
possibly uses a different socket at each access.

My crash happend during a reboot when init(8) is killing syslogd(8)
and some sort of super daemon tries to restart it constantly.
Although this design is questionable, it helps finding kernel bugs :-)

Solution is to access syslogf ony once, use a local copy, and do
the ref counting there.

ok?

bluhm

Index: kern/subr_log.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/kern/subr_log.c,v
retrieving revision 1.48
diff -u -p -r1.48 subr_log.c
--- kern/subr_log.c 23 Jun 2016 15:41:42 -  1.48
+++ kern/subr_log.c 24 Mar 2017 15:31:49 -
@@ -409,14 +409,17 @@ dosendsyslog(struct proc *p, const char 
struct iovec *ktriov = NULL;
int iovlen;
 #endif
+   struct file *fp;
char pri[6], *kbuf;
struct iovec aiov;
struct uio auio;
size_t i, len;
int error;
 
-   if (syslogf)
-   FREF(syslogf);
+   /* Global variable syslogf may change during sleep, use local copy. */
+   fp = syslogf;
+   if (fp)
+   FREF(fp);
else if (!ISSET(flags, LOG_CONS))
return (ENOTCONN);
else {
@@ -467,8 +470,8 @@ dosendsyslog(struct proc *p, const char 
 #endif
 
len = auio.uio_resid;
-   if (syslogf) {
-   error = sosend(syslogf->f_data, NULL, , NULL, NULL, 0);
+   if (fp) {
+   error = sosend(fp->f_data, NULL, , NULL, NULL, 0);
if (error == 0)
len -= auio.uio_resid;
} else if (constty || cn_devvp) {
@@ -515,8 +518,8 @@ dosendsyslog(struct proc *p, const char 
free(ktriov, M_TEMP, iovlen);
}
 #endif
-   if (syslogf)
-   FRELE(syslogf, p);
+   if (fp)
+   FRELE(fp, p);
else
error = ENOTCONN;
return (error);

Re: regarding OpenSSL License change

[Michael W. Lucas]

On Fri, Mar 24, 2017 at 02:37:58PM +0100, Sebastian Benoit wrote:
> It's about "You cannot change the licence without consent of the author" and
> "We just assume that you say yes to this because we dont care about your
> rights", which is morally and legally wrong.


It's very simple. Four words.

"Silence is not consent."

Not in contracts. Not in sex. And not in licensing.

==ml

-- 
Michael W. LucasTwitter @mwlauthor 
nonfiction: https://www.michaelwlucas.com/
fiction: https://www.michaelwarrenlucas.com/
blog: http://blather.michaelwlucas.com/

Re: Ralink (MediaTek) MT7650 / MT7610 usb stick problem with run(4) driver

[Stefan Sperling]

On Thu, Mar 23, 2017 at 07:42:13PM +0300, Denis wrote:
> Having trouble with TP-LINK AC600 Archer T2UH based on Ralink's MT7650
> chipset with run driver on OpenBSD 6.0-stable with all the latest source
> tree patches installed.

Our run(4) driver does not yet support this chipset. Additional changes are
needed to make it work. If you can figure out what else is needed and manage
to make it work, please send a patch.

Re: Atheros AR9280+AR7010 USB stick don't work in BSS mode but Host AP

[Stefan Sperling]

On Thu, Mar 23, 2017 at 07:56:08PM +0300, Denis wrote:
> Have Atheros AR9280+AR7010 USB stick athn(4).
> Long ago I tested it with OpenBSD 5.6 in Host AP mode 5GHz band, it does
> not work as AP but successful in BSS in both supported bands.
> 
> On OpenBSD 6.0 situation is different. It is relatively stable in AP
> mode, but don't work BSS in 2.4GHz band. On OpenBSD 5.6 it works fine in
> BSS mode.
> 
> I don't know what happened, but it will be great to have BSS in 5GHz and
> 2.4GHz working as before.
> 
> I can test all the code modification if necessary.
> 
> Denis

A lot of changes have happened since 6.0. Can you please test -current?
I don't have this hardware so I don't know what the status is in -current.

Re: regarding OpenSSL License change

[Sebastian Benoit]

Steffen Nurpmeso(stef...@sdaoden.eu) on 2017.03.24 14:03:45 +0100:
> Bob Beck  wrote:
>   ...
> 
> Disclaimer: i have read about licenses many years ago (likely over
> a decade, i stopped reading the german computer magazine c't
> somewhen in 2005).  I like and use the ISC license that your
> project has chosen and fosters whenever i can.
> 
> According to [1] the chosen license is however the "best" academic
> license, and the only one which allows patent protection.  Best in
> sofar as all tested items are green.  The Mozilla license was
> surely not possible?
> 
>   [1] http://www.osscc.net/en/licenses.html#compatibility
> 
> Interesting to me is that this is the third time this year that
> this topic comes up, in January i had a private communication with
> J??rg Schilling (who provided this link, again), i think a month
> ago there was a thread on the Austrian Linux User list, and now we
> have this one.
> 
>   ...
>  |thats really not cool
> 
> As far as i understand it, using the Apache license gives more
> protection to end users than the current license does, at least if
> patents get involved.
> 
>   ..
>  |> Apparently lawyers are being paid to help them push this through.  Is
>  |> that being paid for by donations people gave after Heartbleed?  Is
>  |> this why people donated?
> 
> The license is even better for end-users as the current license?

But it's not about "this licence is better than that licence".
The code has a licence and they dont respect that.

It's about "You cannot change the licence without consent of the author" and
"We just assume that you say yes to this because we dont care about your
rights", which is morally and legally wrong.

/B

Re: regarding OpenSSL License change

[Steffen Nurpmeso]

Bob Beck  wrote:
  ...

Disclaimer: i have read about licenses many years ago (likely over
a decade, i stopped reading the german computer magazine c't
somewhen in 2005).  I like and use the ISC license that your
project has chosen and fosters whenever i can.

According to [1] the chosen license is however the "best" academic
license, and the only one which allows patent protection.  Best in
sofar as all tested items are green.  The Mozilla license was
surely not possible?

  [1] http://www.osscc.net/en/licenses.html#compatibility

Interesting to me is that this is the third time this year that
this topic comes up, in January i had a private communication with
Jörg Schilling (who provided this link, again), i think a month
ago there was a thread on the Austrian Linux User list, and now we
have this one.

  ...
 |thats really not cool

As far as i understand it, using the Apache license gives more
protection to end users than the current license does, at least if
patents get involved.

  ..
 |> Apparently lawyers are being paid to help them push this through.  Is
 |> that being paid for by donations people gave after Heartbleed?  Is
 |> this why people donated?

The license is even better for end-users as the current license?

--steffen

Re: pf: percpu anchor stacks

[Alexandr Nedvedicky]

Hello,

I'm attaching patch, which removes stack-as-a-global variable.
it's updated patch [1] to current tree.

sorry for being pushy advocating my old, rusty patch.

thanks and
regards
sasha

[1] 
http://openbsd-archive.7691.n7.nabble.com/Re-PF-SMP-making-anchor-stack-multithreaded-tt275915.html#none

8<---8<---8<--8<
diff -r d6e3a6338889 src/sys/net/pf.c
--- a/src/sys/net/pf.c  Mon Mar 20 01:10:40 2017 +0100
+++ b/src/sys/net/pf.c  Fri Mar 24 11:28:18 2017 +0100
@@ -119,12 +119,37 @@ u_char pf_tcp_secret[16];
 int pf_tcp_secret_init;
 int pf_tcp_iss_off;
 
-struct pf_anchor_stackframe {
-   struct pf_ruleset   *rs;
-   struct pf_rule  *r;
-   struct pf_anchor_node   *parent;
-   struct pf_anchor*child;
-} pf_anchor_stack[64];
+struct pf_test_ctx {
+   int test_status;
+   struct pf_pdesc *pd;
+   struct pf_rule_actions  act;
+   u_int8_ticmpcode;
+   u_int8_ticmptype;
+   int icmp_dir;
+   int state_icmp;
+   int tag;
+   u_short reason;
+   struct pf_rule_item *ri;
+   struct pf_src_node  *sns[PF_SN_MAX];
+   struct pf_rule_slistrules;
+   struct pf_rule  *nr;
+   struct pf_rule  **rm;
+   struct pf_rule  *a;
+   struct pf_rule  **am;
+   struct pf_ruleset   **rsm;
+   struct pf_ruleset   *arsm;
+   struct pf_ruleset   *aruleset;
+   struct tcphdr   *th;
+   int  depth;
+};
+
+#definePF_ANCHOR_STACK_MAX 64
+
+enum {
+   PF_TEST_FAIL = -1,
+   PF_TEST_OK,
+   PF_TEST_QUICK
+};
 
 struct pool pf_src_tree_pl, pf_rule_pl, pf_queue_pl;
 struct pool pf_state_pl, pf_state_key_pl, pf_state_item_pl;
@@ -211,11 +236,8 @@ struct pf_state*pf_find_state(struct p
struct pf_state_key_cmp *, u_int, struct mbuf *);
 int pf_src_connlimit(struct pf_state **);
 int pf_match_rcvif(struct mbuf *, struct pf_rule *);
-voidpf_step_into_anchor(int *, struct pf_ruleset **,
-   struct pf_rule **, struct pf_rule **);
-int pf_step_out_of_anchor(int *, struct pf_ruleset **,
-struct pf_rule **, struct pf_rule **,
-int *);
+int pf_step_into_anchor(struct pf_test_ctx *, struct 
pf_rule *);
+int pf_match_rule(struct pf_test_ctx *, struct pf_ruleset 
*);
 voidpf_counters_inc(int, struct pf_pdesc *,
struct pf_state *, struct pf_rule *,
struct pf_rule *);
@@ -3019,74 +3041,37 @@ pf_tag_packet(struct mbuf *m, int tag, i
m->m_pkthdr.ph_rtableid = (u_int)rtableid;
 }
 
-void
-pf_step_into_anchor(int *depth, struct pf_ruleset **rs,
-struct pf_rule **r, struct pf_rule **a)
+int
+pf_step_into_anchor(struct pf_test_ctx *cx, struct pf_rule *r)
 {
-   struct pf_anchor_stackframe *f;
-
-   if (*depth >= sizeof(pf_anchor_stack) /
-   sizeof(pf_anchor_stack[0])) {
-   log(LOG_ERR, "pf: anchor stack overflow\n");
-   *r = TAILQ_NEXT(*r, entries);
-   return;
-   } else if (a != NULL)
-   *a = *r;
-   f = pf_anchor_stack + (*depth)++;
-   f->rs = *rs;
-   f->r = *r;
-   if ((*r)->anchor_wildcard) {
-   f->parent = &(*r)->anchor->children;
-   if ((f->child = RB_MIN(pf_anchor_node, f->parent)) == NULL) {
-   *r = NULL;
-   return;
-   }
-   *rs = >child->ruleset;
-   } else {
-   f->parent = NULL;
-   f->child = NULL;
-   *rs = &(*r)->anchor->ruleset;
-   }
-   *r = TAILQ_FIRST((*rs)->rules.active.ptr);
-}
-
-int
-pf_step_out_of_anchor(int *depth, struct pf_ruleset **rs,
-struct pf_rule **r, struct pf_rule **a, int *match)
-{
-   struct pf_anchor_stackframe *f;
-   int quick = 0;
-
-   do {
-   if (*depth <= 0)
-   break;
-   f = pf_anchor_stack + *depth - 1;
-   if (f->parent != NULL && f->child != NULL) {
-   f->child = RB_NEXT(pf_anchor_node, f->parent, f->child);
-   if (f->child != NULL) {
-   *rs = >child->ruleset;
-   *r = TAILQ_FIRST((*rs)->rules.active.ptr);
-   if (*r == NULL)
-   continue;
-

Re: [PATCH] pcidump - Enhanced Capabilities

[Mark Kettenis]

> Date: Fri, 24 Mar 2017 00:33:18 -0700
> From: Mike Larkin 
> 
> On Thu, Mar 23, 2017 at 04:20:07PM +0100, Simon Mages wrote:
> > Hi,
> > 
> > on some machines i saw some unknown enhanced capabilities. After
> > looking into it i saw that
> > on some intel chipsets there actually is a capability with id 0x0.
> > This capability contains some
> > registers of the Advanced Error Reporting Capability but not all of
> > them. I guess intel choose
> > 0x0 instead of 0x1 because there implementation contains not all of
> > the minimal Advanced
> > Error Reporting registers.
> > 
> > Anyway, i think it makes sense to print the enhanced capability id,
> > even if it is not in the list.
> > This way one does not have to look at the hexdump of pcidump -xxx to
> > figure out which
> > capability id the unknown capability has.
> > 
> 
> no objections. kettenis?

No.  Looks good to me.

> > Index: usr.sbin/pcidump/pcidump.c
> > ===
> > --- pcidump.c   16 Mar 2017 22:05:46 -  1.42
> > +++ pcidump.c   23 Mar 2017 15:12:07 -
> > @@ -392,6 +392,7 @@ void
> >  dump_pcie_enhanced_caplist(int bus, int dev, int func)
> >  {
> > u_int32_t reg;
> > +   u_int32_t capidx;
> > u_int16_t ptr;
> > u_int16_t ecap;
> > 
> > @@ -407,10 +408,12 @@ dump_pcie_enhanced_caplist(int bus, int
> > 
> > ecap = PCI_PCIE_ECAP_ID(reg);
> > if (ecap >= nitems(pci_enhanced_capnames))
> > -   ecap = 0;
> > +   capidx = 0;
> > +   else
> > +   capidx = ecap;
> > 
> > printf("\t0x%04x: Enhanced Capability 0x%02x: ", ptr, ecap);
> > -   printf("%s\n", pci_enhanced_capnames[ecap]);
> > +   printf("%s\n", pci_enhanced_capnames[capidx]);
> > 
> > ptr = PCI_PCIE_ECAP_NEXT(reg);
> > 
> > 
> > According to Rev. 3.0 of the PCIe spec, the last two bits are reserved
> > for future use. I do not
> > have access to the spec > Rev. 3.0.
> > 
> > Index: dev/pci/pcireg.h
> > ===
> > --- dev/pci/pcireg.h22 Mar 2017 07:21:39 -  1.52
> > +++ dev/pci/pcireg.h23 Mar 2017 13:36:09 -
> > @@ -606,7 +606,7 @@ typedef u_int8_t pci_revision_t;
> >  #define PCI_PCIE_ECAP  0x100
> >  #definePCI_PCIE_ECAP_ID(x) (((x) & 0x))
> >  #define PCI_PCIE_ECAP_VER(x)   (((x) >> 16) & 0x0f)
> > -#definePCI_PCIE_ECAP_NEXT(x)   ((x) >> 20)
> > +#definePCI_PCIE_ECAP_NEXT(x)   (((x) >> 20) & 0xffc)
> >  #define PCI_PCIE_ECAP_LAST 0x0
> > 
> >  /*
> > 
> 

Re: regarding OpenSSL License change

[Constantine A. Murenin]

> Date: Wed, 22 Mar 2017 16:48:10 -0400
> From: lice...@openssl.org
> To: dera...@cvs.openbsd.org
> Subject: OpenSSL License change

[...]

> We are asking for your permission to change the licence for your
> contribution. Please visit this link to respond; you will have a chance

[...]

> If we do not hear from you, we will assume that you have no objection.

Is this for real?!

Who do they think they are?

Entirely absurd.

People should not bother to respond to such nonsense, and then sue
OpenSSL for obvious copyright infringement, and move for a summary
judgement without a trial.

C.

Re: regarding OpenSSL License change

[Franco Fichtner]

> On 24 Mar 2017, at 3:51 AM, Theo de Raadt  wrote:
> 
> it is great that someone found a way to convert between licenses.
> 
> AGPL -> GPL -> ISC -> PD

pfSense went through with this, being a 2-Clause BSD fork of m0n0wall,
going through a 6-Clause ESF and CLA (all your rights are belong to
us) transition cycle in 2014 and then finally circling back to Apache
2.0 in 2016 after having failed to suppress forks thereof in light of
OPNsense and the continuation of 2-Clause BSD in 2015.

I talked to the principal author of m0n0wall who answered along the
lines of:

I wasn't asked about this. It would be impossible to ask all
previous contributors to relicense anyway, but I am no lawyer.

The end result:

Several previous contributor copyrights as well as BSD terms of
conditions stripped from the source code, copyrights for own legal
entity asserted for a blank 2004 - 2016 where it seemed fancy.

The official answer is: we own all the code so shut up.  ;)

Nobody indeed cares, except when a 2-Clause BSD fork of pfSense exists
to keep the ball rolling after the 2014 license uncertainty debacle
it gets probed by lawyers on grounds of suspicious copyright violations
allegedly requested by a larger project entity in the BSD scope (note
that pfSense does not have the pull to do this by itself, but a friendly
entity might).  The president of the organisation leading the legal
probe later personally apologises to OPNsense for the behaviour and
encourages us to continue our open source work.

The original report's results are buried by the BSD entity who allegedly
requested it, because no dirt could be found to throw at the fork.
OPNsense was also never contacted by that entity that it had doubts
about the proven-to-be unfounded handling of copyrights.

So you can: relicense whatever you want and actively hinder the
prosperity of your forks and/or competition and get away with it
instead of just working on code and project quality for the benefit
of the community at large.


Gleefully,
Franco

Re: regarding OpenSSL License change

[bytevolcano]

On Thu, 23 Mar 2017 20:51:06 -0600
"Theo de Raadt"  wrote:

> Dude, you are being melodramatic
> 
> it is great that someone found a way to convert between licenses.
> 
> AGPL -> GPL -> ISC -> PD
> 
> thumbs up to the people who found a shortcut
> 

Now this is genius.

Re: [PATCH] pcidump - Enhanced Capabilities

[Mike Larkin]

On Thu, Mar 23, 2017 at 04:20:07PM +0100, Simon Mages wrote:
> Hi,
> 
> on some machines i saw some unknown enhanced capabilities. After
> looking into it i saw that
> on some intel chipsets there actually is a capability with id 0x0.
> This capability contains some
> registers of the Advanced Error Reporting Capability but not all of
> them. I guess intel choose
> 0x0 instead of 0x1 because there implementation contains not all of
> the minimal Advanced
> Error Reporting registers.
> 
> Anyway, i think it makes sense to print the enhanced capability id,
> even if it is not in the list.
> This way one does not have to look at the hexdump of pcidump -xxx to
> figure out which
> capability id the unknown capability has.
> 

no objections. kettenis?

> Index: usr.sbin/pcidump/pcidump.c
> ===
> --- pcidump.c 16 Mar 2017 22:05:46 -  1.42
> +++ pcidump.c 23 Mar 2017 15:12:07 -
> @@ -392,6 +392,7 @@ void
>  dump_pcie_enhanced_caplist(int bus, int dev, int func)
>  {
>   u_int32_t reg;
> + u_int32_t capidx;
>   u_int16_t ptr;
>   u_int16_t ecap;
> 
> @@ -407,10 +408,12 @@ dump_pcie_enhanced_caplist(int bus, int
> 
>   ecap = PCI_PCIE_ECAP_ID(reg);
>   if (ecap >= nitems(pci_enhanced_capnames))
> - ecap = 0;
> + capidx = 0;
> + else
> + capidx = ecap;
> 
>   printf("\t0x%04x: Enhanced Capability 0x%02x: ", ptr, ecap);
> - printf("%s\n", pci_enhanced_capnames[ecap]);
> + printf("%s\n", pci_enhanced_capnames[capidx]);
> 
>   ptr = PCI_PCIE_ECAP_NEXT(reg);
> 
> 
> According to Rev. 3.0 of the PCIe spec, the last two bits are reserved
> for future use. I do not
> have access to the spec > Rev. 3.0.
> 
> Index: dev/pci/pcireg.h
> ===
> --- dev/pci/pcireg.h  22 Mar 2017 07:21:39 -  1.52
> +++ dev/pci/pcireg.h  23 Mar 2017 13:36:09 -
> @@ -606,7 +606,7 @@ typedef u_int8_t pci_revision_t;
>  #define PCI_PCIE_ECAP0x100
>  #define  PCI_PCIE_ECAP_ID(x) (((x) & 0x))
>  #define PCI_PCIE_ECAP_VER(x) (((x) >> 16) & 0x0f)
> -#define  PCI_PCIE_ECAP_NEXT(x)   ((x) >> 20)
> +#define  PCI_PCIE_ECAP_NEXT(x)   (((x) >> 20) & 0xffc)
>  #define PCI_PCIE_ECAP_LAST   0x0
> 
>  /*
>