Re: Switching from trunk(4) to aggr(4)
On Tue, Dec 15, 2020 at 06:43:12PM -0500, Daniel Jakots wrote: > On Tue, 15 Dec 2020 14:30:16 +1000, David Gwynne > wrote: > > > Can you try tcpdump -p -veni em0 -D in and see if any LACP packets > > appear to come in on the port? If not, can you remove the -p and see > > if em0 starts to work? > > > > There are two main differences between how aggr(4) and trunk(4) > > works. The first you've already found, which is that trunk(4) uses > > the address from one of the ports it's given, while aggr(4) generates > > one when it's created. The second difference is that trunk(4) makes > > member ports promisc, while aggr(4) tries to be a lot more precise > > and takes care to program the ports properly. This means that in your > > environment em(4) has to support changing it's MAC address to the one > > provided by aggr(4), and it has to support joining multicast groups > > properly, including the one that LACP packets are sent to. > > > > tcpdump with -p means that it won't make the interface promiscuous. > > If you don't see LACP packets come in while the port is promisc, that > > means the multicast filter isn't working properly. It should start > > working if you're running tcpdump without -p on the em(4) ports, or > > on aggr(4) itself. > > > Thanks for your reply! > > Here's what I did (spoiler alert, I couldn't get aggr0 to work): > > I switched back the hostname files, and rebooted. > > During boot: > > starting network > aggr0 em0 trunkport: creating port > aggr0 em0 mux: BEGIN (BEGIN) -> DETACHED > aggr0 em0 rxm: BEGIN (BEGIN) -> INITIALIZE > aggr0 em0 rxm: INITIALIZE (UCT) -> PORT_DISABLED > aggr0 em1 trunkport: creating port > aggr0 em1 mux: BEGIN (BEGIN) -> DETACHED > aggr0 em1 rxm: BEGIN (BEGIN) -> INITIALIZE > aggr0 em1 rxm: INITIALIZE (UCT) -> PORT_DISABLED > aggr0 em2 trunkport: creating port > aggr0 em2 mux: BEGIN (BEGIN) -> DETACHED > aggr0 em2 rxm: BEGIN (BEGIN) -> INITIALIZE > aggr0 em2 rxm: INITIALIZE (UCT) -> PORT_DISABLED > vlan10: no linkaggr0 em0 rxm: PORT_DISABLED (port_enabled) -> > EXPIRED .aggr0 em2 rxm: PORT_DISABLED (port_enabled) -> EXPIRED > aggr0 em1 rxm: PORT_DISABLED (port_enabled) -> EXPIRED > ..aggr0 em0 rxm: EXPIRED (current_while_timer expired) -> DEFAULTED > aggr0 em2 rxm: EXPIRED (current_while_timer expired) -> DEFAULTED > aggr0 em1 rxm: EXPIRED (current_while_timer expired) -> DEFAULTED > ... sleeping > > root@pancake:~# tcpdump -p -veni em0 -D in > tcpdump: listening on em0, link-type EN10MB > 18:04:03.996369 80:56:f2:b7:9c:09 ff:ff:ff:ff:ff:ff 8100 60: 802.1Q vid 70 > pri 1 arp who-has 10.70.70.254 tell 10.70.70.101 > 18:04:04.016123 00:17:10:8e:44:a5 ff:ff:ff:ff:ff:ff 8100 64: 802.1Q vid 10 > pri 1 arp who-has 24.48.69.20 tell 24.48.69.1 > 18:04:04.034874 00:17:10:8e:44:a5 ff:ff:ff:ff:ff:ff 8100 64: 802.1Q vid 10 > pri 1 arp who-has 24.48.69.109 tell 24.48.69.1 > > (vlan10 is my uplink to my isp's modem), I didn't have anything but > those arp who-has. > > root@pancake:~# ifconfig aggr0 -> still no carrier > > root@pancake:~# tcpdump -veni em0 -D in > tcpdump: listening on em0, link-type EN10MB > 18:05:11.247455 52:54:00:06:aa:01 00:0d:b9:43:9f:fc 8100 1423: 802.1Q vid 20 > pri 1 10.10.10.44.5638 > 198.48.202.251.25826: udp 1377 (ttl 64, id 2495, len > 1405) > 18:05:11.248427 52:54:00:06:aa:01 00:0d:b9:43:9f:fc 8100 1390: 802.1Q vid 20 > pri 1 10.10.10.44.5638 > 198.48.202.251.25826: udp 1344 (ttl 64, id 47470, > len 1372) > 18:05:11.249478 52:54:00:06:aa:01 00:0d:b9:43:9f:fc 8100 1424: 802.1Q vid 20 > pri 1 10.10.10.44.5638 > 198.48.202.251.25826: udp 1378 (ttl 64, id 57431, > len 1406) > 18:05:11.570690 00:17:10:8e:44:a5 ff:ff:ff:ff:ff:ff 8100 64: 802.1Q vid 10 > pri 1 arp who-has 184.161.78.225 tell 184.161.78.1 > 18:05:11.586920 00:17:10:8e:44:a5 ff:ff:ff:ff:ff:ff 8100 64: 802.1Q vid 10 > pri 1 arp who-has 192.222.131.28 tell 192.222.131.1 > 18:05:12.050180 00:17:10:8e:44:a5 ff:ff:ff:ff:ff:ff 8100 64: 802.1Q vid 10 > pri 1 arp who-has 24.48.76.202 tell 24.48.76.1 > > nothing else than those udp packets (my collectd setup) and the > arp who-has > > root@pancake:~# ifconfig aggr0 -> still no carrier > > At that point I thought "sthen asked me to try to reboot the switch, > let's do it now" and shortly after I got in my console > aggr0 em0 rxm: DEFAULTED (!port_enabled) -> PORT_DISABLED > aggr0 em1 rxm: DEFAULTED (!port_enabled) -> PORT_DISABLED > aggr0 em2 rxm: DEFAULTED (!port_enabled) -> PORT_DISABLED > aggr0 em2 rxm: PORT_DISABLED (port_enabled) -> EXPIRED > aggr0 em1 rxm: PORT_DISABLED (port_enabled) -> EXPIRED > aggr0 em0 rxm: PORT_DISABLED (port_enabled) -> EXPIRED > aggr0 em2 rxm: EXPIRED (current_while_timer expired) -> DEFAULTED > aggr0 em1 rxm: EXPIRED (current_while_timer expired) -> DEFAULTED > aggr0 em0 rxm: EXPIRED (current_while_timer expired) -> DEFAULTED > > I tried again putting in promiscuous mode. I thought also let's do it > on all physical interface as well to be safe :D > > #
Re: Switching from trunk(4) to aggr(4)
On Tue, 15 Dec 2020 14:30:16 +1000, David Gwynne wrote: > Can you try tcpdump -p -veni em0 -D in and see if any LACP packets > appear to come in on the port? If not, can you remove the -p and see > if em0 starts to work? > > There are two main differences between how aggr(4) and trunk(4) > works. The first you've already found, which is that trunk(4) uses > the address from one of the ports it's given, while aggr(4) generates > one when it's created. The second difference is that trunk(4) makes > member ports promisc, while aggr(4) tries to be a lot more precise > and takes care to program the ports properly. This means that in your > environment em(4) has to support changing it's MAC address to the one > provided by aggr(4), and it has to support joining multicast groups > properly, including the one that LACP packets are sent to. > > tcpdump with -p means that it won't make the interface promiscuous. > If you don't see LACP packets come in while the port is promisc, that > means the multicast filter isn't working properly. It should start > working if you're running tcpdump without -p on the em(4) ports, or > on aggr(4) itself. Thanks for your reply! Here's what I did (spoiler alert, I couldn't get aggr0 to work): I switched back the hostname files, and rebooted. During boot: starting network aggr0 em0 trunkport: creating port aggr0 em0 mux: BEGIN (BEGIN) -> DETACHED aggr0 em0 rxm: BEGIN (BEGIN) -> INITIALIZE aggr0 em0 rxm: INITIALIZE (UCT) -> PORT_DISABLED aggr0 em1 trunkport: creating port aggr0 em1 mux: BEGIN (BEGIN) -> DETACHED aggr0 em1 rxm: BEGIN (BEGIN) -> INITIALIZE aggr0 em1 rxm: INITIALIZE (UCT) -> PORT_DISABLED aggr0 em2 trunkport: creating port aggr0 em2 mux: BEGIN (BEGIN) -> DETACHED aggr0 em2 rxm: BEGIN (BEGIN) -> INITIALIZE aggr0 em2 rxm: INITIALIZE (UCT) -> PORT_DISABLED vlan10: no linkaggr0 em0 rxm: PORT_DISABLED (port_enabled) -> EXPIRED .aggr0 em2 rxm: PORT_DISABLED (port_enabled) -> EXPIRED aggr0 em1 rxm: PORT_DISABLED (port_enabled) -> EXPIRED ..aggr0 em0 rxm: EXPIRED (current_while_timer expired) -> DEFAULTED aggr0 em2 rxm: EXPIRED (current_while_timer expired) -> DEFAULTED aggr0 em1 rxm: EXPIRED (current_while_timer expired) -> DEFAULTED ... sleeping root@pancake:~# tcpdump -p -veni em0 -D in tcpdump: listening on em0, link-type EN10MB 18:04:03.996369 80:56:f2:b7:9c:09 ff:ff:ff:ff:ff:ff 8100 60: 802.1Q vid 70 pri 1 arp who-has 10.70.70.254 tell 10.70.70.101 18:04:04.016123 00:17:10:8e:44:a5 ff:ff:ff:ff:ff:ff 8100 64: 802.1Q vid 10 pri 1 arp who-has 24.48.69.20 tell 24.48.69.1 18:04:04.034874 00:17:10:8e:44:a5 ff:ff:ff:ff:ff:ff 8100 64: 802.1Q vid 10 pri 1 arp who-has 24.48.69.109 tell 24.48.69.1 (vlan10 is my uplink to my isp's modem), I didn't have anything but those arp who-has. root@pancake:~# ifconfig aggr0 -> still no carrier root@pancake:~# tcpdump -veni em0 -D in tcpdump: listening on em0, link-type EN10MB 18:05:11.247455 52:54:00:06:aa:01 00:0d:b9:43:9f:fc 8100 1423: 802.1Q vid 20 pri 1 10.10.10.44.5638 > 198.48.202.251.25826: udp 1377 (ttl 64, id 2495, len 1405) 18:05:11.248427 52:54:00:06:aa:01 00:0d:b9:43:9f:fc 8100 1390: 802.1Q vid 20 pri 1 10.10.10.44.5638 > 198.48.202.251.25826: udp 1344 (ttl 64, id 47470, len 1372) 18:05:11.249478 52:54:00:06:aa:01 00:0d:b9:43:9f:fc 8100 1424: 802.1Q vid 20 pri 1 10.10.10.44.5638 > 198.48.202.251.25826: udp 1378 (ttl 64, id 57431, len 1406) 18:05:11.570690 00:17:10:8e:44:a5 ff:ff:ff:ff:ff:ff 8100 64: 802.1Q vid 10 pri 1 arp who-has 184.161.78.225 tell 184.161.78.1 18:05:11.586920 00:17:10:8e:44:a5 ff:ff:ff:ff:ff:ff 8100 64: 802.1Q vid 10 pri 1 arp who-has 192.222.131.28 tell 192.222.131.1 18:05:12.050180 00:17:10:8e:44:a5 ff:ff:ff:ff:ff:ff 8100 64: 802.1Q vid 10 pri 1 arp who-has 24.48.76.202 tell 24.48.76.1 nothing else than those udp packets (my collectd setup) and the arp who-has root@pancake:~# ifconfig aggr0 -> still no carrier At that point I thought "sthen asked me to try to reboot the switch, let's do it now" and shortly after I got in my console aggr0 em0 rxm: DEFAULTED (!port_enabled) -> PORT_DISABLED aggr0 em1 rxm: DEFAULTED (!port_enabled) -> PORT_DISABLED aggr0 em2 rxm: DEFAULTED (!port_enabled) -> PORT_DISABLED aggr0 em2 rxm: PORT_DISABLED (port_enabled) -> EXPIRED aggr0 em1 rxm: PORT_DISABLED (port_enabled) -> EXPIRED aggr0 em0 rxm: PORT_DISABLED (port_enabled) -> EXPIRED aggr0 em2 rxm: EXPIRED (current_while_timer expired) -> DEFAULTED aggr0 em1 rxm: EXPIRED (current_while_timer expired) -> DEFAULTED aggr0 em0 rxm: EXPIRED (current_while_timer expired) -> DEFAULTED I tried again putting in promiscuous mode. I thought also let's do it on all physical interface as well to be safe :D # tcpdump -veni aggr0 -D in # tcpdump -veni em0 -D in # tcpdump -veni em1 -D in # tcpdump -veni em2 -D in root@pancake:~# ifconfig aggr0 -> still no carrier Cheers, Daniel
Re: Switching from trunk(4) to aggr(4)
On Mon, 14 Dec 2020 09:26:36 - (UTC), Stuart Henderson wrote: > >> What does the lacp status look like on the switch? (or does it just > >> say 'up' or something and not really have any status?) > > > > It doesn't say anything about the lacp, it just says the individual > > ports are going up or down (which is normal since I'm rebooting the > > apu to apply the network config change). > > Looking at the switch docs you should get something from "show lacp > internal", "show lacp neighbor" - maybe compare them between trunk > and aggr? I had never connected through serial/cli since I'm a baby who doesn't know what he's doing so the web interface was nice :3 After the whole adventure of configuring a serial account (which meant finding the serial cable with an rj45 connector, finding the port baud rate and so on): TL-SG3216#show lacp <1-8>- Channel group number internal - Actor Lacp Information neighbor - Partner Lacp Information sys-id - Display Lacp Global System Priority. TL-SG3216#show lacp 1 Error: Bad command TL-SG3216#show lacp internal TL-SG3216#show lacp neighbor TL-SG3216#show lacp sys-id 32768, 8416.f99e.a094 how disappointing :-) (I tried these, both under trunk0 and aggr0: same result). I'll reply to your other points in my reply to dlg to centralize all the info. Cheers, Daniel
Re: Switching from trunk(4) to aggr(4)
On Mon, 14 Dec 2020 08:23:15 +0100, Hrvoje Popovski wrote: > maybe to put debug in hostname.aggr0 then destroy it and then sh > netstart aggr0 ? Indeed, making hostname.aggr0: debug trunkport em0 trunkport em1 trunkport em2 up made the debug appear, thanks! Daniel
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: RISC-V and OpenBSD
On 10/12/20 4:33 am, Mihai Popescu wrote: > Just wanted to see if RISC-V architecture is attractive for OpenBSD > development. It's open and it is from Berkeley. I hear it's only truly open if you're part of their exclusive "club". Otherwise it's as much "you take what you're given" as any other architecture. If you're willing to do a port, I doubt any here could stop you. RISC-V hardware needs to become available though before such a port will become any practical use. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
OpenBSD -current not booting on Dell M4800
Hello, I've sent some bug reports about this, but maybe that wasn't the best place to post it. When upgrading to a snapshot with sysupgrade and rebooting, the display hangs as openbsd loads wdisplay0, and xenodm nor X will start. I don't think wdisplay loads at all. This happens on amd64 with the multiprocessor kernel, but not with the single processor one. I did not notice anything out of the ordinary during the upgrade. Anyone might be able to help? Latest bug report with Xorg.log, dmesg, and acpi is here: https://marc.info/?l=openbsd-bugs=160575016004118=2
Re: 9Front on VMM on Ryzen Hardware
e...@disroot.org writes: > Hello, I hope that this is the right mailing list to send this query to. > > First some background. It is possible to run 9front on OpenBSD using > vmm, this is well documented and I have gotten it working before on a > ThinkPad X220. > Where I run into trouble is trying to install it on a T14 AMD, which > uses an AMD processor. Essentially when you begin to run the live cd, > the 9front kernel loads, and then immediately vmd restarts the virtual > machine, presumably because it crashed somewhere in the boot process. > > Now to the question, how would I go about debugging this? I know that > this install works on Intel, this is on OpenBSD -current. > > The 9front IRC told me that it was a vmm issue, as there are different > implementations on AMD and Intel, is this true? > If so, what debugging should I run to help the OpenBSD developers fix > this issue? > > If it's a 9front issue, is there any way for me to be able to take some > kind of memory dump so that the 9front developers can handle this? > > Hopefully this wasn't too off topic, I have read the relevant manual > pages for vmm, but I couldn't work out what debugger to use, I'm not > here to get others to debug it for me, only to work out where to start. > > Thank you I have run into this as well.. There was a change in 9front some time before the release of the amd64 ISOs that seems to have caused it. I was able to boot the 386 ISO (9front-7408.1d345066125a.386.iso) and a amd64 kernel built from the source contained within that ISO. There was about a full year of development between that ISO and when I started seeing the issue, so it's not a very useful data point :P. cinap on #cat-v had some pointers for troubleshooting: 2020-05-29 07:19:47 cinap_lenrekso go to /sys/src/boot/pc 2020-05-29 07:19:55 cinap_lenrekin the mkfile, theres a test.iso target or something 2020-05-29 07:20:02 cinap_lenrekyou can adjust that 2020-05-29 07:20:07 qbitok 2020-05-29 07:20:24 cinap_lenrekbasically, you want a workflow where you just run a command to generate a new iso with the kernel 2020-05-29 07:20:28 cinap_lenreknothing else 2020-05-29 07:20:35 cinap_lenrekthats good enougth to troubleshoot this 2020-05-29 07:20:41 cinap_lenrekand then boot it from vmd Sorry it isn't much help! Cheers, Aaron
Re: www.openbsd.org unreachable for a few days
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. 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 * * * > > > -- > 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: www.openbsd.org unreachable for a few days
On Tue, Dec 15, 2020 at 10:55:27AM -0700, Theo de Raadt wrote: > Janne Johansson wrote: > > > Den tis 15 dec. 2020 kl 13:00 skrev Ottavio Caruso < > > ottavio2006-usenet2...@yahoo.com>: > > > > > 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. > > > > > > $ traceroute 129.128.5.194 > > > traceroute to 129.128.5.194 (129.128.5.194), 30 hops max, 60 byte packets > > > > > > > > ... > > > > > > > 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 > > > > > > I heard a similar complaint elsewhere and that was going over he.net also, > > whereas I could reach it in the mean time, going over shawn to ualbert.ca > > and onwards, so I guess he.net is presently bad at routing to the correct > > places. > > Sorry, you'd be incorrect blaming he.net. > > UofA border is doing some kind of broken filtering, or perhaps it is > incorrect routing of replies into EDU network (cybera/canarie). > > It is up to them to fix it, but there have been no replies yet. I have just traced www.openbsd.org from Poland: [... skip irrelevant part ...] 4 pl-waw02a-ri1-ae-0-0.aorta.net (84.116.138.94) 12.570 ms 13.431 ms 15.473 ms 5 213.46.178.30 (213.46.178.30) 14.047 ms 15.825 ms 13.434 ms 6 100ge16-2.core1.par2.he.net (184.105.213.121) 39.736 ms 53.853 ms 41.229 ms 7 100ge11-2.core1.nyc4.he.net (72.52.92.113) 107.904 ms 116.301 ms 109.851 ms 8 100ge14-1.core1.tor1.he.net (184.105.80.10) 119.988 ms 124.484 ms 119.546 ms 9 100ge6-1.core1.ywg1.he.net (184.105.64.102) 138.756 ms 140.801 ms 139.474 ms 10 100ge5-2.core1.yxe1.he.net (184.104.192.70) 157.590 ms 153.117 ms 155.520 ms 11 100ge11-2.core1.yeg1.he.net (72.52.92.61) 154.828 ms 154.963 ms 156.100 ms 12 university-of-alberta-sms.10gigabitethernet2-2.core1.yeg1.he.net (184.105.18.50) 156.854 ms 157.227 ms 160.990 ms 13 cabcore-esqgw.corenet.ualberta.ca (129.128.255.35) 158.464 ms 163.029 ms katzcore-esqgw.corenet.ualberta.ca (129.128.255.41) 157.714 ms 14 * * * 15 gateway-5.ucs.ualberta.ca (129.128.5.1) 166.056 ms 155.914 ms 160.884 ms 16 obsd3.srv.ualberta.ca (129.128.5.194) 154.972 ms 160.039 ms 156.403 ms 2020-12-15 18:54:31 www.openbsd.org reachable HTH, -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_r...@bigfoot.com **
Re: 9Front on VMM on Ryzen Hardware
On Tue, Dec 15, 2020 at 12:10:42PM +, e...@disroot.org wrote: > Hello, I hope that this is the right mailing list to send this query to. > > First some background. It is possible to run 9front on OpenBSD using > vmm, this is well documented and I have gotten it working before on a > ThinkPad X220. > Where I run into trouble is trying to install it on a T14 AMD, which > uses an AMD processor. Essentially when you begin to run the live cd, > the 9front kernel loads, and then immediately vmd restarts the virtual > machine, presumably because it crashed somewhere in the boot process. > > Now to the question, how would I go about debugging this? I know that > this install works on Intel, this is on OpenBSD -current. > > The 9front IRC told me that it was a vmm issue, as there are different > implementations on AMD and Intel, is this true? > If so, what debugging should I run to help the OpenBSD developers fix > this issue? > > If it's a 9front issue, is there any way for me to be able to take some > kind of memory dump so that the 9front developers can handle this? > > Hopefully this wasn't too off topic, I have read the relevant manual > pages for vmm, but I couldn't work out what debugger to use, I'm not > here to get others to debug it for me, only to work out where to start. > > Thank you > If you know how, build a kernel with VMM_DEBUG enabled and send me the output from dmesg (it will be a lot) when the VM crashes. VMM_DEBUG is settable at the top of vmm.c, fwiw. -ml
Re: www.openbsd.org unreachable for a few days
Janne Johansson wrote: > Den tis 15 dec. 2020 kl 13:00 skrev Ottavio Caruso < > ottavio2006-usenet2...@yahoo.com>: > > > 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. > > > > $ traceroute 129.128.5.194 > > traceroute to 129.128.5.194 (129.128.5.194), 30 hops max, 60 byte packets > > > > > ... > > > > 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 > > > I heard a similar complaint elsewhere and that was going over he.net also, > whereas I could reach it in the mean time, going over shawn to ualbert.ca > and onwards, so I guess he.net is presently bad at routing to the correct > places. Sorry, you'd be incorrect blaming he.net. UofA border is doing some kind of broken filtering, or perhaps it is incorrect routing of replies into EDU network (cybera/canarie). It is up to them to fix it, but there have been no replies yet.
Re: www.openbsd.org unreachable for a few days
On 2020-12-15, Stuart Henderson wrote: > One thing that seems interesting to me is that the working ones have IP > addresses which are covered by RPKI ROAs and the non working ones that > I've seen don't, but the same ISP *does* publish ROAs for other addresses. oh, ROA is there, I just missed it.. I should have just used bgpctl rather than trying to read the list of prefixes :) > Anyway I am prety sure we need traceroutes from UofA to find out more. > > >
Re: www.openbsd.org unreachable for a few days
On 2020-12-15, 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. Has been a problem on *some* connections since about 16:00UTC on the 9th. I believe it is on the return path, because it works from some IP addresses but not others on the same ISP, so there's little we're going to be able to tell from a traceroute from the client side. I've sent private mail to the www server admin to ask if he can check from his side. > $ 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 * * * Yet from another BT connection it works: 1 62.6.243.145 (62.6.243.145) 1.089 ms 0.756 ms 0.595 ms 2 ch-de.eurocore.bt.net (194.72.24.204) 10.445 ms 10.646 ms 10.576 ms 3 core2-te0-11-0-14.colindale.ukcore.bt.net (109.159.254.14) 11.852 ms core2-te0-13-0-1.southbank.ukcore.bt.net (109.159.254.22) 11.479 ms core2-te0-11-0-12.colindale.ukcore.bt.net (109.159.254.6) 11.309 ms 4 109.159.252.138 (109.159.252.138) 11.876 ms core4-hu0-1-0-1.faraday.ukcore.bt.net (195.99.127.50) 11.644 ms core4-hu0-2-0-4.faraday.ukcore.bt.net (195.99.127.70) 10.946 ms 5 166-49-209-194.gia.bt.net (166.49.209.194) 11.333 ms 11.008 ms 11.701 ms 6 40ge1-3.core1.lon2.he.net (195.66.224.21) 12.404 ms 12.326 ms 13.749 ms 7 100ge4-1.core1.nyc4.he.net (72.52.92.166) 77.78 ms 77.304 ms 85.621 ms 8 100ge14-1.core1.tor1.he.net (184.105.80.10) 106.467 ms 89.209 ms 88.499 ms 9 100ge6-1.core1.ywg1.he.net (184.105.64.102) 124.079 ms 123.837 ms 124.221 ms 10 100ge5-2.core1.yxe1.he.net (184.104.192.70) 131.846 ms 132.143 ms 133.125 ms 11 100ge11-2.core1.yeg1.he.net (72.52.92.61) 128.302 ms 127.369 ms 128.946 ms 12 university-of-alberta-sms.10gigabitethernet2-2.core1.yeg1.he.net (184.105.18.50) 139.441 ms 140.486 ms 139.761 ms 13 katzcore-esqgw.corenet.ualberta.ca (129.128.255.41) 139.524 ms cabcore-esqgw.corenet.ualberta.ca (129.128.255.35) 129.582 ms 127.53 ms 14 * * * 15 gateway-5.ucs.ualberta.ca (129.128.5.1) 140.109 ms 141.08 ms 139.615 ms 16 obsd3.srv.ualberta.ca (129.128.5.194) 128.682 ms 128.259 ms 128.715 ms And I have both working and non-working examples on Zen. One thing that seems interesting to me is that the working ones have IP addresses which are covered by RPKI ROAs and the non working ones that I've seen don't, but the same ISP *does* publish ROAs for other addresses. Anyway I am prety sure we need traceroutes from UofA to find out more.
Re: www.openbsd.org unreachable for a few days
wat?! On 2020-12-15, pipus 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 > 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: www.openbsd.org unreachable for a few days
On 15/12/2020 11: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. Both browsing to the website and traceroute work for me (assuming obsd3.srv.ualberta.ca is actually where www.openbsd.org resides). Only just tried traceroute, but the website seems to have been up for me over the last several days, on both Manjaro Linux and Android. I'm in the UK (Newcastle upon Tyne, North East England), if that makes any difference. HTH Jeff.
9Front on VMM on Ryzen Hardware
Hello, I hope that this is the right mailing list to send this query to. First some background. It is possible to run 9front on OpenBSD using vmm, this is well documented and I have gotten it working before on a ThinkPad X220. Where I run into trouble is trying to install it on a T14 AMD, which uses an AMD processor. Essentially when you begin to run the live cd, the 9front kernel loads, and then immediately vmd restarts the virtual machine, presumably because it crashed somewhere in the boot process. Now to the question, how would I go about debugging this? I know that this install works on Intel, this is on OpenBSD -current. The 9front IRC told me that it was a vmm issue, as there are different implementations on AMD and Intel, is this true? If so, what debugging should I run to help the OpenBSD developers fix this issue? If it's a 9front issue, is there any way for me to be able to take some kind of memory dump so that the 9front developers can handle this? Hopefully this wasn't too off topic, I have read the relevant manual pages for vmm, but I couldn't work out what debugger to use, I'm not here to get others to debug it for me, only to work out where to start. Thank you
www.openbsd.org unreachable for a few days
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: 9Front on VMM on Ryzen Hardware
On 15.12.2020 13:10, e...@disroot.org wrote: Hello, I hope that this is the right mailing list to send this query to. First some background. It is possible to run 9front on OpenBSD using vmm, this is well documented and I have gotten it working before on a ThinkPad X220. Where I run into trouble is trying to install it on a T14 AMD, which uses an AMD processor. Essentially when you begin to run the live cd, the 9front kernel loads, and then immediately vmd restarts the virtual machine, presumably because it crashed somewhere in the boot process. Now to the question, how would I go about debugging this? I know that this install works on Intel, this is on OpenBSD -current. The 9front IRC told me that it was a vmm issue, as there are different implementations on AMD and Intel, is this true? If so, what debugging should I run to help the OpenBSD developers fix this issue? Described here https://www.openbsd.org/report.html dmesg(8) is a good start and you may play with https://man.openbsd.org/boot_config If it's a 9front issue, is there any way for me to be able to take some kind of memory dump so that the 9front developers can handle this? Hopefully this wasn't too off topic, I have read the relevant manual pages for vmm, but I couldn't work out what debugger to use, I'm not here to get others to debug it for me, only to work out where to start. Thank you
Re: www.openbsd.org unreachable for a few days
Den tis 15 dec. 2020 kl 13:00 skrev Ottavio Caruso < ottavio2006-usenet2...@yahoo.com>: > 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. > > $ traceroute 129.128.5.194 > traceroute to 129.128.5.194 (129.128.5.194), 30 hops max, 60 byte packets > > ... > 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 I heard a similar complaint elsewhere and that was going over he.net also, whereas I could reach it in the mean time, going over shawn to ualbert.ca and onwards, so I guess he.net is presently bad at routing to the correct places. -- May the most significant bit of your life be positive.
Re: www.openbsd.org unreachable for a few days
> 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. It's not just you, my traceroutes stop at the same point. Curiously though, I _CAN_ reach www.openbsd.org using a NAT64 service provided by my ISP. -- Tyler Griffiths
