Re: Cannot access internet with virtual switch

[Ayaka Koshibe]

> tap0 is a control interface created by switchd to communicate with
> switches. It won't carry normal network traffic.

(Last bit of noise, and I'm done)
Actually, I think I'm wrong here. I'll need to dig a bit more to
answer correctly.

Re: Cannot access internet with virtual switch

[Ayaka Koshibe]

On Sat, May 12, 2018 at 8:54 PM, Ayaka Koshibe  wrote:
>> Currently, I am using a bridge. From what I understand from the patch
>> and the cvsweb history, that patch is waiting for ok and commit.
>
> I've actually held back on that diff since it's a bit insufficient by itself.

Sorry, I should elaborate. If you plan to try the local port, you may
still want the patch in place to prevent the switch from
disconnecting.

Re: Cannot access internet with virtual switch

[Ayaka Koshibe]

> Currently, I am using a bridge. From what I understand from the patch
> and the cvsweb history, that patch is waiting for ok and commit.

I've actually held back on that diff since it's a bit insufficient by itself.

> This time, the switch does not close. However, I am still unable to
> ping 8.8.8.8 with the switch. As usual, I am able to ping 8.8.8.8
> using a bridge.

Actually, you said that you had just em0 on that switch. Can you try
adding a local port (addlocal instead of add) alongside em0? It will
be a vether(4) interface that needs to be given em0's current address,
in its place.

> There is a continuous stream of messages when running "switchd -dvv":
> ...

I can't say what they are without the full output, but you will tend
to see broadcasts (periodic or otherwise) like your second example
even on your bridge. From a second look at your earlier logs, it seems
the 1->1 'loops' are generated by the switch seeing VLAN traffic in
other parts of the network.

> Finally, I have a query - What does the tap0 interface do? I ask this
> because currently I do not pass in/out tap0 traffic in pf. This is
> because I do not know what tap0 is and what it does.

tap0 is a control interface created by switchd to communicate with
switches. It won't carry normal network traffic.

Edgerouter Lite snapshot dmesg

[Sean Murphy]

Good evening, all,

Recently upgraded my ERL to a snapshot (5/10/18) to test out the octcrypto
module that visa recently enabled.  Install went as smoothly as can be
expected, upon reboot I saw the octcrypto module load,and everything
seems to be working great.  I haven't had a chance to test out the module
yet, but I will let the list know when I get to it.

Also, I managed to get the install kernel to recognize that this is a multiproc
machine by using "bootoctlinux $loadaddr bsd coremask=0x3" as my
boot command after the install kernel was loaded via tftpboot.  Excellent
work and thanks to everyone, dmesg to follow:


Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2018 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.3-current (GENERIC.MP) #0: Wed May  9 07:17:26 UTC 2018
visa@octeon:/usr/src/sys/arch/octeon/compile/GENERIC.MP
real mem = 536870912 (512MB)
avail mem = 523845632 (499MB)
mainbus0 at root: board 20002 rev 2.18
cpu0 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation
cpu0: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way
cpu1 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation
cpu1: cache L1-I 32KB 4 way D 16KB 64 way, L2 128KB 8 way
clock0 at mainbus0: int 5
octcrypto0 at mainbus0
iobus0 at mainbus0
simplebus0 at iobus0: "soc"
octciu0 at simplebus0
cn30xxsmi0 at simplebus0
com0 at simplebus0: ns16550a, 64 byte fifo
com0: console
dwctwo0 at iobus0 base 0x118006800 irq 56
usb0 at dwctwo0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Octeon DWC2 root hub" rev
2.00/1.00 addr 1
octrng0 at iobus0 base 0x14000 irq 0
cn30xxgmx0 at iobus0 base 0x118000800
cnmac0 at cn30xxgmx0: RGMII, address 44:d9:e7:40:b5:c8
atphy0 at cnmac0 phy 7: AR8035 10/100/1000 PHY, rev. 2
cnmac1 at cn30xxgmx0: RGMII, address 44:d9:e7:40:b5:c9
atphy1 at cnmac1 phy 6: AR8035 10/100/1000 PHY, rev. 2
cnmac2 at cn30xxgmx0: RGMII, address 44:d9:e7:40:b5:ca
atphy2 at cnmac2 phy 5: AR8035 10/100/1000 PHY, rev. 2
/dev/ksyms: Symbol table not valid.
umass0 at uhub0 port 1 configuration 1 interface 0 "Lexar USB Flash
Drive" rev 2.10/11.00 addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0:  SCSI4
0/direct removable serial.05dca83aZB0L2W63LA4P
sd0: 30526MB, 512 bytes/sector, 62517248 sectors
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
boot device: sd0
root on sd0a (fb74a192b03ee90f.a) swap on sd0b dump on sd0b

Re: pf.conf "reply-to" routing parameter seemingly not working?

[Joseph Crivello]

Apologies, correction:

obsd3# pfctl -f /etc/pf.conf

Should be:

obsd2# pfctl -f /etc/pf.conf

Joe
On Sat, May 12, 2018 at 9:37 PM Joseph Crivello 
wrote:

> I cannot get reply-to working with if-bound under any circumstances. It
> works fine with floating, though.

> Is this expected behavior? The (similar) route-to option works fine with
> if-bound rules, and I cannot find any documentation that states reply-to
> cannot be used with if-bound rules.

> Assuming that this is NOT expected behavior, then this is a bug in at
least
> 6.2 through -current.

> I set up three virtual machines running -current today, in order to
> reproduce this with a basic test case:

> obsd1# echo "inet 10.84.31.10 255.255.255.0" > /etc/hostname.vmx1
> obsd1# echo "inet 10.84.32.10 255.255.255.0" > /etc/hostname.vmx2
> obsd1# echo "net.inet.ip.forwarding=1" > /etc/sysctl.conf
> obsd1# reboot
> ...
> obsd1# route add -net 10.84.33.0/24 10.84.31.11

> obsd2# echo "inet 10.84.31.11 255.255.255.0" > /etc/hostname.vmx1
> obsd2# echo "inet 10.84.32.11 255.255.255.0" > /etc/hostname.vmx2
> obsd2# echo "inet 10.84.33.11 255.255.255.0" > /etc/hostname.vmx3
> obsd2# echo "net.inet.ip.forwarding=1" > /etc/sysctl.conf
> obsd2# reboot
> ...
> obsd2# echo "pass in log on vmx1 inet from 10.84.31.10 to 10.84.33.12 keep
> state (if-bound) reply-to 10.84.32.10@vmx2" >> /etc/pf.conf
> obsd3# pfctl -f /etc/pf.conf

> Host "obsd3" has just one interface, with IP 10.84.33.12.

> No other changes were made to the hosts besides selecting typical
> installation options.

> If we test this setup with an ICMP echo to 10.84.33.12 from obsd1, here is
> what we observe:

> obsd1# ping -c 1 10.84.33.12
> PING 10.84.33.12 (10.84.33.12): 56 data bytes
> ^C
> --- 10.84.33.12 ping statistics ---
> 1 packets transmitted, 0 packets received, 100.0% packet loss

> obsd2# tcpdump -nvvpi vmx1 icmp
> tcpdump: listening on vmx1, link-type EN10MB
> 21:20:08.710088 10.84.31.10 > 10.84.33.12: icmp: echo request (id:306e
> seq:0) [icmp cksum ok] (ttl 255, id 23663, len 84)
> ^C
> 1 packets received by filter
> 0 packets dropped by kernel

> obsd2# tcpdump -nvvpi vmx2 icmp
> tcpdump: listening on vmx2, link-type EN10MB
> ^C
> 0 packets received by filter
> 0 packets dropped by kernel

> obsd2# tcpdump -nvvpi vmx3 icmp
> tcpdump: listening on vmx3, link-type EN10MB
> 21:20:08.710136 10.84.31.10 > 10.84.33.12: icmp: echo request (id:306e
> seq:0) [icmp cksum ok] (ttl 254, id 23663, len 84)
> 21:20:08.710249 10.84.33.12 > 10.84.31.10: icmp: echo reply (id:306e
seq:0)
> [icmp cksum ok] (ttl 255, id 8694, len 84)
> 21:20:08.710272 10.84.33.11 > 10.84.33.12: icmp: 10.84.31.10 protocol 1
> port 40981 unreachable [icmp cksum ok] for 10.84.33.12 > 10.84.31.10:
icmp:
> echo reply (id:306e seq:0) (ttl 254, id 8694, len 84, bad ip cksum 44f5!
->
> 45f5) (ttl 255, id 637, len 56)
> ^C
> 3 packets received by filter
> 0 packets dropped by kernel

> If we change the PF rule we created on obsd2 to "floating" and run the
same
> test again, then the test case works exactly as expected:

> obsd1# ping -c 1 10.84.33.12
> PING 10.84.33.12 (10.84.33.12): 56 data bytes
> 64 bytes from 10.84.33.12: icmp_seq=0 ttl=254 time=0.528 ms

> --- 10.84.33.12 ping statistics ---
> 1 packets transmitted, 1 packets received, 0.0% packet loss
> round-trip min/avg/max/std-dev = 0.528/0.528/0.528/0.000 ms

> obsd2# tcpdump -nvvpi vmx1 icmp
> tcpdump: listening on vmx1, link-type EN10MB
> 21:25:24.970742 10.84.31.10 > 10.84.33.12: icmp: echo request (id:8aec
> seq:0) [icmp cksum ok] (ttl 255, id 27013, len 84)
> ^C
> 1 packets received by filter
> 0 packets dropped by kernel

> obsd2# tcpdump -nvvpi vmx2 icmp
> tcpdump: listening on vmx2, link-type EN10MB
> 21:25:24.971146 10.84.33.12 > 10.84.31.10: icmp: echo reply (id:8aec
seq:0)
> [icmp cksum ok] (ttl 254, id 13581, len 84)
> ^C
> 3 packets received by filter
> 0 packets dropped by kernel

> obsd2# tcpdump -nvvpi vmx3 icmp
> tcpdump: listening on vmx3, link-type EN10MB
> 21:25:24.970800 10.84.31.10 > 10.84.33.12: icmp: echo request (id:8aec
> seq:0) [icmp cksum ok] (ttl 254, id 27013, len 84)
> 21:25:24.970933 10.84.33.12 > 10.84.31.10: icmp: echo reply (id:8aec
seq:0)
> [icmp cksum ok] (ttl 255, id 13581, len 84)
> ^C
> 2 packets received by filter
> 0 packets dropped by kernel

> I am interested in any feedback on the question of whether or not this is
> expected behavior...

> Thank you.

> Joe

> On Thu, May 10, 2018 at 1:50 AM Joe Crivello 
> wrote:

> > Hello!

> > I have a trunk0 interface on a router (#1) that is used for a singular
> > purpose -- to pass (IPsec protected) traffic for an IPIP tunnel (gif0)
to
> > another router (#2). I have configured PF rules on router #1 that
prevent
> > any other type of traffic from passing on trunk0. There are several
> routing
> > table entries that forward to router #2 on gif0.

> > My objective is to configure an additional pass rule that would allow
SSH
> > 

Re: pf.conf "reply-to" routing parameter seemingly not working?

[Joseph Crivello]

I cannot get reply-to working with if-bound under any circumstances. It
works fine with floating, though.

Is this expected behavior? The (similar) route-to option works fine with
if-bound rules, and I cannot find any documentation that states reply-to
cannot be used with if-bound rules.

Assuming that this is NOT expected behavior, then this is a bug in at least
6.2 through -current.

I set up three virtual machines running -current today, in order to
reproduce this with a basic test case:

obsd1# echo "inet 10.84.31.10 255.255.255.0" > /etc/hostname.vmx1
obsd1# echo "inet 10.84.32.10 255.255.255.0" > /etc/hostname.vmx2
obsd1# echo "net.inet.ip.forwarding=1" > /etc/sysctl.conf
obsd1# reboot
...
obsd1# route add -net 10.84.33.0/24 10.84.31.11

obsd2# echo "inet 10.84.31.11 255.255.255.0" > /etc/hostname.vmx1
obsd2# echo "inet 10.84.32.11 255.255.255.0" > /etc/hostname.vmx2
obsd2# echo "inet 10.84.33.11 255.255.255.0" > /etc/hostname.vmx3
obsd2# echo "net.inet.ip.forwarding=1" > /etc/sysctl.conf
obsd2# reboot
...
obsd2# echo "pass in log on vmx1 inet from 10.84.31.10 to 10.84.33.12 keep
state (if-bound) reply-to 10.84.32.10@vmx2" >> /etc/pf.conf
obsd3# pfctl -f /etc/pf.conf

Host "obsd3" has just one interface, with IP 10.84.33.12.

No other changes were made to the hosts besides selecting typical
installation options.

If we test this setup with an ICMP echo to 10.84.33.12 from obsd1, here is
what we observe:

obsd1# ping -c 1 10.84.33.12
PING 10.84.33.12 (10.84.33.12): 56 data bytes
^C
--- 10.84.33.12 ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss

obsd2# tcpdump -nvvpi vmx1 icmp
tcpdump: listening on vmx1, link-type EN10MB
21:20:08.710088 10.84.31.10 > 10.84.33.12: icmp: echo request (id:306e
seq:0) [icmp cksum ok] (ttl 255, id 23663, len 84)
^C
1 packets received by filter
0 packets dropped by kernel

obsd2# tcpdump -nvvpi vmx2 icmp
tcpdump: listening on vmx2, link-type EN10MB
^C
0 packets received by filter
0 packets dropped by kernel

obsd2# tcpdump -nvvpi vmx3 icmp
tcpdump: listening on vmx3, link-type EN10MB
21:20:08.710136 10.84.31.10 > 10.84.33.12: icmp: echo request (id:306e
seq:0) [icmp cksum ok] (ttl 254, id 23663, len 84)
21:20:08.710249 10.84.33.12 > 10.84.31.10: icmp: echo reply (id:306e seq:0)
[icmp cksum ok] (ttl 255, id 8694, len 84)
21:20:08.710272 10.84.33.11 > 10.84.33.12: icmp: 10.84.31.10 protocol 1
port 40981 unreachable [icmp cksum ok] for 10.84.33.12 > 10.84.31.10: icmp:
echo reply (id:306e seq:0) (ttl 254, id 8694, len 84, bad ip cksum 44f5! ->
45f5) (ttl 255, id 637, len 56)
^C
3 packets received by filter
0 packets dropped by kernel

If we change the PF rule we created on obsd2 to "floating" and run the same
test again, then the test case works exactly as expected:

obsd1# ping -c 1 10.84.33.12
PING 10.84.33.12 (10.84.33.12): 56 data bytes
64 bytes from 10.84.33.12: icmp_seq=0 ttl=254 time=0.528 ms

--- 10.84.33.12 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.528/0.528/0.528/0.000 ms

obsd2# tcpdump -nvvpi vmx1 icmp
tcpdump: listening on vmx1, link-type EN10MB
21:25:24.970742 10.84.31.10 > 10.84.33.12: icmp: echo request (id:8aec
seq:0) [icmp cksum ok] (ttl 255, id 27013, len 84)
^C
1 packets received by filter
0 packets dropped by kernel

obsd2# tcpdump -nvvpi vmx2 icmp
tcpdump: listening on vmx2, link-type EN10MB
21:25:24.971146 10.84.33.12 > 10.84.31.10: icmp: echo reply (id:8aec seq:0)
[icmp cksum ok] (ttl 254, id 13581, len 84)
^C
3 packets received by filter
0 packets dropped by kernel

obsd2# tcpdump -nvvpi vmx3 icmp
tcpdump: listening on vmx3, link-type EN10MB
21:25:24.970800 10.84.31.10 > 10.84.33.12: icmp: echo request (id:8aec
seq:0) [icmp cksum ok] (ttl 254, id 27013, len 84)
21:25:24.970933 10.84.33.12 > 10.84.31.10: icmp: echo reply (id:8aec seq:0)
[icmp cksum ok] (ttl 255, id 13581, len 84)
^C
2 packets received by filter
0 packets dropped by kernel

I am interested in any feedback on the question of whether or not this is
expected behavior...

Thank you.

Joe

On Thu, May 10, 2018 at 1:50 AM Joe Crivello 
wrote:

> Hello!

> I have a trunk0 interface on a router (#1) that is used for a singular
> purpose -- to pass (IPsec protected) traffic for an IPIP tunnel (gif0) to
> another router (#2). I have configured PF rules on router #1 that prevent
> any other type of traffic from passing on trunk0. There are several
routing
> table entries that forward to router #2 on gif0.

> My objective is to configure an additional pass rule that would allow SSH
> traffic destined for router #1 to pass in and out on trunk0.

> The problem is that the aforementioned routes on gif0 cause packets sent
in
> reply to incoming SSH traffic to pass out on gif0 (after passing in on
> trunk0). This ends up getting blocked by PF on router #1 because the
> state-policy is set to if-bound (which is how I want it). I am trying to
> use reply-to to enforce 

Remote kernel debugging with kgdb and vmm

[Xavier Guerin]

Hello,

I'd like to dive into the bridge driver and I am trying to setup a
kernel debugging environment.

I chose to use VMM to do that but I don't seem to find a way to connect
my local gdb to the VMM console. I guess I would need another serial
device for KGDB, but I have not found how to do that in the man.

Is anyone using VMM for this? Or plain old QEMU?

Thanks,
Xavier

Re: MIMO in athn(4)

[Stefan Sperling]

On Sun, May 13, 2018 at 01:32:59AM +1000, tomr wrote:
> With one antenna connected, I get about 60-80% signal on my iwm client
> at a distance of approximately 5m. With two antennas connected, the same
> client needs to be <1m away from the AP to connect at all, and even then
> gets about <20%.b

Huh, that is certainly not expected.

This driver generally works fine with two antennas. In fact, 2 antennas
are required for 11n mode to work correctly (use 11a or 11g mode instead
if only one antenna is attached). If such an issue was due to a bug in
the driver it almost certainly would have been noticed elsewhere already.

As a first step, check the health of your antennas and cables.

Re: MIMO in athn(4)

[tomr]

On 05/13/18 01:00, Stefan Sperling wrote:
> On Sat, May 12, 2018 at mybeautifulwifi10:53:29PM +1000, tomr wrote:
>>
>> I've been playing with an apu2 and an AR9280, which is supported by
athn(4).
>>
>> It seems to perform terribly when I connect a second antenna. Is this
>> the expected behaviour currently? Is there some MIMO magic that isn't
>> yet implemented? Or do I just need to get the antenna spacing right?
>>
>> I see a foreboding "No Tx aggregation" in the commit message...
>>
>> Thanks,
>> t
>>
>
> You'll need to be more specific before anyone can help you.
> You're not showing us relevant configuration files, dmesg, etc.
> See https://www.openbsd.org/report.html
>
> Note that there is one known big problem: This driver lacks periodic
> calibration which is a likely reason for bad performance in some
> environments. Make sure to pick a channel where your network
> overlaps with relatively few other networks. That might help.
>
I'll check on the local channels. In the mean time, here's more info.

With one antenna connected, I get about 60-80% signal on my iwm client
at a distance of approximately 5m. With two antennas connected, the same
client needs to be <1m away from the AP to connect at all, and even then
gets about <20%.b

hostname.athn0:
media autoselect mode 11n mediaopt hostap chan 120
nwid 
wpakey 
chan 120
inet 10.1.2.1 255.255.255.0

ifconfig athn0:
athn0: flags=8843 mtu 1500
lladdr 04:f0:21:3e:1f:93
index 1 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect (autoselect mode 11n hostap)
status: active
ieee80211: nwid  chan 120 bssid 04:f0:21:3e:1f:93 wpakey
wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp
inet 10.1.2.1 netmask 0xff00 broadcast 10.1.2.255


dmesg:
OpenBSD 6.3-current (GENERIC.MP) #29: Fri May  4 09:22:48 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4261076992 (4063MB)
avail mem = 4123918336 (3932MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdffb7020 (7 entries)
bios0: vendor coreboot version "4.0.7" date 02/28/2017
bios0: PC Engines APU2
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S2 S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC HEST SSDT SSDT HPET
acpi0: wakeup devices PWRB(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4)
PBR8(S4) UOH1(S3) UOH3(S3) UOH5(S3) XHC0(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD GX-412TC SOC, 998.25 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD GX-412TC SOC, 998.13 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1
cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB
64b/line 16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD GX-412TC SOC, 998.13 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1
cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB
64b/line 16-way L2 cache
cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: AMD GX-412TC SOC, 998.13 MHz
cpu3:

Re: MIMO in athn(4)

[Stefan Sperling]

On Sat, May 12, 2018 at 10:53:29PM +1000, tomr wrote:
> 
> I've been playing with an apu2 and an AR9280, which is supported by athn(4).
> 
> It seems to perform terribly when I connect a second antenna. Is this
> the expected behaviour currently? Is there some MIMO magic that isn't
> yet implemented? Or do I just need to get the antenna spacing right?
> 
> I see a foreboding "No Tx aggregation" in the commit message...
> 
> Thanks,
> t
> 

You'll need to be more specific before anyone can help you.
You're not showing us relevant configuration files, dmesg, etc.
See https://www.openbsd.org/report.html

Note that there is one known big problem: This driver lacks periodic
calibration which is a likely reason for bad performance in some
environments. Make sure to pick a channel where your network
overlaps with relatively few other networks. That might help.

MIMO in athn(4)

[tomr]

I've been playing with an apu2 and an AR9280, which is supported by athn(4).

It seems to perform terribly when I connect a second antenna. Is this
the expected behaviour currently? Is there some MIMO magic that isn't
yet implemented? Or do I just need to get the antenna spacing right?

I see a foreboding "No Tx aggregation" in the commit message...

Thanks,
t

Re: ikev2 All incoming/outgoing traffic over IPsec?

[Johan Hattne]

> On May 11, 2018, at 06:21, Denis  wrote:
> 
> Hello,
> 
> I have working ikev2 tunnel between two virtual aliased subnets. But no
> traffic over IPsec tunnel from $ext_if on server machine to $ext_if on
> client machine and vice-versa. Both machines are using in production and
> firewalled by PF.
> 
> 
> # cat /etc/hostname.em1
> ### server $ext_if
> dhcp
> alias 192.168.5.1
> 255.255.255.0
> 
> |
> | IPsec
> |
> 
> # cat /etc/hostname.axen0
> ### client $ext_if
> dhcp
> alias 192.168.6.1
> 255.255.255.0
> 
> 
> I can ping each 'end' of IPsec virtual subnets from both side of tunnel
> (after IP assigned to both gateways by ISP's dhcp), but no traffic though.
> 
> server# ping 192.168.6.1
> 64 bytes from 192.168.6.1: icmp_seq=0 ttl=255 time 1.064 ms
> ...
> clielnt# ping 192.168.5.1
> 64 bytes from 192.168.5.1: icmp_seq=0 ttl=255 time 0.785 ms
> ...
> 
> The final goal is: All incoming traffic on server's $ext_if = "em1" for
> selected ports 25, 443, 465, 993 etc. must be redirected from aliased
> server's IP:192.168.5.1 though IPsec tunnel to appropriate services on
> aliased client's IP:192.168.6.1. So client can reply to incoming
> connections to remote server's via IPsec lan.
> 
> No routing is needed between server's / client's 'real' private LANs.
> Because of that I've decided to use aliased virtual lans for IPsec
> tunneling. But I'm not sure about correctness of this.
> 
> server# cat /etc/iked.conf
> gw_ip   = "em1"
> local_lan = "192.168.5.0/24" # server side virtual subnet alias to em1 \
> which obtain an address from dhcp
> remote_lan = "192.168.6.0/24" # client virtual subnet alias to axen0 \
> which obtain an address from dhcp too.
> mode= "passive"
> 
> ikev2 "pki-srv" $mode ipcomp esp \
>   from $local_lan to $remote_lan \
>   local $gw_ip peer any \
>   srcid srv-pubkey dstid clnt-pubkey \
>   tag "srv.tld.ipsec"
>   tap "enc0"
> 
> server# cat /etc/pf.conf
> ...
> ext_if= em1
> ipsec_if  = em1
> ipsec_enc_if  = enc0
> ipsec_local_lan = "192.168.5.0/24"
> ipsec_remote_lan = "192.168.6.0/24"
> ...
> queue rootq on $ext_if bandwidth 100M max 100M
>queue ipsecparent rootq bandwidth 90M min 70M max 100M
>queue ipsec_users  parent rootq bandwidth 50M min 30M max 60M
>queue bulk parent rootq bandwidth 10M default
> ...
> block on $ext_if all
> block on $ipsec_enc_if all
> ...
> 
> # --- IPsec
> pass in quick on $ipsec_if proto udp from any to ($ipsec_if) port \
> {isakmp, ipsec-nat-t}
> pass out quick on $ipsec_if proto udp from ($ipsec_if) to any port \
> {isakmp, ipsec-nat-t} keep state
> 
> pass in quick on $ipsec_if proto esp from any to ($ipsec_if)
> pass out quick on $ipsec_if proto exp from ($ipsec_if) to any \
> keep state set queue ipsec
> 
> pass out quick on $ipsec_if tagged srv.tld.ipsec set queue ipsec_users
> 
> pass in quick on $ipsec_enc_if proto ipencap from any to ($ipsec_if) \
> keep state (if-bound)
> pass out quick on $ipsec_enc_if proto ipencap from ($ipsec_if) to any \
> keep state (if-bound)
> 
> pass in quick on $ipsec_enc_if from $ipsec_remote_lan to \
> $ipsec_local_lan keep state (if-bound)
> pass out quick on $ipsec_enc_if from $ipsec_local_lan to \
> $ipsec_remote_lan keep state (if-bound)
> ...
> 
> 
> client# cat /etc/iked.conf
> gw_ip   = "axen0"
> local_lan = "192.168.6.0/24" # clinet virtual subnet alias to axen0 \
> which obtain an address from dhcp
> remote_lan = "192.168.5.0/24" #server side virtual subnet alias to em0 \
> which obtain an address from dhcp
> srv_ip  = "a.b.c.d" #server's IP each time is the same from ISP's dhcp
> mode= "active"
> 
> ikev2 "pki-clnt" $mode ipcomp esp \
>   from $local_lan to $remote_lan \
>   local $gw_ip to $srv_ip \
>   crcid clnt-pubkey dstid srv-pubkey \
>   tag "clnt.tld.ipsec"
>   tap "em0"
> 
> client# cat /etc/pf.conf
> ...
> ext_if= axen0
> ipsec_if  = axen0
> ipsec_enc_if  = enc0
> ipsec_local_lan = "192.168.6.0/24"
> ipsec_remote_lan = "192.168.5.0/24"
> ...
> queue rootq on $ext_if bandwidth 100M max 100M
>queue ipsecparent rootq bandwidth 90M min 70M max 100M
>queue ipsec_users  parent rootq bandwidth 50M min 30M max 60M
>queue bulk parent rootq bandwidth 10M default
> ...
> block on $ext_if all
> block on $ipsec_enc_if all
> ...
> 
> # --- IPsec
> pass in quick on $ipsec_if proto udp from any to ($ipsec_if) port \
> {isakmp, ipsec-nat-t}
> pass out quick on $ipsec_if proto udp from ($ipsec_if) to any port \
> {isakmp, ipsec-nat-t} keep state
> 
> pass in quick on $ipsec_if proto esp from any to ($ipsec_if)
> pass out quick on $ipsec_if proto exp from ($ipsec_if) to any \
> keep state set queue ipsec
> 
> pass out quick on $ipsec_if tagged clnt.tld.ipsec set queue ipsec_users
> 
> pass in quick on 

Re: New lpd server

[Eric Faurot]

On Thu, May 10, 2018 at 10:35:01AM -0400, Predrag Punosevac wrote:
> Where can I learn more about the work on the new lpd server aside of
> reading the code? I learnt about it from the OpenBSD Journal
>
> https://undeadly.org/cgi?action=article;sid=20180509184829
> 
> 
> Thank you!
> Predrag
> 

There is really nothing more than the code currently.

Eric.