Re: fw_update verify firmware?

[Theo de Raadt]

The firmwares are packages, and are signed with the
/etc/signify/openbsd-XX-fs.pub key.

There is no risk.


Mogens Jensen  wrote:

> I was just trying out the fw_update program on OpenBSD 6.5, deleting/
> installing all the firmware and was wondering if fw_update will verify
> the files before installing?
> 
> There is a SHA256.sig in the remote firmware directory, but no
> indication from fw_update, even with verbose output, if this is
> actually used.
> 
> After looking at the source and manpage of fw_update, it was still not
> clear to me if files are checked against SHA256.sig. For syspatch, it's
> easy to tell from both source, manpage and program output.
> 
> Normally I would just assume that fetched files are verified, but maybe
> in the case with fw_update, the rationale is that firmware files are
> binary blobs so we can't know if they are malicious anyway, therefore
> no reason to bother with verification.
> 
> As firmware is fetched over plain HTTP, I guess that in case of no
> verification it would in theory make the system vulnerable to a MITM
> attack, but I'm no expert.
> 
> 
> Regards,
> Mogens Jensen
> 

Re: Intel I210 Fiber Optic Ethernet Card Transceiver Info.

[Vertigo Altair]

Hi,


Sorry for late reply but I had a problem accessing this device.

I’ve tried both OpenBSD 6.6 and 6.7 (amd64), nothing changed:

I think you’re probably right; transceiver command is only available for
ix(4) driver.

But what about ifconfig em0 media output showing only supporting
SX/multi-mode but actually supporting LX-/single-mode too?


Here it is; dmesg:


OpenBSD 6.7 (GENERIC.MP ) #182: Thu May  7 11:11:58 MDT
2020

dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP


real mem = 17122398208 (16329MB)

avail mem = 16590856192 (15822MB)

mpath0 at root

scsibus0 at mpath0: 256 targets

mainbus0 at root

bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7f20a000 (52 entries)

bios0: vendor American Megatrends Inc. version "5.13" date 09/16/2019

bios0: Lanner Electronics Default string

acpi0 at bios0: ACPI 6.1

acpi0: sleep states S0 S5

acpi0: tables DSDT FACP FPDT FIDT MCFG WDAT APIC BDAT HPET UEFI SSDT DMAR
SPCR TPM2 HEST BERT ERST EINJ WSMT

acpi0: wakeup devices PEX0(S0) PEX1(S0) PEX2(S0) PEX3(S0) PEX4(S0) PEX5(S0)
PEX6(S0) PEX7(S0) XHC1(S4) LAN0(S0) LAN1(S0) LAN2(S0) LAN3(S0)

acpitimer0 at acpi0: 3579545 Hz, 24 bits

acpimcfg0 at acpi0

acpimcfg0: addr 0xe000, bus 0-255

acpimadt0 at acpi0 addr 0xfee0: PC-AT compat

cpu0 at mainbus0: apid 4 (boot processor)

cpu0: Intel(R) Atom(TM) CPU C3558 @ 2.20GHz, 2200.41 MHz, 06-5f-01

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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES

cpu0: 2MB 64b/line 16-way L2 cache

cpu0: smt 0, core 2, package 0

mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges

cpu0: apic clock running at 25MHz

cpu0: mwait min=64, max=64, C-substates=0.2.0.2, IBE

cpu1 at mainbus0: apid 12 (application processor)

cpu1: Intel(R) Atom(TM) CPU C3558 @ 2.20GHz, 2200.02 MHz, 06-5f-01

cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES

cpu1: 2MB 64b/line 16-way L2 cache

cpu1: smt 0, core 6, package 0

cpu2 at mainbus0: apid 16 (application processor)

cpu2: Intel(R) Atom(TM) CPU C3558 @ 2.20GHz, 2200.02 MHz, 06-5f-01

cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES

cpu2: 2MB 64b/line 16-way L2 cache

cpu2: smt 0, core 8, package 0

cpu3 at mainbus0: apid 24 (application processor)

cpu3: Intel(R) Atom(TM) CPU C3558 @ 2.20GHz, 2200.02 MHz, 06-5f-01

cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES

cpu3: 2MB 64b/line 16-way L2 cache

cpu3: smt 0, core 12, package 0

ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins

acpihpet0 at acpi0: 2399 Hz

acpiprt0 at acpi0: bus 0 (PCI0)

acpiprt1 at acpi0: bus 2 (PEX0)

acpiprt2 at acpi0: bus 3 (PEX1)

acpiprt3 at acpi0: bus 4 (PEX2)

acpiprt4 at acpi0: bus -1 (PEX3)

acpiprt5 at acpi0: bus 5 (PEX4)

acpiprt6 at acpi0: bus 6 (PEX5)

acpiprt7 at acpi0: bus 7 (PEX6)

acpiprt8 at acpi0: bus 8 (PEX7)

acpiprt9 at acpi0: bus 1 (VRP2)

acpiprt10 at acpi0: bus 9 (VRP0)

acpiprt11 at acpi0: bus 10 (VRP1)

acpicpu0 at acpi0: C1(@1 halt!)

acpicpu1 at acpi0: C1(@1 halt!)

acpicpu2 at acpi0: C1(@1 halt!)

acpicpu3 at acpi0: C1(@1 halt!)

acpitz0 at acpi0: critical temperature is 91 degC

acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x

"PNP0003" at acpi0 not configured

acpicmos0 at acpi0

"PNP0C33" at acpi0 not configured

"MSFT0101" at acpi0 not configured

pci0 at mainbus0 bus 0

0:31:5: mem address conflict 0xfe01/0x1000

pchb0 at pci0 dev 0 function 0 "Intel C3000 Host" rev 0x11

pchb1 at pci0 dev 4 function 0 "Intel C3000 GLREG" rev 0x11

"Intel C3000 

Re: using aggr interface instead of trunk

[Iain R. Learmonth]

Hi,

On 13/05/2020 13:10, mabi wrote:

> I am currently running OpenBSD 6.5 as firewall with two ix interfaces inside 
> a trunk interface with LACP protocol. On top of that I have a few vlan 
> interfaces so it's basically (ix -> trunk -> vlan).
>
> Now I saw that OpenBSD has a new interface specifically for LACP which is 
> called aggr. As I will soon be upgrading to OpenBSD 6.6 I was wondering if it 
> is the right time to switch from trunk to the new aggr interface?

More details are at: https://marc.info/?l=openbsd-cvs=156229058006706=2

> From what I understand the new aggr interface has mainly 2 advantages: it is 
> multi-processor safe and it should be faster than the tun interface. Is this 
> correct?

Assuming you mean trunk, not tun, yes.

> And last point because aggr is pretty new, is it already safe to use it for a 
> production firewall?

I don't see mention of any aggr fixes in the 6.7 changelog, so I guess it 
didn't have any disasters in it. Others are using it on production systems.

Thanks,
Iain.

-- 
https://hambsd.org/

Re: unveil documentation

[Theo de Raadt]

Kevin Chadwick  wrote:

> The unveil man page is perfectly correct and it is not hard to test it's 
> behaviour.
> 
> I just wonder if it may aid unveil adoption in languages other than C, if it
> explicitly mentioned that exec is not required on a dir to allow reading the
> files within, e.g. if the dev is more used to filesystem permissions than OS
> functions?
> 
> Perhaps a FAQ on unveil is intended instead, time permitting? Perhaps a link 
> to
> the following paper or whichever best demonstrates usage, could be added to 
> the
> faq for now?
> 
> https://lteo.net/assets/pdf/lteo-openbsd-carolinacon15-20190427.pdf
> 
> Trying to help provide differing perspectives and not just create work for 
> people.
> 
> Feel free to ignore me, obviously.

It would be improper if every manual page had to start from the foundation
and explain every intrinsic unix behaviour.

unveil is not doing anything special here.

unveil documentation

[Kevin Chadwick]

The unveil man page is perfectly correct and it is not hard to test it's 
behaviour.

I just wonder if it may aid unveil adoption in languages other than C, if it
explicitly mentioned that exec is not required on a dir to allow reading the
files within, e.g. if the dev is more used to filesystem permissions than OS
functions?

Perhaps a FAQ on unveil is intended instead, time permitting? Perhaps a link to
the following paper or whichever best demonstrates usage, could be added to the
faq for now?

https://lteo.net/assets/pdf/lteo-openbsd-carolinacon15-20190427.pdf

Trying to help provide differing perspectives and not just create work for 
people.

Feel free to ignore me, obviously.

Re: Any plans to support newer Loongson-based systems?

[Juan Francisco Cantero Hurtado]

On Tue, May 12, 2020 at 11:46:58AM -0300, Fabio Martins wrote:
> 
> I believe loongson people are primaly after running some Linux distros for
> their processor (new ones), but maybe if you ask them directly about their
> plans to donate people's effort / hardware to OpenBSD, might be a good
> start:

For the record, they donated a board (or a full system, I don't know) a
few years ago. We forgot to add them to the list of donations.

> 
> I asked some months ago about buying Loongson out of China to play wth,
> but got no luck.
> 
> main point of contact inside Loongson, at least for for alpine Linux port,
> is this one:
> 
>  
> 
> maybe some others can help:
> 
> www.loongson.cn
> 
> be safe.
> 
> -- 
> Fabio Martins
> 
> 
> > According to https://www.openbsd.org/loongson.html only some old
> > Loongson-based systems are supported.
> >
> > Are there any plans to support the more recent Loongson 3A3000- or the
> > current 3A4000-based systems?
> >
> > I do not know where OpenBSD MIPS developers are located.
> > Apparently the Loongson-based systems are not easily available outside
> > China, but it seems Chinese merchants are selling 3A4000+mainboard
> > bundles for somewhat less than 500 €, though I do not know if any of
> > them ship outside China.
> >
> > Philipp
> >
> >
> 
> 
> 
> 

-- 
Juan Francisco Cantero Hurtado http://juanfra.info

using aggr interface instead of trunk

[mabi]

Hello,

I am currently running OpenBSD 6.5 as firewall with two ix interfaces inside a 
trunk interface with LACP protocol. On top of that I have a few vlan interfaces 
so it's basically (ix -> trunk -> vlan).

Now I saw that OpenBSD has a new interface specifically for LACP which is 
called aggr. As I will soon be upgrading to OpenBSD 6.6 I was wondering if it 
is the right time to switch from trunk to the new aggr interface?

>From what I understand the new aggr interface has mainly 2 advantages: it is 
>multi-processor safe and it should be faster than the tun interface. Is this 
>correct?

And last point because aggr is pretty new, is it already safe to use it for a 
production firewall?

Best regards,
Mabi

Re: OpenBSD insecurity rumors from isopenbsdsecu.re

[Marko Cupać]

On 2020-05-13 11:02, i...@aulix.com wrote:

(all your emails to @misc)


Dear Info,

the best way to get answers to all of your questions regarding OpenBSD 
is to try and run OpenBSD for a few years trying to make it help with 
your real-world needs, such as personal laptop, home gateway, personal 
email or web server etc. After some time, you will be able to decide 
wheather OpenBSD is the right choice for you.


You should be able to find majority of answers to your questions 
regarding OpenBSD in manpages, FAQ, and books similar to "Absolute 
OpenBSD", "The Book of PF" etc. There are also various blogs from 
OpenBSD users, whose quality varies from very bad to very good.


As for idle gossip, I can suggest local bars, which is what I use. I 
understand they are all closed now due to current situation with 
pandemic, but @misc mailing list is really poor substitute.


Regards,
--
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: OpenBSD insecurity rumors from isopenbsdsecu.re

[info]

> This is "testing the waters" racism.

Where did you find an indication of a racism?

Re: OpenSSH FIDO (Nitrokey) support (Was: Re: OpenBSD insecurity rumors from isopenbsdsecu.re)

[info]

Btw, thanks for this site link, may be something like:

https://web.archive.org/web/20200513115537/https://undeadly.org/cgi?action=article=20190302235509

could work.

> On Wed, May 13, 2020 at 12:59:26PM +0200, i...@aulix.com wrote:
> 
>> Thanks for your suggestion,
>>
>> but googling for keys: +openbsd +nitrokey
>>
>> does not indicate anything interesting except a few of my own questions on 
>> the Nitrokey support forum.
> 
> I had to look up "Nitrokey" to verify that it was what I thought it was, but 
> that had me
> do a quick search for "OpenSSH FIDO support", which turned up among other 
> things this
> article: https://undeadly.org/cgi?action=article;sid=20191115064850 as well 
> as a number
> of blog posts and HOWTO-ish pieces that seem to indicate that quite likely 
> the combination
> would work.
> 
> I haven't tried the thing myself, but you should be able to find the same 
> stuff I did
> on the web. Then you could probably find a way to test with an OpenBSD setup 
> in a way
> that does not break things too horribly in case anything fails.
> 
> All the best,
> 
> --
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: OpenBSD insecurity rumors from isopenbsdsecu.re

[Paul Wisehart]

On Tue, May 12, 2020 at 05:09:16AM +0200, i...@aulix.com wrote:
> Treat it as my secret, I want and that is why I ask because I can, I wish you 
> tell me the answer without a knowledge of "why I ask",
> it is a very long discussion of answering by a question to question in your 
> Jewish style, is not it?

NOPE.
This is "testing the waters" racism.  NOPE NOPE NOPE.
We have this in the US right now all over the place.
This is casual "slip in some comment and see" if I can ramp it up.

It might not seem like a big deal, but I'm seeing nazi flags and 
confederate flags IRL now, and I think this right here is how it 
starts.

GTFO

Re: OpenSSH FIDO (Nitrokey) support (Was: Re: OpenBSD insecurity rumors from isopenbsdsecu.re)

[info]

Thanks for suggestion, I already have seen it and even contacted SSH developer 
Damien Miller regarding FIDO key support a few weeks ago.

What I am looking for right now is something different, it is if 
ssh-pkcs11-helper works with SSHD daemon on OpenBSD to store there its server 
private key in a general Nitrokey Pro 2 (not HSM).

Btw, I am going to use several client side dongles at once for a single SSH 
session like Rutoken ECP2, FIDO2, and Nitrokey Pro 2 only on the server yet.


> On Wed, May 13, 2020 at 12:59:26PM +0200, i...@aulix.com wrote:
> 
>> Thanks for your suggestion,
>>
>> but googling for keys: +openbsd +nitrokey
>>
>> does not indicate anything interesting except a few of my own questions on 
>> the Nitrokey support forum.
> 
> I had to look up "Nitrokey" to verify that it was what I thought it was, but 
> that had me
> do a quick search for "OpenSSH FIDO support", which turned up among other 
> things this
> article: https://undeadly.org/cgi?action=article;sid=20191115064850 as well 
> as a number
> of blog posts and HOWTO-ish pieces that seem to indicate that quite likely 
> the combination
> would work.
> 
> I haven't tried the thing myself, but you should be able to find the same 
> stuff I did
> on the web. Then you could probably find a way to test with an OpenBSD setup 
> in a way
> that does not break things too horribly in case anything fails.
> 
> All the best,
> 
> --
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

OpenSSH FIDO (Nitrokey) support (Was: Re: OpenBSD insecurity rumors from isopenbsdsecu.re)

[Peter N. M. Hansteen]

On Wed, May 13, 2020 at 12:59:26PM +0200, i...@aulix.com wrote:
> Thanks for your suggestion, 
> 
> but googling for keys: +openbsd +nitrokey
> 
> does not indicate anything interesting except a few of my own questions on 
> the Nitrokey support forum.

I had to look up "Nitrokey" to verify that it was what I thought it was, but 
that had me
do a quick search for "OpenSSH FIDO support", which turned up among other 
things this
article: https://undeadly.org/cgi?action=article;sid=20191115064850 as well as 
a number
of blog posts and HOWTO-ish pieces that seem to indicate that quite likely the 
combination
would work.

I haven't tried the thing myself, but you should be able to find the same stuff 
I did
on the web. Then you could probably find a way to test with an OpenBSD setup in 
a way
that does not break things too horribly in case anything fails.

All the best,

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

[www] list of associated projects: adding rpki-client

[Alex Naumov]

Hey,

since rpki-client has its own home page like other "associated projects",
it makes sense to add a new link.

Cheers,
Alex
Index: index.html
===
RCS file: /cvs/www/index.html,v
retrieving revision 1.740
diff -u -p -r1.740 index.html
--- index.html	24 Apr 2020 12:33:07 -	1.740
+++ index.html	13 May 2020 11:08:11 -
@@ -106,5 +106,6 @@
   OpenIKED,
   https://mandoc.bsd.lv;>mandoc,
   https://www.libressl.org;>LibreSSL
+  https://www.rpki-client.org/;>rpki-client
 
   

Re: OpenBSD insecurity rumors from isopenbsdsecu.re

[info]

Thanks for your suggestion, 

but googling for keys: +openbsd +nitrokey

does not indicate anything interesting except a few of my own questions on the 
Nitrokey support forum.

I would like to hear from some real OpenBSD user about he is happy with 
Nitrokey on OpenBSD.

Another my point is about hardware security, it does not matter how long 
someone uses an operation system like OpenBSD (10 or 20 years)
unless he has a very special knowledge he will not determine any hardware 
insecurities without external help.

> On 2020-05-13 11:02, i...@aulix.com wrote:
> 
>>> (all your emails to @misc)
> 
> Dear Info,
> 
> the best way to get answers to all of your questions regarding OpenBSD
> is to try and run OpenBSD for a few years trying to make it help with
> your real-world needs, such as personal laptop, home gateway, personal
> email or web server etc. After some time, you will be able to decide
> wheather OpenBSD is the right choice for you.
> 
> You should be able to find majority of answers to your questions
> regarding OpenBSD in manpages, FAQ, and books similar to "Absolute
> OpenBSD", "The Book of PF" etc. There are also various blogs from
> OpenBSD users, whose quality varies from very bad to very good.
> 
> As for idle gossip, I can suggest local bars, which is what I use. I
> understand they are all closed now due to current situation with
> pandemic, but @misc mailing list is really poor substitute.
> 
> Regards,
> 
> --
> Before enlightenment - chop wood, draw water.
> After enlightenment - chop wood, draw water.
> 
> Marko Cupać
> https://www.mimar.rs/

Re: OpenBSD insecurity rumors from isopenbsdsecu.re

[info]

> Free advice from a fellow East European who might better understand
your obnoxious behaviour on this list:

I find behavior of commenters like you much more obnoxious and simply trolling 
me and the whole topic of this thread and some interesting facts mentioned here 
which might not please people (agents?) like you.

>This community's motto is "Shut up and hack!". 
Is not it idiotic to hack (work on it, spend time and resources on it) 
something until you know exactly if it really solves your problem?

>You are just talking a lot about OpenBSD and not hacking at all on OpenBSD 
>stuff. 

See answer above. I would not spend a single second of my life for working on 
something before I try to verify it is useful enough for me and makes me some 
type of a profit.

> By now, probably lots of people just ignore you, because your frequent (and
sometimes naive) emails amount to spam for most of them, especially
the most knowledgeable.

Trolls like you often like to say from a position of "all", though you are NOT 
all even in a very nearest approach. Actually you a minority opinions of whom 
is not interesting for me and most likely harmful and trying to create wrong 
beliefs for me.

I am interested only in answers of positive minded people who are willing to 
help and prefer to ban out trolls like you from my thread, though it is obvious 
if even trolls have power to blacklist my e-mail I can automate with 
ZennoPoster or pure DotNet/Mono a routing to register under a new account in a 
about 1 min under a new e-mail with new domain and continue discussion only 
with a positive part of the community.

Re: USB 3.0 flash drive not functional

[Andrew Klaus]

So I've confirmed that sd_get_parms is returning -1 here (by using
printf() statements in /usr/src/sys/scsi/sd.c):

1671: if (sd_read_cap(sc, flags) != 0)
1672:return -1;

Then then sets this error variable to -1:
218: error = sd_get_parms(sc, sd_autoconf);

Then this check is false, and is bypassed:

222: if (error == 0) {
223: printf("%s: %lluMB, %u bytes/sector, %llu sectors",
...

This explains why I'm not seeing seeing the "bytes/sector" output.

On Tue, May 12, 2020 at 10:15 PM Andrew Klaus  wrote:
>
> I recently tried using a USB Flash Drive (64GB Capacity) under OpenBSD
> 6.7 on both amd64 and arm64. It's detected as a umass0 device, but
> won't display the disksize/sector line in dmesg and is not available
> for me to use as a drive. This drive does work on other operating
> systems, so I know the drive is functional.
>
> I compiled with options SCSIDEBUG and UMASS_DEBUG, and now seeing this in 
> dmesg:
>
> umass0 at uhub0 port 9 configuration 1 interface 0 "PNY Technologies
> USB 3.0 FD" rev 3.00/1.00 addr 2
> umass0: using SCSI over Bulk-Only
> scsibus4 at umass0: 2 targets, initiator 0
> probe(umass0:1:0): got 36 of 55 bytes of inquiry data:
> --
> 000: 00 80 06 02 33 00 00 00 50 4e 59 00 00 00 00 00
> 016: 55 53 42 20 33 2e 30 20 46 44 00 00 00 00 00 00
> 032: 00 00 00 00
> --
> probe(umass0:1:0): got 55 of 55 bytes of inquiry data:
> --
> 000: 00 80 06 02 33 00 00 00 50 4e 59 00 00 00 00 00
> 016: 55 53 42 20 33 2e 30 20 46 44 00 00 00 00 00 00
> 032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 048: 00 00 00 00 00 00 00
> --
> scsi_inqmatch:  match priority 2. T_DIRECT T_REMOV <"", "", "">
> sd0 at scsibus4 targ 1 lun 0:  SCSI/SPC-4 removable
> serial.154b..
> probe(umass0:1:0): state 0, luns 1, openings 1
> probe(umass0:1:0): flags (0x0801) 
> probe(umass0:1:0): quirks (0x4008) 
> sd0(umass0:1:0): Check Condition (error 0) on opcode 0x1e
> sd0(umass0:1:0): Check Condition (error 0) on opcode 0x9e
> sd0(umass0:1:0): read capacity 10 data:
> --
> 000: 00 00 00 00 00 00 00 00
> --
> sd0(umass0:1:0): Check Condition (error 0) on opcode 0x1e
> sd0(umass0:1:0): Check Condition (error 0) on opcode 0x9e
> sd0(umass0:1:0): read capacity 10 data:
> --
> 000: 00 00 00 00 00 00 00 00
> --
>
> When trying to edit it under fdisk, it gives me Device not configured:
>
> # fdisk -e /dev/rsd0c
> # fdisk: /dev/rsd0c: Device not configured
>
> I presume this has to something to do with the "read capacity 10 data"
> showing null bytes. I looked at this field with other (working) USB
> Flash drives and they have non-null data here.
>
> My knowledge in this area is limited, but I'd like to learn how to fix
> this. I know I could just get another flash drive, but I enjoy the
> challenge.
>
> Any pointers on where to go from here would be really appreciated.
>
> Thanks!