Re: iwm errors with new snapshot

[trondd]

On Tue, January 23, 2018 2:09 pm, Stefan Sperling wrote:
> On Tue, Jan 23, 2018 at 11:50:28AM -0600, Vijay Sankar wrote:
>> Over the weekend, I was trying to do some tests requested in tech@
>> (inteldrm). I downloaded the latest snapshot but had problems with iwm
>> firmware on my laptops (X1 Carbon 5th gen)
>>
>> I did not have these errors with the previous snapshot (from January 8,
>> 2018). DHCP etc all worked properly the past couple of weeks, I was able
>> to
>> copy large file sets through wifi etc.
>>
>> So I tried a new build myself in case there was a mismatch between the
>> packages on firmware.openbsd.org and the latest snapshot but that did
>> not
>> work.
>>
>> Waited couple of days for a newer snapshot, installed it and still get
>> the
>> following errors
>
> Can you please try a kernel compiled from -current CVS source?
>
> Such kernels work for me.
>

Had the same problem with a snapshot installed yesterday.  Building from
-current seems to be fine.

Tim.

OpenSMTPD mail server help

[zklp zeal]

Hi,

I am using *OpenBSD 6.1 *and need help in setting up mail server

tried to send a test mail to gmail account and couldn't get it working

How can i tell OpenSMTPD to forget about the mail and stop trying ?

*smtpd.conf *

### pki setup
pki mail.plrzeal.in certificate "/etc/ssl/mail.plrzeal.in.crt"
pki mail.plrzeal.in key "/etc/ssl/mail.plrzeal.in.key"

###
listen on lo0
listen on egress tls pki mail.plrzeal.in
listen on egress port 587 tls-require pki mail.plrzeal.in auth

###
table aliases db:/etc/mail/aliases.db
table vusers file:/etc/mail/vusers
table vdomains file:/etc/mail/vdomains

###
accept for local alias  deliver to maildir
accept from any for domain  virtual  deliver to maildir
accept from local for any relay


I tried following
*1*. doas rcctl restart smtpd

*2*. doas smtpctl show queue
OUT : 5d1598b89117541b|local|mta|auth|plrv6@atmaview|plr127...@gmail.com|
plr127...@gmail.com|1516696722|1517042322|1516751355|0|inflight|373|

*3*.  doas smtpctl remove 5d1598b89117541b   *(* it seem to get removed but
the message keep coming and if i restart smtpd it shows up again*)*

*4.* doas smtpctl show routes
output below
13. [] <-> 74.125.200.27 (sa-in-f27.1e100.net) N--- nconn=1 nerror=0
penalty=0 timeout=-
12. [] <-> IPv6:2404:6800:4003:c00::1a (sa-in-x1a.1e100.net) N--- nconn=1
nerror=0 penalty=0 timeout=-


*doas smtpd -dv*
debug: init ssl-tree
info: loading pki information for mail.plrzeal.in
debug: init ca-tree
debug: init ssl-tree
info: loading pki keys for mail.plrzeal.in
debug: using "fs" queue backend
debug: using "ramqueue" scheduler backend
debug: using "ram" stat backend
info: *OpenSMTPD 6.0.0 starting*
debug: init ssl-tree
debug: init ssl-tree
debug: init ssl-tree
debug: init ssl-tree
debug: init ssl-tree
info: loading pki information for mail.plrzeal.in
info: loading pki information for mail.plrzeal.in
info: loading pki information for mail.plrzeal.in
info: loading pki information for mail.plrzeal.in
info: loading pki information for mail.plrzeal.in
debug: init ssl-tree
debug: init ca-tree
debug: init ca-tree
debug: init ca-tree
debug: init ca-tree
debug: init ca-tree
info: loading pki information for mail.plrzeal.in
debug: init ssl-tree
debug: init ssl-tree
debug: init ssl-tree
debug: init ssl-tree
debug: init ssl-tree
debug: init ca-tree
info: loading pki keys for mail.plrzeal.in
info: loading pki keys for mail.plrzeal.in
info: loading pki keys for mail.plrzeal.in
info: loading pki keys for mail.plrzeal.in
info: loading pki keys for mail.plrzeal.in
debug: init ssl-tree
debug: using "fs" queue backend
debug: using "fs" queue backend
debug: using "fs" queue backend
debug: using "fs" queue backend
debug: using "fs" queue backend
info: loading pki keys for mail.plrzeal.in
debug: using "ramqueue" scheduler backend
debug: using "ramqueue" scheduler backend
debug: using "ramqueue" scheduler backend
debug: using "ramqueue" scheduler backend
debug: using "ramqueue" scheduler backend
debug: using "fs" queue backend
debug: using "ram" stat backend
debug: using "ram" stat backend
debug: using "ram" stat backend
debug: using "ram" stat backend
debug: using "ram" stat backend
debug: using "ramqueue" scheduler backend
setup_peer: klondike -> control[31057] fd=4
setup_peer: control -> klondike[31654] fd=4
setup_peer: lookup -> control[31057] fd=4
setup_peer: pony express -> control[31057] fd=4
setup_peer: queue -> control[31057] fd=4
debug: using "ram" stat backend
setup_peer: klondike -> pony express[25077] fd=5
setup_peer: control -> lookup[23125] fd=5
setup_peer: lookup -> pony express[25077] fd=5
setup_peer: pony express -> klondike[31654] fd=5
setup_peer: queue -> pony express[25077] fd=5
setup_peer: scheduler -> control[31057] fd=4
setup_done: ca[31654] done
setup_peer: control -> pony express[25077] fd=6
setup_peer: lookup -> queue[5720] fd=6
setup_peer: pony express -> lookup[23125] fd=6
setup_peer: queue -> lookup[23125] fd=6
setup_peer: scheduler -> queue[5720] fd=5
setup_proc: klondike done
setup_peer: control -> queue[5720] fd=7
setup_peer: pony express -> queue[5720] fd=7
setup_peer: queue -> scheduler[43379] fd=7
setup_peer: control -> scheduler[43379] fd=8
setup_done: control[31057] done
setup_proc: lookup done
setup_proc: control done
setup_done: lka[23125] done
setup_proc: pony express done
setup_done: pony[25077] done
filter: building simple chains...
setup_proc: queue done
filter: building complex chains...
setup_done: queue[5720] done
filter: done building complex chains
debug: ca_engine_init: using RSA privsep engine
setup_done: scheduler[43379] done
setup_proc: scheduler done
debug: bounce warning after 4h
smtpd: setup done
debug: parent_send_config_ruleset: reloading
debug: parent_send_config: configuring pony process
debug: parent_send_config: configuring ca process
debug: init private ssl-tree
debug: smtp: listen on IPv6:::1 port 25 flags 0x400 pki "" ca ""
debug: smtp: listen on IPv6:fe80::1%lo0 port 25 flags 0x400 pki "" ca ""
debug: smtp: listen on 127.0.0.1 port 25 

Re: iwm errors with new snapshot

[Vijay Sankar]

Quoting Stefan Sperling :


On Tue, Jan 23, 2018 at 11:50:28AM -0600, Vijay Sankar wrote:

Over the weekend, I was trying to do some tests requested in tech@
(inteldrm). I downloaded the latest snapshot but had problems with iwm
firmware on my laptops (X1 Carbon 5th gen)

I did not have these errors with the previous snapshot (from January 8,
2018). DHCP etc all worked properly the past couple of weeks, I was able to
copy large file sets through wifi etc.

So I tried a new build myself in case there was a mismatch between the
packages on firmware.openbsd.org and the latest snapshot but that did not
work.

Waited couple of days for a newer snapshot, installed it and still get the
following errors


Can you please try a kernel compiled from -current CVS source?

Such kernels work for me.


Sure thing. Will do and get back to you ASAP either tonight or tomorrow night.

Thanks very much,

Vijay


--
Vijay Sankar, M.Eng., P.Eng.
ForeTell Technologies Limited
vsan...@foretell.ca

Re: iwm errors with new snapshot

[Stefan Sperling]

On Tue, Jan 23, 2018 at 11:50:28AM -0600, Vijay Sankar wrote:
> Over the weekend, I was trying to do some tests requested in tech@
> (inteldrm). I downloaded the latest snapshot but had problems with iwm
> firmware on my laptops (X1 Carbon 5th gen)
> 
> I did not have these errors with the previous snapshot (from January 8,
> 2018). DHCP etc all worked properly the past couple of weeks, I was able to
> copy large file sets through wifi etc.
> 
> So I tried a new build myself in case there was a mismatch between the
> packages on firmware.openbsd.org and the latest snapshot but that did not
> work.
> 
> Waited couple of days for a newer snapshot, installed it and still get the
> following errors

Can you please try a kernel compiled from -current CVS source?

Such kernels work for me.

iwm errors with new snapshot

[Vijay Sankar]

Over the weekend, I was trying to do some tests requested in tech@  
(inteldrm). I downloaded the latest snapshot but had problems with iwm  
firmware on my laptops (X1 Carbon 5th gen)


I did not have these errors with the previous snapshot (from January  
8, 2018). DHCP etc all worked properly the past couple of weeks, I was  
able to copy large file sets through wifi etc.


So I tried a new build myself in case there was a mismatch between the  
packages on firmware.openbsd.org and the latest snapshot but that did  
not work.


Waited couple of days for a newer snapshot, installed it and still get  
the following errors


Jan 23 18:57:28 fla1 /bsd: iwm0: could not remove MAC context (error 35)
Jan 23 18:57:28 fla1 /bsd: iwm0: unhandled firmware response  
0xff/0xb810 rx ring 0[7]

Jan 23 18:57:35 fla1 /bsd: iwm0: could not add MAC context (error 35)
Jan 23 18:57:35 fla1 /bsd: iwm0: unhandled firmware response  
0xff/0xb810 rx ring 0[7]

Jan 23 18:57:55 fla1 /bsd: iwm0: could not add sta (error 35)
Jan 23 18:57:55 fla1 /bsd: iwm0: fatal firmware error
Jan 23 18:57:56 fla1 /bsd: iwm0: unhandled firmware response  
0xff/0xb810 rx ring 0[8]

Jan 23 18:58:02 fla1 /bsd: iwm0: fatal firmware error
Jan 23 18:58:03 fla1 /bsd: iwm0: could not remove MAC context (error 35)
Jan 23 18:58:03 fla1 /bsd: iwm0: unhandled firmware response  
0xff/0xb810 rx ring 0[22]


Not sure if it makes any difference but because I lost the two  
Ethernet dongles for the ThinkPads, I was doing the firmware update  
from a USB stick as follows:


fw_update -p /mnt/

OpenBSD -snapshots also were installed from install62.fs, not from a  
PXEBOOT that I usually do.


Here is the dmesg after installing the latest snapshot in case it is  
helpful. It has details about


OpenBSD 6.2-current (RAMDISK_CD) #376: Mon Jan 22 21:15:58 MST 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD

from the installation process and the OS currently installed

OpenBSD 6.2-current (GENERIC.MP) #384: Mon Jan 22 21:11:13 MST 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Please let me know if I am doing something wrong here or if there is  
anything I can do to help -- have two new ThinkPad X1 Carbon 5th to  
work with (as well as a bunch of other ThinkPads) if any tests would  
be useful.


Thanks very much,

Vijay







--
Vijay Sankar, M.Eng., P.Eng.
ForeTell Technologies Limited
vsan...@foretell.ca
OpenBSD 6.2-current (RAMDISK_CD) #376: Mon Jan 22 21:15:58 MST 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 16913035264 (16129MB)
avail mem = 16396693504 (15637MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x4f0e1000 (62 entries)
bios0: vendor LENOVO version "N1MET37W (1.22 )" date 07/04/2017
bios0: LENOVO 20HRCTO1WW
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT BOOT 
BATB SSDT SSDT SSDT WSMT SSDT SSDT DBGP DBG2 MSDM ASF! FPDT UEFI
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz, 2595.04 MHz
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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (RP01)
acpiprt2 at acpi0: bus -1 (RP02)
acpiprt3 at acpi0: bus 4 (RP03)
acpiprt4 at acpi0: bus -1 (RP04)
acpiprt5 at acpi0: bus 5 (RP05)
acpiprt6 at acpi0: bus -1 (RP06)
acpiprt7 at acpi0: bus -1 (RP07)
acpiprt8 at acpi0: bus -1 (RP08)
acpiprt9 at acpi0: bus 6 (RP09)
acpiprt10 at acpi0: bus -1 (RP10)
acpiprt11 at acpi0: bus -1 (RP11)
acpiprt12 at acpi0: bus -1 (RP12)
acpiprt13 at acpi0: bus -1 (RP13)
acpiprt14 at acpi0: bus -1 (RP14)
acpiprt15 at acpi0: bus -1 (RP15)
acpiprt16 at acpi0: bus -1 (RP16)
acpiprt17 at acpi0: bus -1 (RP17)
acpiprt18 at acpi0: bus -1 (RP18)
acpiprt19 at acpi0: bus -1 (RP19)
acpiprt20 at acpi0: bus -1 (RP20)
acpiprt21 at acpi0: bus -1 (RP21)
acpiprt22 at acpi0: bus -1 (RP22)
acpiprt23 at acpi0: bus -1 (RP23)
acpiprt24 at acpi0: bus -1 (RP24)
acpicpu at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpitz at acpi0 not configured
"LEN0268" at acpi0 not configured
"ACPI0003" at acpi0 not configured
"PNP0C0A" at acpi0 not configured

Re: After 6.1amd64 -> 6.2amd64 upgrade namecoind malloc(): free(): error

[Denis]

Running namecoind 13.2 for about two years. OpenBSD 6.1amd64 is the last
version which supports it.

On 6.2 I stuck with malloc() hardening. With no any malloc.conf options
I have these errors:

namecoind (4563) malloc():bogus pointer (double free?) 0xdfdfdfdfdfdfdfdf
namecoind (4563) free(): chunk is already free 0x1bc9981cae20

I get a bit different error while set 'S' to malloc.conf

ln -s 'S' /etc/malloc.conf

namecoind (2501) in free(): chunk canary corrupted 0x1ad4b3e5b3b0
0x2@0x2 (double free?)

Otto wrote that it means

overwrite of a buffer and/or a double free

Afterwards, I've searched on github.com for namecoin project using
malloc keyword, seems nothing changed since 13.2 in malloc functionality.

https://github.com/namecoin/namecoin-core/search?utf8=%E2%9C%93=malloc=

In two Cpp files developers initially reserved additional memory for
pointers plus allocation if I understand code right :

src/txmempool.h


Showing the top match Last indexed Jan 6, 2018
return memusage::/Malloc/Usage(sizeof(CTransactionRef) + 6 *
sizeof(void*)) * queuedTx.size() + cachedInnerUsage;


src/txmempool.cpp


Showing the top match Last indexed Jan 6, 2018
// Estimate the overhead of mapTx to be 15 pointers + an allocation, as
no exact formula for boost::multi_index_contained is implemented.

return memusage::/Malloc/Usage(sizeof(CTxMemPoolEntry) + 15 *
sizeof(void*)) * mapTx.size() + memusage::DynamicUsage(mapNextTx) +
memusage::DynamicUsage(mapDeltas) + memusage::DynamicUsage(mapLinks) +
memusage::DynamicUsage(vTxHashes) + cachedInnerUsage;

Could somebody help to fix namecoin malloc() to latest malloc
restrictions in OpenBSD 6.2 ?

Thank you in advance.

Denis

On 1/22/2018 4:20 PM, Otto Moerbeek wrote:
> On Mon, Jan 22, 2018 at 03:20:42PM +0300, Denis wrote:
>
>> Otto,
>>
>> Thank you for your hint.
>>
>> I've set to ln -s 'S' /etc/malloc.conf and error is a bit different now:
>>
>> namecoind (2501) in free(): chunk canary corrupted 0x1ad4b3e5b3b0
>> 0x2@0x2 (double free?)
> This means that there's an overwrite of a buffer and/or a double free.
> Another indication that something is wrong with memory management.
> Talk to the developers of namecoind
>
>   -Otto
>
>> Denis
>>
>> On 1/21/2018 1:46 PM, Otto Moerbeek wrote:
>>> On Sun, Jan 21, 2018 at 11:21:12AM +0100, Otto Moerbeek wrote:
>>>
 On Sun, Jan 21, 2018 at 12:41:50PM +0300, Denis wrote:

> I used namecoin on 6.1amd64 statically builded from source using boost
> 1.61 library. All works pretty fine before upgrade to 6.2amd64.
>
> I have rebuilt the the same namecoin source with boost 1.61 lib 
> statically.
> After running it on OpenBSD6.2amd64 I see the error with malloc() and
> free() listed below:
>
> namecoind (4563) malloc():bogus pointer (double free?) 0xdfdfdfdfdfdfdfdf
> namecoind (4563) free(): chunk is already free 0x1bc9981cae20
>
> Is something changed in malloc() since than?
> How to get work statically built  namecoin on 6.2?
>
> Thank you for answer in advance.
>
> Denis
 Yes, a few things changed, making malloc more strict.
 This is almost certainly a bug wrt memory management in namecoind. 

-Otto
>>> To diagnose this further, you can play with malloc options. See man
>>> malloc.conf.
>>> e.g. run with option S, which is even more strict. That might give you
>>> a hint where the bug is.
>>>
>>> -Otto
>>>

Disable external USB devices

[Stefan Wollny]

Hi there! This is a purely academical question out of curiosity: Is it
possible to disable all external USB interfaces without cutting the wire
on OpenBSD? You've heard stories of laptops/servers/routers with other
OSes being infected by some clever programms on USB sticks automatically
attaching to the running system without leaving obvious traces.
Assumption is that with OpenBSD and nothing like 'hotplug-diskmount'
installed this should not with be able, even with an unprivileged user
being logged in (with proper doas(1) rules applied). Nevertheless let us
assume some smart blackhat successfully finds a way to infect a running
OpenBSD system by attaching a USB device circumventing e.g. a full-disk
encryption. Or think of a desktop PC under the table where such a device
is not obviously visible. It may not help with Intel-like hardware bugs
but deactivated USB ports should be an extra hurdle for the casual
attacker. Of course any change should require physical access, 'root' and
a reboot (like with chflags(1)). I think disabling umass(4) at boot-time
or permanently might achieve s.th. like this - but what would be the side
effects to consider? KARL comes to my mind.
As the only OpenBSD system at hand is my laptop I do not dare to test by
disabling umass(4) as it is fully-encrypted with the key on a USB stick.
(Fiddling with the kernel on a production system seems to be a
second-class option anyway, right?) And if 'they' sneak into the system
e.g. via ugen(4)-attached devices... yes, I am aware that with enough
time, money and physical access 'they' will find a way, someday. There's
no safe computer - except not having one. Anyway - which other
ports/interfaces are at risk and could easily be disabled alike?
Bluetooth seems rather safe... ;-) Is there another smart way to do s.th.
like the described? I found nothing in the FAQ. Feasibility in practice
might be a matter of the level of paranoia ... or are blocked USB
interfaces nowadays a required precaution? Time for a BIG THANKYOU to the
developers for the most trustworthy OS out there! Best,STEFAN

Re: message authentication code incorrect

[Jan Stary]

On Jan 23 16:48:57, h...@stare.cz wrote:
> I just upgraded my current/amd64 and now con't ssh to it
> from an amd64 machien running the Jan 19 snapshot:

(or from any other machine.)

> $ ssh -v biblio.stare.cz
> OpenSSH_7.6, LibreSSL 2.7.0
> debug1: Reading configuration data /home/hans/.ssh/config
> debug1: /home/hans/.ssh/config line 1: Applying options for *
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Connecting to biblio.stare.cz [147.32.233.137] port 22.
> debug1: Connection established.
> debug1: identity file /home/hans/.ssh/id_rsa type 0
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/hans/.ssh/id_rsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/hans/.ssh/id_dsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/hans/.ssh/id_dsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/hans/.ssh/id_ecdsa type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/hans/.ssh/id_ecdsa-cert type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/hans/.ssh/id_ed25519 type -1
> debug1: key_load_public: No such file or directory
> debug1: identity file /home/hans/.ssh/id_ed25519-cert type -1
> debug1: Local version string SSH-2.0-OpenSSH_7.6
> debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6
> debug1: match: OpenSSH_7.6 pat OpenSSH* compat 0x0400
> debug1: Authenticating to biblio.stare.cz:22 as 'hans'
> debug1: SSH2_MSG_KEXINIT sent
> Bad packet length 1349676916.
> ssh_dispatch_run_fatal: Connection to 147.32.233.137 port 22: message 
> authentication code incorrect
> 
>   Jan
> 

message authentication code incorrect

[Jan Stary]

I just upgraded my current/amd64 and now con't ssh to it
from an amd64 machien running the Jan 19 snapshot:

$ ssh -v biblio.stare.cz
OpenSSH_7.6, LibreSSL 2.7.0
debug1: Reading configuration data /home/hans/.ssh/config
debug1: /home/hans/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to biblio.stare.cz [147.32.233.137] port 22.
debug1: Connection established.
debug1: identity file /home/hans/.ssh/id_rsa type 0
debug1: key_load_public: No such file or directory
debug1: identity file /home/hans/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/hans/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/hans/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/hans/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/hans/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/hans/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/hans/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6
debug1: match: OpenSSH_7.6 pat OpenSSH* compat 0x0400
debug1: Authenticating to biblio.stare.cz:22 as 'hans'
debug1: SSH2_MSG_KEXINIT sent
Bad packet length 1349676916.
ssh_dispatch_run_fatal: Connection to 147.32.233.137 port 22: message 
authentication code incorrect

Jan

Re: vmm support for QEMU possible (planned)?

[Denis]

Fixed.

On 1/23/2018 2:09 PM, Otto Moerbeek wrote:
> On Tue, Jan 23, 2018 at 12:04:36PM +0300, Denis wrote:
>
>> I'am interesting how to accelerate extremely slow QEMU software
>> emulation with vmm driver if was possible right now of in future releases.
>>
>> Does somebody have any results with it?
>>
>> Thank you for answer in advance.
>>
>> Denis
> Fixing your email should be your priority...
>
> I've three emails to you in my outgoing queue that cannot be deliverd
> because of "Connection closed unexpectedly"
>
>   -Otto
>

-- 
mailto: den...@mindall.org

Re: iked random tunnel drops

[danial]

I had something similar happening. In my case I solved it by disabling NAT-T
on one end.

/ Danial 



--
Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html

Re: vmm networking with ubuntu guest [SOLVED-ish]

[Carlos Cardenas]

On Tue, Jan 23, 2018 at 06:38:41PM +1100, tomr wrote:
> 
> So. This email was written before I had tried an earlier LTS version of
> ubuntu as the VMM guest. May the details below help someone else in future!   
> 
> Whatever the problem was, my workaround was to use 16.04-LTS instead 17.10
> 
> t
> 
> --
> 
> I'm trying to get an ubuntu guest running, but something is going wrong
> with its networking. Using the exact same vmd config (apart from disk
> images and lladdr), I can get both OpenBSD and alpine linux guests
> running just fine.

Howdy.

Thanks for reporting this.

The issue at hand is that newer versions of ubuntu have an "updated" vionet
guest driver which is causing issues to the vionet driver in vmd.


+--+
Carlos

Re: [6.2] pf nat-to ignoring static-port?

[Michael Price]

The lack of a quick keyword on that line makes me wonder if you have a
later rule that is matching.

Michael

On Mon, Jan 22, 2018 at 5:34 PM Martin Hlavatý  wrote:

> Interesting. I did a few tests now, and here are results.
>
> This doesn't map ports statically on 6.2 but does on 5.9:
> pass out from 10.11.12.13 to any nat-to 1.2.3.4 static-port
>
> This works fine:
> pass out quick from 10.11.12.13 to any nat-to 1.2.3.4 static-port
>
> This works fine too:
> match out from 10.11.12.13 to any nat-to 1.2.3.4 static-port
>
> Martin
>
>
> On Mon, Jan 22, 2018 at 8:23 PM, Michael Price 
> wrote:
> > It appears to be working on two boxes I checked using a match out rule.
> I’m
> > not using a binat-to line.
> >
> > Michael
> >
> > On Mon, Jan 22, 2018 at 10:49 AM Martin Hlavatý 
> wrote:
> >>
> >> Hello everyone,
> >> in December I upgraded from 5.9 to 6.2 (including 6.0 and
> >> 6.1) and shortly after that few customers contacted me
> >> that they are getting nat type 3 on their xbox\playstation.
> >> When doing some investigation, I noticed that binat-to
> >> rules have static-port specified, but looking into states
> >> table, they were actually not mapped statically. Failing
> >> over to backup box still running 5.9 with identical ruleset,
> >> ports are actually mapped statically and online gaming
> >> on consoles works fine.
> >>
> >> I tried to do some investigation, but am not aware of any
> >> change in pf syntax. So wondering if anyone would be
> >> able to confirm this behavior?
> >>
> >> this is in rules:
> >>
> >>   pass out inet from 10.11.12.13 to any flags S/SA nat-to 5.6.7.8
> >> static-port
> >>   pass in inet from any to 5.6.7.8 flags S/SA rdr-to 10.11.12.13
> >>
> >> and example of states:
> >>
> >> all udp 5.6.7.8:65350 (10.11.12.13:3074) -> 52.166.52.75:1986
> >> MULTIPLE:MULTIPLE
> >> all tcp 5.6.7.8:63203 (10.11.12.13:38010) -> 31.13.91.33:443
> >> ESTABLISHED:ESTABLISHED
> >> all tcp 5.6.7.8:59711 (10.11.12.13:42530) -> 74.125.133.188:5228
> >> ESTABLISHED:ESTABLISHED
> >>
> >>
> >>
> >> Regards,
> >> Martin
> >>
> >
>

Re: vmm support for QEMU possible (planned)?

[Otto Moerbeek]

On Tue, Jan 23, 2018 at 12:04:36PM +0300, Denis wrote:

> I'am interesting how to accelerate extremely slow QEMU software
> emulation with vmm driver if was possible right now of in future releases.
> 
> Does somebody have any results with it?
> 
> Thank you for answer in advance.
> 
> Denis

Fixing your email should be your priority...

I've three emails to you in my outgoing queue that cannot be deliverd
because of "Connection closed unexpectedly"

-Otto

Re: nat-to (least-states / round-robin) problem

[Kapetanakis Giannis]

On 23/01/18 11:08, Kapetanakis Giannis wrote:
> Hi,
> 
> I've discovered something that looks like a bug in nat translation with 
> least-states or round-robin
> 
> Instead of using the nat-pool is uses wrong IPs
> 
> # pfctl -sr -R0
> pass out log quick on vlan123 inet from xx.xx.xx.xx to 188.113.88.193 flags 
> S/SA tagged from_internal nat-to xx.xx.yy.24/29 least-states
> 
> Jan 23 10:59:06.602884 rule 0/(match) pass out on vlan123: 0.0.0.0.62722 > 
> 188.113.88.193.80: S 3243156923:3243156923(0) win 29200  1460,sackOK,timestamp 3169583207 0,nop,wscale 9> (DF)
> Jan 23 10:59:21.836380 rule 0/(match) pass out on vlan123: 0.0.0.1.57696 > 
> 188.113.88.193.80: S 1280038032:1280038032(0) win 29200  1460,sackOK,timestamp 3169598441 0,nop,wscale 9> (DF)
> 
> See the 0.0.0.0 address? That's the first packet. The second packet (2nd 
> wget) uses the next IP, 0.0.0.1 etc.
> 
> The same problem is with round-robin
> 10:54:24.750786 0.0.0.2.50332 > 188.113.88.193.80: S 1923288633:1923288633(0) 
> win 29200  (DF)
> 10:54:28.078831 0.0.0.3.50350 > 188.113.88.193.80: S 925801869:925801869(0) 
> win 29200  (DF)
> 
> If I use random or source-hash I have no problem.
> 
> Maybe this is fixed in current but I though I should report.
> # head -1 /var/run/dmesg.boot
> OpenBSD 6.2-beta (GENERIC.MP) #104: Mon Sep 18 23:31:27 MDT 2017
> 
> I'll try an upgrade later today...
> 
> G
> 
same problem with latest snapshot:
OpenBSD 6.2-current (GENERIC.MP) #382: Sun Jan 21 14:13:38 MST 2018

G

Re: smtpd fails to start

[Jordan Geoghegan]

If you ever find yourself in Western Canada, I'll be happy to keep that 
promise.



On 01/23/18 01:40, Gilles Chehade wrote:

I will remember that promise.

On Tue, Jan 23, 2018 at 01:37:37AM -0800, Jordan Geoghegan wrote:

Thank you Gilles! I knew it was going to be something irritatingly obvious.
I owe you a beer.

Cheers,

Jordan Geoghegan


# pkg_add opensmtpd-extras
quirks-2.367 signed on 2017-10-03T11:21:28Z
opensmtpd-extras-2017031321...:gettext-0.19.8.1p1: ok
opensmtpd-extras-2017031321...:libffi-3.2.1p2: ok
opensmtpd-extras-2017031321...:python-2.7.14: ok
opensmtpd-extras-201703132115p1: ok
--- +python-2.7.14 ---
If you want to use this package as your default system python, as root
create symbolic links like so (overwriting any previous default):
  ln -sf /usr/local/bin/python2.7 /usr/local/bin/python
  ln -sf /usr/local/bin/python2.7-2to3 /usr/local/bin/2to3
  ln -sf /usr/local/bin/python2.7-config /usr/local/bin/python-config
  ln -sf /usr/local/bin/pydoc2.7  /usr/local/bin/pydoc
# rcctl restart smtpd
smtpd(ok)
#


On 01/23/18 01:31, Gilles Chehade wrote:

On Tue, Jan 23, 2018 at 01:21:22AM -0800, Jordan Geoghegan wrote:

Hi Gilles,

The output of the command you sent:

# smtpd -dv
smtpd: table_create: backend "passwd" does not exist

I'm not sure what this means, as /etc/mail/passwd does indeed exist.

Thanks for the fast response!


you need to install the opensmtpd-extras package from ports to use
the table-passwd add-on

Re: smtpd fails to start

[Gilles Chehade]

I will remember that promise.

On Tue, Jan 23, 2018 at 01:37:37AM -0800, Jordan Geoghegan wrote:
> Thank you Gilles! I knew it was going to be something irritatingly obvious.
> I owe you a beer.
> 
> Cheers,
> 
> Jordan Geoghegan
> 
> 
> # pkg_add opensmtpd-extras
> quirks-2.367 signed on 2017-10-03T11:21:28Z
> opensmtpd-extras-2017031321...:gettext-0.19.8.1p1: ok
> opensmtpd-extras-2017031321...:libffi-3.2.1p2: ok
> opensmtpd-extras-2017031321...:python-2.7.14: ok
> opensmtpd-extras-201703132115p1: ok
> --- +python-2.7.14 ---
> If you want to use this package as your default system python, as root
> create symbolic links like so (overwriting any previous default):
>  ln -sf /usr/local/bin/python2.7 /usr/local/bin/python
>  ln -sf /usr/local/bin/python2.7-2to3 /usr/local/bin/2to3
>  ln -sf /usr/local/bin/python2.7-config /usr/local/bin/python-config
>  ln -sf /usr/local/bin/pydoc2.7  /usr/local/bin/pydoc
> # rcctl restart smtpd
> smtpd(ok)
> #
> 
> 
> On 01/23/18 01:31, Gilles Chehade wrote:
> > On Tue, Jan 23, 2018 at 01:21:22AM -0800, Jordan Geoghegan wrote:
> > > Hi Gilles,
> > > 
> > > The output of the command you sent:
> > > 
> > > # smtpd -dv
> > > smtpd: table_create: backend "passwd" does not exist
> > > 
> > > I'm not sure what this means, as /etc/mail/passwd does indeed exist.
> > > 
> > > Thanks for the fast response!
> > > 
> > you need to install the opensmtpd-extras package from ports to use
> > the table-passwd add-on
> > 
> > 
> > 
> 

-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

Re: smtpd fails to start

[Jordan Geoghegan]

Thank you Gilles! I knew it was going to be something irritatingly 
obvious. I owe you a beer.


Cheers,

Jordan Geoghegan


# pkg_add opensmtpd-extras
quirks-2.367 signed on 2017-10-03T11:21:28Z
opensmtpd-extras-2017031321...:gettext-0.19.8.1p1: ok
opensmtpd-extras-2017031321...:libffi-3.2.1p2: ok
opensmtpd-extras-2017031321...:python-2.7.14: ok
opensmtpd-extras-201703132115p1: ok
--- +python-2.7.14 ---
If you want to use this package as your default system python, as root
create symbolic links like so (overwriting any previous default):
 ln -sf /usr/local/bin/python2.7 /usr/local/bin/python
 ln -sf /usr/local/bin/python2.7-2to3 /usr/local/bin/2to3
 ln -sf /usr/local/bin/python2.7-config /usr/local/bin/python-config
 ln -sf /usr/local/bin/pydoc2.7  /usr/local/bin/pydoc
# rcctl restart smtpd
smtpd(ok)
#


On 01/23/18 01:31, Gilles Chehade wrote:

On Tue, Jan 23, 2018 at 01:21:22AM -0800, Jordan Geoghegan wrote:

Hi Gilles,

The output of the command you sent:

# smtpd -dv
smtpd: table_create: backend "passwd" does not exist

I'm not sure what this means, as /etc/mail/passwd does indeed exist.

Thanks for the fast response!


you need to install the opensmtpd-extras package from ports to use
the table-passwd add-on

Re: http_proxy for rc.firsttime after Upgrade

[Raimo Niskanen]

On Mon, Jan 22, 2018 at 08:22:34PM -0500, trondd wrote:
> On Mon, January 22, 2018 2:36 am, Raimo Niskanen wrote:
> > On Fri, Jan 19, 2018 at 10:47:15AM -0500, trondd wrote:
> >> On Fri, January 19, 2018 4:29 am, Raimo Niskanen wrote:
> >> > Hello list!
> >> >
> >> > I have some machines behind a squid proxy and have set the http_proxy
> >> and
> >> > ftp_proxy environment variables both in /etc/profile and in
> >> > /etc/login.conf
> >> > for the default login class.  This works well.
> >> >
> >> > But after an upgrade when rc.firsttime calls fw_update and checks for
> >> > binary patches the proxy is not used, so I have to wait for that to
> >> time
> >> > out or break it with Ctrl-C and call fw_update manually.
> >> >
> >> > So I just wonder if anybody have an idea of how to set the http_proxy
> >> and
> >> > ftp_proxy environment variables so they are picked up by rc.firsttime?
> >> >
> >> > Best regards
> >> > --
> >> >
> >> > / Raimo Niskanen, Erlang/OTP, Ericsson AB
> >> >
> >>
> >> I submitted a patch for this:
> >> https://marc.info/?l=openbsd-tech=151260860105270=2
> >
> > That sure looks like an improvement!  But should maybe $http_proxy be
> > placed between single quotes?
> >
> > Unfortunately I fetch the sets into /var/OpenBSD/`machine` and verify them
> > before rebooting into /bsd62.rd, so it would not work for me...
> >
> >>
> >> In the meantime, before reboot, you can edit the rc.firstime script
> >> after
> >> installation.
> >
> > I'll try that trick next time.  Thank you!
> >
> >>
> >> Tim.
> >
> > --
> >
> > / Raimo Niskanen, Erlang/OTP, Ericsson AB
> >
> 
> Ah, I see.  Yeah, I only acconted for the obvious case when a net install
> was done.
> 
> Having thought about it again, an easier solution will be to write your
> http_proxy export to /etc/rc.firsttime before rebooting into bsd.rd.  If
> you have your update process scripted already, it's an easy additional
> line.  The installer only appends commands so anything you have in
> rc.firsttime will be preserved.
> 
> Tim.
> 

In my case it would work if rc.firsttime sourced /etc/profile, but I do not
know if that is a generally good idea..., in particular since I can not
find any way to set environment variables for /etc/rc to pass to system and
package daemons.

Is this a feature or a missing feature???

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB

Re: smtpd fails to start

[Gilles Chehade]

On Tue, Jan 23, 2018 at 01:21:22AM -0800, Jordan Geoghegan wrote:
> Hi Gilles,
> 
> The output of the command you sent:
> 
> # smtpd -dv
> smtpd: table_create: backend "passwd" does not exist
> 
> I'm not sure what this means, as /etc/mail/passwd does indeed exist.
> 
> Thanks for the fast response!
> 

you need to install the opensmtpd-extras package from ports to use
the table-passwd add-on



-- 
Gilles Chehade

https://www.poolp.org  @poolpOrg

Re: smtpd fails to start

[Jordan Geoghegan]

Hi Gilles,

The output of the command you sent:

# smtpd -dv
smtpd: table_create: backend "passwd" does not exist

I'm not sure what this means, as /etc/mail/passwd does indeed exist.

Thanks for the fast response!



On 01/22/18 23:58, Gilles Chehade wrote:

you almost managed to give enough information to troubleshoot...

... except for logs displaying the problem :-)

`smtpd -dv` will provide useful information

nat-to (least-states / round-robin) problem

[Kapetanakis Giannis]

Hi,

I've discovered something that looks like a bug in nat translation with 
least-states or round-robin

Instead of using the nat-pool is uses wrong IPs

# pfctl -sr -R0
pass out log quick on vlan123 inet from xx.xx.xx.xx to 188.113.88.193 flags 
S/SA tagged from_internal nat-to xx.xx.yy.24/29 least-states

Jan 23 10:59:06.602884 rule 0/(match) pass out on vlan123: 0.0.0.0.62722 > 
188.113.88.193.80: S 3243156923:3243156923(0) win 29200  (DF)
Jan 23 10:59:21.836380 rule 0/(match) pass out on vlan123: 0.0.0.1.57696 > 
188.113.88.193.80: S 1280038032:1280038032(0) win 29200  (DF)

See the 0.0.0.0 address? That's the first packet. The second packet (2nd wget) 
uses the next IP, 0.0.0.1 etc.

The same problem is with round-robin
10:54:24.750786 0.0.0.2.50332 > 188.113.88.193.80: S 1923288633:1923288633(0) 
win 29200  (DF)
10:54:28.078831 0.0.0.3.50350 > 188.113.88.193.80: S 925801869:925801869(0) win 
29200  (DF)

If I use random or source-hash I have no problem.

Maybe this is fixed in current but I though I should report.
# head -1 /var/run/dmesg.boot
OpenBSD 6.2-beta (GENERIC.MP) #104: Mon Sep 18 23:31:27 MDT 2017

I'll try an upgrade later today...

G

vmm support for QEMU possible (planned)?

[Denis]

I'am interesting how to accelerate extremely slow QEMU software
emulation with vmm driver if was possible right now of in future releases.

Does somebody have any results with it?

Thank you for answer in advance.

Denis

Re: Boot problem OpenBSD 6.2 amd64 softraid keydisk

[Raimo Niskanen]

On Mon, Jan 22, 2018 at 11:16:29AM +0100, Stefan Sperling wrote:
> On Mon, Jan 22, 2018 at 10:08:30AM +0100, Raimo Niskanen wrote:
> > Hello misc@!
> > 
> > I just wanted to share a problem and a solution that I encountered.  Just
> > posting to maybe help someone else in the future, and perhaps a developer
> > feels that improving a particular error message could be important enough.
> > 
> > My goal was to create an installation with a fully encrypted hard drive
> > using a keydisk, and at first reboot into the installed system I got this:
> > 
> > Booting from hard disk...
> > Using drive 0, partition 3.
> > Loading..
> > probing: pc0 com0 com1 mem[638K 3582M 496M a20=on]
> > disk: hd0+ hd1+ hd2 sr0*
> > >> OpenBSD/amd64 BOOT 3.33
> > unknown KDF type 2
> > open(sr0a:/etc/boot.conf): Operation not permitted
> > boot>
> > 
> > The error message "unknown KDF type 2" is the one that maybe could
> > be improved...
> 
> This error message has already been improved in -current by sunil@ in r1.3 of
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/lib/libsa/softraid.c
> The message now says ""keydisk not found".

Excellent!

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB

vmm networking with ubuntu guest [SOLVED-ish]

[tomr]

So. This email was written before I had tried an earlier LTS version of
ubuntu as the VMM guest. May the details below help someone else in future! 

Whatever the problem was, my workaround was to use 16.04-LTS instead 17.10

t

--

I'm trying to get an ubuntu guest running, but something is going wrong
with its networking. Using the exact same vmd config (apart from disk
images and lladdr), I can get both OpenBSD and alpine linux guests
running just fine.

Ignoring DHCP for a moment (which works fine in obsd and alpine), I went
ahead and configured a static IP address in the ubuntu (network-)
installer of 192.168.199.2/24.

Running vmd with "-dvvv" I see this repeated a lot:

vionet queue notify - no space, dropping packet

tcpdump repeats this:

tap0:
17:39:10.904793 arp who-has 192.168.199.1 tell 192.168.199.2
17:39:10.904801 arp who-has 192.168.199.1 tell 192.168.199.2
17:39:10.904825 arp reply 192.168.199.1 is-at fe:e1:ba:d0:c5:9b

vether0:
17:39:10.904807 arp who-has 192.168.199.1 tell 192.168.199.2

bridge0:
17:38:30.579065 arp who-has 192.168.199.1 (ff:ff:ff:ff:ff:ff) tell
192.168.199.2
17:38:30.579104 arp reply 192.168.199.1 is-at fe:e1:ba:d0:c5:9b

For each repeat of the arp request, the vionet error from vmd above
repeats once, starting with the first request.

vm.conf, vmd -dvvv output, hostname.vether0, hostname.bridge0 and dmesg
follow. I've left a few details out (net.inet.ip.forwarding, pf config,
dhcpd, etc) because a) the other guests work fine like this, and b)
enabling/disabling the other things hasn't made any material difference.
Apols if I've left something relevant out, and for the
less-than-100%-openbsd-related nature of my question.

thanks for reading,
tomr


### vm.conf
switch "uplink" {
interface bridge0
}

vm "ubuntu" {
disk "/home/tomr/vms/ubuntu.iso"
disk "/home/tomr/vms/ubuntu.img"
memory 2g
interface {
switch "uplink"
lladdr 00:00:00:00:00:02
}
owner tomr
disable
}

vm "alpine" {
#   disk "/home/tomr/vms/alpine.iso"
disk "/home/tomr/vms/alpine-virt.img"
memory 2g
interface {
switch "uplink"
lladdr 00:00:00:00:00:03
}
owner tomr
disable
}

vm "obsd" {
#   disk "/home/tomr/vms/install62.fs"
#   boot "/bsd.rd"
disk "/home/tomr/vms/obsd.img"
memory 2g
interface {
switch "uplink"
lladdr 00:00:00:00:00:04
}
owner tomr
disable
}

### vmd output for ubuntu vm
startup
/etc/vm.conf:5: switch "uplink" registered
vm_register: registering vm 1
/etc/vm.conf:17: vm "ubuntu" registered (disabled)
vm_register: registering vm 2
/etc/vm.conf:29: vm "alpine" registered (disabled)
vm_register: registering vm 3
/etc/vm.conf:42: vm "obsd" registered (disabled)
vm_priv_brconfig: interface bridge0 description switch1-uplink
vmd_configure: not creating vm ubuntu (disabled)
vmd_configure: not creating vm alpine (disabled)
vmd_configure: not creating vm obsd (disabled)
config_setconfig: setting config
config_getconfig: retrieving config
config_getconfig: retrieving config
config_getconfig: retrieving config
vm_opentty: vm ubuntu tty /dev/ttyp7 uid 1000 gid 4 mode 620
vm_register: registering vm 1
vm_priv_ifconfig: interface tap0 description vm1-if0-ubuntu
vm_priv_ifconfig: switch "uplink" interface bridge0 add tap0
ubuntu: started vm 1 successfully, tty /dev/ttyp7
loadfile_bios: loaded BIOS image
run_vm: initializing hardware for vm ubuntu
virtio_init: vm "ubuntu" vio0 lladdr 00:00:00:00:00:02
run_vm: starting vcpu threads for vm ubuntu
vcpu_reset: resetting vcpu 0 for vm 7
run_vm: waiting on events for VM ubuntu
i8259_write_datareg: master pic, reset IRQ vector to 0x8
i8259_write_datareg: slave pic, reset IRQ vector to 0x70
vcpu_exit_i8253: channel 0 reset, mode=0, start=65535
virtio_blk_io: device reset
virtio_blk_io: device reset
vcpu_process_com_lcr: set baudrate = 115200
vcpu_exit_i8253: channel 2 reset, mode=7, start=65535
vcpu_exit_i8253: channel 2 reset, mode=7, start=65535
vcpu_exit_i8253: channel 2 reset, mode=7, start=65535
vcpu_exit_i8253: channel 2 reset, mode=7, start=65535
i8259_write_datareg: master pic, reset IRQ vector to 0x30
i8259_write_datareg: slave pic, reset IRQ vector to 0x38
vcpu_process_com_lcr: set baudrate = 115200
vcpu_exit_i8253: channel 0 reset, mode=1, start=4773
vcpu_exit_i8253: channel 2 reset, mode=7, start=65535
vcpu_exit_i8253: channel 2 reset, mode=7, start=65535
vcpu_exit_i8253: channel 2 reset, mode=7, start=65535
vcpu_exit_i8253: channel 2 reset, mode=7, start=65535
virtio_blk_io: device reset
virtio_blk_io: device reset
virtio_net_io: device reset
vcpu_process_com_lcr: set baudrate = 115200
vcpu_process_com_data: guest reading com1 when not ready
vcpu_process_com_data: guest reading com1 when not ready
vcpu_process_com_data: guest reading com1 when not ready
vcpu_process_com_lcr: set