Problem using httpd as a repository mirror

2021-11-20 Thread Allan Streib
I'm attemting to run an ubuntu mirror for use by local systems, using
httpd on OpenBSD 7.0-stable.

I am running into some issues that look like a bug in httpd but I am
not certain.

When I attempt to install a server using this mirror I will often (but
not always) get an error similar to the one shown in this screen grab:

  https://i.ibb.co/KysrhmH/error.png

The file with the bad hashes has always been one of these two (usually
the first one):
  - /ubuntu/dists/focal/multiverse/cnf/Commands-amd64.xz
  - /ubuntu/dists/focal/multiverse/i18n/Translation-en.xz

Looking at the httpd access log I will see many request for this file:

  default 172.16.99.5 - - [20/Nov/2021:22:24:54 -0500] "GET 
/ubuntu/dists/focal/multiverse/cnf/Commands-amd64.xz HTTP/1.1" 200 9136
  default 172.16.99.5 - - [20/Nov/2021:22:24:54 -0500] "GET 
/ubuntu/dists/focal/multiverse/cnf/Commands-amd64.xz HTTP/1.1" 200 9136
  default 172.16.99.5 - - [20/Nov/2021:22:24:54 -0500] "GET 
/ubuntu/dists/focal/multiverse/cnf/Commands-amd64.xz HTTP/1.1" 200 9136
  default 172.16.99.5 - - [20/Nov/2021:22:24:54 -0500] "GET 
/ubuntu/dists/focal/multiverse/cnf/Commands-amd64.xz HTTP/1.1" 206 8491
  default 172.16.99.5 - - [20/Nov/2021:22:24:54 -0500] "GET 
/ubuntu/dists/focal/multiverse/cnf/Commands-amd64.xz HTTP/1.1" 206 7846
  default 172.16.99.5 - - [20/Nov/2021:22:24:54 -0500] "GET 
/ubuntu/dists/focal/multiverse/cnf/Commands-amd64.xz HTTP/1.1" 206 7201
  default 172.16.99.5 - - [20/Nov/2021:22:24:54 -0500] "GET 
/ubuntu/dists/focal/multiverse/cnf/Commands-amd64.xz HTTP/1.1" 206 6556
  default 172.16.99.5 - - [20/Nov/2021:22:24:54 -0500] "GET 
/ubuntu/dists/focal/multiverse/cnf/Commands-amd64.xz HTTP/1.1" 206 5911
  default 172.16.99.5 - - [20/Nov/2021:22:24:54 -0500] "GET 
/ubuntu/dists/focal/multiverse/cnf/Commands-amd64.xz HTTP/1.1" 206 5266
  default 172.16.99.5 - - [20/Nov/2021:22:24:54 -0500] "GET 
/ubuntu/dists/focal/multiverse/cnf/Commands-amd64.xz HTTP/1.1" 206 4621
  default 172.16.99.5 - - [20/Nov/2021:22:24:54 -0500] "GET 
/ubuntu/dists/focal/multiverse/cnf/Commands-amd64.xz HTTP/1.1" 206 3976
  default 172.16.99.5 - - [20/Nov/2021:22:24:54 -0500] "GET 
/ubuntu/dists/focal/multiverse/cnf/Commands-amd64.xz HTTP/1.1" 206 3331
  default 172.16.99.5 - - [20/Nov/2021:22:24:54 -0500] "GET 
/ubuntu/dists/focal/multiverse/cnf/Commands-amd64.xz HTTP/1.1" 206 2686
  default 172.16.99.5 - - [20/Nov/2021:22:24:54 -0500] "GET 
/ubuntu/dists/focal/multiverse/cnf/Commands-amd64.xz HTTP/1.1" 206 2041
  default 172.16.99.5 - - [20/Nov/2021:22:24:54 -0500] "GET 
/ubuntu/dists/focal/multiverse/cnf/Commands-amd64.xz HTTP/1.1" 206 1396
  default 172.16.99.5 - - [20/Nov/2021:22:24:54 -0500] "GET 
/ubuntu/dists/focal/multiverse/cnf/Commands-amd64.xz HTTP/1.1" 206 751
  default 172.16.99.5 - - [20/Nov/2021:22:24:54 -0500] "GET 
/ubuntu/dists/focal/multiverse/cnf/Commands-amd64.xz HTTP/1.1" 206 106

When the hash check does not fail, I only see one request:

  default 172.16.99.5 - - [20/Nov/2021:22:46:50 -0500] "GET 
/ubuntu/dists/focal/multiverse/cnf/Commands-amd64.xz HTTP/1.1" 200 9136

I tried running httpd with -dvv flags, hoping it would log the request
as well as the response, but it did not. Interestingly though, I never
get this error with httpd in debug mode.

I also have not had this error using nginx as the http server.

So as I understand it, HTTP 206 response must mean the client is
making a range request? But why do I not see this with httpd in debug
mode or with nginx?

I would prefer to use httpd because of the simplicity of configuration
and also a preference for keeping installed packages to a minimum.

What can I do to help debug? I have a couple of hundred Ubuntu
machines to install so I would like to resolve this.

Allan



Re: lm(4) temperature

2021-11-20 Thread gwes




On 11/20/21 2:42 PM, Theo de Raadt wrote:

Jan Stary  wrote:


This is current/i386 on an ALIX.1E (dmesg below).
I am trying to monitor the CPU temperature with

wbsio0 at isa0 port 0x2e/2: W83627HF rev 0x41
lm1 at wbsio0 port 0x290/8: W83627HF

$ sysctl hw.sensors.lm1
hw.sensors.lm1.temp0=69.00 degC
hw.sensors.lm1.temp1=57.00 degC
hw.sensors.lm1.temp2=49.00 degC
hw.sensors.lm1.volt0=1.26 VDC (VCore A)
hw.sensors.lm1.volt1=2.64 VDC (VCore B)
hw.sensors.lm1.volt2=3.42 VDC (+3.3V)
hw.sensors.lm1.volt3=5.11 VDC (+5V)
hw.sensors.lm1.volt4=0.00 VDC (+12V)
hw.sensors.lm1.volt5=-14.91 VDC (-12V)
hw.sensors.lm1.volt6=-7.71 VDC (-5V)
hw.sensors.lm1.volt7=5.07 VDC (5VSB)
hw.sensors.lm1.volt8=0.00 VDC (VBAT)

There are three temperatures reported,
and dev/ic/lm78var.h talks about Temperature 1, 2, 3;
but man lm(4) only says

Temp uK Motherboard Temperature

Does anyone know what exactly they are?


There is a chip in the machine.
It has pins.
Those pins are monitored by the driver, as specific registers.

The pins wired to who the hell knows where by each board manufacturer.

Sometimes the chips need special registers and capacitors

Quite often, the board engineer sent to add this part to the board
choose the wrong registers and capacitors, and sometimes they compensate
for these errors with private tables in the BIOS or various monitoring
programs which move around machine to machine.


We monitor registers.  We assume the vendor did the right thing.


No that I've described what a shitshow it is, I hope you can adjust your
expectations.  Otherwise, maybe it is time to give up and delete these
sensor drivers..


Boot the machine to startup BIOS.
Search for a hardware monitor screen.
Write down what it says - values and descriptions.
Any correlation between that and what sysctl.hw.sensors says is purely
in the mind of the viewer.




Re: lm(4) temperature

2021-11-20 Thread Theo de Raadt
Jan Stary  wrote:

> This is current/i386 on an ALIX.1E (dmesg below).
> I am trying to monitor the CPU temperature with
> 
> wbsio0 at isa0 port 0x2e/2: W83627HF rev 0x41
> lm1 at wbsio0 port 0x290/8: W83627HF
> 
> $ sysctl hw.sensors.lm1
> hw.sensors.lm1.temp0=69.00 degC
> hw.sensors.lm1.temp1=57.00 degC
> hw.sensors.lm1.temp2=49.00 degC
> hw.sensors.lm1.volt0=1.26 VDC (VCore A)
> hw.sensors.lm1.volt1=2.64 VDC (VCore B)
> hw.sensors.lm1.volt2=3.42 VDC (+3.3V)
> hw.sensors.lm1.volt3=5.11 VDC (+5V)
> hw.sensors.lm1.volt4=0.00 VDC (+12V)
> hw.sensors.lm1.volt5=-14.91 VDC (-12V)
> hw.sensors.lm1.volt6=-7.71 VDC (-5V)
> hw.sensors.lm1.volt7=5.07 VDC (5VSB)
> hw.sensors.lm1.volt8=0.00 VDC (VBAT)
> 
> There are three temperatures reported,
> and dev/ic/lm78var.h talks about Temperature 1, 2, 3;
> but man lm(4) only says
> 
>   Temp uK Motherboard Temperature
> 
> Does anyone know what exactly they are?


There is a chip in the machine.
It has pins.
Those pins are monitored by the driver, as specific registers.

The pins wired to who the hell knows where by each board manufacturer.

Sometimes the chips need special registers and capacitors

Quite often, the board engineer sent to add this part to the board
choose the wrong registers and capacitors, and sometimes they compensate
for these errors with private tables in the BIOS or various monitoring
programs which move around machine to machine.


We monitor registers.  We assume the vendor did the right thing.


No that I've described what a shitshow it is, I hope you can adjust your
expectations.  Otherwise, maybe it is time to give up and delete these
sensor drivers..



lm(4) temperature

2021-11-20 Thread Jan Stary
This is current/i386 on an ALIX.1E (dmesg below).
I am trying to monitor the CPU temperature with

wbsio0 at isa0 port 0x2e/2: W83627HF rev 0x41
lm1 at wbsio0 port 0x290/8: W83627HF

$ sysctl hw.sensors.lm1
hw.sensors.lm1.temp0=69.00 degC
hw.sensors.lm1.temp1=57.00 degC
hw.sensors.lm1.temp2=49.00 degC
hw.sensors.lm1.volt0=1.26 VDC (VCore A)
hw.sensors.lm1.volt1=2.64 VDC (VCore B)
hw.sensors.lm1.volt2=3.42 VDC (+3.3V)
hw.sensors.lm1.volt3=5.11 VDC (+5V)
hw.sensors.lm1.volt4=0.00 VDC (+12V)
hw.sensors.lm1.volt5=-14.91 VDC (-12V)
hw.sensors.lm1.volt6=-7.71 VDC (-5V)
hw.sensors.lm1.volt7=5.07 VDC (5VSB)
hw.sensors.lm1.volt8=0.00 VDC (VBAT)

There are three temperatures reported,
and dev/ic/lm78var.h talks about Temperature 1, 2, 3;
but man lm(4) only says

Temp uK Motherboard Temperature

Does anyone know what exactly they are?

Jan


OpenBSD 7.0-current (GENERIC) #276: Wed Nov 10 11:36:02 MST 2021
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem  = 259207168 (247MB)
avail mem = 238137344 (227MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 07/19/10, BIOS32 rev. 0 @ 0xfa950
apm0 at bios0: Power Management spec V1.2 (slowidle)
pcibios0 at bios0: rev 2.1 @ 0xf/0xdfb4
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf30/128 (6 entries)
pcibios0: PCI Exclusive IRQs: 5 10 11
pcibios0: no compatible PCI ICU found: ICU vendor 0x1022 product 0x2090
pcibios0: Warning, unable to fix up PCI interrupt routing
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0xa800 0xef000/0x1000!
cpu0 at mainbus0: (uniprocessor)
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 499 
MHz, 05-0a-02
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
mtrr: K6-family MTRR support (2 registers)
amdmsr0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
vga1 at pci0 dev 1 function 1 "AMD Geode LX Video" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 13 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, address 
00:0d:b9:0e:9e:f4
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, 
model 0x0034
glxpcib0 at pci0 dev 15 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit 
3579545Hz timer, watchdog, gpio, i2c
gpio0 at glxpcib0: 32 pins
iic0 at glxpcib0
pciide0 at pci0 dev 15 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 1-sector PIO, LBA48, 15279MB, 31293360 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
auglx0 at pci0 dev 15 function 3 "AMD CS5536 Audio" rev 0x01: irq 11, CS5536 
AC97
ac97: codec id 0x414c4770 (Avance Logic ALC203 rev 0)
ac97: codec features headphone, 20 bit DAC, 18 bit ADC, No 3D Stereo
audio0 at auglx0
ohci0 at pci0 dev 15 function 4 "AMD CS5536 USB" rev 0x02: irq 5, version 1.0, 
legacy support
ehci0 at pci0 dev 15 function 5 "AMD CS5536 USB" rev 0x02: irq 5
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "AMD EHCI root hub" rev 2.00/1.00 
addr 1
isa0 at glxpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
wbsio0 at isa0 port 0x2e/2: W83627HF rev 0x41
lm1 at wbsio0 port 0x290/8: W83627HF
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "AMD OHCI root hub" rev 1.00/1.00 
addr 1
dt: 445 probes
umass0 at uhub0 port 4 configuration 1 interface 0 "JMicron USB to ATA/ATAPI 
bridge" rev 2.00/1.00 addr 2
umass0: using SCSI over Bulk-Only
scsibus1 at umass0: 2 targets, initiator 0
sd0 at scsibus1 targ 1 lun 0:  
serial.152d2329801130168383
sd0: 228936MB, 512 bytes/sector, 468862128 sectors
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on wd0a (cfeae50a002d1e1d.a) swap on wd0b dump on wd0b



Re: EC 25 pci-express support in arm64

2021-11-20 Thread Heppler, J. Scott

On Nov 20, 2021: 17:38, Łukasz Moskała wrote:

W dniu 20.11.2021 o 16:34, Heppler, J. Scott pisze:

I live in a rural area with poor broadband.  T-mobile is introducing a
cellular based home internet plan and if the speeds are 1/3 of what they
tout, my bandwidth will increase 20x.

This would be stationary and I would build to that goal.

I found there is usb support for the Quectel EC25 but a list search did
not show pci-e.

https://marc.info/?l=openbsd-tech=162106996807242=2

This chipset is available in a pci-express card and there is a base hat
for the Rasberry Pi's 40-pin connector.

https://sixfab.com/product/raspberry-pi-base-hat-3g-4g-lte-minipcie-cards/

I'd prefer a Gigybyte ethernet port on the arm64; Rasberry
Pi4/M3/BPI-M2, Banana Pi, Nano Pi.  These appear to be Realtek or
Broadcom.

Questions:

Is there pci-e interface support for the Quectel EC25?
Broadcom (bge) vs Realtek (re) NIC's; is one better supported than 
the other?




Hi,

Raspberry pi does not have neither PCIe or USB lines on GPIO header. 
Description of that hat says "Both UART and USB communication with 
modules are available on the shield". I assume that to get USB 
communication (since UART will limit you to 115200 bits/second) you 
will have to connect it with usb cable anyway.


At this point you could just go with USB modem, and don't spend the 
$40 on hat that will give you essentially nothing, except maybe more 
compact form factor.


If you really want to connect modem with PCIe, there is rockpro64, 
that has PCIe slot. Or some amd64 thin clients, like fujitsu futro 
s920.


As for second question, a lot of people does not recommend using 
realtek NICs with freebsd, I'd avoid them if possible, in case you 
will want to switch OS in the future. I had problems with them on 
freebsd, but I didn't use them with openbsd so maybe someone else can 
say more.


I didn't have problems with broadcom nics.

If I were you, I'd go with raspberry pi 4 and USB modem, since rpi4 
also has built in wifi, which IIRC is supported in AP mode on openbsd.


Kind regards
--
Łukasz Moskała



Using the usb interface would ensure OpenBSD compatibility from what
I've been able to gleen so far.  Pci-e is more attractive for my use
case but it's unclear the Vendor ID's are in OpenBSD for anything other
thatn usb.

There are pci-e <-> usb adapter or LTE modules on usb cards
https://www.aliexpress.com/item/1267232403.html
Some of the supported boards have usb connectors along another board
edge to prevent obstruction the ethernet port:
https://www.pine64.org/devices/single-board-computers/pine-a64-lts/

Also found male usb2 <-> male usb2 connectors/angle adapters
https://www.ebay.com/itm/224698400405?mkevt=1=1=711-53200-19255-0=5338722076=10001


This board has a usb3 on the opposite edge and pci-e on the underside:
https://wiki.radxa.com/RockpiN10/hardware/rockpiN10
I like the heat sink.  The dwge(4) ethernet appears to be fully
supported.  Has a 27 week lead time in the US or out-of-stock
https://man.openbsd.org/arm64/dwge.4
--
J. Scott Heppler

Penguin Innovations

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 



NOTICE: This e-mail message and any attachments may
contain legally privileged and confidential information intended
solely for the use of the intended recipients. If you are not an
intended recipient, you are hereby notified that you have
received this message in error and any review, dissemination,
distribution, copying, or other unauthorized use of this email
and any attachment is strictly prohibited. If you have received
this email in error, please notify the sender immediately and
delete the message and any attachments from your system.



Re: RTL8852AE wifi driver

2021-11-20 Thread Stefan Sperling
On Sat, Nov 20, 2021 at 04:04:25PM +, Patrick Harper wrote:
> You need to get the authors to change the license to an acceptable one 
> first, as GPL won't cut it. https://www.openbsd.org/policy.html

The rtw89 driver is already dual-licensed as GPL/BSD via:
SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause

So there is no licensing issue here.



Re: EC 25 pci-express support in arm64

2021-11-20 Thread Łukasz Moskała

W dniu 20.11.2021 o 16:34, Heppler, J. Scott pisze:

I live in a rural area with poor broadband.  T-mobile is introducing a
cellular based home internet plan and if the speeds are 1/3 of what they
tout, my bandwidth will increase 20x.

This would be stationary and I would build to that goal.

I found there is usb support for the Quectel EC25 but a list search did
not show pci-e.

https://marc.info/?l=openbsd-tech=162106996807242=2

This chipset is available in a pci-express card and there is a base hat
for the Rasberry Pi's 40-pin connector.

https://sixfab.com/product/raspberry-pi-base-hat-3g-4g-lte-minipcie-cards/

I'd prefer a Gigybyte ethernet port on the arm64; Rasberry
Pi4/M3/BPI-M2, Banana Pi, Nano Pi.  These appear to be Realtek or
Broadcom.

Questions:

Is there pci-e interface support for the Quectel EC25?
Broadcom (bge) vs Realtek (re) NIC's; is one better supported than the 
other?




Hi,

Raspberry pi does not have neither PCIe or USB lines on GPIO header. 
Description of that hat says "Both UART and USB communication with 
modules are available on the shield". I assume that to get USB 
communication (since UART will limit you to 115200 bits/second) you will 
have to connect it with usb cable anyway.


At this point you could just go with USB modem, and don't spend the $40 
on hat that will give you essentially nothing, except maybe more compact 
form factor.


If you really want to connect modem with PCIe, there is rockpro64, that 
has PCIe slot. Or some amd64 thin clients, like fujitsu futro s920.


As for second question, a lot of people does not recommend using realtek 
NICs with freebsd, I'd avoid them if possible, in case you will want to 
switch OS in the future. I had problems with them on freebsd, but I 
didn't use them with openbsd so maybe someone else can say more.


I didn't have problems with broadcom nics.

If I were you, I'd go with raspberry pi 4 and USB modem, since rpi4 also 
has built in wifi, which IIRC is supported in AP mode on openbsd.


Kind regards
--
Łukasz Moskała



Re: RTL8852AE wifi driver

2021-11-20 Thread Patrick Harper
You need to get the authors to change the license to an acceptable one 
first, as GPL won't cut it. https://www.openbsd.org/policy.html

-- 
  Patrick Harper
  paia...@fastmail.com

On Fri, 19 Nov 2021, at 15:24, Moritz Messner wrote:
> Hello,
>
> there seems to be a working driver for this wifi chip which works under
> Linux (https://github.com/lwfinger/rtw89) and I have it in my laptop
> (will probably replace it with a intel ax200/201 so I can use it at school).
>
> How much work would be needed to port the driver to OpenBSD?



EC 25 pci-express support in arm64

2021-11-20 Thread Heppler, J. Scott

I live in a rural area with poor broadband.  T-mobile is introducing a
cellular based home internet plan and if the speeds are 1/3 of what they
tout, my bandwidth will increase 20x.

This would be stationary and I would build to that goal.

I found there is usb support for the Quectel EC25 but a list search did
not show pci-e.

https://marc.info/?l=openbsd-tech=162106996807242=2

This chipset is available in a pci-express card and there is a base hat
for the Rasberry Pi's 40-pin connector.

https://sixfab.com/product/raspberry-pi-base-hat-3g-4g-lte-minipcie-cards/

I'd prefer a Gigybyte ethernet port on the arm64; Rasberry
Pi4/M3/BPI-M2, Banana Pi, Nano Pi.  These appear to be Realtek or
Broadcom.

Questions:

Is there pci-e interface support for the Quectel EC25?
Broadcom (bge) vs Realtek (re) NIC's; is one better supported than the other?


--
J. Scott Heppler