Re: Potential dig bug?
On Wed, Dec 16, 2020 at 02:37:19PM -0800, Jordan Geoghegan wrote: > Hi folks, > > I've found some surprising behaviour in the 'dig' utility. I've noticed that > dig doesn't seem to support link local IPv6 addresses. I've got unbound > listening on a link local IPv6 address on my router and all queries seem to > be working. I'm advertising this DNS info with rad, and I confirmed with > tcpdump that my devices such as iPhones, Macs, Windows, Linux desktops etc > are all properly querying my unbound server over IPv6. > > dhclient doesn't seem to allow you to specify an IPv6 address in it's > 'supersede' options, so I manually edited my OpenBSD desktops resolv.conf > to specify the IPv6 unbound server first. Again, I confirmed with tcpdump > that my desktop was properly querying the unbound server over IPv6 (ie > Firefox, ping, ssh etc all resolved domains using this server). > > I used 'dig' to make a query, and I noticed it was ignoring my link local > IPv6 nameserver in my resolv.conf. I'll save you guys the long form Ted talk > here and just make my point: > > $ cat resolv.conf > nameserver fe80::f29f:c2ff:fe17:b8b2%em0 > nameserver 2606:4700:4700:: > lookup file bind > family inet6 inet4 > > $ dig google.ca > [snip] > ;; Query time: 12 msec > ;; SERVER: 2606:4700:4700::#53(2606:4700:4700::) > [snip] > > There's a bit of a delay as it waits for a time out, and then it falls back > to the cloudflare IPv6 server. > > I tried specifying the server with '@' as well as specifying source > IP/interface with '-I' to no avail. It seems dig really doesn't like the > 'fe80::%em0' notation, as '@' and '-I' worked fine when used without a > link-local address. > > Is this a bug or a feature? Am I just doing something stupid? Any insight > would be appreciated. I think it is a bug and I can reproduce. Will invesigate deeper later. -Otto
Re: Enhancing Privacy in 2020 attached screenshot
F- my formatting got all jub'd up. For prosperity: Oh Lord... > haha Stuart. > Always there to make a low IQ entrance :) Yeah, I think we all agree that Stuart is pretty retarded, like retarded gorilla territory but it's probably rude to point it out like that. It's better to just let him lumber around the mailing list, defecating where he pleases and smelling his own farts(4), it's really not hurting anyone, plus I think he amuses Theo somehow... > Would you be more receptive if it was made by Linus and used Linux I > wonder... ? Um, no? > Try not to be to childish was just a bit of excitement SHUT THE FUCK UP YOU DUMB IDIOT. The mailing list specifically states: "The only mailing lists that allow file attachments are the bugs, ports and tech lists." Didja read that you crap smelling lobster?! > over something we have been waiting for for many decades. Time in an illusion. The only time now is party time, got that? pipus you're a stink butt and no one likes you. Actually, I think you were joking about the commercial revolution but I still hate you otherwise. No regular person wants a Sun Blade 1000 running OpenBSD 6.9 next to their toilet managing their Internet. OpenBSD is for super-friends and no one else. I shall think of you as I throw up. Professor Anus T. Pepper University of Jub Jubjub, NY 34257 ‐‐‐ Original Message ‐‐‐ On Wednesday, December 16, 2020 5:37 PM, Theo de Raadt wrote: > pipus pi...@protonmail.com wrote: > > > 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? > > Because he makes the world better. > > On the other -- whoever you are -- you just smear shit over everything.
Re: Enhancing Privacy in 2020 attached screenshot
Oh Lord... > haha Stuart. > Always there to make a low IQ entrance :) Yeah, I think we all agree that Stuart is pretty retarded, like retarded gorilla territory but it's probably rude to point it out like that. It's better to just let him lumber around the mailing list, defecating where he pleases and smelling his own farts(4), it's really not hurting anyone, plus I think he amuses Theo somehow... > Would you be more receptive if it was made by Linus and used Linux > I wonder... ? Um, no? > Try not to be to childish was just a bit of excitement SHUT THE FUCK UP YOU DUMB IDIOT. The mailing list specifically states: "The only mailing lists that allow file attachments are the bugs, ports and tech lists." Didja read that you crap smelling lobster?! > over something we have been waiting for for many decades. Time in an illusion. The only time now is party time, got that? pipus you're a stink butt and no one likes you. Actually, I think you were joking about the commercial revolution but I still hate you otherwise. No regular person wants a Sun Blade 1000 running OpenBSD 6.9 next to their toilet managing their Internet. OpenBSD is for super-friends and no one else. I shall think of you as I throw up. Professor Anus T. Pepper University of Jub Jubjub, NY 34257
Re: Potential dig bug?
On 16.12.2020 23:56, Jordan Geoghegan wrote: On 12/16/20 2:37 PM, Jordan Geoghegan wrote: Hi folks, I've found some surprising behaviour in the 'dig' utility. I've noticed that dig doesn't seem to support link local IPv6 addresses. I've got unbound listening on a link local IPv6 address on my router and all queries seem to be working. I'm advertising this DNS info with rad, and I confirmed with tcpdump that my devices such as iPhones, Macs, Windows, Linux desktops etc are all properly querying my unbound server over IPv6. dhclient doesn't seem to allow you to specify an IPv6 address in it's 'supersede' options, so I manually edited my OpenBSD desktops resolv.conf to specify the IPv6 unbound server first. Again, I confirmed with tcpdump that my desktop was properly querying the unbound server over IPv6 (ie Firefox, ping, ssh etc all resolved domains using this server). I used 'dig' to make a query, and I noticed it was ignoring my link local IPv6 nameserver in my resolv.conf. I'll save you guys the long form Ted talk here and just make my point: $ cat resolv.conf nameserver fe80::f29f:c2ff:fe17:b8b2%em0 nameserver 2606:4700:4700:: lookup file bind family inet6 inet4 $ dig google.ca [snip] ;; Query time: 12 msec ;; SERVER: 2606:4700:4700::#53(2606:4700:4700::) [snip] There's a bit of a delay as it waits for a time out, and then it falls back to the cloudflare IPv6 server. I tried specifying the server with '@' as well as specifying source IP/interface with '-I' to no avail. It seems dig really doesn't like the 'fe80::%em0' notation, as '@' and '-I' worked fine when used without a link-local address. Is this a bug or a feature? Am I just doing something stupid? Any insight would be appreciated. Regards, Jordan Sorry for the double mail, I hit send too early... Woops, I failed to make the key point here: I checked with tcpdump and confirmed that dig does not even attempt to query the IPv6 link local DNS server, even though it reports a timeout - ie dig sends no traffic over the wire destined to that address: ; <<>> dig 9.10.8-P1 <<>> @fe80::f29f:c2ff:fe17:b8b2%em0 google.ca ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached Regards, Jordan Quick idea for check..how other commands from base behave? nslookup and host namely
Re: Building from source
On 17.12.2020 03:07, Chris Zakelj wrote: Coming back to my self-teaching on how to (hopefully eventually) be semi-competent, I'm working on trying to build a git project from source. Thus far I've been able to figure out things like functions having slight name differences (e.g. |pthread_set_name_np()| instead of |pthread_setname_np()) and missing #includes in .hh files, but getting stuck on a library issue... about halfway through the first module, I'm failing with: Will be nice to know which code/project as maybe someone else work on that too ld: error: unable to find library -lprotoc ld: error: unable to find library -lprotobuf c++: error: linker command failed with exit code 1 (use -v to see invocation) https://www.openbsd.org/report.html There are for sure other places with more info regarding that. Maybe related Makefile is "hardcoded" with paths which are different on OpenBSD. It offers at least hint to use -v for how it was invoked I've pkg_add'ed the necessary packages, and the libraries exist in /usr/local/lib. I found one site that suggested creating a softlink from .so to .so.9.0 in case the linker didn't understand versioning, but that didn't help. Read the .mk files in /usr/share/mk but nothing jumped out as obvious, and /etc/mk.conf doesn't exist. Pretty sure I'm missing something newbie-obvious, I just don't know what, so a kind "Look here..." would be appreciated. | You can create /etc/mk.conf on your own with stuff you need. Maybe you can try to follow https://www.openbsd.org/faq/ports/guide.html as these things are handled on that level and there are tools present like look for 'make port-lib-depends-check' Verify shared library dependencies. Run make port-lib-depends-check and add every LIB_DEPENDS or WANTLIB annotation that is needed until it runs cleanly. You may want to read the update guidelines to understand why this is so important. Or section Known your software, ports(7) and so on. There is too much to read on the start doing it first time however.
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
On Wed, Dec 16, 2020 at 6:12 PM Daniel Jakots wrote: > > While you were "waiting for many decades" (because I assume you were > not able to do the work), Stuart has done more than 17000 commits in > OpenBSD. It could be funny to see how clueless you are, if it wasn't > appalling because of your lack of respect. > > And helped countless others here on misc. I think I know who I respect, and who I don't.
Re: Enhancing Privacy in 2020 attached screenshot
On Wed, 16 Dec 2020 22:55:17 +, pipus wrote: > 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. While you were "waiting for many decades" (because I assume you were not able to do the work), Stuart has done more than 17000 commits in OpenBSD. It could be funny to see how clueless you are, if it wasn't appalling because of your lack of respect. Cheers, Daniel
Building from source
Coming back to my self-teaching on how to (hopefully eventually) be semi-competent, I'm working on trying to build a git project from source. Thus far I've been able to figure out things like functions having slight name differences (e.g. |pthread_set_name_np()| instead of |pthread_setname_np()) and missing #includes in .hh files, but getting stuck on a library issue... about halfway through the first module, I'm failing with: ld: error: unable to find library -lprotoc ld: error: unable to find library -lprotobuf c++: error: linker command failed with exit code 1 (use -v to see invocation) I've pkg_add'ed the necessary packages, and the libraries exist in /usr/local/lib. I found one site that suggested creating a softlink from .so to .so.9.0 in case the linker didn't understand versioning, but that didn't help. Read the .mk files in /usr/share/mk but nothing jumped out as obvious, and /etc/mk.conf doesn't exist. Pretty sure I'm missing something newbie-obvious, I just don't know what, so a kind "Look here..." would be appreciated. |
Re: Switching from trunk(4) to aggr(4)
On Wed, 16 Dec 2020 15:04:36 +1000, David Gwynne wrote: > By default LACP only sends packets every 30 seconds. Did you run > tcpdump for long enough to make sure you saw at least one? If you get > rid of "-D in" do you see the LACP packets that OpenBSD is > transmitting? You were right, I didn't wait long enough. (I didn't know about the "every 30 seconds"). But I tried again and I never saw them with -D in, and with -D out I saw the one from OpenBSD. > Alternatively your switch is configured with a static aggregation, > ie, what the "loadbalance" in trunk(4) does. You were right again. As I didn't see the LACP packets, I looked more carefully and yeah it appeared it was not configured as a LACP trunk. I deleted the trunk and recreated it (it was immutable) and now aggr0 is active. Yay! I thought that since trunk0 in lacp mode was working, it meant the switch was correctly configured. Out of curiosity, I tried the commands from sthen, and indeed now they show something: TL-SG3216#show lacp internal Flags: S - Device is requesting Slow LACPDUs F - Device is requesting Fast LACPDUs A - Device is in active mode P - Device is in passive mode Channel group 1 LACP port Admin OperPortPort Port Flags State Priority Key Key Number State Gi1/0/2 SA Up32768 0x1 0x345 0x2 0x4d Gi1/0/4 SA Up32768 0x1 0x345 0x4 0x4d Gi1/0/6 SA Up32768 0x1 0x345 0x6 0x4d TL-SG3216#show lacp neighbor Flags: S - Device is requesting Slow LACPDUs F - Device is requesting Fast LACPDUs A - Device is in active mode P - Device is in passive mode Channel group 1 LACP port Admin Oper PortPort Port Flags Priority Dev ID KeyKeyNumber State Gi1/0/2 SP 0 .. 0 0 0 0 Gi1/0/4 SP 0 .. 0 0 0 0 Gi1/0/6 SP 0 .. 0 0 0 0 Thank you very much! Daniel
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 +, 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
pipus wrote: > 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? Because he makes the world better. On the other -- whoever you are -- you just smear shit over everything.
Re: Enhancing Privacy in 2020 attached screenshot
On Wed, Dec 16, 2020 at 09:04:30PM +, pipus wrote: > 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. > Whatever. please go away. But read the website. You can sell OpenBSD freely. You can modify it, release that as long as the copyright notices are kept. We could care less what anyone else is doing. Go troll on some mailing list for toilet innovations, because you are full of shit.
Re: Potential dig bug?
On 12/16/20 2:37 PM, Jordan Geoghegan wrote: Hi folks, I've found some surprising behaviour in the 'dig' utility. I've noticed that dig doesn't seem to support link local IPv6 addresses. I've got unbound listening on a link local IPv6 address on my router and all queries seem to be working. I'm advertising this DNS info with rad, and I confirmed with tcpdump that my devices such as iPhones, Macs, Windows, Linux desktops etc are all properly querying my unbound server over IPv6. dhclient doesn't seem to allow you to specify an IPv6 address in it's 'supersede' options, so I manually edited my OpenBSD desktops resolv.conf to specify the IPv6 unbound server first. Again, I confirmed with tcpdump that my desktop was properly querying the unbound server over IPv6 (ie Firefox, ping, ssh etc all resolved domains using this server). I used 'dig' to make a query, and I noticed it was ignoring my link local IPv6 nameserver in my resolv.conf. I'll save you guys the long form Ted talk here and just make my point: $ cat resolv.conf nameserver fe80::f29f:c2ff:fe17:b8b2%em0 nameserver 2606:4700:4700:: lookup file bind family inet6 inet4 $ dig google.ca [snip] ;; Query time: 12 msec ;; SERVER: 2606:4700:4700::#53(2606:4700:4700::) [snip] There's a bit of a delay as it waits for a time out, and then it falls back to the cloudflare IPv6 server. I tried specifying the server with '@' as well as specifying source IP/interface with '-I' to no avail. It seems dig really doesn't like the 'fe80::%em0' notation, as '@' and '-I' worked fine when used without a link-local address. Is this a bug or a feature? Am I just doing something stupid? Any insight would be appreciated. Regards, Jordan Sorry for the double mail, I hit send too early... Woops, I failed to make the key point here: I checked with tcpdump and confirmed that dig does not even attempt to query the IPv6 link local DNS server, even though it reports a timeout - ie dig sends no traffic over the wire destined to that address: ; <<>> dig 9.10.8-P1 <<>> @fe80::f29f:c2ff:fe17:b8b2%em0 google.ca ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached Regards, Jordan
Potential dig bug?
Hi folks, I've found some surprising behaviour in the 'dig' utility. I've noticed that dig doesn't seem to support link local IPv6 addresses. I've got unbound listening on a link local IPv6 address on my router and all queries seem to be working. I'm advertising this DNS info with rad, and I confirmed with tcpdump that my devices such as iPhones, Macs, Windows, Linux desktops etc are all properly querying my unbound server over IPv6. dhclient doesn't seem to allow you to specify an IPv6 address in it's 'supersede' options, so I manually edited my OpenBSD desktops resolv.conf to specify the IPv6 unbound server first. Again, I confirmed with tcpdump that my desktop was properly querying the unbound server over IPv6 (ie Firefox, ping, ssh etc all resolved domains using this server). I used 'dig' to make a query, and I noticed it was ignoring my link local IPv6 nameserver in my resolv.conf. I'll save you guys the long form Ted talk here and just make my point: $ cat resolv.conf nameserver fe80::f29f:c2ff:fe17:b8b2%em0 nameserver 2606:4700:4700:: lookup file bind family inet6 inet4 $ dig google.ca [snip] ;; Query time: 12 msec ;; SERVER: 2606:4700:4700::#53(2606:4700:4700::) [snip] There's a bit of a delay as it waits for a time out, and then it falls back to the cloudflare IPv6 server. I tried specifying the server with '@' as well as specifying source IP/interface with '-I' to no avail. It seems dig really doesn't like the 'fe80::%em0' notation, as '@' and '-I' worked fine when used without a link-local address. Is this a bug or a feature? Am I just doing something stupid? Any insight would be appreciated. Regards, Jordan
Re: Enhancing Privacy in 2020 attached screenshot
On 2020-12-16, pipus 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: amdgpu test ends up with blank screen
Dear Listeners, Two releases later I have tried out my Radeon RX 570 Nitro+ 8GB graphics card on a similar mainboard (Supermicro X9SRA), and it works fine! Sorry, but only now I have found out that some pins of one of the E5 processor sockets of the original X9DRi-F mainboard were damaged. (Onboard graphics works but no dedicated graphic card. Probably neither the AMD graphics card nor the amdgpu driver caused the problem.) For the sake of completeness, I will append the dmesg for the new setup. Thank you and with best regards, Jens OpenBSD 6.8 (GENERIC.MP) #2: Sat Dec 5 07:17:48 MST 2020 r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 68666306560 (65485MB) avail mem = 66570280960 (63486MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec700 (113 entries) bios0: vendor American Megatrends Inc. version "3.2" date 01/16/2015 bios0: Supermicro X9SRA/X9SRA-3 acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC HPET SSDT MCFG DMAR EINJ ERST HEST BERT acpi0: wakeup devices PS2K(S4) PS2M(S4) P0P9(S1) EUSB(S4) USBE(S4) PEX0(S4) PEX4(S4) PEX5(S4) PEX6(S4) PEX7(S4) NPE4(S4) NPE5(S4) NPE6(S4) NPE7(S4) NPE8(S4) NPE9(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-2630L v2 @ 2.40GHz, 2400.32 MHz, 06-3e-04 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 100MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5-2630L v2 @ 2.40GHz, 2400.02 MHz, 06-3e-04 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU E5-2630L v2 @ 2.40GHz, 2400.02 MHz, 06-3e-04 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E5-2630L v2 @ 2.40GHz, 2400.02 MHz, 06-3e-04 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 8 (application processor) cpu4: Intel(R) Xeon(R) CPU E5-2630L v2 @ 2.40GHz, 2400.02 MHz, 06-3e-04 cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 0, core 4, package 0 cpu5 at mainbus0: apid 10 (application processor) cpu5: Intel(R) Xeon(R) CPU E5-2630L v2 @ 2.40GHz, 2400.02 MHz, 06-3e-04 cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu5: 256KB 64b/line 8-way L2 cache cpu5: smt 0,
Re: Enhancing Privacy in 2020 attached screenshot
On Wed, Dec 16, 2020 at 04:11:06PM +, 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
On 2020-12-16, Stuart Henderson wrote: > On 2020-12-16, Nick Holland wrote: >> Right now, I'm getting overall, good performance, but strange >> patterns -- >> >> $ ftp https://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/install68.img >> >> starts out with a very modest speed, but then starts going >> faster and faster, ftp updates its progress about once per second, >> the first few updates are less than 1MB/s, but by the end, it's >> doing 20MB/s. I've attached a typescript of two pulls from >> ftp.openbsd.org to openbsd.cs.toronto.edu. > > That is normal as the tcp congestion window opens up. (depending on behaviour of the TCP stacks involved..)
Re: www.openbsd.org unreachable for a few days
On 2020-12-16, Nick Holland wrote: > Right now, I'm getting overall, good performance, but strange > patterns -- > > $ ftp https://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/install68.img > > starts out with a very modest speed, but then starts going > faster and faster, ftp updates its progress about once per second, > the first few updates are less than 1MB/s, but by the end, it's > doing 20MB/s. I've attached a typescript of two pulls from > ftp.openbsd.org to openbsd.cs.toronto.edu. That is normal as the tcp congestion window opens up.
Re: Enhancing Privacy in 2020 attached screenshot
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
well, someday I'll learn to send to the right target. :-/ Nick. On 2020-12-16 08:35, Nick Holland wrote: > On 2020-12-15 15:45, Theo de Raadt wrote: >> I've been told something was just fixed. >> >> Now is a good time to retry. >> >> Reply just to me, please. >> >> ONLY people who observed the problems. > > a POSSIBLY related data point -- we had problems between UofA > and UofToronto from the end of November to Dec 5. Our friends > at UofT were doing what they could to see what was going on, > but their conclusion was it was at UofA as well, and they said > they got no response from UofT. And then suddenly, things got > better. > > The problems we had were very slow data movement with a lot of > "stalled" (from ftp(1)) messages, where there would be seemingly > zero progress for many seconds. > > Right now, I'm getting overall, good performance, but strange > patterns -- > > $ ftp https://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/install68.img > > starts out with a very modest speed, but then starts going > faster and faster, ftp updates its progress about once per second, > the first few updates are less than 1MB/s, but by the end, it's > doing 20MB/s. I've attached a typescript of two pulls from > ftp.openbsd.org to openbsd.cs.toronto.edu. > > Nick. >
Re: www.openbsd.org unreachable for a few days
On 2020-12-15 15:45, Theo de Raadt wrote: > I've been told something was just fixed. > > Now is a good time to retry. > > Reply just to me, please. > > ONLY people who observed the problems. a POSSIBLY related data point -- we had problems between UofA and UofToronto from the end of November to Dec 5. Our friends at UofT were doing what they could to see what was going on, but their conclusion was it was at UofA as well, and they said they got no response from UofT. And then suddenly, things got better. The problems we had were very slow data movement with a lot of "stalled" (from ftp(1)) messages, where there would be seemingly zero progress for many seconds. Right now, I'm getting overall, good performance, but strange patterns -- $ ftp https://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/install68.img starts out with a very modest speed, but then starts going faster and faster, ftp updates its progress about once per second, the first few updates are less than 1MB/s, but by the end, it's doing 20MB/s. I've attached a typescript of two pulls from ftp.openbsd.org to openbsd.cs.toronto.edu. Nick. typescript Description: Binary data
Re: Neighbor Solicitation packets try to go out on enc0
Routers don't forward neighbour solicitation messages. So this is a bug? Axel --- PGP-Key: CDE74120 ☀ computing @ chaos claudius signature.asc Description: Message signed with OpenPGP
