"groups in groups" with pf tables
Hi,
With other firewall products I like to use groups that contain groups.
In pf I like working with tables. Tables can be negated and rules with
tables are faster than ones with long lists.
I tried to use something like this:
$ cat pf-examples.conf
host_a1 = "192.168.10.11"
host_a2 = "192.168.10.12"
a_hosts = $host_a1 $host_a2
host_b1 = "192.168.20.11"
host_b2 = "192.168.20.12"
b_hosts = $host_b1 $host_b2
net_c1 = "192.168.30.0/24"
net_c2 = "192.168.31.0/24"
c_hosts = $net_c1 $net_c2
table { $a_hosts $b_hosts }
table { $a_hosts $b_hosts $c_hosts }
block log
pass log from to any
pass log inet proto icmp from to any
Unfortunately this does not work with macros containing subnets.
$ pfctl -nf pf-examples.conf
pf-examples.conf:11: syntax error
pf-examples.conf:14: macro 'c_hosts' not defined
pf-examples.conf:14: syntax error
$
Do I miss something regarding the syntax?
Are there other approaches to reach my goal?
Thanks,
Remi
Re: Read sysctl from file
On Thu, Jul 20, 2017 at 06:14:03PM -0700, Lyndon Nerenberg wrote: > > > On Jul 20, 2017, at 6:35 AM, BARDOU Pierre wrote: > > > > Hello, > > > > Is there a way to make sysctl re-read its conf file, or even another file, > > like sysctl -p does on linux systems ? > > Supporting this option would be nice, as it is used by the sysctl module of > > ansible. I'm also using Ansible to distribute sysctl configs to OpenBSD hosts. In the sysctl tasks I set sysctl_set to yes and reload to no. That works fine. Remi
Re: touchpad input driver: testing needed
On Mon, Jul 31, 2017 at 11:02:28PM +0200, Ulf Brosziewski wrote: > for you. As always, a dmesg would be appreciated. The output of > # wsconsctl | grep 'mouse' > could also be of interest here (you must run it as root). This is from a Dell XPS 13 9343. The mouse pointer moves into the wrong (opposite) direction. Only the left soft button is available. mistral ~$ doas wsconsctl | grep mouse wsconsctl: Use explicit arg to view keyboard.map. wsconsctl: mousecfg error: WSMOUSEIO_GETPARAMS (-1) mouse.type=elantech mouse.rawmode=0 mouse.scale=0,1013,0,566,0,0,0 mistral ~$ With the synaptics driver I use this configuration: Section "InputDevice" Identifier "clickpad" Driver "synaptics" Option "Device" "/dev/wsmouse0" Option "AutoServerLayout" "true" Option "ClickPad" "true" Option "EmulateMidButtonTime" "0" Option "SoftButtonAreas""80% 0 82% 0 40% 79% 82% 0" Option "VertTwoFingerScroll""true" Option "TapButton1" "1" EndSection OpenBSD 6.1-current (GENERIC.MP) #40: Wed Aug 2 18:53:06 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8473636864 (8081MB) avail mem = 8210477056 (7830MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed7d0 (84 entries) bios0: vendor Dell Inc. version "A12" date 05/09/2017 bios0: Dell Inc. XPS 13 9343 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! SSDT SSDT SSDT SSDT PCCT SSDT SSDT SSDT SLIC MSDM DMAR CSRT BGRT acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2195.26 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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 2195263540 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2194.92 MHz 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,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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2194.92 MHz 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,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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2194.92 MHz 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,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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpimadt0: bogus nmi for apid 0 acpimadt0: bogus nmi for apid 2 acpimadt0: bogus nmi for apid 1 acpimadt0: bogus nmi for apid 3 acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus 1 (RP01) acpiprt5 at acpi0: bus -1 (RP02) acpiprt6 at acpi0: bus -1 (RP03) acpiprt7 at acpi0: bus 2 (RP04) acpiprt8 at acpi0: bus -1 (RP05) acpiprt9 at a
Re: touchpad input driver: testing needed
On Thu, Aug 03, 2017 at 10:48:12PM +0200, Ulf Brosziewski wrote: > Sorry, I should have been more explicit in my message: Not all > hardware and driver setups are supported yet. Your touchpad is > a HID device, a "Windows Precision Touchpad". Up to now, the > hardware driver (imt(4)) hasn't been adapted to the new wsmouse > functionality, only models that run with pms(4) or ubcmtp(4) > can use the input driver. > > What you see with ws is your touchpad emulating a PS2 mouse. I see. Thanks for the info. > Of course, updating the other touchpad hardware drivers belongs > to the next steps on the agenda. In case you want to test kernel > patches for your case, please tell me ;-) Sure, I can test patches ;-)
Re: 4k display on integrated Intel graphics?
On Fri, Jun 29, 2018 at 11:04:12PM +0200, Maximilian Pichler wrote: > On Fri, Jun 29, 2018 at 9:49 PM, Bryan Vyhmeister > wrote: > > It should work fine because the USB-C ports have DisplayPort signaling > > built-in and I would not expect any issues. > > > > https://www.displayport.org/displayport-over-usb-c/ > > > > HDMI 1.4 does not support 4k at 60Hz like HDMI 2.0 does but HDMI 2.0 is > > not supported as you found out. I have not tested USB-C to DP > > specifically with my NUC6i7KYK but it does drive 4k over DisplayPort > > which should be the same with USB-C to DP. I do get some weird artifacts > > like the screen "shaking" back and forth a bit until I launch Xorg which > > then works perfectly. > > Thanks for explaining. Some shaking could be lived with... > > I just realized that some monitors (e.g. LG 27UD88) can connect via > USB-C directly, whilest serving as a USB hub and power source. Would > this be expected to work as well? Yes, this works. I connect my Asus UX390UAK to a Lenovo P27h with USB-C. This monitor is not 4k but "only" 2560x1440. Keyborad and mouse are connected to the monitor and the monitor also powers the notebook. Remi
Re: alien OSPF route
On Thu, Sep 13, 2018 at 05:21:37PM +0200, Marko Cupać wrote:
> Hi,
>
> I saw this in my log for the first time, after adding 'no redistribute
> default':
>
> ospfd[10921]: alien OSPF route 10.30.1.47/32
>
> My ospfd.conf is quite minimal:
>
> router-priority 0
> router-id IP.ADD.RE.SS
> no redistribute default
> area 0.0.0.0 {
> interface bnx0 { metric 100 }
> }
>
> How to further investigate this? I see this on OpenBSD firewall which
> connects to Cisco router. The address appears to be smartphone on one
> of remote networks.
ospfd logs this message when it sees a routing entry with priority 32
which it did not originate.
When you see this during the start of ospfd it could be from another ospfd
running in the same rdomain. I had this when I wanted to do a config check
but missed to option "-n" and started a second instance. There is now
a check for this in the startup of ospfd in -current.
You will also see this message when you add a static route with the
"-priority 32". ospfd removes such routes after logging it.
What did you do after adding "no redistribute default" to the config file?
Restart with rcctl, reload with ospfctl?
And why did you add "no redistribute default"? By default your default
route is not redistributed.
Remi
Re: alien OSPF route
On Fri, Sep 14, 2018 at 10:07:35AM +0200, Marko Cupać wrote: > On Thu, 13 Sep 2018 21:13:11 +0200 > Remi Locherer wrote: > > > On Thu, Sep 13, 2018 at 05:21:37PM +0200, Marko Cupać wrote: > > > Hi, > > > > > > I saw this in my log for the first time, after adding 'no > > > redistribute default': > > > > > > ospfd[10921]: alien OSPF route 10.30.1.47/32 > > > > > > ospfd logs this message when it sees a routing entry with priority 32 > > which it did not originate. > > Thank you for clarification, Remi. Indeed, this firewall gets > default route with priority of 32 from downstream cisco router, which > is visible in routing table: This is a different thing! ospfd learns the default route from another router and installs it into the routing table with prio 32. Prio 32 is the prio of OSPF in OpenBSD. > Internet: > Destination Gateway Flags Refs Use Mtu Prio Iface > default 193.53.106.254 UGS 1187 10456064776 - 8 bnx1 > default 192.168.225.6UG 00 -32 carp1 The route learned via ospf is not used in this case since you have a static default route. > > When you see this during the start of ospfd it could be from another > > ospfd running in the same rdomain. I had this when I wanted to do a > > config check but missed to option "-n" and started a second instance. > > There is now a check for this in the startup of ospfd in -current. > > Those addresses reported as alien routes are on subnet which is > connected to another openbsd box, something like this: > > openbsd---cisco---openbsd > > All those three boxes talk OSPF. But on remote openbsd box which > probably reports those routes, vlan interfaces for these subnets are > set as passive, so they shouldn't get any updates even if someone ran > OSPF on their phone. > > > You will also see this message when you add a static route with the > > "-priority 32". ospfd removes such routes after logging it. > > > > What did you do after adding "no redistribute default" to the config > > file? Restart with rcctl, reload with ospfctl? > > Restart with rcctl. Did you save the console output and daemon log from the restart? Can you share it? It could mean that the "old" ospfd did not properly clean up it's routes and the "new" ospfd removed the routes from the "old" one. > > > And why did you add "no redistribute default"? By default your default > > route is not redistributed. > > I thought this firewall's carp partner to-be was getting default route > from it, but it doesn't - it gets it from downstream cisco router. > > I don't see any negative effects on my network, just curious if I > should be worried :) Would I be in charge of running this network I would want to know where these alien routes come from. But I think it did not affect your network badly since you did not mention an outage. ;-) > > Regards, > -- > Before enlightenment - chop wood, draw water. > After enlightenment - chop wood, draw water. > > Marko Cupać > https://www.mimar.rs/
Re: alien OSPF route
On Fri, Sep 14, 2018 at 03:48:36PM +0200, Marko Cupać wrote: > On Fri, 14 Sep 2018 15:27:30 +0200 > Remi Locherer wrote: > > > Did you save the console output and daemon log from the restart? > > Can you share it? > > I restarted ospfd again with rcctl, console output gives just usual: > > ospfd(ok) > ospfd(ok) > > The second one waiting a bit more than I remember it used to. > > Here's ospfd-related stuff from daemon log: > > Sep 14 15:40:58 nat1 ospfd[34802]: route decision engine exiting > Sep 14 15:40:58 nat1 ospfd[73845]: ospf engine exiting > Sep 14 15:40:58 nat1 ospfd[2242]: kernel routing table decoupled > Sep 14 15:40:58 nat1 ospfd[2242]: terminating At this point no IPv4 routes with priority 32 should exists on host nat1. You can check this with "route -n show -priority 32". But according to the following log entries there still where some. How many OSPF routes do you have on host nat1? Which OpenBSD version? If I find the time I'll try to reproduce this. > Sep 14 15:40:58 nat1 ospfd[55815]: startup > Sep 14 15:40:58 nat1 ospfd[55815]: alien OSPF route 10.30.1.45/32 > Sep 14 15:40:58 nat1 ospfd[55815]: alien OSPF route 10.30.1.56/32 > Sep 14 15:40:58 nat1 ospfd[55815]: alien OSPF route 10.30.6.81/32 > Sep 14 15:40:58 nat1 ospfd[55815]: alien OSPF route 10.30.19.42/32 > > First three alien routes are on openbsd router two hops away, the last > one is my laptop which is one hop away. > > Could it be these are routes installed when someone connects through > ssh? I am connected through ssh, and it is possible that my colleague > also connected through ssh from 10.30.1.X and 10.30.6.X addresses. > > > Would I be in charge of running this network I would want to know > > where these alien routes come from. But I think it did not affect > > your network badly since you did not mention an outage. ;-) > > My point exactly :) If you have any idea where to start looking I'd be > grateful for any tips. > > Thank you for helping me with this. > -- > Before enlightenment - chop wood, draw water. > After enlightenment - chop wood, draw water. > > Marko Cupać > https://www.mimar.rs/
Re: Ospf adding new interface
Hi Simon
On Fri, Sep 28, 2018 at 10:22:42PM +0200, Simen Stavdal wrote:
> Hi all,
>
> On 6.3, using both octeon and amd64.
>
> While ospfd is running, I would like to add another interface (let’s say a
> loopback if). After adding the loopback if to ospf as passive I reload
> with ospfctl, but it does not start advertising the new interface. Only
> when I restart ospfd will it start doing so, but it seems a bit intrusive
> as all neighbours will recalculate. I am sure that something basic had
> slipped my mind. Any way to make it register the new if?
>
> The config is working since it does pick up the if on ospfd restart.
>
When I do what you describe the route is immediate seen by other ospf
router. I quickly checked on amd64 -current VMs. I did this many times
in the last few years and it always worked for me.
I tested now with this config:
r2# cat /etc/ospfd.conf
router-id 192.168.250.102
area 0.0.0.0 {
interface vio0
interface vlan1
}
Then I started ospfd and created lo33. After that I added this line to
ospfd.conf:
interface lo33 { passive }
Then I did "ospfctl reload" and the expectd route appeared in neighbor's
routing table.
Regards,
Remi
Re: ospfd fib and kernel fib
On Mon, Oct 22, 2018 at 08:48:28AM +0200, open...@kene.nu wrote:
> Hello,
>
> I am having trouble with ospfd not updating the kernel fib as it
> should (I think). This is in my lab environment on vagrant.
>
> host# uname -a
> OpenBSD host 6.4 GENERIC.MP#329 amd64
> host# ospfctl sh rib | grep 172.29.21.2
> 172.29.21.2/32 172.29.2.10 Intra-Area Network 20 00:03:12
> host# ospfctl sh fib | grep 172.29.21.2
> *O 32 172.29.21.2/32 172.29.2.10
> host# netstat -rn | grep 172.29.21.2
> host# cat /etc/ospfd.conf
> router-id 172.29.23.2
>
> area 0.0.0.0 {
> auth-type crypt
> auth-md 1 "one"
> auth-md 2 "two"
> auth-md-keyid 1
> }
Is this the config that was active while you produced above outputs?
It does not contain any interface statements.
>
> So, what is going on? The route is in the ospfd fib but not in the
> kernel fib. I understand that the next hop must be reachable, and it
> is. Other than that I have no idea what qualifies a route to be
> propagated from ospf fib to kernel fib.
>
Re: ospfd fib and kernel fib
On Tue, Oct 23, 2018 at 01:14:52PM +0200, open...@kene.nu wrote:
> Hello,
> On Mon, Oct 22, 2018 at 4:24 PM Remi Locherer wrote:
> >
> > On Mon, Oct 22, 2018 at 08:48:28AM +0200, open...@kene.nu wrote:
> > > Hello,
> > >
> > > I am having trouble with ospfd not updating the kernel fib as it
> > > should (I think). This is in my lab environment on vagrant.
> > >
> > > host# uname -a
> > > OpenBSD host 6.4 GENERIC.MP#329 amd64
> > > host# ospfctl sh rib | grep 172.29.21.2
> > > 172.29.21.2/32 172.29.2.10 Intra-Area Network 20
> > > 00:03:12
> > > host# ospfctl sh fib | grep 172.29.21.2
> > > *O 32 172.29.21.2/32 172.29.2.10
> > > host# netstat -rn | grep 172.29.21.2
> > > host# cat /etc/ospfd.conf
> > > router-id 172.29.23.2
> > >
> > > area 0.0.0.0 {
> > > auth-type crypt
> > > auth-md 1 "one"
> > > auth-md 2 "two"
> > > auth-md-keyid 1
> > > }
> >
> > Is this the config that was active while you produced above outputs?
> > It does not contain any interface statements.
> >
>
> Oh, I accidentally, and erroneously, stripped those along with other
> non relevant config. Assume the interface statements are there.
It's really hard to help with config snippets containing only what is
considered "relevant" by some.
It's much more likely that someone tries to understand your problem if you
post all information. In this case I would expect the full ospf config, the
full output of netstat -rn and the ospf rib and fib.
>
> > >
> > > So, what is going on? The route is in the ospfd fib but not in the
> > > kernel fib. I understand that the next hop must be reachable, and it
> > > is. Other than that I have no idea what qualifies a route to be
> > > propagated from ospf fib to kernel fib.
> > >
>
Re: ospfd in 6.6 when dying doesn't recover database before adj timer expires
Hi Tobias, On Fri, Apr 03, 2020 at 08:39:30AM +, Tobias Urdin wrote: > Hello, > > > We've seen a issue where if you perform a ospfctl reload and have a faulty > configuration for example a interface > > that doesn't exist it dies (which is fair in itself) but the seq num for the > database never catches up with the DR until > > the adjacency timer expires over and over again, can take up to 30 minutes > before it's back. > > > I produce a failure with a faulty interface. > > Apr 3 10:03:46 router1 ospfd[36062]: fatal in rde: rde_nbr_new: unknown > interface > Apr 3 10:03:46 router1 ospfd[19043]: ospf engine exiting > Apr 3 10:03:46 router1 ospfd[67917]: kernel routing table decoupled > Apr 3 10:03:46 router1 ospfd[67917]: terminating Can you tell us, how this failure can be reproduced? ospfd is supposed to log that a config reload failed and carry on with it's old config. > Upon startup we then get stuck in this loop och trying to get back. > > Apr 3 10:04:15 router1 ospfd[91965]: startup > Apr 3 10:06:22 router1 ospfd[19699]: nbr_adj_timer: failed to form adjacency > with x.x.x.1 on interface vmx0 > Apr 3 10:06:42 router1 ospfd[19699]: recv_db_description: neighbor ID > x.x.x.1: invalid seq num, mine 27a9fd66 his 27a99b25 > Apr 3 10:08:22 router1 ospfd[19699]: nbr_adj_timer: failed to form adjacency > with x.x.x.1 on interface vmx0 > Apr 3 10:09:17 router1 ospfd[19699]: recv_db_description: neighbor ID > x.x.x.1: invalid seq num, mine 27aa6475 his 27a9fd69 > Apr 3 10:10:22 router1 ospfd[19699]: nbr_adj_timer: failed to form adjacency > with x.x.x.1 on interface vmx0 > Apr 3 10:11:02 router1 ospfd[19699]: recv_db_description: neighbor ID > x.x.x.1: invalid seq num, mine 27aa9109 his 27aa6476 > Apr 3 10:11:22 router1 ospfd[19699]: recv_db_description: neighbor ID > x.x.x.1: invalid seq num, mine 27aa9109 his 27aa6476 > Apr 3 10:11:27 router1 ospfd[19699]: recv_db_description: neighbor ID > x.x.x.1: invalid seq num, mine 27aa9109 his 27aa6476 > Apr 3 10:11:32 router1 ospfd[19699]: recv_db_description: neighbor ID > x.x.x.1: invalid seq num, mine 27aa9109 his 27aa6476 > Apr 3 10:11:37 router1 ospfd[19699]: recv_db_description: neighbor ID > x.x.x.1: invalid seq num, mine 27aa9109 his 27aa6476 > Apr 3 10:11:42 router1 ospfd[19699]: recv_db_description: neighbor ID > x.x.x.1: invalid seq num, mine 27aa9109 his 27aa6476 > Apr 3 10:11:47 router1 ospfd[19699]: recv_db_description: neighbor ID > x.x.x.1: invalid seq num, mine 27aa9109 his 27aa6476 > Apr 3 10:12:22 router1 ospfd[19699]: nbr_adj_timer: failed to form adjacency > with x.x.x.1 on interface vmx0 > Apr 3 10:12:51 router1 ospfd[19699]: recv_db_description: neighbor ID > x.x.x.1: invalid seq num, mine 27ab558d his 27aa910b > Apr 3 10:12:51 router1 ospfd[19699]: recv_db_description: neighbor ID > x.x.x.1: invalid seq num, mine 27ab558d his 27aa910b > > Can you share a pcap file with the OSPF packages during this situation? > It's like it cannot match the database with the DR until the > DEFAULT_ADJ_TMOUT (120sec) timeout occurs and it starts all over again. > > Anybody seen this before? Should probably note that the DR in the other end > is not a device running OpenOSPFD. What device / software version is on the other end? Thank you, Remi
Re: OSPF seems to stops processing updates
forgot to add misc@ ...
On Mon, Apr 13, 2020 at 11:18:17AM +0200, Remi Locherer wrote:
> Hi Richard,
>
> On Mon, Apr 13, 2020 at 08:38:31AM +0100, Richard Chivers wrote:
> > We have been having a strange issue, whereby OSPF stops updating properly.
> >
> > We can see an entry for an ip route in the database but it is not in the
> > kernel routing table, and when it is the DR, other routers then do not have
> > the route at all.
> >
> > We are seeing this across multiple boxes. We have 10+ ospf speakers, and
> > seem to see the issue at different times.
> >
> > The problem starts with:
> >
> > ospfd[6960]: recv_db_description: neighbor ID x.x.x.x: seq num mismatch,
> > bad flags
>
> The neighbor sent a db desc with the master flag set differently than what
> this ospfd instance recorded before for that particular neighbor.
>
> See 2nd last item on page 100 of RFC 2328:
> https://tools.ietf.org/html/rfc2328#page-100
>
> > ospfd[30114]: lsa_check: bad age
> >
> > And these just then continue, until we restart ospfd, and the problem
> > appears to go away.
>
> Is the neighbor also OpenBSD ospfd or something else?
>
> >
> > We are running some old routers on 5.8 and some new on 6.4. We appreciate
> > that we need to upgrade the 5.8 routers but we are keen to stabalise things
> > first.
> >
> > Having looked at the source, we can see the line generating the message:
> >
> > case NBR_STA_FULL:
> > if (dd_hdr.bits & OSPF_DBD_I ||
> > !(dd_hdr.bits & OSPF_DBD_MS) == !nbr->dd_master) {
> > log_warnx("recv_db_description: neighbor ID %s: "..
> >
> > Could anyone explain the scenario in which this would be expected, so we
> > can see how to resolve the issue.
>
> Please share a pcap file with the OSPF packets. With this we can better
> understand how this happens and where to look for a bug.
>
> >
> > We run some of our routers under VMware, could some sort of OS pause cause
> > this?
>
> Maybe if the router is not getting all OSPF packets because of this.
>
> Remi
Re: OSPF seems to stops processing updates
On Mon, Apr 13, 2020 at 12:05:10PM +0100, Richard Chivers wrote:
> Thanks. Please see my comments below.
>
> On Mon, 13 Apr 2020, 10:18 Remi Locherer, wrote:
>
> > Hi Richard,
> >
> > On Mon, Apr 13, 2020 at 08:38:31AM +0100, Richard Chivers wrote:
> > > We have been having a strange issue, whereby OSPF stops updating
> > properly.
> > >
> > > We can see an entry for an ip route in the database but it is not in the
> > > kernel routing table, and when it is the DR, other routers then do not
> > have
> > > the route at all.
> > >
> > > We are seeing this across multiple boxes. We have 10+ ospf speakers, and
> > > seem to see the issue at different times.
> > >
> > > The problem starts with:
> > >
> > > ospfd[6960]: recv_db_description: neighbor ID x.x.x.x: seq num mismatch,
> > > bad flags
> >
> > The neighbor sent a db desc with the master flag set differently than what
> > this ospfd instance recorded before for that particular neighbor.
> >
> > See 2nd last item on page 100 of RFC 2328:
> > https://tools.ietf.org/html/rfc2328#page-100
>
>
> Thanks, should the routers just recover then from this scenario even if it
> was happening due to lost packets, CPU pause etc.
I think so. But it may take quite a while. It might also be an bug in ospfd
or in another implementation.
>
> >
> > > ospfd[30114]: lsa_check: bad age
> > >
> > > And these just then continue, until we restart ospfd, and the problem
> > > appears to go away.
> >
> > Is the neighbor also OpenBSD ospfd or something else?
> >
> >
> >
> The neighbors complaining are openbsd, we do however have a couple of
> differeent neighbors that are not openbsd.
What software (incl. version please) are these neighbors that make ospfd
log these messages? It should be easy to identify those neighbors since you
see the neighbor ID in the log message.
>
> >
> > > We are running some old routers on 5.8 and some new on 6.4. We appreciate
> > > that we need to upgrade the 5.8 routers but we are keen to stabalise
> > things
> > > first.
> > >
> > > Having looked at the source, we can see the line generating the message:
> > >
> > > case NBR_STA_FULL:
> > > if (dd_hdr.bits & OSPF_DBD_I ||
> > > !(dd_hdr.bits & OSPF_DBD_MS) == !nbr->dd_master) {
> > > log_warnx("recv_db_description: neighbor ID %s: "..
> > >
> > > Could anyone explain the scenario in which this would be expected, so we
> > > can see how to resolve the issue.
> >
> > Please share a pcap file with the OSPF packets. With this we can better
> > understand how this happens and where to look for a bug.
>
>
> We will take a look at this. May be difficult to catch due to regularity.
> Every 30 mins or so.
Then just let tcpdump run for a few hours. If you filter for ospf it should
not need too much diskspace. And don't forget to raise the snaplen.
Eg: tcpdump -i em1 -s 1500 -w /tmp/ospf.pcap proto ospf
>
> >
> > > We run some of our routers under VMware, could some sort of OS pause
> > cause
> > > this?
> >
> > Maybe if the router is not getting all OSPF packets because of this.
> >
> > Remi
> >
Re: OSPF seems to stops processing updates
On Mon, Apr 13, 2020 at 03:30:12PM +0100, Stuart Henderson wrote: > On 2020/04/13 15:21, Richard Chivers wrote: > > Hi, > > > > Thanks everyone, we will update to start with and see how it goes from > > there. If the issues > > continue we will dump the ospf traffic. > > > > When we were looking at these issues I noticed when running ospfctl sh nei > > that we had two DR. > > That will definitely happen with pre-6.3 versions after some flaps. Seeing two DRs in the output of "ospfctl sh nei" is not an issue. There must be a DR for each broadcast or NBMA network. But you should not see multiple DR neighbors on the same link. > > > I thought there could/should only be a single one. > > > > Any ideas on this, are there snearios where this is valid? We only run a > > single area. > > > > Thanks > > > > Richard > > > > > > > > On Mon, 13 Apr 2020, 14:39 Stuart Henderson, wrote: > > > > On 2020-04-13, Claudio Jeker wrote: > > > On Mon, Apr 13, 2020 at 02:08:31PM +0200, Remi Locherer wrote: > > >> On Mon, Apr 13, 2020 at 12:05:10PM +0100, Richard Chivers wrote: > > >> > On Mon, 13 Apr 2020, 10:18 Remi Locherer, > > wrote: > > >> > > > > >> > > On Mon, Apr 13, 2020 at 08:38:31AM +0100, Richard Chivers wrote: > > >> > > > We have been having a strange issue, whereby OSPF stops > > updating > > >> > > properly. > > >> > > > > > >> > > > We can see an entry for an ip route in the database but it is > > not in the > > >> > > > kernel routing table, and when it is the DR, other routers > > then do not > > >> > > have > > >> > > > the route at all. > > >> > > > > > >> > > > We are seeing this across multiple boxes. We have 10+ ospf > > speakers, and > > >> > > > seem to see the issue at different times. > > >> > > > > > >> > > > The problem starts with: > > >> > > > > > >> > > > ospfd[6960]: recv_db_description: neighbor ID x.x.x.x: seq num > > mismatch, > > >> > > > bad flags > > >> > > > > >> > > The neighbor sent a db desc with the master flag set differently > > than what > > >> > > this ospfd instance recorded before for that particular neighbor. > > >> > > > > >> > > See 2nd last item on page 100 of RFC 2328: > > >> > > https://tools.ietf.org/html/rfc2328#page-100 > > >> > > > >> > > > >> > Thanks, should the routers just recover then from this scenario > > even if it > > >> > was happening due to lost packets, CPU pause etc. > > >> > > >> I think so. But it may take quite a while. It might also be an bug > > in ospfd > > >> or in another implementation. > > > > On my 6.6/current boxes it seems to recover fairly quickly from this (30 > > seconds or so). I've definitely seen it take a long time in the past > > though. > > > > > Since this issues happen with 5.8 and 6.4 ospfd I would suggest to > > update > > > to at least 6.6 (especially the 5.8). IIRC there was some issue with > > ospfd > > > neighbor selection that caused troubles when sessions flapped. This > > was > > > fixed some time ago but I doubt 5.8 has that fix in. > > > > That one was fixed in 6.3. > > > > If you also run bgpd then be aware there are crashes with the version in > > 6.6 release - fixed in syspatches (and of course in snapshots), but one > > of the crashes is at startup with some configurations and it's hard to > > run syspatch if you have no routing ;) so either be ready to cope with > > that in case you run into it (e.g. pre-download the syspatch directory > > and make sure you have console access), or consider skipping 6.6 (go > > straight to a -current snapshot). > > > > > > >
Re: aggr(4) not working with Intel XXV710 SFP28 on a Supermicro X11DPi-N(T)
On Tue, Aug 11, 2020 at 02:07:32PM -0400, Winfred Harrelson wrote: > I know others are using the new aggr(4) interface but I am having a > problem with trying to use it on some new servers I have recently > gotten. Hoping I could get some help from someone here since my > searches have not been very fruitful. > > First off this is on a Supermicro X11DPi-N(T) and it is running a 6.7 > snapshot from today because the 6.7 release hangs on trying to install. > > I have two Intel duel port XXV710 cards with SPF28 and trying to > create an LACP bond. Works fine using the trunk(4) interface but > not the aggr(4) interface. This is what I get: > > styx# ifconfig ixl0 > ixl0: flags=8843 mtu 1500 > lladdr fe:e1:ba:d0:cc:aa > index 1 priority 0 llprio 3 > trunk: trunkdev aggr1 ^ ixl0 is already member of aggr1 > media: Ethernet autoselect (25GbaseSR full-duplex) > status: active > styx# ifconfig ixl2 > ixl2: flags=8843 mtu 1500 > lladdr fe:e1:ba:d0:cc:aa > index 3 priority 0 llprio 3 > trunk: trunkdev aggr1 ^ same here > media: Ethernet autoselect (25GbaseSR full-duplex) > status: active > > So everything looks good. Now to create the bond: > > styx# ifconfig aggr0 create > styx# ifconfig aggr0 trunkport ixl0 > styx# ifconfig aggr0 trunkport ixl2 > styx# ifconfig aggr0 up > here you add them to aggr0. have you checked if aggr1 is operational? > No error message so that seems good, however when I look at the bond > I get "no carrier": > > styx# ifconfig aggr0 > aggr0: flags=8843 mtu 1500 > lladdr fe:e1:ba:d1:7d:55 > index 13 priority 0 llprio 7 > trunk: trunkproto lacp > trunk id: [(8000,fe:e1:ba:d1:7d:55,000D,,), > (,00:00:00:00:00:00,,,)] > ixl0 lacp actor system pri 0x8000 mac fe:e1:ba:d1:7d:55, key > 0xd, port pri 0x8000 number 0x1 > ixl0 lacp actor state activity,aggregation,defaulted > ixl0 lacp partner system pri 0x0 mac 00:00:00:00:00:00, key > 0x0, port pri 0x0 number 0x0 > ixl0 lacp partner state activity,aggregation,sync > ixl0 port > ixl2 lacp actor system pri 0x8000 mac fe:e1:ba:d1:7d:55, key > 0xd, port pri 0x8000 number 0x3 > ixl2 lacp actor state activity,aggregation,defaulted > ixl2 lacp partner system pri 0x0 mac 00:00:00:00:00:00, key > 0x0, port pri 0x0 number 0x0 > ixl2 lacp partner state activity,aggregation,sync > ixl2 port > groups: aggr > media: Ethernet autoselect > status: no carrier > > If I add debug to the ifconfig this is all I get in messages: > > Aug 11 13:45:37 styx /bsd: aggr0 ixl0 trunkport: creating port > Aug 11 13:45:37 styx /bsd: aggr0 ixl0 mux: BEGIN (BEGIN) -> DETACHED > Aug 11 13:45:37 styx /bsd: aggr0 ixl0 rxm: BEGIN (BEGIN) -> INITIALIZE > Aug 11 13:45:37 styx /bsd: aggr0 ixl0 rxm: INITIALIZE (UCT) -> PORT_DISABLED > Aug 11 13:45:37 styx /bsd: aggr0 ixl0 rxm: PORT_DISABLED (port_enabled) -> > LACP_DISABLED > Aug 11 13:45:44 styx /bsd: aggr0 ixl2 trunkport: creating port > Aug 11 13:45:44 styx /bsd: aggr0 ixl2 mux: BEGIN (BEGIN) -> DETACHED > Aug 11 13:45:44 styx /bsd: aggr0 ixl2 rxm: BEGIN (BEGIN) -> INITIALIZE > Aug 11 13:45:44 styx /bsd: aggr0 ixl2 rxm: INITIALIZE (UCT) -> PORT_DISABLED > Aug 11 13:45:44 styx /bsd: aggr0 ixl2 rxm: PORT_DISABLED (port_enabled) -> > LACP_DISABLED > Aug 11 13:45:48 styx /bsd: aggr0 ixl0 rxm: LACP_DISABLED (LACP_Enabled) -> > PORT_DISABLED > Aug 11 13:45:48 styx /bsd: aggr0 ixl0 rxm: PORT_DISABLED (port_enabled) -> > EXPIRED > Aug 11 13:45:48 styx /bsd: aggr0 ixl2 rxm: LACP_DISABLED (LACP_Enabled) -> > PORT_DISABLED > Aug 11 13:45:48 styx /bsd: aggr0 ixl2 rxm: PORT_DISABLED (port_enabled) -> > EXPIRED > Aug 11 13:45:51 styx /bsd: aggr0 ixl0 rxm: EXPIRED (current_while_timer > expired) -> DEFAULTED > Aug 11 13:45:51 styx /bsd: aggr0 ixl0: selection logic: unselected (rxm > !CURRENT) > Aug 11 13:45:51 styx /bsd: aggr0 ixl2 rxm: EXPIRED (current_while_timer > expired) -> DEFAULTED > Aug 11 13:45:51 styx /bsd: aggr0 ixl2: selection logic: unselected (rxm > !CURRENT) > > > Only thing I have found so far is a few threads from Nov - Dec 2019: > > https://marc.info/?l=openbsd-misc&m=157641049328878&w=2 > https://marc.info/?l=openbsd-misc&m=157537227501920&w=2 > https://marc.info/?l=openbsd-misc&m=157374699108084&w=2 > > > As with the above threads this works fine using the trunk(4) interface > just not the newer aggr(4) interface. > > They are connected to a Cisco Nexus 9508 switch. Any ideas of what > I can try? dmesg below > > Thanks > > Winfred > > > > stem subclass miscellaneous, rev 0x07) at pci4 dev 8 function 6 not configured > vendor "Intel", unknown product 0x208d (class system subclass miscellaneous, > r
Re: bgpd config advice needed
On Tue, Aug 25, 2020 at 07:11:12AM -, Stuart Henderson wrote: > On 2020-08-24, Claudio Jeker wrote: > > On Mon, Aug 24, 2020 at 04:36:10PM +, Laura Smith wrote: > >> *> N 2001:db8:::/29 2001:db8::::1 100 100 > >> 64512 65500 i > >> * N 2001:db8:::/29 2001:db8::::2 100 100 > >> 65500 65500 i > >> > >> In this example, both 64512 and 65500 are peers (med=100) but obviously > >> 65500 65500 should be the preferred route. > > That's not obvious to me. (The behaviour would be the same with the more > common localpref setting too). AS path length is the same for both cases and med is also the same. The selected path comes from the peer with the lowest IP address I guess. > > > Now it is a bit strange that an AS is prepending on peering. I wonder why > > they do that (is their connection to the IX undersized?). > Maybe AS 65500 just aranged a new peering with AS 64512 and now needs to impose more traffic to suffice some peering agreements? Dr. Peering might give some hints. ;-) http://drpeering.net/tools/HTML_IPP/ipptoc.html
Re: Problems with route installation to fib from OSPF
Hi João, On Thu, Oct 10, 2019 at 03:01:30PM +0200, Joao Alves wrote: > Hello OpenBSD team, > > > We are facing an issue with OSPF related routes and would like to > request your help as it seems to be a OSPF to FIB route replication issue. > > This happened already once in a different location, that one is running > OpenBSD 6.3 and the site of the current report is OpenBSD 6.5 > > > *Describing:* > > > We have a setup with a FW cluster of 2 hosts talking OSPF to 2 Ubuntu > boxes running Quagga. > > > The 2 Ubuntu boxes run keepalived between them to install a secondary IP > address on the interface, the service IP address. > > OSPF is configured to advertise this floating service IP and it's > advertised only when it's available in the interface. > > OSPF is configured to not become DR/BDR in Ubuntu hosts > > > *Initial state:* > > Service is active in ubuntu host A, everything working. > > root@fw1:~# ospfctl show nei > ID Pri State DeadTime Address Iface Uptime > (...) > 10.10.53.28 1 FULL/OTHER 00:00:04 10.10.53.28 vlan1353 00:16:01 > 172.16.50.3 1 FULL/DR 00:00:04 10.10.53.27 vlan1353 03w2d10h > 10.10.53.29 1 FULL/OTHER 00:00:04 10.10.53.29 vlan1353 00:04:38 > > > *Facing the issue:* > > Ubuntu host A is shutdown, keepalived converges to host B and OSPF > advertises the network, but service IP is unreachable. > > FW receives the correct update and we see the new nexthop correct in > "ospfctl show rib", > > > root@fw1:~# ospfctl show rib |grep 10.250.250.153 > 10.250.250.153/32 10.10.53.29 Intra-Area Network 110 > 00:03:10 > root@fw1:~# > > > however FIB still points to old nexthop, the 10.10.53.28. The new > nexthop should end in .29. > > > root@fw1:~# route -n get 10.250.250.153 > route to: 10.250.250.153 > destination: 10.250.250.153 > mask: 255.255.255.255 > gateway: 10.10.53.28 > interface: vlan1353 > if address: 10.10.53.26 > priority: 32 (ospf) > flags: > use mtu expire > 8298 0 0 > root@fw1:~# > > in logs we see this message: > > Oct 10 07:41:53 fw1 ospfd[44713]: send_rtmsg: action 1, prefix > 10.250.250.153/32: File exists > Oct 10 07:42:03 fw1 ospfd[44713]: send_rtmsg: action 1, prefix > 10.250.250.153/32: File exists > > > This prefix is the service IP. > > > *The FIX (manual):* > > > To fix this we need to delete the route manually and since after > deleting it doesn't get the new route automatically installed in FIB, we > then reload the FIB. > > Sequence of commands: > > root@fw1:~# route -n show | grep 10.250.250 > 10.250.250.53/32 10.10.11.155 UG 0 510172 - 48 > vlan1150 > 10.250.250.153/32 10.10.53.28 UGP 1 18861 - 32 > vlan1353 > 10.250.250.153/32 10.10.11.155 UG 0 0 - 48 > vlan1150 > root@fw1:~# route del 10.250.250.153/32 10.10.53.28 > del host 10.250.250.153/32: gateway 10.10.53.28 > root@fw1:~# route -n show | grep 10.250.250 > 10.250.250.53/32 10.10.11.155 UG 0 510185 - 48 > vlan1150 > 10.250.250.153/32 10.10.11.155 UG 0 1550 - 48 > vlan1150 > root@fw1:~# route -n show | grep 10.250.250 > 10.250.250.53/32 10.10.11.155 UG 0 510187 - 48 > vlan1150 > 10.250.250.153/32 10.10.11.155 UG 0 3806 - 48 > vlan1150 > root@fw1:~# route -n show | grep 10.250.250 > 10.250.250.53/32 10.10.11.155 UG 0 510187 - 48 > vlan1150 > 10.250.250.153/32 10.10.11.155 UG 0 4711 - 48 > vlan1150 > root@fw1:~# > root@fw1:~# route -n show | grep 10.250.250 > 10.250.250.53/32 10.10.11.155 UG 0 510188 - 48 > vlan1150 > 10.250.250.153/32 10.10.11.155 UG 0 7373 - 48 > vlan1150 > root@fw1:~# > root@fw1:~# > root@fw1:~# route -n show | grep 10.250.250 > 10.250.250.53/32 10.10.11.155 UG 0 510188 - 48 > vlan1150 > 10.250.250.153/32 10.10.11.155 UG 0 8505 - 48 > vlan1150 > root@fw1:~# > > > root@fw1:~# ospfctl fib reload > reload request sent. > root@fw1:~# > > > root@fw1:~# route -n show | grep 10.250.250 > 10.250.250.53/32 10.10.11.155 UG 0 20 - 48 > vlan1150 > 10.250.250.153/32 10.10.53.29 UG 0 106 - 32 > vlan1353 > 10.250.250.153/32 10.10.11.155 UG 0 0 - 48 > vlan1150 > root@fw1:~# > > > At this point service is restored, and the problem is not reproduce-able > anymore. > > The difference I see is that the new route doesn't have the Multipath > flag anymore. > > > *Details about OpenBSD:* > > *dmesg.boot:* > > OpenBSD 6.5 (GENERIC.MP) #5: Thu Aug 29 20:38:30 CEST 2019 [..] > > *OSPF configuration* > > *FW1* > > router-id 172.16.50.2 > redistribute static > > auth-type crypt > auth-md 1 "
Re: Strong Host Model in OpenBSD network stack
On Thu, Oct 17, 2019 at 10:33:41PM -0600, Theo de Raadt wrote: > > Setting net.inet.ip.check_interface=1 on FreeBSD stopped any ICMP Echo > > replies immediately. > > > > On NetBSD I set net.inet.ip.checkinterface=1 and it showed the same > > behaviour like FreeBSD. No replies anymore, whenever the "wrong" > > interface was contacted. > > How many users set those variables? > > A global seems this is a misguided place to establish such a policy. > > If it was good and neccessary for everyone on all interfaces and had no > downsides, they would have turned it on. But they didn't. > > A similar feature "urpf-failed" which is more nuanced is available in > pf.conf, and you can properly use it on a per-interface basis, also > selecting to do so based un other per-rule options, rather than having > a 'global rule'. > > Something blocked FreeBSD or NetBSD from turning this into the default. > What was that reason -- was it too damaging? > > (I'm going to assume the people with so-called 'strong' views didn't win > the battle, and the so-called 'weak' view pervailed, probably because > the 'strong' option created breakage and prevents the dominant > operational model of Getting-Shit-Done. That's why I ask how many > people in real life subscribe the 'strong' view by turning on this > option in FreeBSD/NetBSD. 3 people or is it 2? In my experience, > everyone is so busy getting on about their lives they don't flip any > knobs which don't provide an immediately confirmable and neccessary > value). > > from source port source os source to dest port dest > This rule applies only to packets with the specified source and > destination addresses and ports. > > Addresses can be specified in CIDR notation (matching netblocks), > as symbolic host names, interface names or interface group names, > or as any of the following keywords: > > any Any address. > no-route Any address which is not currently routable. > route label Any address matching the given route(8) label. > self Expands to all addresses assigned to all interfaces. >Any address matching the given table. > urpf-failed Any source address that fails a unicast reverse path > forwarding (URPF) check, i.e. packets coming in on > an interface other than that which holds the route > back to the packet's source address. > > Convince us we should change to the strong model, and I'll embrace it. > > You won't convince us to make a global which people don't understand... > This "strong" model is a bad fit for routers. When this model is needed we have pf (antispoof or urpf-failed). Alternatively rdomains can be used (put a network interface with management services on it in a separate rdomain). Remi
Re: Problems with route installation to fib from OSPF
Hi Joao,
I'll try to reproduce. It might take some time.
Remi
On Thu, Oct 24, 2019 at 02:09:09PM +0200, Joao Alves wrote:
> Hi Remi,
>
> I've installed a lab with OpenBSD6.6 VM's to see if would happen in the
> newer version.
>
> I was able to reproduce it again, but in slightly different manner.
>
> First of all, you need to have BGP running in FW's also, and have the
> same route received through BGP, otherwise the issue is not
> reproducible, because the MPATH flag will behave well with OSPF only.
> Without the MPATH issue you can't reproduce the rest.
>
> So LAB setup(all openbsd6.6 VM's):
>
> 2x fw/router
> 2x host
> 1x bgp router
>
> fw1:192.168.98.200
>
> fw2:192.168.98.201
>
> host1:192.168.98.202
>
> host2:192.168.98.203
>
> bgp:192.168.98.204
>
>
> In the hosts I run carp with VIP 10.10.10.10/32, carp configured with
> preempt in kernel.
>
> ospf config for host1/2 is (only router id change):
>
> host1# more
> /etc/ospfd.conf
>
>
>
>
> # $OpenBSD: ospfd.conf,v 1.2 2018/08/07 07:06:20 claudio Exp $
>
> # macros
> id="192.168.98.202"
>
> # global configuration
> router-id $id
> # fib-update no
> # stub router no
> # spf-delay 1
> # spf-holdtime 5
>
> # auth-key secret
> # auth-type simple
> # hello-interval 10
> metric 10
> # retransmit-interval 5
> # router-dead-time 40
> router-priority 0
> # transmit-delay 1
>
> # rtlabel "DMZ" external-tag 1
>
> # areas
> area 0.0.0.0 {
> interface em0 {
> auth-type simple
> auth-key secret
> }
>
> interface carp1 {
> passive
> }
> }
> host1#
>
> For FW1/2 is(router ID and router priority change, in FW2 priority is
> 10, so BDR):
>
> fw1# more
> /etc/ospfd.conf
>
>
>
>
> # $OpenBSD: ospfd.conf,v 1.2 2018/08/07 07:06:20 claudio Exp $
>
> # macros
> id="192.168.98.200"
>
> # global configuration
> router-id $id
> # fib-update no
> # stub router no
> # spf-delay 1
> # spf-holdtime 5
>
> # auth-key secret
> # auth-type simple
> # hello-interval 10
> metric 10
> # retransmit-interval 5
> # router-dead-time 40
> router-priority 100
> # transmit-delay 1
>
> # rtlabel "DMZ" external-tag 1
>
> # areas
> area 0.0.0.0 {
> interface em0 {
> auth-type simple
> auth-key secret
> }
> }
> fw1#
>
> For BGPD configs:
>
> FW1/2:
>
>
> fw1# more
> /etc/bgpd.conf
>
>
>
>
> # $OpenBSD: bgpd.conf,v 1.15 2018/11/17 17:22:38 deraadt Exp $
> # example bgpd configuration file, see bgpd.conf(5)
>
> # define our own ASN as a macro
> ASN="65123"
>
> # global configuration
> AS $ASN
> router-id 192.168.98.200
>
> # list of networks that may be originated by our ASN
> prefix-set mynetworks { \
> 192.0.6.0/24 \
> 2001:db8:abef::/48 \
> }
>
> # define bogon prefixes which should not be part of the DFZ
> prefix-set bogons {
> 0.0.0.0/8 or-longer # 'this' network [RFC1122]
> 10.0.0.0/8 or-longer # private space [RFC1918]
> 100.64.0.0/10 or-longer # CGN Shared [RFC6598]
> 127.0.0.0/8 or-longer # localhost [RFC1122]
> 169.254.0.0/16 or-longer # link local [RFC3927]
> 172.16.0.0/12 or-longer # private space [RFC1918]
> 192.0.2.0/24 or-longer # TEST-NET-1 [RFC5737]
> 192.88.99.0/24 or-longer # 6to4 anycast relay [RFC7526]
> 192.168.0.0/16 or-longer # private space [RFC1918]
> 198.18.0.0/15 or-longer # benchmarking [RFC2544]
> 198.51.100.0/24 or-longer # TEST-NET-2 [RFC5737]
> 203.0.113.0/24 or-longer # TEST-NET-3 [RFC5737]
> 224.0.0.0/4 or-longer # multicast
> 240.0.0.0/4 or-longer # reserved for future use
> ::/8 or-longer # RFC 4291 IPv4-compatible,
> loopback, et al
> 0100::/64 or-longer # Discard-Only [RFC]
> 2001:2::/48 or-longer # BMWG [RFC5180]
> 2001:10::/28 or-longer # ORCHID [RFC4843]
> 2001:db8::/32 or-longer # docu range [RFC3849]
> 2002::/16 or-longer # 6to4 anycast r
Re: Problems with route installation to fib from OSPF
On Thu, Oct 24, 2019 at 02:09:09PM +0200, Joao Alves wrote:
> Hi Remi,
>
> I've installed a lab with OpenBSD6.6 VM's to see if would happen in the
> newer version.
>
> I was able to reproduce it again, but in slightly different manner.
>
> First of all, you need to have BGP running in FW's also, and have the
> same route received through BGP, otherwise the issue is not
> reproducible, because the MPATH flag will behave well with OSPF only.
> Without the MPATH issue you can't reproduce the rest.
Can you also reproduce without BGP but with a static route added like this:
route add -net 10.10.10.10 -netmask 255.255.255.255 192.168.98.204 -priority 40
>
> So LAB setup(all openbsd6.6 VM's):
>
> 2x fw/router
Can you also reproduce with only 1 fw or are both fw nodes needed to reproduce?
> 2x host
> 1x bgp router
>
> fw1:192.168.98.200
>
> fw2:192.168.98.201
>
> host1:192.168.98.202
>
> host2:192.168.98.203
>
> bgp:192.168.98.204
>
>
> In the hosts I run carp with VIP 10.10.10.10/32, carp configured with
> preempt in kernel.
>
> ospf config for host1/2 is (only router id change):
>
> host1# more
> /etc/ospfd.conf
>
>
>
>
> # $OpenBSD: ospfd.conf,v 1.2 2018/08/07 07:06:20 claudio Exp $
>
> # macros
> id="192.168.98.202"
>
> # global configuration
> router-id $id
> # fib-update no
> # stub router no
> # spf-delay 1
> # spf-holdtime 5
>
> # auth-key secret
> # auth-type simple
> # hello-interval 10
> metric 10
> # retransmit-interval 5
> # router-dead-time 40
> router-priority 0
> # transmit-delay 1
>
> # rtlabel "DMZ" external-tag 1
>
> # areas
> area 0.0.0.0 {
> interface em0 {
> auth-type simple
> auth-key secret
> }
>
> interface carp1 {
> passive
> }
> }
> host1#
Please show the configs of em0 and carp1.
>
> For FW1/2 is(router ID and router priority change, in FW2 priority is
> 10, so BDR):
>
> fw1# more
> /etc/ospfd.conf
>
>
>
>
> # $OpenBSD: ospfd.conf,v 1.2 2018/08/07 07:06:20 claudio Exp $
>
> # macros
> id="192.168.98.200"
>
> # global configuration
> router-id $id
> # fib-update no
> # stub router no
> # spf-delay 1
> # spf-holdtime 5
>
> # auth-key secret
> # auth-type simple
> # hello-interval 10
> metric 10
> # retransmit-interval 5
> # router-dead-time 40
> router-priority 100
> # transmit-delay 1
>
> # rtlabel "DMZ" external-tag 1
>
> # areas
> area 0.0.0.0 {
> interface em0 {
> auth-type simple
> auth-key secret
> }
> }
> fw1#
>
> For BGPD configs:
>
> FW1/2:
>
>
> fw1# more
> /etc/bgpd.conf
>
>
>
>
> # $OpenBSD: bgpd.conf,v 1.15 2018/11/17 17:22:38 deraadt Exp $
> # example bgpd configuration file, see bgpd.conf(5)
>
> # define our own ASN as a macro
> ASN="65123"
>
> # global configuration
> AS $ASN
> router-id 192.168.98.200
>
> # list of networks that may be originated by our ASN
> prefix-set mynetworks { \
> 192.0.6.0/24 \
> 2001:db8:abef::/48 \
> }
>
> # define bogon prefixes which should not be part of the DFZ
> prefix-set bogons {
> 0.0.0.0/8 or-longer # 'this' network [RFC1122]
> 10.0.0.0/8 or-longer # private space [RFC1918]
> 100.64.0.0/10 or-longer # CGN Shared [RFC6598]
> 127.0.0.0/8 or-longer # localhost [RFC1122]
> 169.254.0.0/16 or-longer # link local [RFC3927]
> 172.16.0.0/12 or-longer # private space [RFC1918]
> 192.0.2.0/24 or-longer # TEST-NET-1 [RFC5737]
> 192.88.99.0/24 or-longer # 6to4 anycast relay [RFC7526]
> 192.168.0.0/16 or-longer # private space [RFC1918]
> 198.18.0.0/15 or-longer # benchmarking [RFC2544]
> 198.51.100.0/24 or-longer # TEST-NET-2 [RFC5737]
> 203.0.113.0/24 or-longer # TEST-NET-3 [RFC5737]
> 224.0.0.0/4 or-longer # multicast
> 240.0.0.0/4 or-longer # reserved for future use
> ::/8 or-longer # RFC 4291 IPv4-compatible,
> loopback, et al
> 0100::/64 or-longer # Discard-Only [RFC]
> 2001:2::/48 or
Re: Problems with route installation to fib from OSPF
ges: 0.00, 0.00, 0.00 > 10.10.10.10/32 192.168.98.203 UGP 0 0 - 32 > em0 > 10.10.10.10/32 192.168.98.204 UGS 0 0 - 40 > em0 > fw1# > fw1# > > But at this stage we are still with the correct nexthop in the FIB > > > > We now bring up the Host1 em0 in VSphere: > > fw1# uptime && ospfctl show rib > 12:22PM up 15 days, 1:52, 1 user, load averages: 0.00, 0.00, 0.00 > Destination Nexthop Path Type Type Cost > Uptime > 10.10.10.10/32 192.168.98.202 Intra-Area Network 20 > 00:00:03 > 192.168.98.0/24 192.168.98.200 C Intra-Area Network 10 > 00:12:28 > > fw1# uptime && route -n show | grep 10.10.10 > 12:22PM up 15 days, 1:52, 1 user, load averages: 0.00, 0.00, 0.00 > 10.10.10.10/32 192.168.98.203 UGP 0 6 - 32 > em0 > 10.10.10.10/32 192.168.98.204 UGS 0 0 - 40 > em0 > fw1# > fw1# > > You receive the route from Host1, but is not installed on FIB. > > fw1# uptime && ospfctl show rib > 1:39PM up 15 days, 3:09, 1 user, load averages: 0.00, 0.00, 0.00 > Destination Nexthop Path Type Type Cost > Uptime > 10.10.10.10/32 192.168.98.202 Intra-Area Network 20 > 01:17:11 > 192.168.98.0/24 192.168.98.200 C Intra-Area Network 10 > 01:29:36 > > fw1# uptime && route -n show | grep 10.10.10 > 1:39PM up 15 days, 3:09, 1 user, load averages: 0.00, 0.00, 0.00 > 10.10.10.10/32 192.168.98.203 UGP 0 7 - 32 > em0 > 10.10.10.10/32 192.168.98.204 UGS 0 0 - 40 > em0 > fw1# > > > This is still true after more then 1h. > > > > We now reload the FIB: > > > fw1# ospfctl fib reload > reload request sent. > fw1# > fw1# uptime && ospfctl show rib > 1:40PM up 15 days, 3:10, 1 user, load averages: 0.00, 0.00, 0.00 > Destination Nexthop Path Type Type Cost > Uptime > 192.168.98.0/24 0.0.0.0 C Intra-Area Network 10 > 00:00:02 > > fw1# uptime && route -n show | grep 10.10.10 > 1:40PM up 15 days, 3:10, 1 user, load averages: 0.00, 0.00, 0.00 > 10.10.10.10/32 192.168.98.204 UGS 0 0 - 40 > em0 > fw1# > fw1# > > fw1# uptime && ospfctl show rib > 1:41PM up 15 days, 3:11, 1 user, load averages: 0.00, 0.00, 0.00 > Destination Nexthop Path Type Type Cost > Uptime > 10.10.10.10/32 192.168.98.202 Intra-Area Network 20 > 00:00:19 > 192.168.98.0/24 192.168.98.200 C Intra-Area Network 10 > 00:00:24 > > fw1# uptime && route -n show | grep 10.10.10 > 1:41PM up 15 days, 3:11, 1 user, load averages: 0.00, 0.00, 0.00 > 10.10.10.10/32 192.168.98.202 UG 0 0 - 32 > em0 > 10.10.10.10/32 192.168.98.204 UGS 0 0 - 40 > em0 > fw1# > > > And we get to the good state condition. > > > Hope this helps. > > > Best regards, > > João > > > > > On 05.11.19 23:19, Remi Locherer wrote: > > On Thu, Oct 24, 2019 at 02:09:09PM +0200, Joao Alves wrote: > >> Hi Remi, > >> > >> I've installed a lab with OpenBSD6.6 VM's to see if would happen in the > >> newer version. > >> > >> I was able to reproduce it again, but in slightly different manner. > >> > >> First of all, you need to have BGP running in FW's also, and have the > >> same route received through BGP, otherwise the issue is not > >> reproducible, because the MPATH flag will behave well with OSPF only. > >> Without the MPATH issue you can't reproduce the rest. > > Can you also reproduce without BGP but with a static route added like this: > > route add -net 10.10.10.10 -netmask 255.255.255.255 192.168.98.204 > > -priority 40 > > > >> So LAB setup(all openbsd6.6 VM's): > >> > >> 2x fw/router > > Can you also reproduce with only 1 fw or are both fw nodes needed to > > reproduce? > > > >> 2x host > >> 1x bgp router > >> > >> fw1:192.168.98.200 > >> > >> fw2:192.168.98.201 > >> > >> host1:192.168.98.202 > >> > >> host2:192.168.98.203 > >> > >> bgp:192.168.98.204 > >> > >> > >> In the ho
Re: Low throughput with 1 GigE interface
On January 30, 2020 4:17:16 PM UTC, Ian Darwin wrote: >Peter wrote: > >> chi# iperf -c beta.internal.centroid.eu >> >> Client connecting to beta.internal.centroid.eu, TCP port 5001 >> TCP window size: 17.0 KByte (default) >> >> [ 3] local 192.168.177.40 port 13242 connected with 192.168.177.2 >port 5001 >> [ ID] Interval Transfer Bandwidth >> [ 3] 0.0-10.0 sec 536 MBytes 449 Mbits/sec >> >> ... on an APU1C4, could it be you have a slow switch or router? Any >other >> hardware that could slow yours down? >> >> I'm happy with this result, the APU1 is not really a powerhorse. > >That is pretty normal. From an older Intel-cpu laptop with a bge >interface, >to my APU2, both on a TP-Link gig switch, I get > >$ iperf -c gw-int > >Client connecting to gw-int, TCP port 5001 >TCP window size: 32.5 KByte (default) > >[ 3] local 192.168.42.46 port 21653 connected with 192.168.42.254 port >5001 >[ ID] Interval Transfer Bandwidth >[ 3] 0.0-10.0 sec 502 MBytes 421 Mbits/sec >$ > >Again, that's with no tuning. Did you try a different cable? iperf vs. iperf3?
problem mounting ext4 filesystem
Hi, I tried to mount an ext4 filesystem on OpenBSD which was created on CentOS7. I get this: remi@mistral:~% doas mount -t ext2fs /dev/sd0m /mnt mount_ext2fs: /dev/sd0m on /mnt: specified device does not match mounted device remi@mistral:~% dmesg | grep incomp ext2fs: unsupported incompat features 0x2c2 remi@mistral:~% Which feature is 0x2c2? Maybe I can disable this or re-create the filesystem on Linux without this feature? Thanks, Remi tune2fs (on OpenBSD): tune2fs 1.42.12 (29-Aug-2014) Filesystem volume name: Last mounted on: / Filesystem UUID: c2b2aefb-2cc0-4cec-8346-26e35c26a7b9 Filesystem magic number: 0xEF53 Filesystem revision #:1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options:user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 3768320 Block count: 15062272 Reserved block count: 753113 Free blocks: 12427964 Free inodes: 3611179 First block: 0 Block size: 4096 Fragment size:4096 Group descriptor size:64 Reserved GDT blocks: 1024 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 Flex block group size:16 Filesystem created: Sat Jan 2 10:15:09 2016 Last mount time: Tue Jan 5 07:12:45 2016 Last write time: Tue Jan 5 08:12:44 2016 Mount count: 12 Maximum mount count: -1 Last checked: Sat Jan 2 10:15:09 2016 Check interval: 0 () Lifetime writes: 12 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group wheel) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode:8 Default directory hash: half_md4 Directory Hash Seed: 2ae71fa4-8b6c-4770-bdde-210a6a596f9b Journal backup: inode blocks disklabel: # /dev/rsd0c: type: SCSI disk: SCSI disk label: LITEON L8H-256V2 duid: 5871eb4bf4f4b2bc flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 31130 total sectors: 500118192 boundstart: 84934722 boundend: 378536002 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a:293601280 84934722RAID c:5001181920 unused i: 1048576 64 MSDOS j: 83886080 1048641NTFS k:32768378537984 unknown l: 1048576378570752 ext2fs m:120498176379619328 ext2fs dmesg: OpenBSD 5.9-beta (GENERIC.MP) #23: Mon Dec 28 12:03:11 CET 2015 r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8473636864 (8081MB) avail mem = 8212668416 (7832MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed7d0 (84 entries) bios0: vendor Dell Inc. version "A07" date 11/11/2015 bios0: Dell Inc. XPS 13 9343 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! SSDT SSDT SSDT SSDT PCCT SSDT SSDT SSDT SLIC MSDM DMAR CSRT BGRT acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.65 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.24 MHz 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NX
Dell XPS 9343 and OpenBSD
Hi, I read tedu@'s post about OpenBSD on laptops and thought a little report about running -current on Dell XPS 13 might be interest. http://www.tedunangst.com/flak/post/openbsd-laptops I'm running -current on this and use it daily. o Graphics: Works ok with the modsetting driver (now default). o Battery: I don't have exact measures. It runs about a day with one charge. I mainly use a bunch of xterms and browsers. o WLAN The notebook shipped with a unsupported broadcom wlan adpater. I replaced it with an iwm0 card. The notebook can be opened with a torx screwdriver. o LAN There is no built in Ethernet device. I use an USB3 to Gig. Ethernet adapter from Edimax (axen). o Audio Only works with a patched kernel: http://marc.info/?l=openbsd-misc&m=144270531711263&w=2 o Touchpad Works more or less. Sometimes a click is not recognized or the pointer makes unexpected jumps and dmesg fills with: pms0: not in sync yet, discard input (state 0) It got a little bit better with BIOS updates. On CentOS 7 it's the same behaviour. o Camera video(4) says: video: could not find a usable encoding o Suspend, resume and hibernate Works reliable. Only when suspended by closing the lid it behaves strange: after opening the lid it resumes and then supends again. Then pressing the power button finaly resumes the device. o EFI Booting with EFI works. Sometimes after efiboot loaded the kernel it reboots. Then I either have to shutdown the notebook for some hours or boot into the BIOS or another OS. Then it boots again. I didn't figure out how to willingly reproduce this. Remi OpenBSD 5.9-beta (GENERIC.MP) #3: Wed Jan 13 21:41:17 CET 2016 r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8473636864 (8081MB) avail mem = 8212652032 (7832MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed7d0 (84 entries) bios0: vendor Dell Inc. version "A07" date 11/11/2015 bios0: Dell Inc. XPS 13 9343 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! SSDT SSDT SSDT SSDT PCCT SSDT SSDT SSDT SLIC MSDM DMAR CSRT BGRT acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.64 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.24 MHz 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.24 MHz 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.24 MHz 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpimadt0: bogus nmi for apid 0 acpimadt0: bogus nmi for apid 2 acpimadt0: bogus nmi for apid
Re: can't run multiple instances of httpd, flags not visible in processes
On Thu, Jan 28, 2016 at 06:52:18PM +0100, Ingo Schwarze wrote:
> Hi,
>
> Antoine Jacoutot wrote on Thu, Jan 28, 2016 at 10:41:52AM +0100:
>
> > As mentioned in another thread already:
> > # ln -s /etc/rc.d/mydaemon /etc/rc.d/mydaemon2
> > Then use mydaemon2_flags ... in rc.conf.local.
>
> This seems to be a recurring user question.
>
> Do you consider this addition useful?
>
> I think rcctl(8) is the best place to document it because that's
> the highest level user interface and "How do i run multiple copies
> of a daemon?" is a very high-level user question, while rc.d(8)
> and rc.conf(8) document lower, more technical levels.
>
> I'd love to make the example more specific and document an actual
> use case that frequently occurs in practice, but even though many
> have said that such cases do occur, i can't think of any. For
> example, for httpd(8), it looks like all use cases can be solved
> by running one copy and using "server ... { ... }" well in
> httpd.conf(5). So, if anybody can describe a specific use case to
> make the example better, that's quite welcome.
I'm running several instances of dhcrelay because I can only specify
one "-i if" option. The example could look like this:
# ln -s dhcrelay dhcrelay_vlan2
# ln -s dhcrelay dhcrelay_vlan3
# rcctl set dhcrelay_vlan2 flags -i vlan2 10.0.0.2
# rcctl set dhcrelay_vlan3 flags -i vlan3 10.0.0.2
>
> I certainly don't want an example in the style of
>
> # ln -s httpd httpd2
>
> That's a terrible name. The next admin coming along will have no
> clue what this second httpd is needed for.
>
> Yours,
> Ingo
>
>
> Index: rcctl.8
> ===
> RCS file: /cvs/src/usr.sbin/rcctl/rcctl.8,v
> retrieving revision 1.26
> diff -u -p -r1.26 rcctl.8
> --- rcctl.8 24 Oct 2015 17:08:36 - 1.26
> +++ rcctl.8 28 Jan 2016 17:39:13 -
> @@ -193,6 +193,18 @@ ntpd_user=root
> # echo $?
> 0
> .Ed
> +.Pp
> +The recommended way to run a second copy of a given daemon for a
> +different purpose is to create a symbolic link to its
> +.Xr rc.d 8
> +control script:
> +.Bd -literal -offset indent
> +# cd /etc/rc.d/
> +# ln -s httpd httpd_purpose
> +# rcctl set httpd_purpose flags -some options ...
> +# rcctl set httpd_purpose status on
> +# rcctl start httpd_purpose
> +.Ed
> .Sh SEE ALSO
> .Xr rc.conf.local 8 ,
> .Xr rc.d 8
Re: OSPF over gif on top of IPsec transport -current
On Sun, Mar 04, 2018 at 01:08:21PM +0200, Atanas Vladimirov wrote: > Hi, > > I can't make OSPF to work on gif over IPsec. > With tcpdump on gif I see the OSPFv2-hello only from localhost: > > # R1 > [ns]~$ tcpdump -nei gif0 > tcpdump: listening on gif0, link-type LOOP > 23:19:29.181685 10.255.255.2 > 224.0.0.5: OSPFv2-hello 44: rtrid > 192.168.1.1 area 0.0.0.1 [tos 0xc0] [ttl 1] > 23:19:39.192025 10.255.255.2 > 224.0.0.5: OSPFv2-hello 44: rtrid > 192.168.1.1 area 0.0.0.1 [tos 0xc0] [ttl 1] > 23:19:49.202372 10.255.255.2 > 224.0.0.5: OSPFv2-hello 44: rtrid > 192.168.1.1 area 0.0.0.1 [tos 0xc0] [ttl 1] > 23:19:59.212730 10.255.255.2 > 224.0.0.5: OSPFv2-hello 44: rtrid > 192.168.1.1 area 0.0.0.1 [tos 0xc0] [ttl 1] > 23:20:09.223064 10.255.255.2 > 224.0.0.5: OSPFv2-hello 44: rtrid > 192.168.1.1 area 0.0.0.1 [tos 0xc0] [ttl 1] > 23:20:19.233393 10.255.255.2 > 224.0.0.5: OSPFv2-hello 44: rtrid > 192.168.1.1 area 0.0.0.1 [tos 0xc0] [ttl 1] > > # R2 > [hodor]~$ tcpdump -nei gif0 > tcpdump: listening on gif0, link-type LOOP > 12:51:59.316704 10.255.255.1 > 224.0.0.5: OSPFv2-hello 44: rtrid 172.16.1.1 > backbone [tos 0xc0] [ttl 1] > 12:52:09.327002 10.255.255.1 > 224.0.0.5: OSPFv2-hello 44: rtrid 172.16.1.1 > backbone [tos 0xc0] [ttl 1] > 12:52:19.337314 10.255.255.1 > 224.0.0.5: OSPFv2-hello 44: rtrid 172.16.1.1 > backbone [tos 0xc0] [ttl 1] > > While on enc0 both hello's appears (not sure if `bad ip cksum` is the reason > for my issues): > > # R1 > [ns]~$ tcpdump -nvi enc0 > tcpdump: listening on enc0, link-type ENC > 12:24:37.625873 (authentic,confidential): SPI 0x11af4dae: 93.123.39.67 > > 95.87.227.232: 10.255.255.1 > 224.0.0.5: OSPFv2-hello 44: rtrid 172.16.1.1 > backbone E mask 255.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] > (id 25841, len 64) (ttl 60, id 37752, len 84) > 12:24:41.882173 (authentic,confidential): SPI 0x1a3fbc6d: 95.87.227.232 > > 93.123.39.67: 10.255.255.2 > 224.0.0.5: OSPFv2-hello 44: rtrid 192.168.1.1 > backbone E mask 255.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] > (id 27818, len 64) (ttl 64, id 60563, len 84, bad ip cksum 32d7! -> c614) > 12:24:47.636188 (authentic,confidential): SPI 0x11af4dae: 93.123.39.67 > > 95.87.227.232: 10.255.255.1 > 224.0.0.5: OSPFv2-hello 44: rtrid 172.16.1.1 > backbone E mask 255.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] > (id 36067, len 64) (ttl 60, id 65348, len 84) > 12:24:51.892467 (authentic,confidential): SPI 0x1a3fbc6d: 95.87.227.232 > > 93.123.39.67: 10.255.255.2 > 224.0.0.5: OSPFv2-hello 44: rtrid 192.168.1.1 > backbone E mask 255.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] > (id 5127, len 64) (ttl 64, id 12476, len 84, bad ip cksum 201! -> 81ec) > 12:24:57.646535 (authentic,confidential): SPI 0x11af4dae: 93.123.39.67 > > 95.87.227.232: 10.255.255.1 > 224.0.0.5: OSPFv2-hello 44: rtrid 172.16.1.1 > backbone E mask 255.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] > (id 39220, len 64) (ttl 60, id 1938, len 84) > > # R2 > [hodor]~$ tcpdump -nvi enc0 | grep OSPF > tcpdump: listening on enc0, link-type ENC > 12:28:57.894007 (authentic,confidential): SPI 0x11af4dae: 93.123.39.67 > > 95.87.227.232: 10.255.255.1 > 224.0.0.5: OSPFv2-hello 44: rtrid 172.16.1.1 > backbone E mask 255.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] > (id 3667, len 64) (ttl 64, id 14037, len 84, bad ip cksum 2b6d! -> 7bd3) > 12:29:02.151763 (authentic,confidential): SPI 0x1a3fbc6d: 95.87.227.232 > > 93.123.39.67: 10.255.255.2 > 224.0.0.5: OSPFv2-hello 44: rtrid 192.168.1.1 > backbone E mask 25 > 5.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] (id 16974, len > 64) (ttl 60, id 21648, len 84) > 12:29:07.904315 (authentic,confidential): SPI 0x11af4dae: 93.123.39.67 > > 95.87.227.232: 10.255.255.1 > 224.0.0.5: OSPFv2-hello 44: rtrid 172.16.1.1 > backbone E mask 255 > .255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] (id 45590, len 64) > (ttl 64, id 35262, len 84, bad ip cksum 2743! -> 28ea) > 12:29:12.162049 (authentic,confidential): SPI 0x1a3fbc6d: 95.87.227.232 > > 93.123.39.67: 10.255.255.2 > 224.0.0.5: OSPFv2-hello 44: rtrid 192.168.1.1 > backbone E mask 25 > 5.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] (id 19966, len > 64) (ttl 60, id 3134, len 84) > 12:29:17.914621 (authentic,confidential): SPI 0x11af4dae: 93.123.39.67 > > 95.87.227.232: 10.255.255.1 > 224.0.0.5: OSPFv2-hello 44: rtrid 172.16.1.1 > backbone E mask 255 > .255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] (id 36161, len 64) > (ttl 64, id 53105, len 84, bad ip cksum fcb8! -> e336) > 12:29:22.172468 (authentic,confidential): SPI 0x1a3fbc6d: 95.87.227.232 > > 93.123.39.67: 10.255.255.2 > 224.0.0.5: OSPFv2-hello 44: rtrid 192.168.1.1 > backbone E mask 25 > 5.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] (id 36221, len > 64) (ttl 60, id 29514, len 84) > > If I set a static routes the regular traffic flows as it should. > > The configs are the same on both routers: >
Re: OSPF over gif on top of IPsec transport -current
On Fri, Mar 09, 2018 at 06:13:10PM +0100, Remi Locherer wrote: > On Sun, Mar 04, 2018 at 01:08:21PM +0200, Atanas Vladimirov wrote: > > Hi, > > > > I can't make OSPF to work on gif over IPsec. > > With tcpdump on gif I see the OSPFv2-hello only from localhost: > > > > # R1 > > [ns]~$ tcpdump -nei gif0 > > tcpdump: listening on gif0, link-type LOOP > > 23:19:29.181685 10.255.255.2 > 224.0.0.5: OSPFv2-hello 44: rtrid > > 192.168.1.1 area 0.0.0.1 [tos 0xc0] [ttl 1] > > 23:19:39.192025 10.255.255.2 > 224.0.0.5: OSPFv2-hello 44: rtrid > > 192.168.1.1 area 0.0.0.1 [tos 0xc0] [ttl 1] > > 23:19:49.202372 10.255.255.2 > 224.0.0.5: OSPFv2-hello 44: rtrid > > 192.168.1.1 area 0.0.0.1 [tos 0xc0] [ttl 1] > > 23:19:59.212730 10.255.255.2 > 224.0.0.5: OSPFv2-hello 44: rtrid > > 192.168.1.1 area 0.0.0.1 [tos 0xc0] [ttl 1] > > 23:20:09.223064 10.255.255.2 > 224.0.0.5: OSPFv2-hello 44: rtrid > > 192.168.1.1 area 0.0.0.1 [tos 0xc0] [ttl 1] > > 23:20:19.233393 10.255.255.2 > 224.0.0.5: OSPFv2-hello 44: rtrid > > 192.168.1.1 area 0.0.0.1 [tos 0xc0] [ttl 1] > > > > # R2 > > [hodor]~$ tcpdump -nei gif0 > > tcpdump: listening on gif0, link-type LOOP > > 12:51:59.316704 10.255.255.1 > 224.0.0.5: OSPFv2-hello 44: rtrid 172.16.1.1 > > backbone [tos 0xc0] [ttl 1] > > 12:52:09.327002 10.255.255.1 > 224.0.0.5: OSPFv2-hello 44: rtrid 172.16.1.1 > > backbone [tos 0xc0] [ttl 1] > > 12:52:19.337314 10.255.255.1 > 224.0.0.5: OSPFv2-hello 44: rtrid 172.16.1.1 > > backbone [tos 0xc0] [ttl 1] > > > > While on enc0 both hello's appears (not sure if `bad ip cksum` is the reason > > for my issues): > > > > # R1 > > [ns]~$ tcpdump -nvi enc0 > > tcpdump: listening on enc0, link-type ENC > > 12:24:37.625873 (authentic,confidential): SPI 0x11af4dae: 93.123.39.67 > > > 95.87.227.232: 10.255.255.1 > 224.0.0.5: OSPFv2-hello 44: rtrid 172.16.1.1 > > backbone E mask 255.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] > > (id 25841, len 64) (ttl 60, id 37752, len 84) > > 12:24:41.882173 (authentic,confidential): SPI 0x1a3fbc6d: 95.87.227.232 > > > 93.123.39.67: 10.255.255.2 > 224.0.0.5: OSPFv2-hello 44: rtrid 192.168.1.1 > > backbone E mask 255.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] > > (id 27818, len 64) (ttl 64, id 60563, len 84, bad ip cksum 32d7! -> c614) > > 12:24:47.636188 (authentic,confidential): SPI 0x11af4dae: 93.123.39.67 > > > 95.87.227.232: 10.255.255.1 > 224.0.0.5: OSPFv2-hello 44: rtrid 172.16.1.1 > > backbone E mask 255.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] > > (id 36067, len 64) (ttl 60, id 65348, len 84) > > 12:24:51.892467 (authentic,confidential): SPI 0x1a3fbc6d: 95.87.227.232 > > > 93.123.39.67: 10.255.255.2 > 224.0.0.5: OSPFv2-hello 44: rtrid 192.168.1.1 > > backbone E mask 255.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] > > (id 5127, len 64) (ttl 64, id 12476, len 84, bad ip cksum 201! -> 81ec) > > 12:24:57.646535 (authentic,confidential): SPI 0x11af4dae: 93.123.39.67 > > > 95.87.227.232: 10.255.255.1 > 224.0.0.5: OSPFv2-hello 44: rtrid 172.16.1.1 > > backbone E mask 255.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] > > (id 39220, len 64) (ttl 60, id 1938, len 84) > > > > # R2 > > [hodor]~$ tcpdump -nvi enc0 | grep OSPF > > tcpdump: listening on enc0, link-type ENC > > 12:28:57.894007 (authentic,confidential): SPI 0x11af4dae: 93.123.39.67 > > > 95.87.227.232: 10.255.255.1 > 224.0.0.5: OSPFv2-hello 44: rtrid 172.16.1.1 > > backbone E mask 255.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] > > (id 3667, len 64) (ttl 64, id 14037, len 84, bad ip cksum 2b6d! -> 7bd3) > > 12:29:02.151763 (authentic,confidential): SPI 0x1a3fbc6d: 95.87.227.232 > > > 93.123.39.67: 10.255.255.2 > 224.0.0.5: OSPFv2-hello 44: rtrid 192.168.1.1 > > backbone E mask 25 > > 5.255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] (id 16974, len > > 64) (ttl 60, id 21648, len 84) > > 12:29:07.904315 (authentic,confidential): SPI 0x11af4dae: 93.123.39.67 > > > 95.87.227.232: 10.255.255.1 > 224.0.0.5: OSPFv2-hello 44: rtrid 172.16.1.1 > > backbone E mask 255 > > .255.255.255 int 10 pri 1 dead 40 nbrs [tos 0xc0] [ttl 1] (id 45590, len 64) > > (ttl 64, id 35262, len 84, bad ip cksum 2743! -> 28ea) > > 12:29:12.162049 (authentic,confidential): SPI 0x1a3fbc6d: 95.87.227.232 > > > 93.123.39.67: 10.255.255.2 > 224.0.0.5: OSPFv2-hello 44: rtrid 192.168.1.1 > > backbone E mask 25 > > 5.255.
Re: OSPF over gif on top of IPsec transport -current
On 2018-03-13 07:28, David Gwynne wrote: On 11 Mar 2018, at 05:30, Atanas Vladimirov wrote: On 2018-03-10 00:01, Remi Locherer wrote: With below diff the setup works as expected: tcpdump shows OSPF hellos on gif0 and ospfd sees the neighbour. I don't think it's the correct fix though. Index: if_gif.c === RCS file: /cvs/src/sys/net/if_gif.c,v retrieving revision 1.112 diff -u -p -r1.112 if_gif.c --- if_gif.c28 Feb 2018 23:28:05 - 1.112 +++ if_gif.c9 Mar 2018 20:52:46 - @@ -745,8 +745,8 @@ gif_input(struct gif_tunnel *key, struct } /* XXX What if we run transport-mode IPsec to protect gif tunnel ? */ - if (m->m_flags & (M_AUTH | M_CONF)) - return (-1); + //if (m->m_flags & (M_AUTH | M_CONF)) + // return (-1); key->t_rtableid = m->m_pkthdr.ph_rtableid; Hi Remi, Thanks for confirming that there is an issue and I'm not doing something wrong on my side. I'll try the diff as soon as possible. it isnt clear to me how ipsec and gif(4) are supposed to interact. on the one hand you have the gif(4) manpage saying this: BUGS There are many tunnelling protocol specifications, defined differently from each other. gif may not interoperate with peers which are based on different specifications, and are picky about outer header fields. For example, you cannot usually use gif to talk with IPsec devices that use IPsec tunnel mode. so it's saying that ipsec tunnel mode and gif don't work, but then you have the code that remi is disabling saying that gif and ipsec transport dont work. BUGS is about one site using IPsec tunnel and the other site IPsec transport with gif. The problem reported by Atanas is about IPsec transport + gif on both sites. i can understand the issue since a decrypted esp packet looks a lot like the packets gif wants to handle. if we change to code or doco to make something work, which way should we go? right now i would use gre inside ipsec transport mode, not gif. it has the benefit of working, yes ;-) and it is harder for traffic inside the tunnel to leak out of ipsec. more specifically, gif handles 3 ip protocols, ipv4, ipv6, and mpls, which are ip protocol numbers 4, 41, and 137 respectively. it is likely that people could set up ipsec to protect ipv4, but forget about ipv6 and mpls. if you then configure v6 or mpls on the gif interface, that traffic will leak. I don't see the big difference here between gif and gre. To prevent traffic leave your box unprotected you have to setup pf rules in both cases. gre on the other hand is a single ip protocol, so more straightforward to protect. there's also a very clear line in the sand between the inner and outer traffic, which esp tunnel and transport mode lack. But gre alone does not protect the traffic! You still need esp transport for protection. My main point about this is: The setup described by Atanas used to work. There are setups out there (including mine) that are operational for years and rely on OSPF working via gif + esp transport. With the current state of gif these setups will break. Regards, Remi
Re: OpenBSD-based network switch with >16 GigE ports.
On Sat, Apr 07, 2018 at 12:01:54AM +0200, Karel Gardas wrote: > > > Hello, > > I'm looking to buy a new switch for house network. Ideally I'd like to setup > everything here on OpenBSD, but I'm not lucky > to find any OpenBSD-based switch. I need just GigE ports, at least 18-20. > Preferably fanless. 1-2U shallow depth into small rack. > I know all those Marvells, Broadcoms etc. holding majority in switch business > with strict NDAs are not OpenBSD friendly, but > still hope something may have slipped from my sight. There is some hope: Broadcom recently published their SDKLT as open source. https://www.broadcom.com/products/ethernet-connectivity/software/sdklt A switch with a Tomahawk ASIC might be a bit oversized for you home network. ;-) Remi > > Any advice appreciated. > > Thanks! > Karel
Re: OSPF and CARP interfaces
On Tue, Dec 22, 2020 at 02:04:27PM +0100, open...@kene.nu wrote:
> Hello,
> I am seeing what I deem to be unexpected behavior with ospfd and depending
> on carp interfaces.
> Running 6.8 with latest patches applied on all three routers.
>
> # uname -a
> OpenBSD extfw1.lab.kambi.com 6.8 GENERIC.MP#2 amd64
>
> My setup is as following;
> Two openbsd boxes (FW1 and FW2) acting as a firewall pair sharing carp
> interfaces.
> Single openbsd box (R1) that in this instance acts as a client trying to
> reach servers that are reachable via the FWs.
> VLan20 (actually carp20) is my nexthop (BGP wise) to reach any networks
> behind the FW pair.
> VLan21 is the link network between all the three boxes. The FWs share a
> carp21 interface.
>
> My FW ospfd.conf (same on all three boxes apart from the "depend on" which
> is absent from R1):
> router-id
>
> area 0.0.0.0 {
> interface lo1
> interface vlan20 {
> depend on carp20
> }
> interface vlan21 {
> depend on carp21
> }
> }
>
> Carp20:
> root@FW1:~ # ifconfig carp20 | grep inet
> inet 172.30.9.21 netmask 0xfff0 broadcast 172.30.9.31
>
> Now to the strange part. I see that the selected route in R1 points to FW1
> even though carp20/21 on FW1 is in state BACKUP. No matter what I do, apart
> from setting static metrics, ospfd on R1 always selects FW1 as nexthop.
> root@FW1:~ # ifconfig vlan21 | grep inet
> inet 172.30.9.34 netmask 0xfff0 broadcast 172.30.9.47
> root@FW1:~ # ifconfig carp20 | grep carp:
> carp: BACKUP carpdev vlan20 vhid 1 advbase 1 advskew 10
> root@FW1:~ # ifconfig carp21 | grep carp:
> carp: BACKUP carpdev vlan21 vhid 1 advbase 1 advskew 10
>
> root@FW2:~ # ifconfig vlan21 | grep inet
> inet 172.30.9.35 netmask 0xfff0 broadcast 172.30.9.47
> root@FW2:~ # ifconfig carp20 | grep carp:
> carp: MASTER carpdev vlan20 vhid 1 advbase 1 advskew 100
> root@FW2:~ # ifconfig carp21 | grep carp:
> carp: MASTER carpdev vlan21 vhid 1 advbase 1 advskew 100
>
> root@R1:~ # ospfctl sh
> neighID Pri StateDeadTime Address Iface
> Uptime
> 172.30.9.4 1 FULL/OTHER 00:00:38 172.30.9.35 vlan2100:21:33
> 172.30.9.3 1 FULL/BCKUP 00:00:38 172.30.9.34 vlan2100:22:14
>
> root@R1:~ # ospfctl sh fib | grep 172.30.9.16/2
> *O 32 172.30.9.16/28 172.30.9.34
> *O 32 172.30.9.16/28 172.30.9.35
>
> root@R1:~ # ospfctl sh rib | grep 172.30.9.16/2
> 172.30.9.16/28 172.30.9.34 Intra-Area Network 20
> 00:30:33
> 172.30.9.16/28 172.30.9.35 Intra-Area Network 20
> 00:29:56
>
> root@R1:~ # route -n get 172.30.9.21
>route to: 172.30.9.21
> destination: 172.30.9.16
>mask: 255.255.255.240
> gateway: 172.30.9.34
> interface: vlan21
> if address: 172.30.9.37
>priority: 32 (ospf)
> flags:
> use mtuexpire
> 11 0 0
>
> As seen above R1 selects 172.30.9.34 as the nexthop based on ospf which is
> wrong. It should be 172.30.9.35 as FW2 is carp master for carp20/21. What I
> in the end want to achieve is that the router with carp20/21 MASTER should
> be the preferred carp20 nexthop. An assumption can be made that carp20/21
> will always have the same FW as master in my case.
Can you test if it works as expected with current?
I think you are affected by a bug fixed by dlg with this commit:
https://marc.info/?l=openbsd-cvs&m=160427701605657&w=2
Re: current snapshot: pc powered down for high cpu temp
On Thu, Jul 18, 2013 at 06:08:17PM +0200, Riccardo Mottola wrote: > Hi, > > I upgraded to a currents snapshot today (I was using one of July 9 > previously). > > Now if I power on my laptop, it will boot, get about to the loign > prompt, say my CPU temperature is 5296C and starts a shut down. > > (besides: it doesn't shut down completely, the computer still > remains on, like I reported a couple of days ago). > > How can I give you more information? (And no, the machine was > unlikely overheated and certainly not at a temperature where Silicon > would melt... I just powered the machine on and the fan is working) > > Riccardo > Same here on a new Samsung 900X3F notebook. It worked nice with a snapshot from Jul 6. But with the snapshots from Jul 13 and later acpitz0 shows wrong values and shuts down the notebook. Below first a dmesg with from a working kernel and then a newer one. Remi OpenBSD 5.3-current (GENERIC.MP) #18: Sat Jul 6 16:54:29 MDT 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3881746432 (3701MB) avail mem = 3770683392 (3596MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries) bios0: vendor Phoenix Technologies Ltd. version "P00ACX" date 04/26/2013 bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI MSDM UEFI UEFI acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.39 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 cpu0: apic clock running at 99MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus 1 (RP01) acpiprt3 at acpi0: bus -1 (RP02) acpiprt4 at acpi0: bus -1 (RP03) acpiprt5 at acpi0: bus 2 (RP04) acpiprt6 at acpi0: bus 3 (RP05) acpiprt7 at acpi0: bus -1 (RP06) cpiprt8 at acpi0: bus -1 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus -1 (PEG0) acpiprt11 at acpi0: bus -1 (PEG1) acpiprt12 at acpi0: bus -1 (PEG2) acpiprt13 at acpi0: bus -1 (PEG3) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpicpu2 at acpi0: C3, C2, C1, PSS acpicpu3 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: FN00 acpipwrres1 at acpi0: FN01 acpipwrres2 at acpi0: FN02 acpipwrres3 at acpi0: FN03 acpipwrres4 at acpi0: FN04 acpitz0 at acpi0: critical temperature is 106 degC acpitz1 at acpi0: critical temperature is 106 degC acpibat0 at acpi0: BAT1 type LION oem "SAMSUNG Electronics" acpiac0 at acpi0: AC unit online acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: PWRB acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD02 cpu0: Enhanced SpeedStep 1696 MHz: speeds: 1801, 1800, 1700, 1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800, 774 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function
Re: IPSec tunnel doesn't work after CARP fail over (no fast fail over).
Hi
On Mon, Jul 22, 2013 at 12:56:38PM +0100, Andy wrote:
> Hi,
>
> I hope this is helpful to someone else and maybe a dev could add
> this solution (or an improvement thereof) into the code as standard.
>
> - I found an issue with IPSec and OpenBSD with CARP during
> fail-over, whereby a fail over with the default recommended set-up
> results in broken IPSec tunnels for a while.
>
> isakmpd does all the work of setting up phase 1 and phase 2 for the
> VPN and the actual encryption/decryption of packets etc.
>
> isakmpd;
> -K is needed to make isakmpd controlable by ipsecctl or bgpd etc.
> -S is needed to make isakmpd startup in a passive move, and not
> initiate connections or process incoming traffic unless CARP master
> (If sasyncd is enabled in rc.conf.local, rc.d scripts add -S
> automatically).
>
> All sasyncd does is to synchronise the established SA's to the
> backup CARP firewall.
>
> The problem I found is that when the secondary firewall is started
> up/rebooted, isakmpd starts up and does nothing (is passive, but
> does not even know about the tunnel policies). sasyncd starts and
> receives SAs from the master.
>
> The CARP pair now fail-over and the tunnels stop working even though
> the SAs are all present and correct, the problem is simply that
> isakmpd on the secondary was never told to read the policies!
>
> I have simply modified '/etc/rc.d/sasyncd' so after it starts,
> isakmpd reads the policies.
>
> /etc/rc.d/sasyncd;
> #!/bin/sh
> #
> # $OpenBSD: sasyncd,v 1.1 2011/07/06 18:55:36 robert Exp $
>
> daemon="/usr/sbin/sasyncd"
>
> . /etc/rc.d/rc.subr
>
> pexp="sasyncd: \[priv\]"
>
> rc_start() {
> ${rcexec} "${daemon} ${daemon_flags} ${_bg}"
> ipsecctl -f /etc/ipsec.conf
> }
Why don't you use "ipsec=YES" in /etc/rc.conf.local ?
>
> rc_cmd $1
>
> Now when the firewalls fail-over the tunnels work immediately :)
> I'm sure there is a more elegant solution to this, but this works
> well enough.
>
> Cheers, Andrew Lemin
Re: spdy support on base nginx
On Sun, Sep 08, 2013 at 11:21:58AM -0600, Alvaro Mantilla Gimenez wrote: > Hi, > >Do nginx from base installation (5.3) support SPDY? I didn't found any > reference in man pages and/or ports. The SPDY module was added to base nginx on July 1 2013 [1] but disabled later [2]. [1] http://marc.info/?l=openbsd-cvs&m=137010319309380&w=2 [2] http://marc.info/?l=openbsd-cvs&m=137165889526832&w=2
Re: OpenOSPFD (6.4) "depend on" feature forces "type 1"
On Wed, Jan 09, 2019 at 10:47:21PM +0700, Igor Podlesny wrote:
> Hi!
>
> My tests show that OpenOSPFD "depend on" feature forces "type 1"
> overriding explicitly specified "type 2". For example this statement
> can be used:
>
> redistribute 0.0.0.0/0 set { type 2 } depend on carp1
>
> (or keyword "default" can be used instead of prefix.)
>
> Is it an intended behaviour or it's not?
It is not intended. I'll look into it.
> Is this mail list appropriate for similar topics related to OpenOSPFD
> at all or some other mail list should better be used instead?
Next time maybe bugs@.
>
> System information:
> * 6.4 GENERIC.MP#3 amd64
> * syspatch up to 010_pcbopts installed
>
> --
> End of message. Next message?
>
Re: OpenOSPFD (6.4) "depend on" feature forces "type 1"
On Thu, Jan 10, 2019 at 03:06:59PM +0700, Igor Podlesny wrote: > On Thu, 10 Jan 2019 at 01:21, Remi Locherer wrote: > [...] > > > > It is not intended. I'll look into it. I can reproduce it. Interestingly it only sends out the wrong type when the "depend on" interfac (carp1 in your example) is down or in backup state and the configured type is 2. I don't have much time right now so please don't expect a fast fix. > > I see, thank you. BTW, if-when it's fixed would such a fix be brought > within standard syspatch update process or > what would it be otherwise? I don't think this is worth a syspatch. It is not a vulnerability or stability issue. And I also don't see how it affects existing setups. > > Can you also explain why Type 1 has been chosen as default one at all? For e. > g. > > https://www.juniper.net/documentation/en_US/junos/topics/concept/ospf-routing-external-metrics-overview.html > states "By default, OSPF uses the Type 2 external metric." > Bird OSPF also uses Type 2 for default route announcements. > > It's interesting hence why OpenOSPFD uses Type 1 instead. I have no clue. But now it is unlikely that the default changes since that would affect existing setups. > > -- > End of message. Next message? >
Re: OpenOSPFD (6.4) "depend on" feature forces "type 1"
On Fri, Jan 11, 2019 at 12:06:09AM +0700, Igor Podlesny wrote: > On Thu, 10 Jan 2019 at 21:11, Remi Locherer wrote: > [...] > > I can reproduce it. Interestingly it only sends out the wrong type when > > the "depend on" interfac (carp1 in your example) is down or in backup > > state and the configured type is 2. > > That's an irony for real! -- Type 1 is "heavier" than Type 2; so it means then > when it shouldn't be announcing "heavy" default due it's BACKUP it > actually is announcing > it as "heavy" (preferred) one. > > > I don't have much time right now so please don't expect a fast fix. > > Understood. > > > > I see, thank you. BTW, if-when it's fixed would such a fix be brought > > > within standard syspatch update process or > > > what would it be otherwise? > > > > I don't think this is worth a syspatch. It is not a vulnerability or > > stability issue. > > The second part of my question was exactly about how this fix would be > supplied then if > not with syspatch? OpenOSPFD seems to be part of the OS, and I thought that > syspatch is the appropriate mechanism for that hence. What else if not > syspatch? > A fix will go to -current which will then become the next release. > > And I also don't see how it affects existing setups. > > Well, setting Type 2 is a sign of interaction with different routing > software since most of it > use Type 2 by default. Then: > > * if config isn't mixed it runs on Type 1 and fix won't affect it in a way; > * if it's mixed and doesn't use "depend on" it won't be broken as well. > > But only if it's mixed and uses "depend on" it would be affected (read > "fixed") :) Yes. But this feature is relatively new so I don't expect thousands of networks using it. ;-)
Re: Ignore MTU on OSPFD
On Mon, Jan 14, 2019 at 03:08:32PM -0500, Henry Bonath wrote: > Is it possible to set to ignore MTU on OpenOSPFD? No, this is not supported. > > For example on Cisco IOS I can add the command "ip ospf mtu-ignore" > > I am having some issues if the MTU is mismatched and some neighbors will be > stuck in Exstart or Exchange. Exactly. If the MTU differs between neighbors the adjacency will not come up. > Other times those neighbors work fine, and it's unclear whether the MTU is > coming into play, however those neighbors do have MTU of 9000. Maybe it is worth checking that you configured the MTU for L2 and for L3 on these Cisco devices.
Re: OpenOSPFD (6.4) "depend on" feature forces "type 1"
Hi Igor On Thu, Jan 10, 2019 at 11:31:00PM +0100, Sebastian Benoit wrote: > Remi Locherer(remi.loche...@relo.ch) on 2019.01.10 21:18:58 +0100: > > On Fri, Jan 11, 2019 at 12:06:09AM +0700, Igor Podlesny wrote: > > > On Thu, 10 Jan 2019 at 21:11, Remi Locherer wrote: > > > [...] > > > > I can reproduce it. Interestingly it only sends out the wrong type when > > > > the "depend on" interfac (carp1 in your example) is down or in backup > > > > state and the configured type is 2. > > > > > > That's an irony for real! -- Type 1 is "heavier" than Type 2; so it means > > > then > > > when it shouldn't be announcing "heavy" default due it's BACKUP it > > > actually is announcing > > > it as "heavy" (preferred) one. > > > > > > > I don't have much time right now so please don't expect a fast fix. > > > > > > Understood. > > > > > > > > I see, thank you. BTW, if-when it's fixed would such a fix be brought > > > > > within standard syspatch update process or > > > > > what would it be otherwise? > > > > > > > > I don't think this is worth a syspatch. It is not a vulnerability or > > > > stability issue. > > > > > > The second part of my question was exactly about how this fix would be > > > supplied then if > > > not with syspatch? OpenOSPFD seems to be part of the OS, and I thought > > > that > > > syspatch is the appropriate mechanism for that hence. What else if not > > > syspatch? > > We supply errata (and thus syspatches) for security issues and for problems > that can cause a lot of grief to many people. > > depend on is a nice feature, but not critical to the use of ospfd, so this > probably wont get an errata. If you really need the fix, you can apply the > patch to /usr/src/usr.sbin/ospfd yourself (i believe it should apply without > problems), build and install it, until you update to 6.5. > > /Benno > > > A fix will go to -current which will then become the next release. > > > > > > And I also don't see how it affects existing setups. > > > > > > Well, setting Type 2 is a sign of interaction with different routing > > > software since most of it > > > use Type 2 by default. Then: > > > > > > * if config isn't mixed it runs on Type 1 and fix won't affect it in a > > > way; > > > * if it's mixed and doesn't use "depend on" it won't be broken as well. > > > > > > But only if it's mixed and uses "depend on" it would be affected (read > > > "fixed") :) > > > > Yes. But this feature is relatively new so I don't expect thousands of > > networks using it. ;-) > I just committed a fix for ospfd and ospf6d to -current. You can try it with the next snapshot or wait for the next release. If you need this functionality now on OpenBSD 6.4 with type2 external LSAs you can use ifstated to monitor a carp interface, modifying metrics in ospfd.conf and reloading ospfd. Thank you for reporting the problem! Regards, Remi
Re: openbgpd; strip private ASNs from bgp updates
On Sun, Mar 31, 2019 at 01:09:06PM +0200, Claudio Jeker wrote: > On Fri, Mar 29, 2019 at 08:36:26AM +0100, open...@kene.nu wrote: > > I forgot to add to my previous email. One thing that could be useful > > in this case is to mimic the Cisco option "neighbor x.x.x.x > > remove-private-as" which removes any private ASes from the path on any > > updates to a peer. Just throwing it out there, cant be a very > > difficult option to implement I guess? > > I think changing the AS PATH is a bad thing, removing elements from your > AS path has a major impact on the route selection and opens doors for > routing loops. In general I will only add features like 'as-override' when > there is a clear reason why it is needed. > So my question is, why do you need to use private AS numbers in your > internal network? It's common to use private AS numbers in data center networks for Clos topologies (one AS number per leaf switch and one for all spine switches because of ECMP). Private AS numbers are also used for large DMVPN deployments. Many BGP implementations have this feature: Junos (remove-private), NetIron (remove-private-as), IOS (remove-private-as) > > > On Thu, Mar 28, 2019 at 2:55 PM wrote: > > > > > > That will indeed help. Will check it out. > > > > > > How I have solved it now is by having network statements on the edge > > > (/24s). To make the internal routing work I announce more specific > > > prefixes from the internal router, so externally I announce a /24 > > > (from edge to peering partners) but internally I announce two /25s > > > (from internal to edge). That way internet knows how to find my /24 > > > and edge knows how to find its way internally due to /25 being more > > > specific compared to /24. > > > > > > On Wed, Mar 27, 2019 at 9:33 PM Sebastian Benoit > > > wrote: > > > > > > > > open...@kene.nu(open...@kene.nu) on 2019.03.27 12:25:33 +0100: > > > > > Hello, > > > > > > > > > > That would unforunately affect all the prefixes announced to the edge > > > > > router from the internal router. I need it to be only prefixes > > > > > announced to my peering partners. > > > > > > > > > > /Oscar > > > > > > > > > > On Tue, Mar 26, 2019 at 3:50 PM Denis Fondras > > > > > wrote: > > > > > > > > > > > > On Tue, Mar 26, 2019 at 02:54:38PM +0100, open...@kene.nu wrote: > > > > > > > Hello, > > > > > > > > > > > > > > Is there a way to make openbgpd strip private ASNs from updates it > > > > > > > sends to certain neighbors? > > > > > > > I am using openbgpd on my edge routers and distribute routes > > > > > > > generated > > > > > > > internally to the rest of the world. However, the internal > > > > > > > routers use > > > > > > > private ASNs and this is obviously frowned upon by my peering > > > > > > > partners. > > > > > > > > > > > > > > I can of course have network statements on my edge routers but > > > > > > > that > > > > > > > assumes the prefixes will always be reachable via said edge > > > > > > > router, > > > > > > > something I can never be certain of. I would rather the updates > > > > > > > rely > > > > > > > on the prefix actually being announced from the source. > > > > > > > > > > > > > > > > > > > Perhaps with transparent-as ? > > > > > > > > In current (snapshots) there is "as-override": > > > > > > > > as-override (yes|no) > > > > If set to yes, all occurrences of the neighbor AS in the AS > > > > path will be replaced with the local AS before running the > > > > filters. The Adj-RIB-In still holds the unmodified AS > > > > path. > > > > The default value is no. > > > > > > > > this is a neighbor option and used on the session to a peer that uses a > > > > private AS. > > > > > > > > You dont say much about your network structure, but if your edge router > > > > has > > > > a normal As number, and your internal ebgp peers have private As > > > > numbers, > > > > this option will help. > > > > > > > > /Benno > > > > > > > > -- > :wq Claudio >
Re: Looking for DMVPN implementation
On Sat, Oct 01, 2016 at 10:44:02PM +, Jens Sauer wrote: > Hi OpenBSD community, > > i'm looking for an OpenSource implementation of DMVPN (Dynamic Multipoint > Virtual private network). > > Currently i just found the draft (from 2013) : > https://tools.ietf.org/html/draft-detienne-dmvpn-00 > > Comming from Cisco and would be pleased to see it under OpenBSD. > http://www.cisco.com/c/dam/en/us/products/collateral/security/dynamic-multipoint-vpn-dmvpn/DMVPN_Overview.pdf > > Hope i could get an advice in how to implement (use) it under OpenDSD. OpenBSD does not have support for mGRE and NHRP. If you're not having hundreds of sites you want to connect you could set up tunnels (gif or gre), protect it with ipsec and run a routing protocol over that. It scales best if you automate it (I use ansible for this). Remi
Re: starting ssh-agent on ssh login
On Sat, Oct 08, 2016 at 09:41:41AM -0400, Predrag Punosevac wrote: > "soko.tica" wrote: > > > Hi Predrag, > > > > I am not sure that I am getting your question right, but for starting ssh > > agent on my lap, I simply uncomment (or create?) the following in my > > .xinitrc > > You are not. I am not running X so I am not using .xinitrc. I am ssh-ing > to the headless server and I want to run ssh-agent automatically on that > remote server. I think I need similar script in my .profile. > I use this snipped in a similar setup: --%<%<-- pgrep -u $USER ssh-agent >/dev/null || ssh-agent -t 28800 > ~/.ssh-agent.out eval $( cat ~/.ssh-agent.out ) >/dev/null ssh-add -l | grep "The agent has no identities." >/dev/null && ssh-add --%<%<-- Tha last line could be removed if you have an up-to-date ssh client that supports "AddKeysToAgent yes" Remi > > ... > > if [ "$SSH_AGENT_PID" ]; then > > ssh-add -D < /dev/null > > eval `ssh-agent -s -k` > > fi > > ... > > > > For starting (and keeping alive) a ssh agent on a remote host I use > > http://www.funtoo.org/Keychain > > > > keychain is for Linux kids who don't want to learn how to use > ssh-agent:) > > > > If the keys of the remote host are password protected, the password needs > > to be typed in upon any (re)start of the remote host. > > > > I hope I was on topic. > > > > Regards, > > > > On Fri, Oct 7, 2016 at 10:38 PM, Predrag Punosevac > > wrote: > > > > > Hi Misc, > > > > > > This is a rather trivial question. What is the recommended way of > > > starting ssh-agent when upon ssh login into the remote host. Namely I > > > have a remote host which is used as a gateway to a bunch of machines > > > whose ssh keys are password protected. I have > > > > > > AddKeysToAgent yes > > > > > > in my ~/.ssh/config file as well as > > > > > > xidle -program "/usr/bin/ssh-add -D" -timeout 300 & > > > > > > in my .xsession file. Everything works nice and neat when I am on my > > > desktop but I want to replicate functionality when I ssh to a headless > > > (no X) shell gateway. > > > > > > Thanks, > > > Predrag
Re: starting ssh-agent on ssh login
On Sat, Oct 08, 2016 at 04:44:16PM -0400, Predrag Punosevac wrote: > I just want to give an update to this thread. I got lots of replays off > the list as well but not the answer I was looking for > > For now Iexperimented with the single > > eval `ssh-agent -t 60` > > in my .profile file with that you start a new ssh-agent with every ssh session. after some time you will have a lot of ssh-agent processes on your box. > > and > > AddKeysToAgent yes > > in my > > ~/.ssh/config > > file. Everything works as I wont but there is big caveat. ssh-agent > doesn't get killed after I log out so it looks like this would be very > easy to abuse. I could kill ssh-agent after some time let say 10 > minutes with the cron job. Reading again through ssh-agent man pages I > don't see expiration switch but it might be somehow possible to tie > ssh-agent proce to the PID of current ssh login. I actaully feel > unconfortable leaving ssh-agent -t 60 in .profile until I learn how to > kill it automatically upon log out. Maybe ssh agent forwarding would be better for you (ssh -A). > > Predrag
Re: axen(4) usb ethernet problems
On Thu, Oct 13, 2016 at 05:40:18PM -0700, Ilya Kaliman wrote: > Hi! > > I have a "Plugable USB 3.0 ethernet adapter" with ASIX AX88179 > chipset. The device is successfully recognized by axen(4) driver but > behaves strangely. When I plug in the ethernet cable the ifconfig > axen0 status says active and the leds start blinking. But after a > second or two both leds turn off and status says: no carrier. > Re-plugging the cable have no effect. Re-plugging the adapter itself > brings it up again for a second or two. > > The device itself seems to be fine as it works in other OSes without > problems. I suspect it has to do with OpenBSD driver. > > I have axen(4) driver compiled with debug - it prints a lot of stuff, > but nothing that seem to indicate an error. Can anyone give some > pointers on how to diagnose the problem? > > Thanks, > Ilya What version of OpenBSD are you running? Usually it's best to add the output of dmesg to such a mail to give others an idea what you are running. There was a change to axen in March this year that made my adapter work reliably. It ships with 6.0. http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/if_axen.c Remi
Re: Routes to downed interfaces
On Sun, Oct 30, 2016 at 12:36:12PM +0100, Jasper Siepkes wrote: > Hi all, > > I've got a question about how OpenBSD deals with routes and interfaces > that are considerd 'down'. I've noticed that when an interface in > OpenBSD is down the route to that interface will remain in the routing > table and is also not flagged with R(eject). The route stays exactly > the same wheter the device is up or down. > > In Linux (and I have no idea wheter this is a good idea or not) the > route of the downed interface is removed. Something similar was discussed in this thread: http://marc.info/?t=14599935538&r=1&w=2 OpenBSD behaves different to what I know from routers I work with. There a route disapears when I shut an interface. > Is the above behavior normal? WHat should I do if I don't want to > route traffic to downed interfaces (like backup CARP interfaces). > > The reason why I'm asking is because I want to route traffic somewhere > else with ifstated when a device goes in CARP backup mode (upstream > uses ECMP routing). But because the device route of the downed > interface (the interface being a CARP interface in backup mode in this > scenario) stays in the routing table with priority 1 I can't > override it. Maybe a setup without carp on the interfaces towards your upstream would work better? But I can not tell based on the information you provide. Remi
Re: OSPFD over IPSEC
On 2016-11-14 12:48, Comète wrote: Hi, I'm trying to run OSPFD over IPSEC with OpenBSD 6.0 stable, so I first start looking at http://undeadly.org/cgi?action=article&sid=20131105075303 Now that etherip has it's own interface in 6.0, I tried to replace gif with etherip like this: On one host: -=>> cat /etc/hostname.bridge0 add etherip0 add vether0 up -=>> cat /etc/hostname.vether0 inet 10.60.10.2 255.255.255.0 NONE up -=>> cat /etc/hostname.etherip0 tunnel 1.2.3.4 4.3.2.1 up -=>> doas cat /etc/ipsec.conf ike active esp proto etherip from 1.2.3.4 to 4.3.2.1 psk "mypassword" -=>> doas ipsecctl -sa FLOWS: flow esp in proto etherip from 4.3.2.1 to 1.2.3.4 peer 4.3.2.1 srcid 1.2.3.4/32 dstid 4.3.2.1/32 type use flow esp out proto etherip from 1.2.3.4 to 4.3.2.1 peer 4.3.2.1 srcid 1.2.3.4/32 dstid 4.3.2.1/32 type require SAD: esp tunnel from 4.3.2.1 to 1.2.3.4 spi 0x3d8e9212 auth hmac-sha2-256 enc aes esp tunnel from 1.2.3.4 to 4.3.2.1 spi 0x900fc2c5 auth hmac-sha2-256 enc aes On the other host: -- -=>> cat /etc/hostname.bridge0 add etherip0 add vether0 up -=>> cat /etc/hostname.vether0 inet 10.60.10.1 255.255.255.0 NONE up -=>> cat /etc/hostname.etherip0 tunnel 4.3.2.1 1.2.3.4 up -=>> doas cat /etc/ipsec.conf ike passive esp proto etherip from 4.3.2.1 to 1.2.3.4 psk "mypassword" -=>> doas ipsecctl -sa FLOWS: flow esp in proto etherip from 1.2.3.4 to 4.3.2.1 peer 1.2.3.4 srcid 4.3.2.1/32 dstid 1.2.3.4/32 type use flow esp out proto etherip from 4.3.2.1 to 1.2.3.4 peer 1.2.3.4 srcid 4.3.2.1/32 dstid 1.2.3.4/32 type require SAD: esp tunnel from 4.3.2.1 to 1.2.3.4 spi 0x3d8e9212 auth hmac-sha2-256 enc aes esp tunnel from 1.2.3.4 to 4.3.2.1 spi 0x900fc2c5 auth hmac-sha2-256 enc aes I forgot to mention that i didn't set net.inet.etherip.allow=1 and let it set to 0, as said in "etherip" man page, because I use IPSEC. As you can see the ipsec VPN is well established, but my problem is that I can't ping 10.60.10.1 from 10.60.10.2 and 10.60.10.2 from 10.60.10.1. On each vether interface, tcpdump -nettti shows me that nothing is going out of them. Any idea ? Can you show pf.conf? Are there any blocks if you check on pflog0 with tcpdump? But why do you want to have Ethernet frames tunneled? If you use gif interfaces and make ospfd beeing active on it you save a few bits. That way you can make the MTU bigger. https://cway.cisco.com/tools/ipsec-overhead-calc/ can give you and idea how big your MTU can be (needs an account but is free). Be careful when configuring gif interfaces. ospfd only recognizes that it is a point-to-point interface when you configure the netmask as 255.255.255.255.
Re: OSPFD over IPSEC
On Mon, Nov 14, 2016 at 04:50:21PM +, Comète wrote: > 14 novembre 2016 14:50 "Remi Locherer" a écrit: > > On > 2016-11-14 12:48, Comète wrote: > > > >> Hi, > >> I'm trying to run OSPFD over > IPSEC with OpenBSD 6.0 stable, so I first > >> start looking at > > http://undeadly.org/cgi?action=article&sid=20131105075303 > >> Now that etherip > has it's own interface in 6.0, I tried to replace gif > with > >> etherip like > this: [...] > > Can > you show pf.conf? Are there any blocks if you check on pflog0 with tcpdump? > > > > But why do you want to have Ethernet frames tunneled? If you use gif > interfaces > > and make ospfd beeing active on it you save a few bits. That way > you can make > > the MTU bigger. > https://cway.cisco.com/tools/ipsec-overhead-calc can give you > > and idea how > big your MTU can be (needs an account but is free). > > > > Be careful when > configuring gif interfaces. ospfd only recognizes that it is a > > > point-to-point interface when you configure the netmask as 255.255.255.255. > I finally got it working. I forgot the 'link2' option in /etc/hostname.bridge0 > : > > -=>> cat /etc/hostname.bridge0 > add etherip0 add vether0 > up link2 > > but it > wasn't enough... > I had to set 'net.inet.etherip.allow=1' in sysctl.conf > despite what it is said in the 'etherip' man page: > > "The sysctl(3) variable > net.inet.etherip.allow must be set to 1, unless ipsec(4) is being used to > protect the traffic." > > This is what I don't understand, is there any > particular case in this configuration or maybe something changed in 6.0 ? > thanks I can not tell you what is wrong with your configuration. Im not using etherip. But why do you think you need to tunnel Ethernet? You don't need it for ospf. rWWith gif interfaces you're doing ip-over-ip and don't need bridge and vether. Then just add the gif interface to ospfd.conf.
Re: rsyslog does not produce log on OpenBSD 6.0
On December 17, 2016 12:07:18 PM GMT+01:00, Federico Donati wrote: >Hi all, > >I've a problem with an OpenBSD 6.0 box with rsyslog. > >I need to send every local logs to a remote server and I can't use >syslogd, because it does not send the hostname of the server (the one >indicated in /etc/myname), but on the remote server messages come with >the PTR record of my public ip. have you tried -h for syslogd from base? > >I've installed rsyslogd, but it doesn't send anything to the remote >server. And more than that, it doesn't write anything local. > >I've also tried to run it in conjunction with syslogd, so locally >syslogd writes all the logs, but on the remote server rsyslog doesn't >send anything (verified also with tcpdump). > >This is my configuration rsyslog.conf file: > >~ >module(load="imuxsock") # provides support for local system logging >(e.g. via logger command) >module(load="imklog") # provides kernel logging support (previously >done by rklogd) > >$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat > >*.* @@ip.ip.ip.ip:514 >~ > > > >Output of configuration file parser: > >~ ># rsyslogd -f /etc/rsyslog.conf -N 4 > > >rsyslogd: version 8.16.0, config validation run (level 4), master >config >/etc/rsyslog.conf >rsyslogd: End of config validation run. Bye. >~ > > >My box uname -a: > >OpenBSD xxx.xxx.xx 6.0 GENERIC.MP#0 amd64 > > >Anyone can help?
Re: radicale and httpd
On Sat, Jan 14, 2017 at 11:06:29AM +, Stuart Henderson wrote: > On 2017-01-13, Jan Lambertz wrote: > > Hi, > > > > having Problems for some time now with the webserver in python2/3 and > > radicale, i tried to get it working with httpd. > > > > installed flup. python is working in the chroot. > > > > here's my work so far but i'm not getting any further. anyone got this > > working ? > > I'm no expert on httpd(8), but it doesn't seem right to be using slowcgi(8) > for something that can already be made to speak fastcgi. Few month ago I looked at radicale. I made radical run as fastcgi daemon and httpd talking to it via a socket. I started with this but used flup instead of flipflop: https://github.com/Kozea/Radicale/blob/master/radicale.fcgi Sorry, I don't have my script anymore. I decided to not use radicale since it was not able to handle my data. Remi
Re: dig/nslookup limitations - can only do NSLOOKUPs using port 53
On Mon, Jan 16, 2017 at 06:58:59AM +0100, Sebastien Marie wrote: > On Mon, Jan 16, 2017 at 03:37:11PM +1100, Damian McGuckin wrote: > > On Mon, 16 Jan 2017, Stuart Henderson wrote: > > > [...] > > > > > > Prior to the change to make -p an error, but after the dns pledge was > > > added, -p was allowed but ignored with a warning. See the commit adding > > > SOCK_DNS. > > > > On my OpenBSD 5.1 system, '-p' was still allowed, and it had a pledge list > > of "stdio dns". When 'rpath' was added to the pledge list, it was at this > > time at which '-p' was effectively disabled. > > The implementation of "dns" promise has been refined with the time. > > > > > Maybe I need more enlightening on my poor understanding of pledge as to > > > > why restricting the port number to only 53 is needed. > > > > > > Some people just use dig for looking up DNS records and I think for them > > > the dns pledge restrictions are a useful way to limit bug damage. > > > > Pledge is great. But I cannot see the link between pledge and killing off > > the '-p' option. Maybe I am getting senile, or just too much summer sun on > > my brain. > > When a program is using the "dns" promise, the kernel could enforce > several restriction that are network related. > > Basically with "stdio rpath dns", the program could: > - doing stdio stuff > - accessing readonly any file > - having a limited access to network, just for doing DNS stuff > > The point of using "dns" instead of "inet" promise is on "limited access > to network" and "for doing DNS stuff". > > The implementation of "for doing DNS stuff" relies on the socket(2) > flag SOCK_DNS with permit the kernel to enforce restriction on the way > the socket is used. > > In these restrictions, the port number is included: a socket flagged > with SOCK_DNS couldn't use another port than 53. > > And it is the link with -p flag. > > For looking up DNS records, "dns" is the right promise to use. > > > > Others use dig as a DNS server debugging tool and I think in those cases > > > the port restriction (and forcing traffic through rebound if it's running) > > > can get in the way. > > I agree with sthen@. For debugging purpose, things are more complex, and > "dns" doesn't fit well. > > > [...] > > > > Alternatively you could use the version of dig from packages which > > > doesn't use pledge: > > > > > > pkg_add isc-bind > > > /usr/local/bin/dig -p > > > > > > However, because this one doesn't use pledge at all, bugs are a bigger > > > risk. > > > > I thought the whole idea of using NSD/UNBOUND is to avoid installing > > 'isc_bind'. > > sthen@, does a subpackage for tools like dig could be a way ? Eventually > with pledging it with "inet" (instead of "dns") ? > > > I still cannot see what risk there is on qujerying a DNS on a non-standard > > port. Enlighten me please? > > > > pledge(2) isn't a magic bullet, but a mitigation. By using pledge with > "dns", you ensure the program could reach network only on limited way. > > As dig has also "rpath", it means a bug in dig could makes the program > to be able to exflitrate file contents. With "dns", the exfiltration is > more complex (but not impossible I agree: pledge is only a mitigation). > Why not make pledge dns dependent the -p flag? Remi
Re: ipsec ... again
On Tue, Apr 18, 2017 at 01:35:58PM +0200, Markus Rosjat wrote:
> Hi there,
>
> since my attempt with ikev2 failed I thought I go back to ikev1 but it seems
> since the last time I used it something has changed with that too.
>
> I simply try to set up a site to site tunnel with a PSK
>
> here is the ipsec.conf on the openbsd machine
>
> ike from {10.10.10.0/24} to 10.10.15.0/24 \
You need to add "peer AA.BB.CC.DD" here.
> main auth hmac-sha1 enc blowfish group modp1024\
> quick auth hmac-sha1 enc blowfish group modp1024\
> psk "my_psk"
>
If you control both ends of the VPN I recommend you choose stronger
cyphers. Check the defaults of OpenBSD or the recommendation of ENISA:
https://www.enisa.europa.eu/publications/algorithms-key-size-and-parameters-report-2014
How do you start isakmpd? This should configure your system to start
isakmpd and load the ipsec rules during boot:
# rcctl enable isakmpd
# rcctl set isakmpd flags -vK
# rcctl enable ipsec
> and here is the pf.conf
Add the log keyword to your pf rules. Without that it's hard to debug.
Also check man ipsec.conf for a full example.
>
> ### define networks ##
> tun_in="10.10.15.0/24"
> tun_end="{10.10.10.0/24}"
>
> # simple ipsec
> pass in proto { esp ah } to ($ext_if)
> pass in on $ext_if proto udp from any to port {500 4500} keep state
>
> pass in on enc0 proto ipencap
> pass in on enc0 from {$tun_in} to $tun_end
>
> pass out proto {esp ah}
> pass out on enc0 from $tun_end to {$tun_in}
>
> this works at least for a openbsd 5.6 and a srewsoft client (this is
> basically my other endpoint).
>
> with this setup Im not able to connect to a openBSD 6.1 and the logs don't
> show anything helpfull
>
> so the question is where do I need to do the rewriting and is there some
> example beside the ipsec.conf in /etc/examples ?
>
> Regards
>
> --
> Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de
>
> G+H Webservice GbR Gorzolla, Herrmann
> Königsbrücker Str. 70, 01099 Dresden
>
> http://www.ghweb.de
> fon: +49 351 8107220 fax: +49 351 8107227
>
> Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you
> print it, think about your responsibility and commitment to the ENVIRONMENT
Re: nfs_server=YES in /etc/rc.conf.local does not work
> > The problem is that they are still visible to the search function. Well, > > at least the spanish one was. > > In this case maybe the search stuff should only return original pages, not > the translated ones. > maybe this patch helps. remi Index: robots.txt === RCS file: /cvs/www/robots.txt,v retrieving revision 1.6 diff -u -p -r1.6 robots.txt --- robots.txt 20 Jun 2010 08:58:01 - 1.6 +++ robots.txt 28 Oct 2012 15:35:20 - @@ -1,6 +1,12 @@ User-agent: * Disallow: /cgi-bin/ Disallow: /faq/new/ +Disallow: /faq/es/ +Disallow: /faq/hu/ +Disallow: /faq/pl/ +Disallow: /faq/pt/ +Disallow: /faq/ru/ +Disallow: /faq/zh/ Disallow: /donations.html Disallow: /cs/donations.html Disallow: /de/donations.html
Re: OpenSMTPd error after upgrading to -current
On Sun, Feb 03, 2013 at 10:19:02PM +0100, Frank Brodbeck wrote: > Hi, > > I upgraded yesterday to the latest snapshot and have a problem with my > smtpd.conf which I can't resolve: > > /etc/mail/smtpd.conf:12: error: invalid url: smtps+auth://mail.split-brain.de > > The corresponding line is: > > # grep smtps+auth /etc/mail/smtpd.conf > > > accept for any relay via smtps+auth://mail.split-brain.de auth as > f...@split-brain.de > > smtpd.conf(5) didn't help me either. I guess I am missing something very > obvious here... I had the same issue today after installing the snapshot from Feb 1. Looks like a "label" in the url is now required and used as lookup key in the secrets map. # /etc/mail/smtpd.conf: listen on lo0 table aliases db:/etc/mail/aliases.db table secrets file:/etc/mail/secrets accept for local alias deliver to mbox accept for any relay via smtps+auth://b...@typhoon.relo.ch auth \ # /etc/mail/secrets blue user:pass I would prefere if just the host or a combination of user and host would be used for password lookup and not a label. Remi
hp dl360 gen9
Hi, I'm just starting to use hp dl360 gen9 servers with OpenBSD. With a few tweaks in the bios most stuff works fine: System Options o Processor Options - Hyperthreading -> disable # HT does not help on a OpenBSD firewall - Core disable -> 4 # That way the other cores can run at # higher speed - Processor x2apic support -> disabled # if enabled OpenBSD only sees cpu0 and # not the others o USB Options - USB 3.0 Mode -> disabled # with usb3 enabled the keyboard does not # work in boot promt o Boot Options - Boot Mode -> legacy bios mode # disable uefi Unfortunately the serial console does not work. I try to use the virtual serial port via iLO. While I have access to the BIOS and the boot loader it stops working once the kernel starts. dmesg says: com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo com1: probed fifo depth: 0 bytes On gen8 servers also a ns16550a is recoginized and it works nicely. Anybody knows how to make this work? Below outputs from dmesg, pcidump and usbdevs. Remi OpenBSD 5.7 (GENERIC.MP) #881: Sun Mar 8 11:04:17 MDT 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 68572934144 (65396MB) avail mem = 66743619584 (63651MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x79173000 (218 entries) bios0: vendor HP version "P89" date 03/05/2015 bios0: HP ProLiant DL360 Gen9 acpi0 at bios0: rev 2 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP UEFI MCEJ SSDT HEST BERT ERST EINJ HPET PMCT WDDT APIC MCFG SRAT SPMI RASF SPCR MSCT BDAT PCCT SSDT SSDT SSDT DMAR acpi0: wakeup devices PEX4(S4) BR05(S4) BR03(S4) BR07(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz, 2397.54 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,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.0, IBE cpu1 at mainbus0: apid 12 (application processor) cpu1: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz, 2397.23 MHz 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,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 6, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz, 2397.23 MHz 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,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 14 (application processor) cpu3: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz, 2397.23 MHz 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,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 7, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins ioapic1 at mainbus0: apid 9 pa 0xfec01000, version 20, 24 pins acpimcfg0 at acpi0 addr 0x8000, bus 0-255 acpiprt0 at acpi0: bus 255 (UNC0) acpiprt1 at acpi0: bus 0 (PCI0) acpiprt2 at acpi0: bus 1 (PEX2) acpiprt3 at acpi0: bus 2 (PEX4) acpiprt4 at acpi0: bus 3 (BR01) acpiprt5 at acpi0: bus 4 (BR05) acpiprt6 at acpi0: bus 5 (BR03) acpiprt7 at acpi0: bus 8 (BR07) acpicpu0 at acpi0: C2, C1 acpicpu1 at acpi0: C2, C1 acpicpu2 at acpi0: C2, C1 acpicpu3 at acpi0: C2, C1 ipmi at mainbus0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel E5 v3 Host" rev 0x02 ppb0 at pci0 dev 1 function 0 "Intel E5 v3 PCIE" rev 0x02 pci1 at ppb0 bus 3 ciss0 at pci1 dev 0 function 0 "Hewlett-Pa
Re: Can't ping IPv6
On Tue, Sep 15, 2015 at 10:01:03PM +0100, Mark Carroll wrote: > I have a fairly vanilla OpenBSD 5.7 installation on > a machine for which my provider told me, > > Net : 5.28.62.155, 2001:41c9:1:41c::155 > > My pf.conf is simple; it still has the, > block return# block stateless traffic > that I suppose I got from somewhere and generally seems to work fine. > > I can ping 5.28.62.155 just fine from anywhere, and from on the machine > itself I can ping6 its other address. I don't have IPv6 set up at home > but from various online IPv6 ping check tools I /don't/ seem to be able > to ping 2001:41c9:1:41c::155. On the machine "route show" provides a > bunch of stuff, > > Internet6: > DestinationGatewayFlags Refs Use Mtu Prio Iface > ::/104 localhost UGRS 00 32768 8 lo0 > ::/96 localhost UGRS 00 32768 8 lo0 > localhost localhost UHl 140 32768 1 lo0 > localhost localhost UH 00 32768 4 lo0 > ::127.0.0.0/104localhost UGRS 00 32768 8 lo0 > ::224.0.0.0/100localhost UGRS 00 32768 8 lo0 > ::255.0.0.0/104localhost UGRS 00 32768 8 lo0 > :::0.0.0.0/96 localhost UGRS 00 32768 8 lo0 > 2001-41c9-0001-041 link#1 UC 00 - 4 vio0 Strange notation with "-". Never seen such an output from "routei show" or "netstat -rn" command. > green.ixod.org fe:ff:00:00:4f:1a UHLl 0 22 - 1 lo0 > 2002::/24 localhost UGRS 00 32768 8 lo0 > 2002:7f00::/24 localhost UGRS 00 32768 8 lo0 > 2002:e000::/20 localhost UGRS 00 32768 8 lo0 > 2002:ff00::/24 localhost UGRS 00 32768 8 lo0 > fe80::/10 localhost UGRS 00 32768 8 lo0 > fe80::%vio0/64 link#1 UC 20 - 4 vio0 > fe80::523d:e5ff:fe 50:3d:e5:3b:a1:3f UHLc 0 102 - 4 vio0 > fe80::523d:e5ff:fe 50:3d:e5:3b:d7:3f UHLc 0 116 - 4 vio0 > fe80::fcff:ff:fe00 fe:ff:00:00:4f:1a UHLl 00 - 1 lo0 > fe80::%lo0/64 fe80::1%lo0U 00 32768 4 lo0 > fe80::1%lo0fe80::1%lo0UHl00 32768 1 lo0 > fec0::/10 localhost UGRS 00 32768 8 lo0 > ff01::/16 localhost UGRS 00 32768 8 lo0 > ff01::%vio0/32 link#1 UC 00 - 4 vio0 > ff01::%lo0/32 localhost UC 00 32768 4 lo0 > ff02::/16 localhost UGRS 00 32768 8 lo0 > ff02::%vio0/32 link#1 UC 00 - 4 vio0 > ff02::%lo0/32 localhost UC 00 32768 4 lo0 > > When I use one of the online ping6 tools, on tcpdump I can watch > requests come in, like, > > 21:57:52.144975 2a02:348:82:cb69::6 > green.ixod.org: icmp6: echo request > (id:3244 seq:0) [icmp6 cksum ok] (len 40, hlim 248) > > but I never seem to see anything go back out on the interface (and > neither it seems do they). Should I do something else to make the > machine pingable via IPv6? Feel free to just point me to the fine manual > if I missed something, I'm still learning the places where documentation > lurks. > > -- Mark > You don't have a default route set for IPv6. Remi
Re: audio codec RealTek ALC3263
On Sat, Sep 19, 2015 at 08:31:24PM +, Alexey Suslikov wrote: > Remi Locherer relo.ch> writes: > > > My Dell XPS 13 has a RealTek ALC3263 codec (according to the BIOS). In > > dmesg only the following shows up: > > > > azalia0 at pci0 dev 3 function 0 "Intel Core 5G HD Audio" rev 0x09: msi > > azalia0: No codecs found > > Could you please build a kernel with AUDIO_DEBUG/AZALIA_DEBUG and > re-post dmesg? > OpenBSD 5.8-current (GENERIC.MP.AUDIO_DEBUG) #0: Sat Sep 19 22:50:26 CEST 2015 r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP.AUDIO_DEBUG real mem = 8168914944 (7790MB) avail mem = 7917355008 (7550MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed840 (84 entries) bios0: vendor Dell Inc. version "A05" date 07/14/2015 bios0: Dell Inc. XPS 13 9343 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT SSDT TPM2 SSDT ASF! SSDT SSDT SSDT SSDT PCCT SSDT SSDT SSDT SLIC MSDM DMAR CSRT acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.58 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.24 MHz 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.24 MHz 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.24 MHz 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpimadt0: bogus nmi for apid 0 acpimadt0: bogus nmi for apid 2 acpimadt0: bogus nmi for apid 1 acpimadt0: bogus nmi for apid 3 acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus 1 (RP01) acpiprt5 at acpi0: bus -1 (RP02) acpiprt6 at acpi0: bus -1 (RP03) acpiprt7 at acpi0: bus 2 (RP04) acpiprt8 at acpi0: bus -1 (RP05) acpiprt9 at acpi0: bus -1 (RP06) acpiprt10 at acpi0: bus -1 (RP07) acpiprt11 at acpi0: bus -1 (RP08) acpiec0 at acpi0 acpicpu0 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PG00, resource for PEG0 acpipwrres1 at acpi0: PG01, resource for PEG1 acpipwrres2 at acpi0: PG02, resource for PEG2 acpitz0 at acpi0: critica
Re: audio codec RealTek ALC3263
On Sun, Sep 20, 2015 at 08:17:59AM +0200, Remi Locherer wrote:
> On Sat, Sep 19, 2015 at 07:26:56PM -0400, Bryan Steele wrote:
> > On Sat, Sep 19, 2015 at 06:44:13PM -0400, Bryan Steele wrote:
> > > On Sat, Sep 19, 2015 at 02:38:02PM +0200, Remi Locherer wrote:
> > > > Hi
> > > >
> > > > My Dell XPS 13 has a RealTek ALC3263 codec (according to the BIOS). In
> > > > dmesg only the following shows up:
> > > >
> > > > azalia0 at pci0 dev 3 function 0 "Intel Core 5G HD Audio" rev 0x09: msi
> > > > azalia0: No codecs found
> > >
> > > This device is related to unsupported HDMI audio output, there should
> > > be a second azailia(4) device.
> > >
> > > For example, my laptop has:
> > >
> > > azalia1 at pci0 dev 27 function 0 "Intel 9 Series HD Audio" rev 0x03:
> > > msi
> > > azalia1: codecs: Realtek/0x0283
> > > audio0 at azalia1
> > >
> > > > Of course there is no audio :-(
> > >
> > > It appears this function is disabled on your system, you might want
> > > to check and see if there is a BIOS toggle, otherwise there's not
> > > much else that can be done.
> > >
> > > > Regards,
> > > > Remi
> > >
> > > -Bryan.
> >
> > Actually, there may be some funny ACPI interactions going on
> > that appear responsible for this.
> >
> > Can you try the following diff?
> >
> > Linux has this workaround for your model..
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=18d78b64fddc11eb336f01e46ad3303a3f55d039
> >
> > Index: dsdt.c
> > ===
> > RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
> > retrieving revision 1.218
> > diff -u -p -u -r1.218 dsdt.c
> > --- src/sys/dev/acpi/dsdt.c 20 Aug 2015 20:50:10 - 1.218
> > +++ src/sys/dev/acpi/dsdt.c 19 Sep 2015 23:11:54 -
> > @@ -1457,7 +1457,7 @@ struct aml_defval {
> > struct aml_value**gval;
> > } aml_defobj[] = {
> > { "_OS_", AML_OBJTYPE_STRING, -1, osstring },
> > - { "_REV", AML_OBJTYPE_INTEGER, 2, NULL },
> > + { "_REV", AML_OBJTYPE_INTEGER, 5, NULL },
> > { "_GL", AML_OBJTYPE_MUTEX, 1, NULL, &aml_global_lock },
> > { "_OSI", AML_OBJTYPE_METHOD, 1, aml_callosi },
> >
>
> I applied this and also commented out DIAGNOSTIC in
> azalia.c/azalia_get_response.
This morning I just did a reboot with the patched kernel. Now after a cold
boot there is another azalia device! And now I can listen to music with this
notebook.
Thanks Bryan for the "coold boot" hint.
dmesg:
OpenBSD 5.8-current (GENERIC.MP.AUDIO_DEBUG) #1: Sun Sep 20 07:31:22 CEST 2015
r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP.AUDIO_DEBUG
real mem = 8168914944 (7790MB)
avail mem = 7917355008 (7550MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed840 (84 entries)
bios0: vendor Dell Inc. version "A05" date 07/14/2015
bios0: Dell Inc. XPS 13 9343
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT SSDT TPM2 SSDT
ASF! SSDT SSDT SSDT SSDT PCCT SSDT SSDT SSDT SLIC MSDM DMAR CSRT
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4)
PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4)
PXSX(S4) RP05(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.56 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.23 MHz
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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,
Re: audio codec RealTek ALC3263
On Sun, Sep 20, 2015 at 05:45:08PM +0200, Alexandre Ratchov wrote: > On Sat, Sep 19, 2015 at 10:59:53PM +0200, Remi Locherer wrote: > > azalia0 at pci0 dev 3 function 0 "Intel Core 5G HD Audio" rev 0x09: msi > > azalia_reset: resetting > > azalia_reset: reset counter = 5000 > > azalia_reset: reset counter = 5000 > > azalia0: host: High Definition Audio rev. 1.0 > > azalia0: host: 3 output, 0 input, and 0 bidi streams > > azalia0: found a codec at #0 > > azalia_init_corb: CORB allocation succeeded. > > azalia_init_corb: CORBWP=0; size=256 > > azalia_init_rirb: RIRB allocation succeeded. > > azalia_init_rirb: RIRBRP=0, size=256 > > azalia0: RIRB time out > > This could be caused by the no-snoop setting. Does this improve > things? > > Index: azalia.c > === > RCS file: /cvs/src/sys/dev/pci/azalia.c,v > retrieving revision 1.222 > diff -u -p -u -p -r1.222 azalia.c > --- azalia.c 29 Jul 2015 08:06:29 - 1.222 > +++ azalia.c 20 Sep 2015 15:41:40 - > @@ -460,6 +460,7 @@ azalia_configure_pci(azalia_t *az) > case PCI_PRODUCT_INTEL_9SERIES_HDA: > case PCI_PRODUCT_INTEL_9SERIES_LP_HDA: > case PCI_PRODUCT_INTEL_BAYTRAIL_HDA: > + case PCI_PRODUCT_INTEL_CORE5G_HDA_1: > reg = azalia_pci_read(az->pc, az->tag, > INTEL_PCIE_NOSNOOP_REG); > reg &= INTEL_PCIE_NOSNOOP_MASK; Should I try this patch after the result from the other patch after a cold boot? https://marc.info/?l=openbsd-misc&m=144277570223298&w=2
Re: Dualbooting with GRUB in a UEFI environment
On Mon, Feb 29, 2016 at 11:19:57AM -0600, joshua stein wrote: > On Mon, 29 Feb 2016 at 15:19:24 +0100, Noth wrote: > > Hi misc@, > > > > I just cracked this and it doesn't seem to be well documented so I thought > > I'd stick it here. > > > > My setup is a VAIO laptop dualbooting Ubuntu 16.04 and OpenBSD -CURRENT. > > I've got sd0a setup as a cryptoraid partition, so I needed a way to > > chainload into the OBSD bootloader to get a prompt to decrypt the partition. > > FWIW, I use rEFInd to manage EFI booting between OpenBSD, Linux, and > FreeBSD on my laptop: > > http://www.rodsbooks.com/refind/ > > Just putting the OpenBSD bootx64.efi file into /efi/openbsd/ will > allow rEFInd to find it and show an OpenBSD logo on boot: > > https://i.imgur.com/y2PHRFu.jpg > > This way OpenBSD does not depend on grub and Linux can do whatever > it wants to the grub config without locking me out of OpenBSD. > rEFInd can be configured by editing the /efi/refind/refind.conf file > but by default it will automatically find things. I'm also using refind for that purpose. Just make sure you copy the OpenBSD efi boot program to an other directory than /efi/boot as joshua suggested. Otherwise installers from other OSs will likely overwrite OpenBSD's efiboot. It would be nice if installboot(8) could do that: http://marc.info/?l=openbsd-tech&m=145396912725902&w=2 Remi
Re: dhclient.conf and hostname.if
On Fri, May 06, 2016 at 06:21:00AM -0600, Duncan Patton a Campbell wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Fri, 06 May 2016 12:06:58 +0100 > Mark Carroll wrote: > > > On 06 May 2016, Duncan Patton a. Campbell wrote: > > > > > Is there any similar tag to access the addess assigned by dhcp? > > > What other mechanisms exist to update dynamic dns assignments? > > > > Could ifstated(8) help here? I've separately wondered if I ought to be > > using it to kick pf because it otherwise doesn't realize that 'self' > > includes the address eventually assigned by PPP. > > > > -- Mark > > > > Yes. Looking at the man page this might be a way to do what I want. > ...just need to sort out the macro language in man ifstated.conf ;^) ifstated looks at the physical link of an interface. In ifconfig output this is the line starting with status. This state does not change when a new address is assigned to an interface. Remi
Re: dhclient.conf and hostname.if
On Fri, May 06, 2016 at 04:35:47AM -0600, Duncan Patton a Campbell wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > > Back when the script tag was removed from dhclient.conf the > functionality to do external commands was ostensibly moved > into hostname.if via the > > !command mechanism. > > in man hostname.if it says > > "It is worth noting that ``\$if'' in a command > line will be replaced by the interface name" > > Is there any similar tag to access the addess assigned by dhcp? > What other mechanisms exist to update dynamic dns assignments? You could write a script around "route monitor" (in a while loop) to get notified when you get a new address assigned to the interface. Another possibility is to use dhclient with option -L in combiantion with a tool like entr (in ports) to react on file changes. Remi
Re: internet connection issues
On Wed, Jun 22, 2016 at 03:05:56PM -0400, Sonic wrote: > Have a client whose Internet connection is less then reliable. It's > cable service and the cable company always claims there is nothing > wrong on their end. Of course the service is intermittent and by the > time the onsite clerk calls the ISP it's usually back up and always by > the time they get someone sent out. > > The problem is ongoing - it was a problem before I took over the > account, and is still a problem even though the previous firewall has > been replaced with a shiny OpenBSD box and the previous rented cable > modem has also been replaced with a shiny new Arris model (separated > by a few months). > > I discovered that when the problem occurs I (of course) cannot connect > to the firewall remotely, nor can I ping it. However I can ping the > gateway node. Which to me says the problem is between the ISP gateway > node and the cable modem. Two cable modems with the same issue lead me > to discount them as the problem, and two firewalls with the same > problem are a bit far fetched as well. Plus the OpenBSD firewall logs > no errors, either in dmesg or any other log file. > > I would like to be able to provide a way to document the outage no > matter when it occurs both via some job running on the firewall and a > job running remotely - to be positive that when the Internet cannot be > seen from the firewall the problem is at the suspected gateway node > and that at the same time the remote job can verify that the gateway > node can be seen but the firewall cannot, creating logs in both > systems only during the outage times. All of this possibly under the > mistaken idea that I can actually get WOW to repair their service. > > Would like some suggestions on ways to about this. smokeping could give you nice graphs for this.
Re: SSH key encryption when using FDE
On Mon, Aug 01, 2016 at 07:10:21PM -0300, Hugo Osvaldo Barrera wrote: > Hi, > > I've always used password-protected ssh keys, with ssh-agent, and in > recent year, I've been using full disk encryption as well. > I'm wondering if there's some redundancy here, and if using FDE > nullifies the need for password-protecting the keys, or if there's some > attack vector I'm no considering. > > Keep in mind that I using ssh-agent, and unlock the keys usually as a > first action after startup (I guess *not* using ssh-agent completely > changes the scenario). I still makes sense to encrypt your ssh keys. Think of a bug in a browser that allows a server reading your files. Remi
Re: Logging/backup .ksh_history
On Mon, Aug 08, 2016 at 11:22:33AM +0200, Kamil Cholewiński wrote: > On Mon, 08 Aug 2016, Francois Pussault wrote: > >> > >> From: Craig Skinner > >> Sent: Mon Aug 08 09:49:11 CEST 2016 > >> To: > >> Subject: Re: Logging/backup .ksh_history > >> > >> > >> Hi John, > >> > >> On 2016-08-08 Mon 14:39 PM |, johnw wrote: > >> > Hi, I use /bin/ksh as a console/terminal shell program, I want to > >> > log/backup all command, run on console/terminal/ksh, > >> > > >> > Any idea how to do this? > >> > > >> > >> See HISTFILE and HISTSIZE in ksh(1). > >> > >> Cheers, > >> -- > >> It isn't easy being a Friday kind of person in a Monday kind of world. > >> > > > > Using Ksh options is a good idea but that logs only the current user. > > > > a if you wanna get all actions even using successive multiples users with > > su, > > you might use a screen session to log absolute console instead of logging > > history. > > > > screen OPTIONS 2>&1 /var/log/screen.session.$$.$(date +%Y%m%d).log > > > > This is barbarian version but very usefull sometimes. > > Also try script(1). > > http://man.openbsd.org/OpenBSD-current/man1/script.1 Another option is sudo: https://www.sudo.ws/man/1.8.17/sudoers.man.html#I/O_LOG_FILES
Re: problem with IPSec between OpenBSD 5.5 and Cisco 2901
On Tue, Jun 17, 2014 at 05:34:27PM +0200, Sebastian Reitenbach wrote:
> Hi,
>
> I'm trying to establish an IPSec tunnel between an OpenBSD 5.5 (amd64)
> box and a Cisco 2901, the whole day, but doesn't seem to
> get it to work. I think I have something wrong with the
> crypto transforms for phase two, since this NO_PROPOSAL_CHOSEN
> I get in the logs, which I think is in phase two.
>
>
> Network looks similar to this one:
>
>
> Host behind OBSD (192.168.13.12/24)
> |
> |
> OBSD (XXX.191.219.14)
> |
> |
> Internet
> |
> |
> NAT FW (XXX.217.33.11)
> |
> |
> Internal Network
> |
> |
> Cisco 2901 (192.168.14.126)
> |
> |
> Host behind Cisco (192.168.13.19/24)
>
>
>
> Yes, they have both the same network behind each VPN Endpoints.
> Something, more or less the same we have up and running between
> two Cisco 2901.
How is this supposed to work with the same subnet on each site?
Do you add special routes on the hosts behind the VPN gateways?
The -L option from isakmpd helped me often to see what's happening.
>
>
> OpenBSD configuration:
>
>
> rem_gw="XXX.217.33.11"
> bb_gw="XXX.191.219.14"
>
> ike active esp from { 192.168.13.12 } to { 192.168.13.19 } \
> local $bb_gw peer $rem_gw \
> main auth hmac-sha1 enc aes-128 group modp1024 \
> quick auth hmac-md5 enc 3des group none \
> psk "SuperTopSecret"
>
>
>
> crypto isakmp policy 1
> encr aes
> authentication pre-share
> group 2
> crypto isakmp key SuperTopSecret address XXX.191.219.14 no-xauth
> crypto isakmp keepalive 30 5
>
> crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
>
> crypto map TO_BB 1 ipsec-isakmp
> set peer XXX.191.219.14
> set transform-set ESP-3DES-MD5
> match address 101
>
>
> interface GigabitEthernet0/1
> description outside-interface
> ip address 192.168.14.126 255.255.255.0
> duplex auto
> speed auto
> crypto map TO_BB
>
>
> access-list 101 permit ip host 192.168.13.12 host 192.168.13.19
>
>
> I think from the logs, see below, Phase one gets established, but then
> it runs into trouble with Phase 2, at least how I would interpret the logs:
>
> On the Cisco, status looks like:
>
>
> # show crypto isakmp sa
> IPv4 Crypto ISAKMP SA
> dst src state conn-id status
> 192.168.14.126 XXX.191.219.14 QM_IDLE 1442 ACTIVE
>
> IPv6 Crypto ISAKMP SA
>
> #show crypto ipsec sa
>
> interface: GigabitEthernet0/1
> Crypto map tag: TO_BBN, local addr 192.168.14.126
>
>protected vrf: (none)
>local ident (addr/mask/prot/port): (192.168.13.12/255.255.255.255/0/0)
>remote ident (addr/mask/prot/port): (192.168.13.19/255.255.255.255/0/0)
>current_peer XXX.191.219.14 port 500
> PERMIT, flags={origin_is_acl,}
> #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
> #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
> #pkts compressed: 0, #pkts decompressed: 0
> #pkts not compressed: 0, #pkts compr. failed: 0
> #pkts not decompressed: 0, #pkts decompress failed: 0
> #send errors 0, #recv errors 0
>
> local crypto endpt.: 192.168.14.126, remote crypto endpt.: XXX.191.219.14
> path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/1
> current outbound spi: 0x0(0)
> PFS (Y/N): N, DH group: none
>
> inbound esp sas:
>
> inbound ah sas:
>
> inbound pcp sas:
>
> outbound esp sas:
>
> outbound ah sas:
>
> outbound pcp sas:
>
> On the OpenBSD box it looks like:
> ipsecctl -s all
>
>
> FLOWS:
> No flows
>
> SAD:
> No entries
>
>
> isakmpd with isakmpd -d -D A=75 -K,
> after loading the configuration, trying to connect to the remote
> endpoint:
>
> 171646.650413 Timr 10 timer_handle_expirations: event ui_conn_reinit(0x0)
> 171646.650515 Misc 30 connection_reinit: reinitializing connection list
> 171646.650592 Timr 10 timer_add_event: event connection_checker(0x20f87dac0)
> added last, expiration in 0s
> 171646.650722 Misc 60 connection_record_passive: passive connection
> "from-192.168.13.12-to-192.168.13.19" added
> 171646.650811 Timr 10 timer_handle_expirations: event
> connection_checker(0x20f87dac0)
> 171646.650884 Timr 10 timer_add_event: event connection_checker(0x20f87dac0)
> added last, expiration in 60s
> 171646.650943 Sdep 70 pf_key_v2_connection_check: SA for
> from-192.168.13.12-to-192.168.13.19 missing
> 171646.651021 Trpt 70 transport_setup: added 0x2018f7680 to transport list
> 171646.651092 Trpt 70 transport_setup: added 0x2018f7280 to transport list
> 171646.651150 Trpt 70 transport_setup: virtual transport 0x2018f7b00
> 171646.651227 Timr 10 timer_add_event: event exchange_free_aux(0x2018f6e00)
> added last, expiration in 120s
> 171646.651288 Cryp 60 hash_get: requested algorithm 1
> 171646.651356 Exch 1
Re: Firewall cluster.
On Mon, Jul 07, 2014 at 08:44:43PM +0200, Mxher wrote: > Hello again, > > I'm doing few more tests and now I'm wondering if this is possible to > disallow CARP to have some resources on serverA and others on serverB? Have you set the sysctl net.inet.carp.preempt=1? > > Here is my tests (advbase=1 and advskew=0 for every interfaces on both > servers): advskew should be different on master from backkup. Try advskew=200 on obsd2. Please read man carp. The first example is exactly what you need. > * Initial state > root@obsd1:~# ifconfig HA |grep status > status: master > status: master > status: master > status: master > root@obsd2:~# ifconfig HA |grep status > status: backup > status: backup > status: backup > status: backup > > * I unplugged em2 and em3 on obsd2 and em1 on obsd1: > root@obsd1:~# ifconfig HA |grep status > status: master > status: invalid > status: master > status: master > root@obsd2:~# ifconfig HA |grep status > status: backup > status: master > status: invalid > status: invalid > > > obsd2 became master for em1 while obsd1 is master for everything else. > Is there any (proper and automatic) way to avoid that ? > > I know that kind of situation will not happens often but... > > > Thanks again! > > > Le 06/07/2014 13:13, Mxher a écrit : > > Le 06/07/2014 12:05, Otto Moerbeek a écrit : > >> On Sun, Jul 06, 2014 at 10:59:16AM +0200, Janne Johansson wrote: > >> > >>> The sysctl for carp.preempt controls if they should all fail at the same > >>> time. > >> > >> read carp(4). It contains answers to some questions asked. > >> > >>-Otto > >> > > > >>> Den 6 jul 2014 10:12 skrev "Adam Thompson" : > I recall someone pointing out that interface groups of carp interfaces > will all transition simultaneously. I find ifconfig(8) inconclusive; run > your own tests and if that works, you have a built-in solution for > keeping > all the carp interfaces in sync. > Then, use ifstated to manage the pppoe interfaces depending on ifstate of > the relevant wan interface? You could set up a carp interface with no IP > address bound, set it into the common if group and it would go up/down > with > the other carp ifs. > Maybe. I haven't tried anything like that myself. > -Adam > > > > I run some tests and this is working as expected! > > > > Only thing I see is that there will be no group failback if this is a > > virtual carp interface which goes down. > > > > To be clear if the parent interface of carp2 goes down the whole group > > will switch but not if carp2 goes down by itself (by an admin mistake > > for example): > > * initial states > > root@obsd1:~# sysctl -a|grep preem > > net.inet.carp.preempt=1 > > root@obsd1:~# ifconfig HA |grep status > > status: master > > status: master > > status: master > > status: master > > > > root@obsd2:~# sysctl -a|grep preem > > net.inet.carp.preempt=1 > > root@obsd2:~# ifconfig HA |grep status > > status: backup > > status: backup > > status: backup > > status: backup > > > > > > * states with carp2 down on obsd1 > > root@obsd1:~# ifconfig carp2 down > > root@obsd1:~# ifconfig HA |grep status > > status: master > > status: master > > status: invalid > > status: master > > > > root@obsd2:~# ifconfig HA |grep status > > status: backup > > status: backup > > status: master > > status: backup > > > > > > * also unfortunately when carp2 goes UP again on obsd1 it still remains > > on obsd2: > > root@obsd1:~# ifconfig carp2 up > > root@obsd1:~# ifconfig HA |grep status > > status: master > > status: master > > status: backup > > status: master > > > > root@obsd2:~# ifconfig HA |grep status > > status: backup > > status: backup > > status: master > > status: backup > > > > > > Anyway I think this is an acceptable risk. > > > > > > @Adam: I will now try to use ifstated to manage pppoe interfaces like > > you suggest. > > > > > > Thanks to everyone of you.
Re: Firewall: Where is the bottleneck?
On Tue, Oct 28, 2014 at 10:13:54PM +0100, jum...@yahoo.de wrote:
> Hi Andy,
>
> sorry for the delay, but a lot of more important work were between your mail
> and this answer ;).
>
> >You can set a simple prio on a rule like;
> >pass proto tcp from $left to $right set prio (1,4)
>
> With PRIQ I mean the scheduler priq instead of cbq.
>
> Relevant lines of my current pf.conf rule set.
>
>
> ...
> altq on em0 priq bandwidth 1000Mb queue { std_em0, tcp_ack_em0 }
> queue std_em0 priq(default)
> queue tcp_ack_em0 priority 6
>
> altq on em1 priq bandwidth 1000Mb queue { std_em1, tcp_ack_em1 }
> queue std_em1 priq(default)
> queue tcp_ack_em1 priority 6
>
> match em0 on em0 inet proto tcp from any to any queue(std_em0, tcp_ack_em0)
> match em0 on em1 inet proto tcp from any to any queue(std_em1, tcp_ack_em1)
> ...
>
>
> I have read The Book of PF 2nd, but there is nothing about troubleshooting.
> What should I do to find the problem?
>
> I have made some notes for troubleshooting purpose:
>
> top -> Interrupts -> High CPU or network interfaces => Hardware limit systat
> -> Interrupts on CPU and network cards => Hardware limit
> bwm-ng -> Bandwidth near the theoretical limit => Hardware limit
> pfctl -si -> Look for current states, default limit to 1. The memory
> counter shows failed allocation of memory for states. Is this number is high
> and increased further => Set limit for states (pfctl -sm -> shows States
> Limit)
> sysctl kern.netlivelocks -> High number means something like two processes
> blocks each user => Hardware limit
>
> No problem can be found with above steps:
Two more things you can check:
# netstat -m
If peak is close of equal to max raise kern.maxclusters with sysctl.
# sysctl net.inet.ip.ifq.drops
If this counter goes up try to increase net.inet.ip.ifq.maxlen with
sysctl. It defines how many packets can be queued in the ip input queue
before further packets are dropped.
Remi
> - prioritize TCP-ACK for tcp traffic
>
> Best Regards,
> Patrick
>
>
> On Thu, 9 Oct 2014, Andy wrote:
>
> >Hi,
> >
> >Just so I understand what you have done, PRIQ is not the same as queuing.
> >
> >You can set a simple prio on a rule like;
> >pass proto tcp from $left to $right set prio (1,4)
> >
> >But this doesn't manage the situations where you have lots of different
> >types/profiles of traffic on your network.
> >For example you might have some big file transfers going on which can be
> >delayed and can have a high latency but high throughput, alongside your
> >control/real-time protocols which need low latency etc.
> >Generally in this situation just using prio won't always be enough and
> >your file transfers will still swamp your Interactive SSH or VNC
> >connections etc..
> >
> >So we do something like this;
> >
> >altq on $if_trunk1 bandwidth 4294Mb hfsc queue { _wan }
> > oldqueue _wan on $if_trunk1 bandwidth 4290Mb priority 15 hfsc(linkshare
> >4290Mb, upperlimit 4290Mb) { _wan_rt, _wan_int, _wan_pri, _wan_vpn,
> >_wan_web, _wan_dflt, _wan_bulk }
> > oldqueue _wan_rt on $if_trunk1 bandwidth 20% priority 7 qlimit 50
> >hfsc(realtime(20%, 5000, 10%), linkshare 20%)
> > oldqueue _wan_int on $if_trunk1 bandwidth 10% priority 5 qlimit 100
> >hfsc(realtime 5%, linkshare 10%)
> > oldqueue _wan_pri on $if_trunk1 bandwidth 10% priority 4 qlimit 100
> >hfsc(realtime(15%, 2000, 5%), linkshare 10%)
> > oldqueue _wan_vpn on $if_trunk1 bandwidth 30% priority 3 qlimit 300
> >hfsc(realtime(15%, 2000, 5%), linkshare 30%)
> > oldqueue _wan_web on $if_trunk1 bandwidth 10% priority 2 qlimit 300
> >hfsc(realtime(10%, 3000, 5%), linkshare 10%)
> > oldqueue _wan_dflt on $if_trunk1 bandwidth 15% priority 1 qlimit
> >100 hfsc(realtime(10%, 5000, 5%), linkshare 15%, ecn, default)
> > oldqueue _wan_bulk on $if_trunk1 bandwidth 5% priority 0 qlimit 100
> >hfsc(linkshare 5%, upperlimit 30%, ecn, red)
> >
> >altq on $if_trunk2 bandwidth 4294Mb hfsc queue { _wan }
> > oldqueue _wan on $if_trunk2 bandwidth 4290Mb priority 15 hfsc(linkshare
> >4290Mb, upperlimit 4290Mb) { _wan_rt, _wan_int, _wan_pri, _wan_vpn,
> >_wan_web, _wan_dflt, _wan_bulk }
> > oldqueue _wan_rt on $if_trunk2 bandwidth 20% priority 7 qlimit 50
> >hfsc(realtime(20%, 5000, 10%), linkshare 20%)
> > oldqueue _wan_int on $if_trunk2 bandwidth 10% priority 5 qlimit 100
> >hfsc(realtime 5%, linkshare 10%)
> > oldqueue _wan_pri on $if_trunk2 bandwidth 10% priority 4 qlimit 100
> >hfsc(realtime(15%, 2000, 5%), linkshare 10%)
> > oldqueue _wan_vpn on $if_trunk2 bandwidth 30% priority 3 qlimit 300
> >hfsc(realtime(15%, 2000, 5%), linkshare 30%)
> > oldqueue _wan_web on $if_trunk2 bandwidth 10% priority 2 qlimit 300
> >hfsc(realtime(10%, 3000, 5%), linkshare 10%)
> > oldqueue _wan_dflt on $if_trunk2 bandwidth 15% priority 1 qlimit
> >100 hfsc(realtime(10%, 5000, 5%), linkshare 15%, ecn, default)
> > oldqueue _wan_bulk on $if_trunk2 bandwidth 5% priority 0 qlim
Re: 5.6 arrived
On Wed, Oct 29, 2014 at 04:54:26PM +0100, Harald Dunkel wrote: > Hi Oliver, > > On 10/28/14 14:23, Oliver Peter wrote: > > > > If the difference between release and snapshot is too confusing for > > you, you should probably just stay with release. If you need releases > > on time you should order a CD set next time. > > > > Of course I understand that there is a difference between snapshot > and release. 5.5 didn't recognize the network hardware, so I had to > use a snapshot. > > I got the CDs yesterday (by chance). > > > Any please don't try to install a current 5.6 snapshot and use it like > > it was a 5.6 release. Please don't do that. > > > > If I got Theo correctly then there is no such thing as a "5.6 snapshot", > but a snapshot built from the CVS development branch, which might include > some code for future releases beyond 5.7 or even purely experimental code. Theo gave a presentation about the release process: http://2009.asiabsdcon.org/live/abc2009-PT1.html This helps to understand this topic. Remi > Hopefully you agree that the file name "snapshots/amd64/install56.iso" > is misleading? Looking at the file name I had assumed/hoped there is some > kind of upgrade path from the "install56.iso" snapshot to the 5.6 release. > My mistake. > > > Regards > Harri
Re: unbound dnssec revisited
On Mon, Dec 30, 2013 at 03:22:34PM -0500, Ted Unangst wrote: > On Mon, Dec 30, 2013 at 12:10, Chris Smith wrote: > > I've been working on using dnssec with the unbound package and viewing > > some of the threads here on the list regarding this. > > > > Enabling autotrust and the validator module in unbound.conf and > > running unbound-anchor before starting unbound will enable dnssec but > > eventually will log errors of: > > > > could not open autotrust file for writing > > > > This is apparently because the _unbound user or group does not have > > write privileges to the directory, running unbound-anchor with "sudo > > -u _unbound" doesn't change the directory perms. > > That is on purpose. It's very bad for running daemons to have write > privileges. > > There are a couple solutions. More elaborately, it should use some > sort of privelege separation code to communicate with another daemon > if it needs to create new files after startup. > > More simply, can that file be moved to another location? Then we can > enable write permissions to /var/unbound/etc/autotrust/files/... or > something, without giving away the keys to the whole kingdom. Having the root.key in a separate directory works. My unbound.conf file: server: verbosity: 1 interface: 127.0.0.1 interface: ::1 root-hints: "named.cache" auto-trust-anchor-file: "/var/unbound/etc/autotrust/root.key" dlv-anchor-file: "dlv.isc.org.key" remote-control: control-enable: ye The directory structure and permissions: # find /var/unbound/etc -ls 18448664 drwxr-xr-x3 root wheel 512 Dec 30 23:43 /var/unbound/etc 18448674 -rw-r--r--1 root wheel 245 Dec 30 23:44 /var/unbound/etc/unbound.conf 18448704 -rw-r-1 root wheel1281 Feb 6 2011 /var/unbound/etc/unbound_server.key 18448714 -rw-r-1 root wheel1277 Feb 6 2011 /var/unbound/etc/unbound_control.key 18448978 -rw-r--r--1 root wheel3048 Nov 11 18:31 /var/unbound/etc/named.cache 18448734 -rw-r-1 root wheel 790 Feb 6 2011 /var/unbound/etc/unbound_server.pem 18448744 drwxr-xr-x2 _unbound _unbound 512 Dec 30 23:45 /var/unbound/etc/autotrust 18449074 -rw-r--r--1 _unbound _unbound 759 Dec 30 23:45 /var/unbound/etc/autotrust/root.key 18448754 -rw-r-1 root wheel 802 Feb 6 2011 /var/unbound/etc/unbound_control.pem 18448774 -rw-r--r--1 root wheel 386 Feb 6 2011 /var/unbound/etc/dlv.isc.org.key
Re: dhclient
Quoting Holger Glaess :
Am 30.01.2014 13:10, schrieb Giancarlo Razzolini:
Em 29-01-2014 18:13, Holger Glaess escreveu:
hi
i try to setup and multipath configuration with 2 line provider
1 cable with dhcp(client)
1 with pppoe
just dynamic ips.
the pppoe config create well the new default route with -math
but dhclient dont.
[snip pppoe config]
inet 0.0.0.0 255.255.255.255 NONE \
pppoedev msk0 authproto pap \
authname 'bla@blub' authkey 'blub' up
dest 0.0.0.1
!/sbin/route add -mpath default -ifp pppoe0 0.0.0.1
[/snip pppoe config]
after a couple of days i found that the dhclient not use the
dhclient-script since 5.3 anymore.
so how can i setup the -math option at the dhclient config ?
or it is possible to add some lines in dhclient that he check the
sysctl and , if net.inet.ip.multipath=1 ,
he add the default route with ( for ) multipathing.
holger
Check if your dhcp server always gives you the same router ip address.
If so, you can tweak with your dhclient.conf to reject and not ask for
routers, and then set it up manually as you do in your hostname.pppoe0.
And you can always run a script that is run after the dhcp negotiation,
looks for the gateway related entry, deletes it and then re-adds it with
the mpath modifier. There are a lot of options in this regard.
Cheers,
hi
shure , i can write a wrap around solution for the but this not the
"dynamic" way like
pppoe or dhcp to get and set ips.
i'm not the C programmer but i think it is not mutch work to add a
solution in dhclient,
or as option to reaktivate the dhclient-script part.
holger
You can get an event and trigger your acctions as before with the
dhclient-script
by watching changes in the routing table. Something like this might
work for you:
# route -n monitor | { while read l; do [[ $l = RTM_NEWADDR* ]] &&
echo do your stuff here; done }
USB Ethernet ASIX AX88179 not attaching to axen
I tried an Edimax USB Ethernet adapter on my -current system. It attaches as ugen1 but not as axen0: ugen1 at uhub3 port 2 "ASIX Elec. Corp. AX88179" rev 2.10/1.00 addr 3 According to axen(4) this device should be supported. But config does not find axen. Is this becaus usb is handled differently or is the driver not enabled yet? $ config -ef /bsd OpenBSD 5.5-current (GENERIC.MP) #25: Tue Mar 25 15:40:38 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Enter 'help' for information ukc> find axen ukc> quit Device details (lsusb) and dmesg: Bus 001 Device 003: ID 0b95:1790 ASIX Electronics Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.10 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0b95 ASIX Electronics Corp. idProduct 0x1790 bcdDevice1.00 iManufacturer 1 ASIX Elec. Corp. iProduct2 AX88179 iSerial 3 0002B5 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 248mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol 0 iInterface 4 Network_Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 11 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Status: 0x (Bus Powered) OpenBSD 5.5-current (GENERIC.MP) #25: Tue Mar 25 15:40:38 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8357658624 (7970MB) avail mem = 8126451712 (7749MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries) bios0: vendor LENOVO version "6QET61WW (1.31 )" date 10/26/2010 bios0: LENOVO 3626GN8 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! BOOT SSDT TCPA DMAR SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz, 1197.25 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 133MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.0, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz, 1197.01 MHz 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz, 1197.01 MHz 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,
Re: smokeping errors on OpenBSD 5.4
On Sat, Apr 05, 2014 at 10:37:40PM +0200, Thorleif Wiik [BCIX] wrote: > Hey all, > > just tried to run smokeping on OpenBSD 5.4, > but I have the following error after installing it with "pkg_add smokeping" > > # > > >smokeping --help > > > > > Can't load > '/usr/local/libdata/perl5/site_perl/amd64-openbsd/auto/RRDs/RRDs.so' for > module RRDs: Cannot load specified object at > /usr/libdata/perl5/amd64-openbsd/5.16.3/DynaLoader.pm line 190. > > at /usr/local/bin/../lib/Smokeping.pm line 15. > > Compilation failed in require at /usr/local/bin/../lib/Smokeping.pm line 15. > > BEGIN failed--compilation aborted at /usr/local/bin/../lib/Smokeping.pm > line 15. > > Compilation failed in require at /usr/local/bin/smokeping line 12. > > BEGIN failed--compilation aborted at /usr/local/bin/smokeping line 12. > # > > > Any tips on that ? Is the package "rrdtool" installed? It should since it's a depencensy of smokeping. > > > > Thanks, Thorleif
Re: Find last month abbreviation
On Fri, Apr 18, 2014 at 04:06:18PM +0200, Ingo Schwarze wrote: > Hi, > > lilit-aibolit wrote on Fri, Apr 18, 2014 at 03:24:36PM +0300: > > > $ date --date="last month" +%b > > Mar > > Time for a little shell golfing? > > Look, i'll play it nice and even add two blanks for readability. > > $ date -j +%b $(printf "%02d01" $(( ($(date +%m)+11)%12 ))) > Mar You don't like January? $ date -j +%b $(printf "%02d01" $(( (01+11)%12 ))) date: illegal time format usage: date [-aju] [-d dst] [-r seconds] [-t minutes_west] [-z output_zone] [+format] [[cc]yy]mm]dd]HH]MM[.SS]] My handicap doesn't allow do include a better version. ;)
Re: bgpd, announce to ibgp from 2 routers, prefixes only show up from 1
On Sat, Nov 13, 2021 at 12:11:08AM +, Stuart Henderson wrote:
> I have a pair of -current routers running bgpd (let's call them rtr-a
> and rtr-b) on a subnet which also has some vpn gateways and firewalls.
>
> These routers provide a carp address which the vpn gateways are using
> as default route. There are some networks behind the vpn gateways (a
> /32 to accept incoming vpn connections and some other prefixes that vpn
> clients are numbered from).
>
> rtr-a and rtr-b have static routes to those networks, and they have
> network statements in bgpd.conf to announce them to their ibgp peers
> ("network 172.24.232.0/21 set nexthop XXX" etc) so the paths are reachable
> from the rest of the network. (This is replacing an existing setup using
> ospf, trying to remove routing protocols from machines that don't really
> need them).
>
> It is working but something seems a little odd - the paths are announced
> from both routers briefly and show up on the rest of the network from
> both rtr-a and rtr-b. But after a few seconds, rtr-b receives these
> paths from rtr-a, and then rtr-b stops announcing them itself. (they
> stop showing in "bgpctl sh rib out" on rtr-b; "bgpctl sh nex" does
> correctly identify the associated nexthops as connected/UP).
>
> Is this expected/correct behaviour?
>
> I'd prefer to have them announced from both rtr-a and rtr-b, so there's
> no blackhole period if rtr-a is restarted while rtr-b figures out that
> it should start announcing them, etc. (No need for tracking carp state
> in this case, I'm not using stateful pf rules on the traffic involved).
>
> If rtr-b stops seeing the prefixes from rtr-a (either by taking down
> the ibgp session, or by filtering) I see the announcements from both
> rtr-a and rtr-b again. So the obvious workaround is to filter, but
> I thought I'd ask first in case it's something that is better handled
> by code changes rather than config.
>
This reminds me of the knob "bgp best external" on some routers.
Juniper:
https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/ref/sta
+tement/advertise-external-edit-protocols-bgp.html
Cisco:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/x
+e-17/irg-xe-17-book/bgp-best-external.html
The difference is that in your case it's an internal route
Remi
ipsec + mtu configuration
Hi misc@ We got notice from a customer who connects to us through an ipsec tunnel that loading websites on our site is really slow. On our site we use OpenBSD 5.0 i386 as ipsec gateway. On the other site of the VPN is a Linux StrongSwan gateway. Our analysis showed that our webserver starts sending packages with an mtu of 1500. The OpenBSD ipsec gateway then drops the package and returns an icmp unreachable "fragmentation needed" with mtu next hop set to 0. The webserver then starts again sending the packages but with mtu 576. As a workaround we added this to our pf rules: match on enc0 scrub (max-mss 1334) Searching the mailing list I found this thread which describes the same problem with a different workaround: http://marc.info/?l=openbsd-misc&m=133677069826075&w=2 Is there a recommended configuration that allows PMTU discovery? I tried to understand why the OpenBSD gateway returns a next-hop mtu 0. In ip_input.c I found the code that gets the mtu from the next interface (line 1579). But the enc0 interface has no mtu. There is a "#define ENCMTU 1536" in if_enc.h but that is not used in if_enc.c. RFC 1191 (Path MTU Discovery) chapter 4 says this about the Next-Hop MTU field in the ICMP message: To support the Path MTU Discovery technique specified in this memo, the router MUST include the MTU of that next-hop network in the low-order 16 bits of the ICMP header field that is labelled "unused" in the ICMP specification [7]. ... This field will never contain a value less than 68, since every router "must be able to forward a datagram of 68 octets without fragmentation" Remi
Re: ipsec + mtu configuration
Is there nobody with a config that allows pmtu discovery with ipsec? On Fri, Jul 06, 2012 at 04:49:31PM +0200, Remi Locherer wrote: > Hi misc@ > > We got notice from a customer who connects to us through an ipsec tunnel > that loading websites on our site is really slow. On our site we use > OpenBSD 5.0 i386 as ipsec gateway. On the other site of the VPN is a Linux > StrongSwan gateway. > > Our analysis showed that our webserver starts sending packages with an > mtu of 1500. The OpenBSD ipsec gateway then drops the package and > returns an icmp unreachable "fragmentation needed" with mtu next hop set > to 0. The webserver then starts again sending the packages but with mtu > 576. > > As a workaround we added this to our pf rules: > match on enc0 scrub (max-mss 1334) > > Searching the mailing list I found this thread which describes the same > problem with a different workaround: > http://marc.info/?l=openbsd-misc&m=133677069826075&w=2 > > Is there a recommended configuration that allows PMTU discovery? > > I tried to understand why the OpenBSD gateway returns a next-hop mtu 0. > In ip_input.c I found the code that gets the mtu from the next interface > (line 1579). But the enc0 interface has no mtu. There is a "#define ENCMTU > 1536" in if_enc.h but that is not used in if_enc.c. > > RFC 1191 (Path MTU Discovery) chapter 4 says this about the Next-Hop MTU > field in the ICMP message: > >To support the Path MTU Discovery >technique specified in this memo, the router MUST include the MTU of >that next-hop network in the low-order 16 bits of the ICMP header >field that is labelled "unused" in the ICMP specification [7]. >... >This field will never contain a value less than 68, since every >router "must be able to forward a datagram of 68 octets without >fragmentation" > > > Remi
Re: Suspect fragmented packets.
On Mon, Aug 06, 2012 at 12:54:48AM +0930, David Walker wrote: > Daniel Melameth wrote: > > When using pppoe(4), MSS can be a problem. I recommend you read the > > MTU/MSS ISSUES section of the man page and see if that resolves your > > issue. > > I have read and tried. > As far as I can see there's an issue with incoming packets. > AFAIUI, MSS will limit the size of outgoing. > I'd like to know the relationship between that and path MTU and what I > see as the apparent default block on ICMP in pf ... > Sending packets is one thing but if a distant host is unable to > determine the MTU for the next hop (to me) via ICMP then there's a > problem right? > Does setting MSS on PPP and therefore MTU affect this? > Do I need to explicitly allow ICMP to enable this behaviour? > The MSS field from your syn packages tells the other side what max package size you accept. I found this white paper helpful to understand MTU, PMTUD and MSS: http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml Remi
Re: softraid questions
Hi chris On Mon, Aug 20, 2012 at 07:53:25AM -0600, Chris Lobkowicz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Pardon the noise, but I'm wondering if softraid supports nested raid types? > > Specifically, I'm looking to do a raid 0+1 over 4 drives. A mirror of > stripes. > > wd1 & wd2 would be striped to stripe0 > wd3 & wd4 would be striped to stripe1 > > stripe0 would be mirrored to stripe1. > > > Is this even possible with bioctl? As far as I know this is not possible. But you can configure raid 1 with with 4 disks according to the man page. -Remi > > I'm currently assembling my hardware, and I would like to at least ask a > high-level question before digging into the low-level areas. > > > The reason I ask, is the softraid and bioctl man pages do not mention > nesting capabilities. Or, am I going about this the wrong way and should > I concatenate wd1+2 & wd3+3 and then mirror? > > I'm not looking to create a bomb-proof solution, just something to > create a little bit of fault tolerance in my home data store. > > And lastly, can I create my wd1+2 stripe, populate the data, then create > my second stripe & mirror and rebuild/cross pollinate? > > Thanks > Chris > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJQMkFVAAoJEFxdNdJhPdR3O2cH/28PHfw4ZNgHzjqNM0+IceAj > nxl/bN3j3B781FM6WzPDiApp4qBpn8MdaU13aVzBH5PYHszYKYBcSpfGuYWZxvt7 > gA1wkTQr7hwuMImLR4E5QoyeVY241xf/rET2e7uM7PXEQmz8TtziJV/SQkM+Dbvu > jtZzw9rgL5FkKU+uxXj0HFJtVGOQB3tI/tRoXQMoEmhaA2jfpwfK9Uc8L6/Prlvk > VSTP28x0EabiXAlXaaZhrrXWt5t7SppDo9IZlOl12+822C390IDFUHG3fvCOpJD9 > 6pDxq0lZxdl2aW8+vwIxF9vgVjsmlPsNQ1nMcYhiJ9IzIFfjbVqaGKZz67PF1JQ= > =0tGa > -END PGP SIGNATURE-
Re: softraid questions
On Mon, Aug 20, 2012 at 04:02:19PM +0200, Remi Locherer wrote: > Hi chris > > On Mon, Aug 20, 2012 at 07:53:25AM -0600, Chris Lobkowicz wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Pardon the noise, but I'm wondering if softraid supports nested raid types? > > > > Specifically, I'm looking to do a raid 0+1 over 4 drives. A mirror of > > stripes. > > > > wd1 & wd2 would be striped to stripe0 > > wd3 & wd4 would be striped to stripe1 > > > > stripe0 would be mirrored to stripe1. > > > > > > Is this even possible with bioctl? > > As far as I know this is not possible. But you can configure raid 1 with > with 4 disks according to the man page. It is possible but not officially supported: http://marc.info/?l=openbsd-misc&m=132412873715774&w=2 But I recommend you to just use raid 1.
problem setting inet6 route
Hi
I rented a server from Hetzner where I installed OpenBSD 5.1. Hetzner also
provides IPv6 but somehow with a strange setup. I got something like the
following from them:
Gateway Address: 2001:db8:1:1110::1/64
Subnet I can use: 2001:db8:1:/64
If I now assign for example 2001:db8:1::1/64 to the interface on my
server it doesn't let me set the default gateway becaus it's not in the
same subnet:
openbsd# ifconfig rl0 inet6 2001:db8:1::/64
openbsd# route add -inet6 default 2001:db8:1:1110::1
route: writing to routing socket: Network is unreachable
add net default: gateway 2001:db8:1:1110::1: Network is unreachable
For Linux they give these instructions:
linux# ip route add 2001:db8:1:1110::1 dev eth0
linux# ip route add default via 2001:db8:1:1110::1
I tried:
openbsd# route add -inet6 -iface 2001:db8:1:1110::1 2001:db8:1:::1
openbsd# route add -inet6 default 2001:db8:1:1110::1
But now it's not possible to ping6 2001:db8:1:1110::1 or any other IPv6
address.
In pf.conf I have the following rules and pflog shows no blocked
icmp6 traffic:
>block in log
>pass out log quick
>block log quick from
>pass log inet proto icmp icmp-type { echoreq, unreach }
>pass log inet6 proto icmp6
>pass in log on egress proto {tcp udp} to any port domain
>pass in log on egress proto tcp to any port ssh
How can I make this work?
Remi
Re: problem setting inet6 route
On Fri, Aug 31, 2012 at 09:22:06AM +, Stuart Henderson wrote: > On 2012-08-31, Remi Locherer wrote: > > I rented a server from Hetzner where I installed OpenBSD 5.1. Hetzner also > > provides IPv6 but somehow with a strange setup. I got something like the > > following from them: > > > > Gateway Address: 2001:db8:1:1110::1/64 > > Subnet I can use: 2001:db8:1:/64 > > > > If I now assign for example 2001:db8:1::1/64 to the interface on my > > server it doesn't let me set the default gateway becaus it's not in the > > same subnet: > > > > openbsd# ifconfig rl0 inet6 2001:db8:1::/64 > > openbsd# route add -inet6 default 2001:db8:1:1110::1 > > route: writing to routing socket: Network is unreachable > > add net default: gateway 2001:db8:1:1110::1: Network is unreachable > > > > For Linux they give these instructions: > > linux# ip route add 2001:db8:1:1110::1 dev eth0 > > linux# ip route add default via 2001:db8:1:1110::1 > > > > I tried: > > openbsd# route add -inet6 -iface 2001:db8:1:1110::1 2001:db8:1:::1 > > openbsd# route add -inet6 default 2001:db8:1:1110::1 > > > > But now it's not possible to ping6 2001:db8:1:1110::1 or any other IPv6 > > address. > > No idea if it will work, but you could try something like this > > route add -inet6 -mpath default -ifp rl0 2001:db8:1:1110::1 > Unfortunately this does not work. With this the link local address is used: openbsd# sysctl net.inet6.ip6.multipath=1 net.inet6.ip6.multipath: 0 -> 1 openbsd# route add -inet6 -mpath default -ifp rl0 2001:db8:1:1110::1 add net default: gateway 2001:db8:1:1110::1 openbsd# ping6 2001:db8:1:1110::1 PING6(56=40+8+8 bytes) 2001:db8:1:::78 --> 2001:db8:1:1110::1 ping6: sendmsg: No route to host ping6: wrote 2001:db8:1:1110::1 16 chars, ret=-1 ^C --- 2001:db8:1:1110::1 ping6 statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss openbsd# route -n get -inet6 2001:db8:1:1110::1 route to: 2001:db8:1:1110::1 destination: :: mask: default gateway: 2001:db8:1:1110::1 interface: rl0 if address: fe80::2e0:4cff:fec2:697c%rl0 priority: 8 (static) flags: use mtuexpire 24 0 0 root@typhoon#
Re: problem setting inet6 route
On Fri, Aug 31, 2012 at 04:27:50PM +0200, Claudio Jeker wrote: > On Fri, Aug 31, 2012 at 09:22:06AM +, Stuart Henderson wrote: > > On 2012-08-31, Remi Locherer wrote: > > > I rented a server from Hetzner where I installed OpenBSD 5.1. Hetzner also > > > provides IPv6 but somehow with a strange setup. I got something like the > > > following from them: > > > > > > Gateway Address: 2001:db8:1:1110::1/64 > > > Subnet I can use: 2001:db8:1:/64 > > > > > > If I now assign for example 2001:db8:1::1/64 to the interface on my > > > server it doesn't let me set the default gateway becaus it's not in the > > > same subnet: > > > > > > openbsd# ifconfig rl0 inet6 2001:db8:1::/64 > > > openbsd# route add -inet6 default 2001:db8:1:1110::1 > > > route: writing to routing socket: Network is unreachable > > > add net default: gateway 2001:db8:1:1110::1: Network is unreachable > > > > > > For Linux they give these instructions: > > > linux# ip route add 2001:db8:1:1110::1 dev eth0 > > > linux# ip route add default via 2001:db8:1:1110::1 > > > > > > I tried: > > > openbsd# route add -inet6 -iface 2001:db8:1:1110::1 2001:db8:1:::1 > > > openbsd# route add -inet6 default 2001:db8:1:1110::1 > > > > > > But now it's not possible to ping6 2001:db8:1:1110::1 or any other IPv6 > > > address. > > > > No idea if it will work, but you could try something like this > > > > route add -inet6 -mpath default -ifp rl0 2001:db8:1:1110::1 > > > > Bad adivece. Hetzner gave the wrong gateway or the wrong network. It is > funny that the Linux example they give is using proper network numbers. They're realy giving customers a gateway address that is not part of the clients subnet. http://wiki.hetzner.de/index.php/Zusaetzliche_IP-Adressen#Root-Server (german website) > In short, the gateway MUST be part of a connected route (network > configured on the interface) because ND or ARP for INET is needed to > figure out the MAC address to talk to that host on the L2 network. I found instructions for FreeBSD. There it is recommended to add static configuration for ndp. Since FreeBSD 8.3 they use /etc/rc.d/static_ndp for that. But I don't like it because I wouldn't reach my server when the routers mac changes. http://blog.vx.sk/archives/33-FreeBSD-Netzwerkkonfiguration-auf-Servern-von-Hetzner.html (german website) > > The only excpetion are point to point interfaces but those have a > destination IP on the interface and don't need a L2 address resolution > protocol. > -- > :wq Claudio
Re: problem setting inet6 route
On Fri, Aug 31, 2012 at 09:47:39AM -0400, Simon Perreault wrote: > (I rearranged your email: provider info at the top, your actions at > the bottom.) > > Le 2012-08-31 03:19, Remi Locherer a ?crit : > >I rented a server from Hetzner where I installed OpenBSD 5.1. Hetzner also > >provides IPv6 but somehow with a strange setup. I got something like the > >following from them: > > > >Gateway Address: 2001:db8:1:1110::1/64 > >Subnet I can use: 2001:db8:1:/64 > > > >For Linux they give these instructions: > >linux# ip route add 2001:db8:1:1110::1 dev eth0 > >linux# ip route add default via 2001:db8:1:1110::1 > > I would understand this to mean: > > a---[You]---b---[Them]---Internet Right except there is no network a. On [You] there is only one interface (rl0). > > a = 2001:db8:1:::/64 > b = 2001:db8:1:1110::/64 > > You on a = 2001:db8:1::: > You on b = 2001:db8:1:1110:: > Them on b = 2001:db8:1:1110::1 > > If you don't need a, don't configure it. > > >If I now assign for example 2001:db8:1::1/64 to the interface on my > >server it doesn't let me set the default gateway becaus it's not in the > >same subnet: > > > >openbsd# ifconfig rl0 inet6 2001:db8:1::/64 > >openbsd# route add -inet6 default 2001:db8:1:1110::1 > >route: writing to routing socket: Network is unreachable > >add net default: gateway 2001:db8:1:1110::1: Network is unreachable > > > >I tried: > >openbsd# route add -inet6 -iface 2001:db8:1:1110::1 2001:db8:1:::1 > >openbsd# route add -inet6 default 2001:db8:1:1110::1 > > > >But now it's not possible to ping6 2001:db8:1:1110::1 or any other IPv6 > >address. > > Yeah that's all wrong. Assuming that rl0 is on network b, try: > > ifconfig rl0 inet6 2001:db8:1:1110::2 > route add -inet6 default 2001:db8:1:1110::1 This works. But I have to figure out (ask Hetzner) if I'm the only customer they use 2001:db8:1:1110::/64 (I think so). Also over their web interface they only offer me to create DNS entries for 2001:db8:1:::/64.
Re: problem setting inet6 route
On Fri, Aug 31, 2012 at 09:01:44PM +0200, Joakim Aronius wrote: > * Remi Locherer (remi.loche...@relo.ch) wrote: > > Hi > > > > I rented a server from Hetzner where I installed OpenBSD 5.1. Hetzner also > > provides IPv6 but somehow with a strange setup. I got something like the > > following from them: > > > > Gateway Address: 2001:db8:1:1110::1/64 > > Subnet I can use: 2001:db8:1:/64 > > You could begin with actually getting real IPv6 addresses. 2001:DB8::/32 is a > reserved prefix for use in documentation. http://tools.ietf.org/html/rfc3849 > Do you really think that these addresses are the ones I got from the provider?
Re: problem setting inet6 route
On Sat, Sep 01, 2012 at 01:29:02PM -0700, Philip Guenther wrote: > On Fri, Aug 31, 2012 at 7:52 AM, Remi Locherer wrote: > > On Fri, Aug 31, 2012 at 09:47:39AM -0400, Simon Perreault wrote: > >> Le 2012-08-31 03:19, Remi Locherer a ?crit : > >> >I rented a server from Hetzner where I installed OpenBSD 5.1. Hetzner also > >> >provides IPv6 but somehow with a strange setup. I got something like the > >> >following from them: > >> > > >> >Gateway Address: 2001:db8:1:1110::1/64 > >> >Subnet I can use: 2001:db8:1:/64 > > > > This works. But I have to figure out (ask Hetzner) if I'm the only > > customer they use 2001:db8:1:1110::/64 (I think so). > > I think the question I would have asked them is > What does your box (2001:db8:1:1110::1) need in order for it to > figure out how to send packets for my network (2001:db8:1:::/64) > to my box? Does my box need to have a specific address or send > out router advertisements? > > I.e., how is is their box going to know get the ethernet address of > your box so that it can send the packets to it? I now got an answer from Hetzner: - I'm not allowed to use an address from the gateway subnet. They will block my traffic if I'm using such an address - They recommend that I configure a /59 prefix. In my opinion this makes no sense. I now configured a /63 prefix which contains my subnet and the gateway subnet (this works). They did not explain how their gateway is configured to send traffic to my host without configuring a specific address on my host. Remi
acceleration for softraid crypto
Hi
I'm running OpenBSD 4.9 on an Atom based system. On that system one disk is
encrypted using softraid. When I do "dd if=/dev/zero of=/dev/rsd0c bs=1m"
(sd0 is the encrypted softraid device) systat shows a speed of ~ 9200K and
90% sys cpu usage.
To speed up the encryption I'm looking at the vpn1411 card from soekris.
The hifn(4) man page tells me that this card is supported and the chip
(hifn 7955) accelerates AES-CBC.
Will this card help making softraid crypto faster on that system?
Regards,
Remi
dmesg:
OpenBSD 4.9 (GENERIC) #671: Wed Mar 2 07:09:00 MST 2011
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Atom(TM) CPU Z530 @ 1.60GHz ("GenuineIntel" 686-class) 1.60 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,D
S,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,xTPR,
PDCM,MOVBE
real mem = 2141278208 (2042MB)
avail mem = 2096115712 (1999MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 08/12/10, BIOS32 rev. 0 @ 0xf0010, SMBIOS
rev. 2.5 @ 0xfbe70 (18 entries)
bios0: vendor American Megatrends Inc. version "080015" date 08/12/2010
bios0: OpenVox IPC100
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET GSCI SSDT
acpi0: wakeup devices USB0(S4) USB1(S4) USB2(S4) EUSB(S4) POP4(S4) POP5(S4) LID_
(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 132MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (POP4)
acpiprt2 at acpi0: bus 2 (P2P6)
acpiprt3 at acpi0: bus 3 (POP5)
acpicpu0 at acpi0: PSS
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
acpibtn2 at acpi0: LID_
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD01
acpivout1 at acpivideo0: DD02
acpivout2 at acpivideo0: DD03
acpivout3 at acpivideo0: DD04
bios0: ROM list: 0xc/0xe600!
cpu0: Enhanced SpeedStep 1597 MHz: speeds: 1600, 1333, 1067, 800 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel US15W Host" rev 0x07
vga1 at pci0 dev 2 function 0 "Intel US15W Video" rev 0x07
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
intagp at vga1 not configured
ppb0 at pci0 dev 28 function 0 "Intel SCH PCIE" rev 0x07: apic 1 int 16 (irq 10)
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 "TI XIO2000A PCIE-PCI" rev 0x03
pci2 at ppb1 bus 2
rl0 at pci2 dev 2 function 0 "Realtek 8139" rev 0x10: apic 1 int 18 (irq 15), ad
dress a0:98:05:01:01:aa
rlphy0 at rl0 phy 0: RTL internal PHY
rl1 at pci2 dev 3 function 0 "Realtek 8139" rev 0x10: apic 1 int 19 (irq 5), add
ress a0:98:05:01:01:a9
rlphy1 at rl1 phy 0: RTL internal PHY
ral0 at pci2 dev 4 function 0 "Ralink RT2561S" rev 0x00: apic 1 int 16 (irq 10),
address 00:12:0e:61:53:e8
ral0: MAC/BBP RT2561C, RF RT5225
ppb2 at pci0 dev 28 function 1 "Intel SCH PCIE" rev 0x07: apic 1 int 17 (irq 11)
pci3 at ppb2 bus 3
re0 at pci3 dev 0 function 0 "Realtek 8168" rev 0x03: RTL8168D/8111D (0x2800), a
pic 1 int 17 (irq 5), address a0:98:05:01:ab:86
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2
uhci0 at pci0 dev 29 function 0 "Intel SCH USB" rev 0x07: apic 1 int 16 (irq 10)
ehci0 at pci0 dev 29 function 7 "Intel SCH USB" rev 0x07: apic 1 int 19 (irq 5)
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
pcib0 at pci0 dev 31 function 0 "Intel SCH LPC" rev 0x07
pciide0 at pci0 dev 31 function 1 "Intel SCH IDE" rev 0x07: DMA, channel 0 wired
to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA48, 476940MB, 976773168 sectors
wd1 at pciide0 channel 0 drive 1:
wd1: 1-sector PIO, LBA, 3823MB, 7831152 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 4
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 "Intel UHCI root hub" rev 1.00/1.00 addr 1
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
it0 at isa0 port 0x2e/2: IT8712F rev 8, EC port 0xa10
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
mtrr: Pentium Pro MTRR support
vscsi0 at root
scsibus0 at vscsi0: 256 targets
softraid0 at root
root on wd1a swap on wd1b dump on wd1b
Re: OpenLDAP
Hi Friedich It's in current: http://marc.info/?l=openbsd-ports&m=129440451210138&w=2 Regards, Remi On 01/11/2011 12:56 AM, Friedrich Locke wrote: Hi folks, is there plan for openbsd support openldap with recent version(s) of bdb ? Thanks in advance, Gustavo.
