Re: Enhancing Privacy in 2020 attached screenshot
First rule Dunning-Kruger club is to suck on Stuart's bits and bless him as much as possible and ignore innovation that could change the security of the normie home. :). Based on your own development. Interesting 28 public and private emails protecting Stuart and his parts 2 really nice private emails on the product itself :) They were right Unix is dead. Australia is nearing a totalitarian state, Netherlands in many ways too, Curacao (due to the Dutch government) now has a law that removes all rights to ownership and freedom, Poland is folding in on itself, the China digital model is expanding at an alarming rate in western cultures ... so laugh it up boys . who gives a fuck right? :) Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, 21 December 2020 23:39, Predrag Punosevac wrote: > Arib Mason wrote: > > > On Sat, Dec 19, 2020 at 2:01 PM Ashlen euryd...@riseup.net wrote: > > > > > On 20/12/16 22:55, pipus wrote: > > > > > > > haha Stuart. > > > > Always there to make a low IQ entrance :) > > > > Ever hear of Dunning-Kruger, pipus? > > > > > > https://lsa.umich.edu/psych/news-events/all-news/faculty-news/the-dunning-kruger-effect-shows-why-some-people-think-they-re-gr.html > > > > First rule of Dunning-Kruger club is you don't know you're in > > Dunning-Kruger club. > > Russell's paradox! > > > -- > > Aaron Mason - Programmer, open source addict > > I've taken my software vows - for beta or for worse
Re: Enhancing Privacy in 2020 attached screenshot
Stuart, one more thing, many of us have a question for you. Why does Theo, someone we have a huge amount of respect for, give you such leeway in the forum? You are Linus loving pseudo-tech. A very much pointless person although you reply to sooo sooo many threads. You know your idol doesn't even use Linux himself right? Linus uses BSD, Darwin, because the 11 million lines of linux code is such a peace of crap he cannot even use it in his daily life, too unstable and insecure. Not a single stable distro except maybe RHEL which requires massive effort to keep clean. A beautiful idea terribly corrupted. Imagine losing your rag with us in 98 and then copying Unix really fecking badly, slapping your name on it, and then not making a single viable distro that doesn't break with almost every update. He played a great joke on the tech society on the world as a whole. hahaha. He followed Gates with the spread of the unusable. Good model it seems. SME alone we get 20-50 major hacks on the linux domain at great cost to B2B a year, let alone wrapping DMZ after DMZ on LE. Some communities are trying hard to keep stable but it is an uphill battle. So a few of us were wondering why you are here. Do you bring in the big donos? Did you marry someone's sister, cat, hamster? Let us know if you can. Did you get lost maybe fell into the forum by accident thinking it was Linux? :). It is not. It is something built a little better. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, 16 December 2020 22:46, Stuart Henderson wrote: > On 2020-12-16, pipus pi...@protonmail.com wrote: > > > I am sure they will inform once they launch > > If they do, I hope they stick to one single mail without a load of > nonsense and no stupid jpeg attachments. This is a mailing list for > discussions of OpenBSD not a marketing forum.
Re: Enhancing Privacy in 2020 attached screenshot
haha Stuart. Always there to make a low IQ entrance :) Would you be more receptive if it was made by Linus and used Linux I wonder... ? Try not to be to childish was just a bit of excitement over something we have been waiting for for many decades. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, 16 December 2020 22:46, Stuart Henderson wrote: > On 2020-12-16, pipus pi...@protonmail.com wrote: > > > I am sure they will inform once they launch > > If they do, I hope they stick to one single mail without a load of > nonsense and no stupid jpeg attachments. This is a mailing list for > discussions of OpenBSD not a marketing forum.
Re: Enhancing Privacy in 2020 attached screenshot
Ah cool Yes I have seen it in action it is real and apparently coming out in less than a month. But I hope that those on this list realise what it means. A commercial revolution for OpenBSD. It should not be for only us. But then I am not their marketing team so will let them announce when it comes. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, 16 December 2020 21:33, Lari Huttunen wrote: > On Wed, Dec 16, 2020 at 04:11:06PM +0000, pipus wrote: > > > I am sure they will inform once they launch > > There are a few of them on the list. > > OK, cool. > > > > > So dear Lari we can agree to disagree. :) I believe at least 1000 of those > > on this list would prefer BSD to linux as a home gateway and don't have > > time to code it all themselves. In fact since I was told about the product > > I haven't found anything even close to the functionality. It seems to sit > > uniquely. > > No, you misunderstood me. I think there definitely is a market for what you > described if it exists. It is high time something like that needs to be > available. If someone does it commercially, more power to them. I hope them > the best of luck with their endeavors. > > Best regards, > > Lari Huttunen > > --- > > "See the unseen. - https://photography.huttu.net
Re: Enhancing Privacy in 2020 attached screenshot
Lari, I am sure they will inform once they launch There are a few of them on the list. And as always with some techs they believe they have to live on the CLI and fear peer visibility if they don't. Trust me you grow out of this once you have delivered enough. Those of us with families, other interests, deadlines, we don't have time to do it all ourselves and happily admit it. I would bet that if your IQ is over 140, on this list or not, having a prebuilt OpenBSD home gateway with 9 functions in one box would get you rather excited. And don't worry you can buy it without telling anyone :). How long have we waited for such a thing ? Imagine ... Firewall, NAS (including Time-machine), Home Cloud, Free App Store, Media/Music Centre, Internet VPN & Home Anywhere VPN, Ad Blocking & DNS Control, Net & WiFI Remote Mgt, Privacy Proxy, & Parental Control ... plus a dev hub .. creator hub ... all built in and ready to go for the whole home, not just a single node. So dear Lari we can agree to disagree. :) I believe at least 1000 of those on this list would prefer BSD to linux as a home gateway and don't have time to code it all themselves. In fact since I was told about the product I haven't found anything even close to the functionality. It seems to sit uniquely. Wasn't this why we developed Unix in the first place? So this list is the perfect place :) Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, 16 December 2020 15:53, Lari Huttunen wrote: > On Tue, Dec 15, 2020 at 09:38:47PM +, pipus wrote: > > > so I got lucky. See attacked screenshot of the present portal. > > I managed to persuade to get a screenshot of the Home Gateway passed on > > OpenBSD. It shows the "home anywhere" so a one click home in bound & > > outbound VPN without opening your network with port forwarding and being > > able to roam behind the home gateway anywhere in the world. Pretty cool. > > So interesting right? An OpenBSD consumer product that is a gateway that > > protects your whole home in firewall, in built VPN, privacy filter, > > ransomeware protection, even cookie caching through proxy. > > And yes some of them are ex-Sun Microsystems so know the firewall well :). > > It feels familiar somehow :) > > So when they go live in the next few weeks you can ask for features I am > > sure they would be willing. Nice group of guys. > > Looks interesting and would like to know more about the company and the > product. > As security and trust go hand in hand, the more likely demography for this > type of product most likely lies outside this "forum", but for the average > consumer, why not. :) > > Best regards, > > Lari Huttunen > > - > > "See the unseen." - https://photography.huttu.net
Re: www.openbsd.org unreachable for a few days
it is ok ... go sleepies :) Before you were born Unix was made with a smile and whim :) Finger me node please or blow me without a job your linux has made you too serious Stuart. Be careful not to break our final resting place. VMS, AIX; HPUX; Darwin, SunOS, are all dead this is the only place left for us. Theo and this before you have made the final haven. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, 15 December 2020 17:57, Stuart Henderson wrote: > wat?! > > On 2020-12-15, pipus pi...@protonmail.com wrote: > > > are you trying from a Windows or Linux machine? > > As sometimes the website blocks broken and poorly architected OSes by > > default through CoPP. :) > > Bur Sur is also blocked sometimes as it is getting as bad as windows for > > bypassing firewalls and stealing your data. Kext bypass anyone? > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > > On Tuesday, 15 December 2020 12:57, Ottavio Caruso > > ottavio2006-usenet2...@yahoo.com wrote: > > > > > Hi, > > > I asked on Freenode#OpenBSD and apparently it's only me, but I haven't > > > been able to access www.openbsd.org for a few days. > > > There is nothing in my firewall/router that blocks OpenBSD.org. Ping, > > > traceroute and telnet don't seem to access the site. Can anybody help? > > > Diagnostics follow. > > > $ telnet www.openbsd.org 443 > > > Trying 129.128.5.194... > > > telnet: Unable to connect to remote host: Connection timed out > > > $ telnet www.openbsd.org 80 > > > Trying 129.128.5.194... > > > telnet: Unable to connect to remote host: Connection timed out > > > $ host www.openbsd.org > > > www.openbsd.org has address 129.128.5.194 > > > $ ping 129.128.5.194 > > > PING 129.128.5.194 (129.128.5.194) 56(84) bytes of data. > > > ^C > > > --- 129.128.5.194 ping statistics --- > > > 31 packets transmitted, 0 received, 100% packet loss, time 30696ms > > > $ traceroute 129.128.5.194 > > > traceroute to 129.128.5.194 (129.128.5.194), 30 hops max, 60 byte packets > > > 1 gateway (192.168.2.1) 0.879 ms 1.433 ms 2.591 ms > > > 2 192.168.1.254 (192.168.1.254) 3.400 ms 6.013 ms 11.119 ms > > > 3 host81-139-176-1.in-addr.btopenworld.com (81.139.176.1) 23.841 ms > > > 24.279 ms 24.892 ms > > > 4 217.32.25.94 (217.32.25.94) 26.975 ms 32.948 ms 33.224 ms > > > 5 217.32.25.120 (217.32.25.120) 34.331 ms 34.815 ms 35.379 ms > > > 6 31.55.185.228 (31.55.185.228) 36.239 ms 31.55.185.192 > > > (31.55.185.192) 18.589 ms 31.55.185.208 (31.55.185.208) 23.081 ms > > > 7 core1-hu0-16-0-6.colindale.ukcore.bt.net (213.121.192.16) 24.023 > > > ms core2-hu0-12-0-5.colindale.ukcore.bt.net (195.99.127.122) 24.013 > > > ms core1-hu0-16-0-7.colindale.ukcore.bt.net (213.121.192.18) 24.400 > > > ms > > > 8 109.159.252.138 (109.159.252.138) 25.195 ms > > > core2-hu0-1-0-1-1.colindale.ukcore.bt.net (195.99.127.9) 26.188 ms > > > core3-hu0-8-0-0.faraday.ukcore.bt.net (195.99.127.36) 27.082 ms > > > 9 62.6.201.145 (62.6.201.145) 27.534 ms 166-49-209-194.gia.bt.net > > > (166.49.209.194) 28.250 ms 62.6.201.145 (62.6.201.145) 33.835 ms > > > 10 166-49-209-194.gia.bt.net (166.49.209.194) 34.201 ms 34.174 ms 34.132 > > > ms > > > 11 40ge1-3.core1.lon2.he.net (195.66.224.21) 35.068 ms > > > 100ge4-1.core1.nyc4.he.net (72.52.92.166) 101.075 ms 86.105 ms > > > 12 100ge4-1.core1.nyc4.he.net (72.52.92.166) 85.940 ms 87.165 ms > > > 100ge14-1.core1.tor1.he.net (184.105.80.10) 97.811 ms > > > 13 100ge6-1.core1.ywg1.he.net (184.105.64.102) 122.819 ms > > > 100ge14-1.core1.tor1.he.net (184.105.80.10) 98.632 ms 99.697 ms > > > 14 100ge6-1.core1.ywg1.he.net (184.105.64.102) 124.813 ms > > > 100ge5-2.core1.yxe1.he.net (184.104.192.70) 138.323 ms > > > 100ge6-1.core1.ywg1.he.net (184.105.64.102) 134.804 ms > > > 15 100ge5-2.core1.yxe1.he.net (184.104.192.70) 137.811 ms > > > 100ge11-2.core1.yeg1.he.net (72.52.92.61) 164.945 ms 163.780 ms > > > 16 * 100ge11-2.core1.yeg1.he.net (72.52.92.61) 164.850 ms * > > > 17 * * * > > > 18 * * * > > > 19 * * * > > > 20 * * * > > > 21 * * * > > > 22 * * * > > > 23 * * * > > > 24 * * * > > > 25 * * * > > > 26 * * * > > > 27 * * * > > > 28 * * * > > > 29 * * * > > > > > > Ottavio Caruso
Re: www.openbsd.org unreachable for a few days
are you trying from a Windows or Linux machine? As sometimes the website blocks broken and poorly architected OSes by default through CoPP. :) Bur Sur is also blocked sometimes as it is getting as bad as windows for bypassing firewalls and stealing your data. Kext bypass anyone? Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, 15 December 2020 12:57, Ottavio Caruso wrote: > Hi, > > I asked on Freenode#OpenBSD and apparently it's only me, but I haven't > been able to access www.openbsd.org for a few days. > > There is nothing in my firewall/router that blocks OpenBSD.org. Ping, > traceroute and telnet don't seem to access the site. Can anybody help? > Diagnostics follow. > > $ telnet www.openbsd.org 443 > Trying 129.128.5.194... > telnet: Unable to connect to remote host: Connection timed out > > $ telnet www.openbsd.org 80 > Trying 129.128.5.194... > telnet: Unable to connect to remote host: Connection timed out > > $ host www.openbsd.org > www.openbsd.org has address 129.128.5.194 > > $ ping 129.128.5.194 > PING 129.128.5.194 (129.128.5.194) 56(84) bytes of data. > ^C > --- 129.128.5.194 ping statistics --- > 31 packets transmitted, 0 received, 100% packet loss, time 30696ms > > $ traceroute 129.128.5.194 > traceroute to 129.128.5.194 (129.128.5.194), 30 hops max, 60 byte packets > 1 gateway (192.168.2.1) 0.879 ms 1.433 ms 2.591 ms > 2 192.168.1.254 (192.168.1.254) 3.400 ms 6.013 ms 11.119 ms > 3 host81-139-176-1.in-addr.btopenworld.com (81.139.176.1) 23.841 ms > 24.279 ms 24.892 ms > 4 217.32.25.94 (217.32.25.94) 26.975 ms 32.948 ms 33.224 ms > 5 217.32.25.120 (217.32.25.120) 34.331 ms 34.815 ms 35.379 ms > 6 31.55.185.228 (31.55.185.228) 36.239 ms 31.55.185.192 > (31.55.185.192) 18.589 ms 31.55.185.208 (31.55.185.208) 23.081 ms > 7 core1-hu0-16-0-6.colindale.ukcore.bt.net (213.121.192.16) 24.023 > ms core2-hu0-12-0-5.colindale.ukcore.bt.net (195.99.127.122) 24.013 > ms core1-hu0-16-0-7.colindale.ukcore.bt.net (213.121.192.18) 24.400 > ms > 8 109.159.252.138 (109.159.252.138) 25.195 ms > core2-hu0-1-0-1-1.colindale.ukcore.bt.net (195.99.127.9) 26.188 ms > core3-hu0-8-0-0.faraday.ukcore.bt.net (195.99.127.36) 27.082 ms > 9 62.6.201.145 (62.6.201.145) 27.534 ms 166-49-209-194.gia.bt.net > (166.49.209.194) 28.250 ms 62.6.201.145 (62.6.201.145) 33.835 ms > 10 166-49-209-194.gia.bt.net (166.49.209.194) 34.201 ms 34.174 ms 34.132 ms > 11 40ge1-3.core1.lon2.he.net (195.66.224.21) 35.068 ms > 100ge4-1.core1.nyc4.he.net (72.52.92.166) 101.075 ms 86.105 ms > 12 100ge4-1.core1.nyc4.he.net (72.52.92.166) 85.940 ms 87.165 ms > 100ge14-1.core1.tor1.he.net (184.105.80.10) 97.811 ms > 13 100ge6-1.core1.ywg1.he.net (184.105.64.102) 122.819 ms > 100ge14-1.core1.tor1.he.net (184.105.80.10) 98.632 ms 99.697 ms > 14 100ge6-1.core1.ywg1.he.net (184.105.64.102) 124.813 ms > 100ge5-2.core1.yxe1.he.net (184.104.192.70) 138.323 ms > 100ge6-1.core1.ywg1.he.net (184.105.64.102) 134.804 ms > 15 100ge5-2.core1.yxe1.he.net (184.104.192.70) 137.811 ms > 100ge11-2.core1.yeg1.he.net (72.52.92.61) 164.945 ms 163.780 ms > 16 * 100ge11-2.core1.yeg1.he.net (72.52.92.61) 164.850 ms * > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > > >
Re: Enhancing Privacy in 2020
I heard someone on this mailing list is creating a home gateway with firewall,VPN, web proxy, DNS blocker, privacy filter, even with its own middleware. I never got a name but they maybe might peek their head above water if they see this thread. >From what I heard it is and all in one security, media, dev hub and NAS >gateway using OpenBSD as a base with an easy to use portal. If true I would be begging for it. But someone might talk somewhere :) ... maybe. As I know that they should be going commercial soon. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, 14 December 2020 22:09, Lari Huttunen wrote: > Cheers! > > For the past couple of weeks I've been tinkering on a hobby project, whose > aim is > make it easier for users to improve their privacy on the network level and > make it > easier for them to access geo-fenced Internet resources. > > I've documented the prototype here and comments, feedback, corrections are > most > welcome. I hope people trying to learn about rdomain(4) and openvpn(8) on > OpenBSD > can at least get something out of it. > > https://www.huttu.net/posts/rtable/ > > Best regards, > > Lari Huttunen > > --- > > "See the unseen." - https://photography.huttu.net
Re: Impact of 002_icmp6.patch
he is real ... but from the Linux side :) but maybe the second troll of the thread. I cannot imagine anyone being that ignorant. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, 30 October 2020 13:36, Florian Obser wrote: > On Fri, Oct 30, 2020 at 11:58:41AM +0100, Martin Schröder wrote: > > > Am Fr., 30. Okt. 2020 um 11:54 Uhr schrieb Denis Fondras > > open...@ledeuns.net: > > > > > Please, fix your tweet. The default install answer for IPv6 is 'none'. > > > > This borders on "switch off v6 for security reasons", which would be just > > wrong. > > since you like to put words in our mouths... > > > I'd much prefer that the project adopted a" v6 first, vintage ip > > second" approach. > > But I'm not a dev. > > ... you are saying if you were a dev things would be better? > > Thanks for ignoring all the hard work we put into making IPv6 better > in OpenBSD. > > > Best > > Martin > > -- > > I'm not entirely sure you are real.
Re: Impact of 002_icmp6.patch
we battered the IETF, and even government interest, on this for years back in late 2007, and beyond ... any remember IPv5? :) IPv6 is a massive security risk in so many ways. No real NAT so you are distributed into the worldwide even if billions of addresses there is no protection. There is NAT64 / DS-lite so you don't need IPv6, even PCP, 1:1 million ratios :) I could write a book on IPv6 insecurities, failings of the open multicast, RA timers, NPD holes and link local omg 30 years I have written protocols, solutions and systems, my advice is switch IPv6 off by default! And anyone who suggests different is off my Christmas list and Santa will put you on the naughty list. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, 30 October 2020 11:58, Martin Schröder wrote: > Am Fr., 30. Okt. 2020 um 11:54 Uhr schrieb Denis Fondras open...@ledeuns.net: > > > Please, fix your tweet. The default install answer for IPv6 is 'none'. > > This borders on "switch off v6 for security reasons", which would be just > wrong. > > I'd much prefer that the project adopted a" v6 first, vintage ip > second" approach. > But I'm not a dev. > > Best > Martin
Re: Fwd: Re: man netstart(8) OpenBSD-6.8
aye agreed. Another option which we were also looking at it a community wiki as a separate src. So sys admins and devs can upload their own usage examples easily. With the caveat ofc that these are not official examples. If you could do something like a triple pipe ||| or even a "sudo !!!" and it would automatically upload as an example if the command worked that would be quite 21st century. But would be nice if we could alleviate the immense workload and bw from the present devs from having to add 10-20 examples for each command or even flag. My issue, even though I ran ITE, and lived on the CLI even in SunScreen was remembering all of the flags and their positioning. Examples really help on that front. Btw interesting signature Luke not that I particularly agree but nice to see another viewpoint, people seem to love the idea of the pre-universe getting flatulent and producing all of this life, biological programming, and beauty. The Big Bang is such a joke mathematically, just completely impossible, but people love to take sides. And I am NOT starting a religious conversation here! Just thought I would comment on your bravery. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, 27 October 2020 21:48, Luke Call wrote: > > ----- message from pipus pi...@protonmail.com - > > Date: Mon, 26 Oct 2020 08:29:41 + > > From: pipus pi...@protonmail.com > > To: Theo de Raadt dera...@openbsd.org > > Cc: "misc@openbsd.org" misc@openbsd.org > > Subject: Re: man netstart(8) OpenBSD-6.8 > > > > I could explain process class priority configuration until my mind is numb > > but in the end without seeing the commands that would actually be used it > > is really making your life far harder. > > I liked Theo's idea of having a "such as (possibly) x, y, and z, but see > the actual /etc/netstart script for accurate details", as striking a > good balance between being briefly informative with examples, and > more accurate over time. > > On Sunday, 25 October 2020 17:44, Theo de Raadt dera...@openbsd.org wrote: > > > Jason McIntyre j...@kerhand.co.uk wrote: > > > > > On Sun, Oct 25, 2020 at 10:16:54AM -0600, Theo de Raadt wrote: > > > > > > > Jason McIntyre j...@kerhand.co.uk wrote: > > > > > > > > > whereas /etc/netstart is actually doing: > > > > > > > > > > - configure non-physical: (1) > > > > > aggr trunk svlan vlan carp pppoe > > > > > > > > > > - routing (2) > > > > > > > > > > - rest of non-physical: (3) > > > > > tun tap gif etherip gre egre mobileip pflow wg > > > > > > > > > > > > > > > we could try to keep this list up to date, but it may be easier to > > > > > just > > > > > generally describe what netstart is doing. > > > > > > > > I think we goes wrong by trying to maintain these as lists, and part of > > > > where this goes wrong is weak definition of the reasons for the > > > > ordering. (Meaning, the developers who tweak netstart to handle the > > > > concerns I'm about to describe, don't tend to think about the manual > > > > page). > > > > The (1) list of non-physical can probably be called "link-layer control > > > > interfaces". Or let's find a name for this. These devices mutate the > > > > presentation of other devices. That's why their configuration needs to > > > > be done before the physical device. > > > > (2) The physical device is then brought up, including IP addressing. The > > > > things in (1) need to be done beforehands, or the physical device is > > > > participating in the wrong layer of network. > > > > the (3) list of non-physical devices are layer-2 or layer-3 and operate > > > > on devices which are already configured with some some sort of > > > > "addressing" configured. > > > > It would be nice to have our networking people come up with nice names > > > > for group (1) and (2); words which succinctly describe the > > > > classification like I've done above. We need to increase understanding > > > > of this order, rather than just abstractly listing names of devices with > > > > complicated behaviours. > > > > Once that is done, I still think it is problematic for us to list all > > > > devices in each catagory: > > > > a) new subsystems will be forgotten > > > > b) the order of instantiation will sometimes be
Re: man netstart(8) OpenBSD-6.8
maybe a little less coffee ? :)
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Monday, 26 October 2020 10:16, Rachel Roch wrote:
> Re: submitting something. Theo has spoken and given his judgement. Theo
> decreed "no, it should not be there", thus I shall not be wasting my time
> submitting something that won't ever be accepted due to whatever weird reason
> Theo thinks a random half-baked description of what is going on with
> netstart(8) is acceptable.
>
> 25 Oct 2020, 13:44 by pi...@protonmail.com:
>
> > Rachel, you could submit something to be helpful if you like, fill the gap
> > that you see. Only 60 devs and most of the man page content is incredibly
> > up to date and valuable.
> > So I for one look forward to you adding your entry into the netstart man
> > page for community review.
> > Sent with ProtonMail Secure Email.
> > ‐‐‐ Original Message ‐‐‐
> > On Sunday, 25 October 2020 09:42, Rachel Roch rr...@tutanota.de wrote:
> >
> > > 25 Oct 2020, 01:25 by dera...@openbsd.org:
> > >
> > > > Rachel Roch rr...@tutanota.de wrote:
> > > >
> > > > > Is it just me or is the man entry for netstart(8) missing a reference
> > > > > to wg(4) ?
> > > >
> > > > ... and 300 other network interfaces.
> > > > In otherwords, no, it should not be there.
> > >
> > > OK smart alec, then why bother enumerating any of the non-physical
> > > interfaces on the man page ?
> > > Afterall, the man page does state at the head of the list "During the
> > > system boot, netstart is executed. netstart performs the following
> > > operations, in the sequence given".
> > > There is little point giving a half-assed description. Either you
> > > enumerate ALL the non-physical interfaces, or otherwise you treat them
> > > the same way as the physical ones ("Configure all the physical
> > > interfaces").
> > > Otherwise you are failing to explain what happens to any of your "300
> > > other interfaces". Enumerate or don't enumerate, I don't care ... but
> > > surely it is sensible to pay some reference to them.
> > > Sheesh !
Re: man netstart(8) OpenBSD-6.8
In Sun we always got hammered for this especially among the 3rd party coops as the man pages never really had an real world examples, and if they were there they were poor, I would keep as many examples as you can as most learn from seeing-in-action, instead of being told how. I could explain process class priority configuration until my mind is numb but in the end without seeing the commands that would actually be used it is really making your life far harder. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, 25 October 2020 17:44, Theo de Raadt wrote: > Jason McIntyre j...@kerhand.co.uk wrote: > > > On Sun, Oct 25, 2020 at 10:16:54AM -0600, Theo de Raadt wrote: > > > > > Jason McIntyre j...@kerhand.co.uk wrote: > > > > > > > whereas /etc/netstart is actually doing: > > > > > > > > - configure non-physical: (1) > > > > aggr trunk svlan vlan carp pppoe > > > > > > > > - routing (2) > > > > - rest of non-physical: (3) > > > > tun tap gif etherip gre egre mobileip pflow wg > > > > > > > > > > > > we could try to keep this list up to date, but it may be easier to just > > > > generally describe what netstart is doing. > > > > > > I think we goes wrong by trying to maintain these as lists, and part of > > > where this goes wrong is weak definition of the reasons for the > > > ordering. (Meaning, the developers who tweak netstart to handle the > > > concerns I'm about to describe, don't tend to think about the manual > > > page). > > > The (1) list of non-physical can probably be called "link-layer control > > > interfaces". Or let's find a name for this. These devices mutate the > > > presentation of other devices. That's why their configuration needs to > > > be done before the physical device. > > > (2) The physical device is then brought up, including IP addressing. The > > > things in (1) need to be done beforehands, or the physical device is > > > participating in the wrong layer of network. > > > the (3) list of non-physical devices are layer-2 or layer-3 and operate > > > on devices which are already configured with some some sort of > > > "addressing" configured. > > > It would be nice to have our networking people come up with nice names > > > for group (1) and (2); words which succinctly describe the > > > classification like I've done above. We need to increase understanding > > > of this order, rather than just abstractly listing names of devices with > > > complicated behaviours. > > > Once that is done, I still think it is problematic for us to list all > > > devices in each catagory: > > > a) new subsystems will be forgotten > > > b) the order of instantiation will sometimes be listed wrong -- for some > > > of these the order is highly significant. > > > We can try to list as many as possible, but people who want the precise > > > list (and order) should look in the netstart code. The lists will get > > > long and wrong. If we find we cannot maintain the lists correctly > > > because it is duplicated information, man page wording like "such as" > > > could be used, also something which leads people to consider the script > > > source as authoritative, ie. have them go read the script > > > > ok, here is a start. > > i have left the description as "non-physical", because i think that is > > clear. we could easily amend it. ifconfig.8 create talks about "network > > pseudo-devices" - that could be a possibility. > > You've deleted all the interface names, so now there are no examples. > I disagree strongly. That creates a hurdle and people won't learn how > our network pieces are configured into a multi-layer stack.
Re: man netstart(8) OpenBSD-6.8
Rachel, you could submit something to be helpful if you like, fill the gap that
you see. Only 60 devs and most of the man page content is incredibly up to
date and valuable.
So I for one look forward to you adding your entry into the netstart man page
for community review.
Please don't forget all G703 types, and any algorithms behind the l1 to L3
protocols, like preference level on BGP attributes per physical type, maybe add
in the voltages as well. You know push and pull 0 and 1 0-15 and - voltage
ranges etc for each as well.
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Sunday, 25 October 2020 09:42, Rachel Roch wrote:
> 25 Oct 2020, 01:25 by dera...@openbsd.org:
>
> > Rachel Roch rr...@tutanota.de wrote:
> >
> > > Is it just me or is the man entry for netstart(8) missing a reference to
> > > wg(4) ?
> >
> > ... and 300 other network interfaces.
> > In otherwords, no, it should not be there.
>
> OK smart alec, then why bother enumerating any of the non-physical interfaces
> on the man page ?
>
> Afterall, the man page does state at the head of the list "During the system
> boot, netstart is executed. netstart performs the following operations, in
> the sequence given".
>
> There is little point giving a half-assed description. Either you enumerate
> ALL the non-physical interfaces, or otherwise you treat them the same way as
> the physical ones ("Configure all the physical interfaces").
>
> Otherwise you are failing to explain what happens to any of your "300 other
> interfaces". Enumerate or don't enumerate, I don't care ... but surely it is
> sensible to pay some reference to them.
>
> Sheesh !
Re: man netstart(8) OpenBSD-6.8
Rachel, you could submit something to be helpful if you like, fill the gap that
you see. Only 60 devs and most of the man page content is incredibly up to
date and valuable.
So I for one look forward to you adding your entry into the netstart man page
for community review.
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Sunday, 25 October 2020 09:42, Rachel Roch wrote:
> 25 Oct 2020, 01:25 by dera...@openbsd.org:
>
> > Rachel Roch rr...@tutanota.de wrote:
> >
> > > Is it just me or is the man entry for netstart(8) missing a reference to
> > > wg(4) ?
> >
> > ... and 300 other network interfaces.
> > In otherwords, no, it should not be there.
>
> OK smart alec, then why bother enumerating any of the non-physical interfaces
> on the man page ?
>
> Afterall, the man page does state at the head of the list "During the system
> boot, netstart is executed. netstart performs the following operations, in
> the sequence given".
>
> There is little point giving a half-assed description. Either you enumerate
> ALL the non-physical interfaces, or otherwise you treat them the same way as
> the physical ones ("Configure all the physical interfaces").
>
> Otherwise you are failing to explain what happens to any of your "300 other
> interfaces". Enumerate or don't enumerate, I don't care ... but surely it is
> sensible to pay some reference to them.
>
> Sheesh !
Re: Multiple USB NICs
I thought we were free to worship our totalitarian leader, butt an all, on and off list. This is, after all, not a linux list. :) Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, 21 October 2020 22:08, Stuart Longland wrote: > On 21/10/20 10:53 pm, pipus wrote: > > > but Theo your butt is magical :( > > Perhaps you can worship it off list then. ;-) > > > > Stuart Longland (aka Redhatter, VK4MSL) > > I haven't lost my mind... > ...it's backed up on a tape somewhere.
Re: Multiple USB NICs
but Theo your butt is magical :( You do it no justice. I have a microwave that is a bit glitchy . Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, 21 October 2020 07:42, Theo de Raadt wrote: > Stuart Longland stua...@longlandclan.id.au wrote: > > > On 21/10/20 9:55 am, Lee Nelson wrote: > > > > > > Alternatively use a single nic with vlans, and break out to separate > > > > ports on a managed switch. > > > > > > Yes, that could work too, but this is one side of a pfsync/carp > > > redundant firewall setup, so I want to keep it as simple as possible. > > > > Silly question, what hardware are the USB NICs plugging into? > > USB trades off determinism for hot-pluggability, and it seems a > > firewall, you absolutely do want an interface to appear in a specific > > location. I'd be looking at something that plugs into the system > > peripheral bus somehow (PCIe, PCI, ISA, … etc). > > Oh come on, you know the answer before you ask it. > > Using cheap hardware and expecting free software developers to > pull magic out of their ass to make it solve unsolveable problems, and > produce a result as too as state of the art expensive hardware --- or > even cheaper hardware --- with DEDICATED PORTS -- it is madness. We > can't do it. And we said so. > > And Lee gets it. But do the rest of the thread participants? > > I think it's fine for us as a community to humour the attempt for a bit, > but THEN THE DISCUSSION MIGHT AS WELL END, as the consequences of the > choice ARE WHAT THEY ARE. > > You get what you paid for. And we (OpenBSD) played no part in the > decision or the consequences, hotplug is what it is. > > Can we end this discussion?
Re: Sending Mail to misc
it can be a usr error so maybe check /usr/dev/bull/ Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, 18 October 2020 21:38, Jeff Joshua Rollin wrote: > On Sun, 2020-10-18 at 15:00 -0400, J Doe wrote: > > > > On Oct 18, 2020, at 2:47 PM, Jeffrey Joshua Rollin < > > > j...@jeffjoshua.club> wrote: > > > Hi, > > > I’m able to send mail from my iPad (sorry), but not from my OpenBSD > > > machine (same address). Any ideas what could be causing this? > > > In the meantime, thanks for 6.8 and happy anniversary. > > > Jeff > > > > Hi, > > I sent two messages to misc yesterday from Thunderbird on Ubuntu > > Linux 20.04 LTS and they also did not make it to the list. Perhaps > > there is an issue on the mail server side ? > > Thanks, > > > > - J > > Well, I can't speak for your problem yesterday but if this message > makes it then the problem was clearly on my side. Something was wrong > with my smtp server settings but when I deleted my accounts and > recreated them in Evolution, I was able to send a message to someone > else. Maybe you could check your Ubuntu settings just in case you've > done the same. > > Apologies to all as I should have checked this before sending anything. > > Jeff.
Re: dmesg for 6.8-release on Pine A64+ 1GB (Arm64)
maybe no need to ruin the 6.8 release with a mention of linux,"other unfinished broken operating systems" might be better as a reference point? :) Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, 18 October 2020 18:02, stolen data wrote: > 6.8 seems to work OK on the Arm64 Pine A64+ with 1GB RAM. > > Some observations: > > OpenBSD sees 896MB of RAM and makes only 838MB available. When running > Debian Linux on the exact same board the available RAM after boot is > 994MB, a difference of more than 150MB. Perhaps this can be improved by > tuning the DTB. > > A contrived test of network performance, using httpd(8) to serve a > large file from an mfs ramdisk over plain http, yields about 175 mbit/s > sustained transfer speed. I was not expecting to reach even 100 mbit/s > so this was a positive surprise, even if it's nowhere near the full > gigabit that other OSes can squeeze out of this board. > > = > > OpenBSD 6.8 (GENERIC.MP) #828: Sun Oct 4 20:35:47 MDT 2020 > dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP > real mem = 940503040 (896MB) > avail mem = 879267840 (838MB) > random: good seed from bootblocks > mainbus0 at root: Pine64+ > psci0 at mainbus0: PSCI 1.1, SMCCC 1.2 > cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4 > cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache > cpu0: 512KB 64b/line 16-way L2 cache > cpu1 at mainbus0 mpidr 1: ARM Cortex-A53 r0p4 > cpu1: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache > cpu1: 512KB 64b/line 16-way L2 cache > cpu2 at mainbus0 mpidr 2: ARM Cortex-A53 r0p4 > cpu2: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache > cpu2: 512KB 64b/line 16-way L2 cache > cpu3 at mainbus0 mpidr 3: ARM Cortex-A53 r0p4 > cpu3: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache > cpu3: 512KB 64b/line 16-way L2 cache > efi0 at mainbus0: UEFI 2.8 > efi0: Das U-Boot rev 0x20200700 > apm0 at mainbus0 > "display-engine" at mainbus0 not configured > "osc24M_clk" at mainbus0 not configured > "osc32k_clk" at mainbus0 not configured > "internal-osc-clk" at mainbus0 not configured > simpleaudio0 at mainbus0 > "spdif-out" at mainbus0 not configured > agtimer0 at mainbus0: tick rate 24000 KHz > simplebus0 at mainbus0: "soc" > sxisyscon0 at simplebus0 > sxisid0 at simplebus0 > sxiccmu0 at simplebus0 > sxipio0 at simplebus0: 103 pins > ampintc0 at simplebus0 nirq 224, ncpu 4 ipi: 0, 1: "interrupt-controller" > sxirtc0 at simplebus0 > sxiccmu1 at simplebus0 > sxipio1 at simplebus0: 13 pins > sxirsb0 at simplebus0 > axppmic0 at sxirsb0 addr 0x3a3: AXP803 > "de2" at simplebus0 not configured > "dma-controller" at simplebus0 not configured > "lcd-controller" at simplebus0 not configured > "lcd-controller" at simplebus0 not configured > sximmc0 at simplebus0 > sdmmc0 at sximmc0: 4-bit, sd high-speed, mmc high-speed, dma > "usb" at simplebus0 not configured > "phy" at simplebus0 not configured > ehci0 at simplebus0 > usb0 at ehci0: USB revision 2.0 > uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev > 2.00/1.00 addr 1 > ohci0 at simplebus0: version 1.0 > ehci1 at simplebus0 > usb1 at ehci1: USB revision 2.0 > uhub1 at usb1 configuration 1 interface 0 "Generic EHCI root hub" rev > 2.00/1.00 addr 1 > ohci1 at simplebus0: version 1.0 > com0 at simplebus0sxiccmu_ccu_reset: 0x002e > : ns16550, no working fifo > com0: console > sxitwi0 at simplebus0 > iic0 at sxitwi0 > dwxe0 at simplebus0: address 02:ba:06:9f:01:af > rgephy0 at dwxe0 phy 1: RTL8169S/8110S/8211 PHY, rev. 5 > "hdmi" at simplebus0 not configured > "hdmi-phy" at simplebus0 not configured > "interrupt-controller" at simplebus0 not configured > sxidog0 at simplebus0 > gpio0 at sxipio0: 32 pins > gpio1 at sxipio0: 32 pins > gpio2 at sxipio0: 32 pins > gpio3 at sxipio0: 32 pins > gpio4 at sxipio0: 32 pins > gpio5 at sxipio0: 32 pins > gpio6 at sxipio0: 32 pins > gpio7 at sxipio0: 32 pins > gpio8 at sxipio1: 32 pins > usb2 at ohci0: USB revision 1.0 > uhub2 at usb2 configuration 1 interface 0 "Generic OHCI root hub" rev > 1.00/1.00 addr 1 > usb3 at ohci1: USB revision 1.0 > uhub3 at usb3 configuration 1 interface 0 "Generic OHCI root hub" rev > 1.00/1.00 addr 1 > "hdmi-connector" at mainbus0 not configured > "binman" at mainbus0 not configured > scsibus0 at sdmmc0: 2
