Re: WireGuard, Windows mobile laptop and pf.conf?

2020-12-28 Thread Thomas Bohl 

Hi,


    wgport 53
Unbound is configured to only listen on the loopback interface, so that 
shouldn't be interfering...


But it does
https://www.mail-archive.com/misc@openbsd.org/msg175837.html

Re: WireGuard, Windows mobile laptop and pf.conf?

2020-12-28 Thread Hakan E. Duran 
Hi Steve,

On 20/12/28 04:14PM, Steve Williams wrote:
> ...
>
> I am not sure where my issue is...

I am going to cut to the chase here since I am no wireguard or OpenBSD
expert; however, I happen to come across this blog today that may help
you clarify some of your questions:

https://ozgur.kazancci.com/secure-fast-vpn-server-wireguard-setup-on-openbsd-and-configure-windows-10-clients-to-connect-through-it/

I hope it helps. I am planning to set up one myself in the near future.
Please keep us posted how yours turn out.

Hakan Duran

WireGuard, Windows mobile laptop and pf.conf?

2020-12-28 Thread Steve Williams 

Hi,

I am not sure where my issue is...

As I understand, WireGuard is strictly UDP.

I am working on a road warrior setup, where one end of the tunnel is my 
OpenBSD server with a static public IP address and the other end will be 
Windows 7/10 laptops with random public IP addresses.


My hostname.wg0:

   wgkey 
   wgport 53
   wgpeer  wgpka 25 wgaip 192.168.126.2/32
   inet 192.168.126.1/24
   up

I haven't put "wgendpoint" in the OpenBSD config file as I don't know 
what the remote IP address is.  I assumed that "the local interface" 
would update after receiving a correctly authenticated packet from my 
Windows 10 laptop...but perhaps the issue?


from ifcon|fig(8):
||wgendpoint| ip port
Set the IP address and port to send the encapsulated packets to. If the 
peer changes address, the local interface will update the address after 
receiving a correctly authenticated packet. The IP address can be either 
IPv4 or IPv6, and the port is a regular 16-bit UDP port.



In my Windows WireGuard client:

   [Interface]
   PrivateKey = 
   Address = 192.168.126.2/24

   [Peer]
   PublicKey = 
   AllowedIPs = 0.0.0.0/1
   Endpoint = :53



Since I don't want to filter any of the Wireguard traffic, at the top of 
the pf.conf, I have:

set skip on wg0

Then I am allowing incoming traffic to port 53.
# Wireguard running on DNS port
pass in on egress inet proto udp from any to (egress) port { domain }


When I initiate a connection from my road warrior setup (Windows 7, 
WireGuard client which has the IP / Port configured of my OpenBSD 
server), it is just continually retrying.
2020-12-28 12:22:54.401: [TUN] [OpenBSD] peer(IQsw…D4W8) - Handshake did 
not complete after 5 seconds, retrying (try 2)


On my OpenBSD box, I can tcpdump -i em0 (egress, public IP address) and 
see the packets getting to the OpenBSD box from the Windows laptop..


However, when I doing a tcpdump -i wg0, there is no traffic at all.

Unbound is configured to only listen on the loopback interface, so that 
shouldn't be interfering...


(/var/unbound/etc/unbound.conf)
server:a
    interface: 127.0.0.1
    interface: ::1


Hum... now that I am thinking about it...how does it all work?

   1.  A packet leaves wg0 interface with 192.168.126.1 ip address
   2.  The packet is routed to the default gateway (egress)
   3.  The packet hits the Internet and is dropped as a non-routable IP
   address

or...
Does the packet get routed out my external interface, whereby the NAT 
rule would apply?

match out on egress inet from !(egress:network) to any nat-to (egress:0)

I'm just a little bit lost on how to configure pf for this all.

Thanks,
Steve W.

Re: Wireguard

2020-12-28 Thread Daniel Jakots 
On Mon, 28 Dec 2020 21:17:42 +, Peter Fraser 
wrote:

> This is my first attempt to set up wireguard, and of course I can't
> get it to work.
> 
> The wg man page shows "ifconfig wgN debug" as an option to help
> debugging. The man page for ifconfig does document the option.
> Nor does the man page tell how to turn the option off.

As any other ifconfig option, with a leading -, i.e. ifconfig wg0 -debug

> I hoped it might show me my problem, I don't now where the messages
> are going,

dmesg(8) or /var/log/messages


Cheers,
Daniel

Wireguard

2020-12-28 Thread Peter Fraser 
This is my first attempt to set up wireguard, and of course I can't get it to 
work.

The wg man page shows "ifconfig wgN debug" as an option to help debugging.
The man page for ifconfig does document the option.
Nor does the man page tell how to turn the option off.

I hoped it might show me my problem, I don't now where the messages are going,

i386 "panic: pci_make_tag: bad request" after acpi sleep states

2020-12-28 Thread Ian Darwin 
Kernel is OpenBSD 6.8-current (GENERIC) #561: Sun Dec 27 18:29:43 MST 2020

Machine is a Wyse C90 - orignially sold as a "thin client" - tiny machine, no 
serial port (ps and trace typed in).
HW Info at https://www.parkytowers.me.uk/thin/wyse/cx0/
Was planning to use it as a wifi bridge, so tiny is fine.

"Latest" BIOS (2012 edition). "BIOS reset" did not help.
cpu info: VIA Eden Processor 1000MHz ("CentaurHauls" 686-class) 1.01 GHz, 
06-0d-00
RAM: 1GB (despite reported as 3/4 of that)

Full dmesg below; full ACPI attached.

Boot used   Kernel  FromResult
pxeboot bsd.rd  tftpOK
pxeboot bsd hd0aOK (via tftpboot/etc/conf)
bootbsd hd0apanic

I.e., Boots fine with pxeboot "set device hd0a", but booting exact same kernel 
off same disk via /boot causes panic.

It's an older machine so it's likely a buggy acpi, not worth massive investment 
of time, just wonder if there's an easy workaround.
Presume it's getting something different in some AML, based on where boot code 
loaded from,
or else pxeboot vs boot setting environment slightly differently?

On screen after panic:

bios0: WYSE C CLASS
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S1 S3 s4 S5panic: pci_make_tag: bad request
Stopped at db_enter+0x4: popl %eb

trace:

db_enter(d0e5e189,d10f6704,2,0,0) at db_enter+0x4
panic(d0c3d47d,1,d10f6750,d0854f11,0) at panic+0xd3
pci_make_tag(0,0,11,0) at pci_make_tag+0x95
acpi_gasio(d2b1b400,0,2,6e,11,1,1,d10f67d8) at acpi_gasio+0x1f1
aml_opreg_pcicfg_handler(0,0,6e,11,1,d10f67d8) at aml_opreg_pcicfg_handler+0x21
aml_rwgen(d2b338c4,373,1,d2b3f304,0,1) at aml_rwgen+0x571
aml_rwfield(d2b2bc04,0,1,d2b3f304,0) at aml_rwfield+0x37a
aml_eval(d2b40704,d2b2bc04,74,d10f692c,0) at aml_eval+0x17a
aml_parse(d2b40704,74,d2b2f804) at aml_parse+0x2b15
aml_parse(d2b40704,69,38) at aml_parse+0x351
aml_parse(d2b40704,54,9,d2b36518,d2b40704) at aml_parse+0x351
aml_eval(0,d2b36544,74,0,0) at aml_eval+0x277
aml_evalnode(d10f6b10,d2b36504,0,0,d10f6ac0) at aml_evalnode+0xae
aml_evalinteger(d1b1b400,d2b36a84,d0c17e38,0,0,d10f6b30) at aml_evalinteger+0xae
acpi_foundprw(d2b36d04,d2b1b400) at acpi_foundprw+0x2f
aml_find_node(d2b36a84,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x?2
aml_find_node(d2b336c4,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x9b 
aml_find_node(d2b296c4,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x9b 
aml_find_node(d2b31484,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x9b 
aml_find_node(d0eba1a8,d0b9299b,d0859b90,d2b1b400) at aml_find_node+0x9b
acpi_init_gpes (d2b1b400) at acpi_init_gpes+0x195 
acpi_attach_common(d2b1b400,f67a0) at acpi_attach_common+0x355
acpi_attach(d2b210c0,d2b1b400,d10f6db8) at acpi_attach+0xZc
config attach(d2b210c0,d0df60d4,d10f6db8,d0928b30) at config attach+0x18a
config_found_sm(d2b210c0,d10f6db8,d0928630,0) at config_found_sm+0x29
biosattach(d2b21080, d2b210c0,d10f6eb8) at biosattach+0x19a
config attach (d2b21080, d0df 4c94,d10f6eb8, d02431f0) at config_attach+0x18a 
config_found_sm(dZbZ1080, d10f beb8, d02431f0,0) at config_found_sm+0x29 
mainbus_attach(0,d2b21080,0) at mainbus attach_0x5c
config_attach(0,d0df 2614,0,0) at config_attach+0x18a
cpu_configure(lie340b7,10f 4000, 1103000, 10 7000,0) at cpu_configure+0x24 
main(0,0,0,0,0) at main+0x311
ddb>

ps:
   TID   PID  UID  PRFLAGS  PFLAGS  CPU  COMMAND
*0 00  0x1  0x200 0  swapper

Dmesg:
ssh wyse cat /var/run/dmesg.boot
OpenBSD 6.8-current (GENERIC) #561: Sun Dec 27 18:29:43 MST 2020
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem  = 803459072 (766MB)
avail mem = 772513792 (736MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 01/16/12, BIOS32 rev. 0 @ 0xfdd30, SMBIOS rev. 2.6 @ 
0x2fed8000 (48 entries)
bios0: vendor Phoenix Technologies version "1.0G" date 01/16/2012
bios0: WYSE C CLASS
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC MCFG HPET
acpi0: wakeup devices PWRB(S4) PCI0(S5) PS2M(S3) PS2K(S3) USB1(S4) USB2(S4) 
USB3(S4) USB4(S4) USB5(S4) HDAC(S5) SP2P(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: VIA Eden Processor 1000MHz ("CentaurHauls" 686-class) 1.01 GHz, 06-0d-00
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE,SSE3,EST,TM2,xTPR,NXE
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: RNG AES AES-CTR SHA1 SHA256 RSA
cpu0: apic clock running at 100MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 3, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-0
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (SP2P)
acpibtn0 at acpi0: PWRB
"PNP0A03" at acpi0 not configured
acpicmos0 at acpi0
acpicpu0 at acpi0: !C3(@800 io@0x4015), !C2(@80 io@0x40

Re: misc panics

2020-12-28 Thread Gregory Edigarov 



On 12/28/20 12:18 PM, rgc wrote:
> On Mon, Dec 28, 2020 at 10:39:56AM +0100, Otto Moerbeek wrote:
>> On Mon, Dec 28, 2020 at 10:25:08AM +0100, Bastien Durel wrote:
>>
>>> Le lundi 28 d?cembre 2020 ? 09:17 +, Stuart Henderson a ?crit?:
> So hardware failure confirmed :/ Do you think I can change the RAM
> or
> it's more likely a CPU/Chipset failure ?
>
> Thanks,
>
 If you have multiple sticks of RAM, try removing some.
>>> I have only one
>> trying to reaset it is worth a try.
>>
>>  -Otto
>>
> or doing the eraser magick
>
> you clean the contacts (remove oxidation) of the RAM module (the side that
> sticks in the motherboard) by rubbing a pencil eraser on the contacts of the
> RAM module.
>
in my experience, all the RAM modules nowadays comes gold plated, so no
need to use eraser on them.
just a piece of paper, to make sure there is no grease on the contacts

Re: misc panics

2020-12-28 Thread rgc 
On Mon, Dec 28, 2020 at 10:39:56AM +0100, Otto Moerbeek wrote:
> On Mon, Dec 28, 2020 at 10:25:08AM +0100, Bastien Durel wrote:
> 
> > Le lundi 28 d?cembre 2020 ? 09:17 +, Stuart Henderson a ?crit?:
> > > > So hardware failure confirmed :/ Do you think I can change the RAM
> > > > or
> > > > it's more likely a CPU/Chipset failure ?
> > > > 
> > > > Thanks,
> > > > 
> > > 
> > > If you have multiple sticks of RAM, try removing some.
> > I have only one
> 
> trying to reaset it is worth a try.
> 
>   -Otto
> 

or doing the eraser magick

you clean the contacts (remove oxidation) of the RAM module (the side that
sticks in the motherboard) by rubbing a pencil eraser on the contacts of the
RAM module.

- rgc

Re: misc panics

2020-12-28 Thread Otto Moerbeek 
On Mon, Dec 28, 2020 at 10:25:08AM +0100, Bastien Durel wrote:

> Le lundi 28 décembre 2020 à 09:17 +, Stuart Henderson a écrit :
> > > So hardware failure confirmed :/ Do you think I can change the RAM
> > > or
> > > it's more likely a CPU/Chipset failure ?
> > > 
> > > Thanks,
> > > 
> > 
> > If you have multiple sticks of RAM, try removing some.
> I have only one

trying to reaset it is worth a try.

-Otto

Re: misc panics

2020-12-28 Thread Bastien Durel 
Le lundi 28 décembre 2020 à 09:17 +, Stuart Henderson a écrit :
> > So hardware failure confirmed :/ Do you think I can change the RAM
> > or
> > it's more likely a CPU/Chipset failure ?
> > 
> > Thanks,
> > 
> 
> If you have multiple sticks of RAM, try removing some.
I have only one

-- 
Bastien

Re: misc panics

2020-12-28 Thread Stuart Henderson 
On 2020-12-28, Bastien Durel  wrote:
> Le lundi 28 décembre 2020 à 09:23 +1000, Stuart Longland a écrit :
>> On 28/12/20 3:56 am, Bastien Durel wrote:
>> > After that I got a (maybe) endless loop of panics inducing panics
>> > (I did 
>> > not got the output, it was cycling fast), and after that the /bsd
>> > file 
>> > was left empty :
>> > 
>> > > > > OpenBSD/amd64 BOOT 3.52
>> > > boot> NOTE: random seed is being reused.
>> > > booting hd0a:/bsd: read header
>> > >  failed(0). will try /bsd
>> …
>> > How can I figure out the cause of all these problems ?
>> 
>> Seems awfully strange for `/bsd` to become zero-length out-of-the-
>> blue. 
>>   Got a `memtest86` disk handy?
>> 
>> I'd be checking:
>> - RAM
>> - disks
>> - CPU
>> 
>> I think from the `dmesg` the storage device is a SSD?  Could it be it
>> has failed early?  Some do that, and they give practically no warning
>> when they do.
>
> SMART is OK on the disk
>
> I ran a memtest86 test, and got thousands of errors
>
>
> Test Start Time   2020-12-28 08:38:08
> Elapsed Time  0:01:11
> Memory Range Tested   0x0 - 16F00 (5872MB)
> CPU Selection ModeParallel (All CPUs)
> ECC Polling   Enabled
>
> Lowest Error Address  0x12AA18018 (4778MB)
> Highest Error Address 0x12BFE7FF8 (4799MB)
> Bits in Error MaskFF00
> Bits in Error 8
> Max Contiguous Errors 1
>
>
>
> Test  # Tests Passed  Errors
> Test 0 [Address test, walking ones, 1 CPU]1/1 (100%)  0
> Test 1 [Address test, own address, 1 CPU] 0/0 (0%)10988
>
>
> Last 10 Errors
> 2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7FF8,
> Expected: 00012BFE7FF8, Actual: 10012BFE7FF8
> 2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7FE8,
> Expected: 00012BFE7FE8, Actual: 04012BFE7FE8
> 2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7F58,
> Expected: 00012BFE7F58, Actual: 04012BFE7F58
> 2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7F48,
> Expected: 00012BFE7F48, Actual: 08012BFE7F48
> 2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7EF8,
> Expected: 00012BFE7EF8, Actual: 40012BFE7EF8
> 2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7EE8,
> Expected: 00012BFE7EE8, Actual: C0012BFE7EE8
> 2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7EC8,
> Expected: 00012BFE7EC8, Actual: 04012BFE7EC8
> 2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7E58,
> Expected: 00012BFE7E58, Actual: 40012BFE7E58
> 2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7D58,
> Expected: 00012BFE7D58, Actual: 08012BFE7D58
> 2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7D48,
> Expected: 00012BFE7D48, Actual: 08012BFE7D48
>
>
> So hardware failure confirmed :/ Do you think I can change the RAM or
> it's more likely a CPU/Chipset failure ?
>
> Thanks,
>

If you have multiple sticks of RAM, try removing some.

Re: misc panics

2020-12-28 Thread Bastien Durel 
Le lundi 28 décembre 2020 à 09:23 +1000, Stuart Longland a écrit :
> On 28/12/20 3:56 am, Bastien Durel wrote:
> > After that I got a (maybe) endless loop of panics inducing panics
> > (I did 
> > not got the output, it was cycling fast), and after that the /bsd
> > file 
> > was left empty :
> > 
> > > > > OpenBSD/amd64 BOOT 3.52
> > > boot> NOTE: random seed is being reused.
> > > booting hd0a:/bsd: read header
> > >  failed(0). will try /bsd
> …
> > How can I figure out the cause of all these problems ?
> 
> Seems awfully strange for `/bsd` to become zero-length out-of-the-
> blue. 
>   Got a `memtest86` disk handy?
> 
> I'd be checking:
> - RAM
> - disks
> - CPU
> 
> I think from the `dmesg` the storage device is a SSD?  Could it be it
> has failed early?  Some do that, and they give practically no warning
> when they do.

SMART is OK on the disk

I ran a memtest86 test, and got thousands of errors


Test Start Time 2020-12-28 08:38:08
Elapsed Time0:01:11
Memory Range Tested 0x0 - 16F00 (5872MB)
CPU Selection Mode  Parallel (All CPUs)
ECC Polling Enabled

Lowest Error Address0x12AA18018 (4778MB)
Highest Error Address   0x12BFE7FF8 (4799MB)
Bits in Error Mask  FF00
Bits in Error   8
Max Contiguous Errors   1



Test# Tests Passed  Errors
Test 0 [Address test, walking ones, 1 CPU]  1/1 (100%)  0
Test 1 [Address test, own address, 1 CPU]   0/0 (0%)10988


Last 10 Errors
2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7FF8,
Expected: 00012BFE7FF8, Actual: 10012BFE7FF8
2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7FE8,
Expected: 00012BFE7FE8, Actual: 04012BFE7FE8
2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7F58,
Expected: 00012BFE7F58, Actual: 04012BFE7F58
2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7F48,
Expected: 00012BFE7F48, Actual: 08012BFE7F48
2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7EF8,
Expected: 00012BFE7EF8, Actual: 40012BFE7EF8
2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7EE8,
Expected: 00012BFE7EE8, Actual: C0012BFE7EE8
2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7EC8,
Expected: 00012BFE7EC8, Actual: 04012BFE7EC8
2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7E58,
Expected: 00012BFE7E58, Actual: 40012BFE7E58
2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7D58,
Expected: 00012BFE7D58, Actual: 08012BFE7D58
2020-12-28 08:39:19 - [Data Error] Test: 1, CPU: 0, Address: 12BFE7D48,
Expected: 00012BFE7D48, Actual: 08012BFE7D48


So hardware failure confirmed :/ Do you think I can change the RAM or
it's more likely a CPU/Chipset failure ?

Thanks,

-- 
Bastien Durel