Re: [PATCH] pcidump - Enhanced Capabilities
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 > > /* >
Re: regarding OpenSSL License change
> On 24 Mar 2017, at 3:51 AM, Theo de Raadtwrote: > > 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
> 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
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
> 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: pf: percpu anchor stacks
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: regarding OpenSSL License change
Bob Beckwrote: ... 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
relayd.conf.5: X-Forwarded-By $REMOTE_ADDR typo
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
[Patch] (www) Updated Copyright on CVS Page
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;>
Re: regarding OpenSSL License change
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
Re: ipcomp bcopy -> mem*
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 */
"PF - Introduction to Open BSD" Edit
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
ipcomp bcopy -> mem*
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 */
J-core MMU and OpenBSD/landisk
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.
Typo in faq1.html
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)
Re: regarding OpenSSL License change
"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
Sebastian Benoitwrote: |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
Re: Ralink (MediaTek) MT7650 / MT7610 usb stick problem with run(4) driver
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
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: Ralink (MediaTek) MT7650 / MT7610 usb stick problem with run(4) driver
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: regarding OpenSSL License change
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/
sendsyslog file race
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: Atheros AR9280+AR7010 USB stick don't work in BSS mode but Host AP
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
Steffen Nurpmeso(stef...@sdaoden.eu) on 2017.03.24 14:03:45 +0100: > Bob Beckwrote: > ... > > 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