Re: Tor Relay log warning

[lawgiver]

On 5/5/2021 at 5:34 PM, "Theo Buehler"  wrote:
>
>On Wed, May 05, 2021 at 08:06:09AM -0300, Matheus Coelho wrote:
>> Hello List!
>> 
>> I have a tor relay server and in version 6.9 of openbsd the log 
>started
>> showing this message:
>> 
>> tor_tls_finish_handshake: Bug: For some reason, wasV2Handshake 
>didn't get
>> set. Fixing that. (on Tor 0.4.5.7 )

Experiencing the same (running a bridge).

>> I suspect something related to libressl according to this post:
>
>Yes, libressl doesn't fully support the info callback that tor
>relies on to set wasV2Handshake. This will be a bit tricky to fix.
>I think tor will still work, but the log spam is annoying.

For what it's worth, metrics.torproject.org now reports my bridge as "offline", 
so in this instance tor no longer appears to still work.

>> https://gitlab.torproject.org/tpo/core/tor/-/issues/40128
>
>This post conflates many different issues, most of which should be
>resolved.
>
>> 
>> it makes sense?
>> 
>> thanks in advance.
>> --
>> Matheus Coelho Torres Macedo

-lg.

Re: Install fail on Latitude E64460 : disk not recognised

[lawgiver]

On 4/3/2017 at 1:31 PM, "Thuban"  wrote:
>I try to help a friend installing OpenBSD on a Dell Latitude E6440.
>It seems the disk (SSD) isn't recognised, only the USB stick is 
>found by
>the installer, even with the last snapshot.

Is your situation perhaps similar to the one here?

https://marc.info/?l=openbsd-misc&m=149083706402019&w=2

>You can see the dmesg and installer output as screenshots below. 
>(yes,
>it's not ideal but that is the best I could ask via mail).
>
>https://clbin.com/lRWaSs.jpeg
>https://clbin.com/bsJGm7.jpeg
>https://clbin.com/ddgY4d.jpeg
>https://clbin.com/BkaCiG.jpeg
>https://clbin.com/ji8jtn.jpeg
>https://clbin.com/DGBVtl.jpeg
>https://clbin.com/OR6ZBu.jpeg
>
>Do you have any advice?
>
>Regards.
>--
>:thuban:

support for AMD Radeon RX400 series

[lawgiver]

I've acquired an AMD Sapphire Nitro Radeon RX460 video card, a
recently released (August 2016) GPU which is attractive for its
good performance and low TDP.  On amd64-current #2488 Sep 24 2016
it is detected as:

vga1 at pci1 dev 0 function 0 vendor "ATI", unknown product 0x67ef rev 0xcf

There is currently no listed support for this series in the 
manpage, so as expected radeondrm does not attach and there 
is no KMS or X acceleration.

AMD released[0] an open source Linux driver along with the hardware.
Because this card has a new (Polaris) chipset, does/will support for
this chipset in OpenBSD eventually come from upstream somewhere or
from an OpenBSD developer doing a driver port (in which case, would
a hardware donation have value)?

[0] http://www.phoronix.com/scan.php?page=article&item=amdgpu-rx480-linux&num=2

OT: While exploring the source tree at /usr/src/sys/dev/pci/drm/radeon/
I found a few typo nits, would patches come here?

Re: WinSCP clients unable to connect to recent amd64 -current

[lawgiver]

On 5/4/2015 at 9:39 PM, "Darren Tucker"  wrote:
>[...]
>> debug1: Client protocol version 2.0; client software version 
>WinSCP_release_5.7.2
>[...]
>> Hm, kex protocol error: type 30 seq 1 [preauth]
>
>message type 30 is the pre-RFC4419 group exchange message.  Since
>RFC4419 was published nearly 10 years ago support for the
>non-standardized message was recently removed from OpenSSH.
>
>> What did we break and how can we fix it?
>
>Please try this patch on your server.
>
>Index: compat.c
>===
>RCS file: /cvs/src/usr.bin/ssh/compat.c,v
>retrieving revision 1.91
>diff -u -p -r1.91 compat.c
>--- compat.c   4 May 2015 06:10:48 -   1.91
>+++ compat.c   5 May 2015 04:33:04 -
>@@ -177,6 +177,7 @@ compat_datafellows(const char *version)
> "TTSSH/2.70*,"
> "TTSSH/2.71*,"
> "TTSSH/2.72*",SSH_BUG_HOSTKEYS },
>+  { "WinSCP*",SSH_OLD_DHGEX },
>   { NULL, 0 }
>   };
> 

We upgrade from snapshots, and don't have the source installed, so we can't 
easily check this patch.

However, your response prompted us to look again into the WinSCP options, and 
under Advanced Site Settings > SSH > Key exchange, there is the ability to 
reorder the preferred key exchange algorithms.

Preferring "D-H group 14" before "D-H group exchange" allows the client to 
connect.  If D-H group exchange is obsolete then the fix should really be 
applied to WinSCP?

Thanks!

(I think my email line-lengths are messed up, sorry)

WinSCP clients unable to connect to recent amd64 -current

[lawgiver]

We follow -current on amd64, upgrading about once a month.

Occasional WinSCP (5.7.1, 5.7.2) clients, which previously worked fine, appear 
to be unable to connect following recent upgrades to -current.  We don't know 
exactly which snapshot this stopped working.  FileZilla on Linux clients still 
work fine.  /etc/ssh/sshd_config is stock.

On 5.7 GENERIC.MP#971 amd64 (May 2), this happens:

$ sudo /usr/sbin/sshd -ddd 
debug2: load_server_config: filename /etc/ssh/sshd_config
debug2: load_server_config: done config len = 245
debug2: parse_server_config: config /etc/ssh/sshd_config len 245
debug3: /etc/ssh/sshd_config:37 setting LogLevel DEBUG1
debug3: /etc/ssh/sshd_config:52 setting AuthorizedKeysFile .ssh/authorized_keys
debug3: /etc/ssh/sshd_config:87 setting UsePrivilegeSeparation sandbox  
debug3: /etc/ssh/sshd_config:92 setting UseDNS no
debug3: /etc/ssh/sshd_config:103 setting Subsystem sftp /usr/libexec/sftp-server
debug1: sshd version OpenSSH_6.8, LibreSSL 2.1
debug1: private host key #0: ssh-rsa SHA256:
debug1: private host key #1: ssh-dss SHA256:
debug1: private host key #2: ecdsa-sha2-nistp256 SHA256:
debug1: private host key #3: ssh-ed25519 SHA256:
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-ddd'
debug2: fd 3 setting O_NONBLOCK
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug2: fd 4 setting O_NONBLOCK
debug1: Bind to port 22 on ::.
Server listening on :: port 22.

(WinSCP attempts connect here)

debug1: fd 5 clearing O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 8 config len 245
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from 192.168.0.7 port 49179 on 192.168.0.11 port 22
debug1: Client protocol version 2.0; client software version 
WinSCP_release_5.7.2
debug1: no match: WinSCP_release_5.7.2
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.8
debug2: fd 3 setting O_NONBLOCK
debug3: ssh_sandbox_init: preparing systrace sandbox
debug2: Network child is on pid 9854
debug3: ssh_sandbox_parent: wait for child 9854
debug3: ssh_sandbox_parent: child 9854 stopped
debug3: ssh_sandbox_parent: systrace attach, fd=9
debug3: ssh_sandbox_parent: policy: enable syscall 1
debug3: ssh_sandbox_parent: policy: enable syscall 3
debug3: ssh_sandbox_parent: policy: enable syscall 4
debug3: ssh_sandbox_parent: policy: enable syscall 5
debug3: ssh_sandbox_parent: policy: enable syscall 6
debug3: ssh_sandbox_parent: policy: enable syscall 7
debug3: ssh_sandbox_parent: policy: enable syscall 20
debug3: ssh_sandbox_parent: policy: enable syscall 48
debug3: ssh_sandbox_parent: policy: enable syscall 67
debug3: ssh_sandbox_parent: policy: enable syscall 71
debug3: ssh_sandbox_parent: policy: enable syscall 73
debug3: ssh_sandbox_parent: policy: enable syscall 74
debug3: ssh_sandbox_parent: policy: enable syscall 75
debug3: ssh_sandbox_parent: policy: enable syscall 83
debug3: ssh_sandbox_parent: policy: enable syscall 87
debug3: ssh_sandbox_parent: policy: enable syscall 134
debug3: ssh_sandbox_parent: policy: enable syscall 197
debug3: ssh_sandbox_parent: policy: enable syscall 252
debug3: ssh_sandbox_parent: policy: enable syscall 286
debug3: ssh_sandbox_parent: start child 9854
debug3: preauth child monitor started
debug3: privsep user:group 27:27 [preauth]
debug1: permanently_set_uid: 27/27 [preauth]
debug3: ssh_sandbox_child: ready [preauth]
debug3: ssh_sandbox_child: started [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 
[preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug2: kex_parse_kexinit: 
curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
 [preauth]
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 
[preauth]
debug2: kex_parse_kexinit: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
 [preauth]
debug2: kex_parse_kexinit: 
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
 [preauth]
debug2: kex_parse_kexinit: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
 [preauth]
debug2: kex_parse_kexinit: 
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
 [preauth]
debug2: kex_parse_kexinit: none,z...@openssh.com [preauth]
debug2: kex_parse_kexinit: none,z...@openssh.com [preauth