Re: axen - need working USB NIC using axen to test driver change
* gwes [2020-05-03 19:10:35 -0400]: > Currently axen.c has its PHY address hardwired to 3. > I have a StarTech which has the PHY at 0. > The driver currently searches for all PHYs connected to the MII > and then ignores the result. > I want to test my fix on devices which work now. > > Can anyone point me to a USB NIC which works with axen? > thanks > Geoff Steckel > Hi Goeff, I have an USB axen(4) branded as amazon basics. It works. happy to test your diff! :) >From dmesg: axen0 at uhub0 port 12 configuration 1 interface 0 "ASIX Elec. Corp. AX88179" rev 3.00/1.00 addr 5 axen0: AX88179, address 00:50:b6:1c:1d:fa rgephy0 at axen0 phy 3: RTL8169S/8110S/8211 PHY, rev. 5 >From lsusb: Bus 000 Device 005: ID 0b95:1790 ASIX Electronics Corp. -- Pratik
SpeedTest-cli results accuracy ?
Hello all, First post here. So please be indulgent ;-)). My question is about the speedtest-cli tool and the tests results with OpenBsd.Let me explain. I have multiple machines - physical and virtual - mix of BSD and Linux - and I am in a process of rebuilding my Firewall - obviously with OpenBSD/PF. I have had an old Firewall using EdgeRouterLite which is broken now (no response from keyboard input using the console access - different story).With the ERL FW, when I increase the ISP contract speeds from 200/30 Mbps to 400/50 Mbps - doing a speed using any computer from the LAN did not pass over around ~220/35 Mbps. The provider provided a Zyxel (if this matters) which "acts temporarily" as the Firewall + DHCP, etc. Any speedtest from Linux, Windows (son's game computer) got around the 400 Mbps/50Mbps or more. The OpenBSD station (running 6.6) gets no more than 250 Mbps - the new Firewall I'm building shows the same results (see dmesg below) - no GUI for the 2 machines - using speedtest-cli. Following are the tests - machines - I ran with their respective results: - Lenovo ThinkCenter - OpenBSD 6.6 - speedtest-cli : ~230/37 Mbps- Future Firewall (acting as workstation for the test) - OpenBSD 6.6: around the same results- OpenBSD 6.6 running as VM on Manjaro Linux - around the same results - Manjaro Linux (Physical) hosting the OBSD VM - reach around or more the ~420/52 Mbps (using speedtest-cli and the Browser)- PFSense running as VM on Manjaro Linux - where I installed speedtest-cli - reach around the ~400/50 Mbps Even they are not the same tools (iperf vs speedtest-cli) - running iperf3 between OBSD vs OBSD/Linux and/or tcpbench, the tests display results close to 960 Mbps. So my question is can: I rely on the on the speedtest results? What else should I verify? Changing cables/direct connections to the current router were already done. Thanks for any inputs and clarification. Kanto dmesg for the future Router/Firewall OpenBSD 6.6 (GENERIC.MP) #8: Fri Apr 17 15:06:32 MDT 2020 r...@syspatch-66-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8489873408 (8096MB) avail mem = 8219873280 (7839MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec410 (83 entries) bios0: vendor American Megatrends Inc. version "5.6.5" date 06/30/2018 bios0: INTEL Corporation Q3XXG4-P acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! SSDT SSDT SSDT DMAR acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(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) i3-4030U CPU @ 1.90GHz, 1895.92 MHz, 06-45-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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) i3-4030U CPU @ 1.90GHz, 1895.62 MHz, 06-45-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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) i3-4030U CPU @ 1.90GHz, 1895.62 MHz, 06-45-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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) i3-4030U CPU @ 1.90GHz, 1895.62 MHz, 06-45-01 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES
Re: SpeedTest-cli results accuracy ?
Hello Kanto, speedtest-cli is horribly inaccurate in my experience. I used it when I first started using OpenBSD as a router and spent mor etime than I care to admit "troubleshooting" before realizing I was getting the correct speeds on devices on the network. To be fair, and since it has been a couple of years since I last tried it, I just installed it again and ran the test to see if the results were more accurate than in the past. My results were 260Mbit Down, and 82Mbit Up. I tested using the browser on my laptop via a wifi connection that uses the same router as the gateway, and got 380MBit Down, 240MBit Up. I am on Gigabit Fiber right now and can get >900MBit both ways when I'm hardwired. So don't make any assumptions on the routing speed capabilities of your hardware based on the results of that tool. On 5/5/20 8:47 PM, Kanto Andria wrote: Hello all, First post here. So please be indulgent ;-)). My question is about the speedtest-cli tool and the tests results with OpenBsd.Let me explain. I have multiple machines - physical and virtual - mix of BSD and Linux - and I am in a process of rebuilding my Firewall - obviously with OpenBSD/PF. I have had an old Firewall using EdgeRouterLite which is broken now (no response from keyboard input using the console access - different story).With the ERL FW, when I increase the ISP contract speeds from 200/30 Mbps to 400/50 Mbps - doing a speed using any computer from the LAN did not pass over around ~220/35 Mbps. The provider provided a Zyxel (if this matters) which "acts temporarily" as the Firewall + DHCP, etc. Any speedtest from Linux, Windows (son's game computer) got around the 400 Mbps/50Mbps or more. The OpenBSD station (running 6.6) gets no more than 250 Mbps - the new Firewall I'm building shows the same results (see dmesg below) - no GUI for the 2 machines - using speedtest-cli. Following are the tests - machines - I ran with their respective results: - Lenovo ThinkCenter - OpenBSD 6.6 - speedtest-cli : ~230/37 Mbps- Future Firewall (acting as workstation for the test) - OpenBSD 6.6: around the same results- OpenBSD 6.6 running as VM on Manjaro Linux - around the same results - Manjaro Linux (Physical) hosting the OBSD VM - reach around or more the ~420/52 Mbps (using speedtest-cli and the Browser)- PFSense running as VM on Manjaro Linux - where I installed speedtest-cli - reach around the ~400/50 Mbps Even they are not the same tools (iperf vs speedtest-cli) - running iperf3 between OBSD vs OBSD/Linux and/or tcpbench, the tests display results close to 960 Mbps. So my question is can: I rely on the on the speedtest results? What else should I verify? Changing cables/direct connections to the current router were already done. Thanks for any inputs and clarification. Kanto dmesg for the future Router/Firewall OpenBSD 6.6 (GENERIC.MP) #8: Fri Apr 17 15:06:32 MDT 2020 r...@syspatch-66-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8489873408 (8096MB) avail mem = 8219873280 (7839MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec410 (83 entries) bios0: vendor American Megatrends Inc. version "5.6.5" date 06/30/2018 bios0: INTEL Corporation Q3XXG4-P acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! SSDT SSDT SSDT DMAR acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(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) i3-4030U CPU @ 1.90GHz, 1895.92 MHz, 06-45-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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) i3-4030U CPU @ 1.90GHz, 1895.62 MHz, 06-45-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache
Re: SpeedTest-cli results accuracy ?
Hi Kanto, The Edgerouter Lite will not push much more than 200mbps, so that will certainly be a bottleneck. The only reason the ERlite can push 1Gbit with stock firmware is because of proprietary cut through routing and other garbage -- what they dont tell you is that as soon as you enable QoS or any fancy firewalling (or even IPv6!) you lose that hardware acceleration and all forwarding/packet handling is done purely on the CPU. With regards to speedtest-cli, those results are not accurate. The only way to be sure it to use something like tcpbench and test it against multiple locations (I usually spin up a few vultr VPS in various locations to confirm my speeds for example). Also, I'm sure you already know this, but you also should never run the benchmarking program on your router, as that will obviously skew the results. Cheers, Jordan On 2020-05-05 17:47, Kanto Andria wrote: Hello all, First post here. So please be indulgent ;-)). My question is about the speedtest-cli tool and the tests results with OpenBsd.Let me explain. I have multiple machines - physical and virtual - mix of BSD and Linux - and I am in a process of rebuilding my Firewall - obviously with OpenBSD/PF. I have had an old Firewall using EdgeRouterLite which is broken now (no response from keyboard input using the console access - different story).With the ERL FW, when I increase the ISP contract speeds from 200/30 Mbps to 400/50 Mbps - doing a speed using any computer from the LAN did not pass over around ~220/35 Mbps. The provider provided a Zyxel (if this matters) which "acts temporarily" as the Firewall + DHCP, etc. Any speedtest from Linux, Windows (son's game computer) got around the 400 Mbps/50Mbps or more. The OpenBSD station (running 6.6) gets no more than 250 Mbps - the new Firewall I'm building shows the same results (see dmesg below) - no GUI for the 2 machines - using speedtest-cli. Following are the tests - machines - I ran with their respective results: - Lenovo ThinkCenter - OpenBSD 6.6 - speedtest-cli : ~230/37 Mbps- Future Firewall (acting as workstation for the test) - OpenBSD 6.6: around the same results- OpenBSD 6.6 running as VM on Manjaro Linux - around the same results - Manjaro Linux (Physical) hosting the OBSD VM - reach around or more the ~420/52 Mbps (using speedtest-cli and the Browser)- PFSense running as VM on Manjaro Linux - where I installed speedtest-cli - reach around the ~400/50 Mbps Even they are not the same tools (iperf vs speedtest-cli) - running iperf3 between OBSD vs OBSD/Linux and/or tcpbench, the tests display results close to 960 Mbps. So my question is can: I rely on the on the speedtest results? What else should I verify? Changing cables/direct connections to the current router were already done. Thanks for any inputs and clarification. Kanto dmesg for the future Router/Firewall OpenBSD 6.6 (GENERIC.MP) #8: Fri Apr 17 15:06:32 MDT 2020 r...@syspatch-66-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8489873408 (8096MB) avail mem = 8219873280 (7839MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec410 (83 entries) bios0: vendor American Megatrends Inc. version "5.6.5" date 06/30/2018 bios0: INTEL Corporation Q3XXG4-P acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! SSDT SSDT SSDT DMAR acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(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) i3-4030U CPU @ 1.90GHz, 1895.92 MHz, 06-45-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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) i3-4030U CPU @ 1.90GHz, 1895.62 MHz, 06-45-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 2
filter-dkimsign and multiple domains
I saw the recent thread regarding multiple domains and filter-dkimsign. I just wanted to add in my $.02 that I prefer to have as much proof-of-work as reasonable since it seems, at least a little, to help with inboxing at the oligopoly providers. The trend for them to direct legitimate mail to spam filters has been notching up year-by-year, and having the domain of the DKIM signature match the from address seems like an easy check for them to perform. My purpose for filter-dkimsign is on a webserver that sends transactional email for several domains. A solution that would work for me does not have to be complex or feature-rich. For example, if there were an option to sign with whatever domain is in the from address (everything after '@'), that would be perfect. In any case, thank you for the very easy to implement DKIM signing solution. Paul
Re: pkg_add -u: no such dir
Jan Betlach @ 2020-05-05 17:05 IST: > Is 6.7 being released already? No, they're probably using a snapshot. signature.asc Description: PGP signature
Re: filter-dkimsign and multiple domains
On 5/5/20 7:15 PM, Paul N. Pace wrote: > I saw the recent thread regarding multiple domains and filter-dkimsign. > > I just wanted to add in my $.02 that I prefer to have as much > proof-of-work as reasonable since it seems, at least a little, to help > with inboxing at the oligopoly providers. The trend for them to direct > legitimate mail to spam filters has been notching up year-by-year, and > having the domain of the DKIM signature match the from address seems > like an easy check for them to perform. > > My purpose for filter-dkimsign is on a webserver that sends > transactional email for several domains. > > A solution that would work for me does not have to be complex or > feature-rich. For example, if there were an option to sign with whatever > domain is in the from address (everything after '@'), that would be perfect. > > In any case, thank you for the very easy to implement DKIM signing solution. > > Paul > You've read the threat so you know my position and you know what it would take for me to change my mind, yet you come here with a feature- request that's actually worth what you priced it. Your request *IS* complex and it *IS* feature-rich if you actually took the time to work out the details of what you're asking. If I'm wrong in that show me your diff and we'll talk. martijn@
Re: 10Gbps X520 network adapter only passing 3.5Gbps
On 2020-05-04, Kalle Kadakas wrote: > Greetings OpenBSD community, > > I am running into severe bandwidth limitations whilst passing traffic > through an OpenBSD firewall. > The NIC in use is an Intel 10Gb 2-port X520 adapter from which I would > hope to pass through at least 7Gbps+, yet the best results I have > gotten is only around 3.5Gbps. > > The results of bandwidth measurements (iperf for 30sec, lacp trunk is > 2x10 Gbps, without carp means that the IP was moved on top of VLAN > direcly): > PF+carp+isakmpd+lacp = 2.03 Gbits/sec > PF+isakmpd+lacp = 2.88 Gbits/sec > PF+lacp = 2.53 Gbits/sec > lacp = 2.90 Gbits/sec > W/O LACP single direct 10 Gbps link to OpenBSD box = 3.44 Gbits/sec Are you measuring iperf running on the router itself? Because that won't tell you anything about forwarding performance. I don't know what you'll see (definitely don't expect wirespeed and to be honest I'll be pretty surprised if you get 7Gb) but performance for routing is usually higher than performance for sending traffic from the machine itself. > In the full setup the interface hierarchy goes like this: > ix0+ix1 > trunk0 > vlanXXX > carpXXX Since you use LACP, you can try the newer aggr(4) interface instead of trunk(4), it may help a bit. > Tested the bandwidth also with 1, 2, 4 cores but that did not change > the results for the better (left it at 4). OpenBSD only makes partial use of multiple cores for now.
Re: pkg_add -u: no such dir
Thanks. My bad, I’ve realized that as soon as I’ve hit the send button. On 5 May 2020, at 17:19, Andinus wrote: > Jan Betlach @ 2020-05-05 17:05 IST: > >> Is 6.7 being released already? > > No, they're probably using a snapshot.
Re: pf table for all publicly routable ipv4 addresses
On Mon, May 4, 2020 at 4:43 PM Marko Cupać wrote: > ...so I can permit hosts on guest vlan access Internet hosts, but not > hosts on other private vlans similar to: > > block log all > pass in on $guest_vlan from $guest_vlan:network to > I suspect the best path forward here is: block log all pass in on $guest_vlan from $guest_vlan:network to ! Then make a table that's like , but also including your other vlan subnets you don't want guests to be able to reach. Each entry added to a table is implicitly an 'or'. So adding A and B to means that you get a match if you check for A, or you check for B. And adding !A and !B means that matches if it's not A, OR not B. A satisfies '!B' so that matches, B satisfies '!A' so that matches, and indeed anything else also matches. So using ! *inside* a table definition rarely does what you intend. Using ! , however, is fine and should do what you want. -ken
Re: pkg_add -u: no such dir
Is 6.7 being released already? Jan On 5 May 2020, at 13:28, Groot wrote: > I tried updating all applications, only to be greeted with > the following message. > > doas pkg_add -u > https://ftp.OpenBSD.org/pub/OpenBSD/6.7/packages/amd64/: no such dir > list of applications > > I'm sure someone must have noticed by now. > Only the directories within https://ftp.OpenBSD.org/pub/OpenBSD/6.7/ > give 404 Not found error in a browser.
Re: OSPF lsa_check issue
Hi,
We have sent the pcap directly for the raw packets.
In terms of the above change, we haven't compiled ospf previously, we will
give it a go and see how we get on.
Are we ok to clone off the github mirror?
Cheers
Richard
On Tue, May 5, 2020 at 10:22 AM Claudio Jeker
wrote:
> On Tue, May 05, 2020 at 10:51:40AM +0200, Claudio Jeker wrote:
> > On Tue, May 05, 2020 at 09:07:34AM +0100, Richard Chivers wrote:
> > > After some more work this morning we have managed to extract the
> > > information from tcpdump of the full LS-Update packet, we couldn't see
> it
> > > on bsd, but running:
> > >
> > > tcpdump -v -r ~/Downloads/ospf.pcap on osx did the trick.
> > >
> > > What we are seeing is that a pair of firewalls are both sending updates
> > > like this:
> > >
> > > 07:16:09.346525 IP (tos 0xc0, ttl 1, id 47473, offset 0, flags [+],
> proto
> > > OSPF (89), length 1500)
> > > x.x.x.x > ospf-dsig.mcast.net: OSPFv2, LS-Update, length 1480
> [len 1672]
> > > Router-ID x.x.x.x, Backbone Area, Authentication Type: simple (1)
> > > Simple text password: dslkfjld, 1 LSA
> > > LSA #1
> > > Advertising Router x.x.x.x, seq 0x806e, age 0s, length 1624
> > >Router LSA (1), LSA-ID: x.x.x.x
> > >Options: [External]
> > >Router LSA Options: [ASBR]
> > > Stub Network: 10.128.32.128, Mask: 255.255.255.128
> > > topology default (0), metric 10
> > > Stub Network: 10.128.9.0, Mask: 255.255.255.128
> > > *{ another 50 or so networks here}*
> > >
> > > Each time we get one of these updates the DR logs the lsa_check: bad
> age.
> > >
> > > Another 5 or so seconds later the same LS-Update comes in with the
> same seq
> > > number. This appears to continue indefinitely. Our only fix appears to
> be
> > > restarting ospfd on the routers.
> > >
> > > Does anyone have an idea what is going wrong here?
> > >
> > > Something we have considered being a problem is that we do have many
> > > interfaces, we have 90 or so, so the LS-Update packets are quite large
> and
> > > do get fragmented, as we are using a 1500mtu.
> > >
> > > The fact that ospfd sees the age and complains though makes us think
> this
> > > is not a problem.
> > >
> >
> > Looking at the tcpdump output there is something strange with the various
> > reported length fields. Is it possible to get the raw packet dumps?
> >
>
> Can you try the following diff and see if it fixes the issue?
>
> --
> :wq Claudio
>
> Index: lsupdate.c
> ===
> RCS file: /cvs/src/usr.sbin/ospfd/lsupdate.c,v
> retrieving revision 1.47
> diff -u -p -r1.47 lsupdate.c
> --- lsupdate.c 19 Nov 2019 09:55:55 - 1.47
> +++ lsupdate.c 5 May 2020 09:20:50 -
> @@ -186,7 +186,7 @@ add_ls_update(struct ibuf *buf, struct i
> return (0);
> }
>
> - lsage = ibuf_reserve(buf, 0);
> + lsage = ibuf_reserve(buf, len);
> if (ibuf_add(buf, data, len)) {
> log_warn("add_ls_update");
> return (0);
>
Re: pkg_add -u: no such dir
Hi, Groot wrote on Tue, May 05, 2020 at 04:58:34PM +0530: > I tried updating all applications, only to be greeted with > the following message. You don't say so explicitly, but let's assume you upgraded to the latest snapshot. While that is not the final 6.7 release yet, the operating system release string as returned by "uname -r" was already switched to "6.7" (without -beta) in preparation for release, so your upgraded system already tries to use 6.7 release packages, which do not exist yet. > doas pkg_add -u > https://ftp.OpenBSD.org/pub/OpenBSD/6.7/packages/amd64/: no such dir > list of applications > > I'm sure someone must have noticed by now. > Only the directories within https://ftp.OpenBSD.org/pub/OpenBSD/6.7/ > give 404 Not found error in a browser. That's expected. For now, use "pkg_add -u -D snap" as documented here: https://man.openbsd.org/pkg_add.1#snap Yours, Ingo
Re: OSPF lsa_check issue
On Tue, May 05, 2020 at 10:51:40AM +0200, Claudio Jeker wrote:
> On Tue, May 05, 2020 at 09:07:34AM +0100, Richard Chivers wrote:
> > After some more work this morning we have managed to extract the
> > information from tcpdump of the full LS-Update packet, we couldn't see it
> > on bsd, but running:
> >
> > tcpdump -v -r ~/Downloads/ospf.pcap on osx did the trick.
> >
> > What we are seeing is that a pair of firewalls are both sending updates
> > like this:
> >
> > 07:16:09.346525 IP (tos 0xc0, ttl 1, id 47473, offset 0, flags [+], proto
> > OSPF (89), length 1500)
> > x.x.x.x > ospf-dsig.mcast.net: OSPFv2, LS-Update, length 1480 [len 1672]
> > Router-ID x.x.x.x, Backbone Area, Authentication Type: simple (1)
> > Simple text password: dslkfjld, 1 LSA
> > LSA #1
> > Advertising Router x.x.x.x, seq 0x806e, age 0s, length 1624
> >Router LSA (1), LSA-ID: x.x.x.x
> >Options: [External]
> >Router LSA Options: [ASBR]
> > Stub Network: 10.128.32.128, Mask: 255.255.255.128
> > topology default (0), metric 10
> > Stub Network: 10.128.9.0, Mask: 255.255.255.128
> > *{ another 50 or so networks here}*
> >
> > Each time we get one of these updates the DR logs the lsa_check: bad age.
> >
> > Another 5 or so seconds later the same LS-Update comes in with the same seq
> > number. This appears to continue indefinitely. Our only fix appears to be
> > restarting ospfd on the routers.
> >
> > Does anyone have an idea what is going wrong here?
> >
> > Something we have considered being a problem is that we do have many
> > interfaces, we have 90 or so, so the LS-Update packets are quite large and
> > do get fragmented, as we are using a 1500mtu.
> >
> > The fact that ospfd sees the age and complains though makes us think this
> > is not a problem.
> >
>
> Looking at the tcpdump output there is something strange with the various
> reported length fields. Is it possible to get the raw packet dumps?
>
Can you try the following diff and see if it fixes the issue?
--
:wq Claudio
Index: lsupdate.c
===
RCS file: /cvs/src/usr.sbin/ospfd/lsupdate.c,v
retrieving revision 1.47
diff -u -p -r1.47 lsupdate.c
--- lsupdate.c 19 Nov 2019 09:55:55 - 1.47
+++ lsupdate.c 5 May 2020 09:20:50 -
@@ -186,7 +186,7 @@ add_ls_update(struct ibuf *buf, struct i
return (0);
}
- lsage = ibuf_reserve(buf, 0);
+ lsage = ibuf_reserve(buf, len);
if (ibuf_add(buf, data, len)) {
log_warn("add_ls_update");
return (0);
Re: OSPF lsa_check issue
On Tue, May 05, 2020 at 09:07:34AM +0100, Richard Chivers wrote:
> After some more work this morning we have managed to extract the
> information from tcpdump of the full LS-Update packet, we couldn't see it
> on bsd, but running:
>
> tcpdump -v -r ~/Downloads/ospf.pcap on osx did the trick.
>
> What we are seeing is that a pair of firewalls are both sending updates
> like this:
>
> 07:16:09.346525 IP (tos 0xc0, ttl 1, id 47473, offset 0, flags [+], proto
> OSPF (89), length 1500)
> x.x.x.x > ospf-dsig.mcast.net: OSPFv2, LS-Update, length 1480 [len 1672]
> Router-ID x.x.x.x, Backbone Area, Authentication Type: simple (1)
> Simple text password: dslkfjld, 1 LSA
> LSA #1
> Advertising Router x.x.x.x, seq 0x806e, age 0s, length 1624
>Router LSA (1), LSA-ID: x.x.x.x
>Options: [External]
>Router LSA Options: [ASBR]
> Stub Network: 10.128.32.128, Mask: 255.255.255.128
> topology default (0), metric 10
> Stub Network: 10.128.9.0, Mask: 255.255.255.128
> *{ another 50 or so networks here}*
>
> Each time we get one of these updates the DR logs the lsa_check: bad age.
>
> Another 5 or so seconds later the same LS-Update comes in with the same seq
> number. This appears to continue indefinitely. Our only fix appears to be
> restarting ospfd on the routers.
>
> Does anyone have an idea what is going wrong here?
>
> Something we have considered being a problem is that we do have many
> interfaces, we have 90 or so, so the LS-Update packets are quite large and
> do get fragmented, as we are using a 1500mtu.
>
> The fact that ospfd sees the age and complains though makes us think this
> is not a problem.
>
Looking at the tcpdump output there is something strange with the various
reported length fields. Is it possible to get the raw packet dumps?
--
:wq Claudio
Re: OSPF lsa_check issue
On Tue, May 05, 2020 at 09:07:34AM +0100, Richard Chivers wrote: > Another 5 or so seconds later the same LS-Update comes in with the same seq > number. This appears to continue indefinitely. Our only fix appears to be > restarting ospfd on the routers. > > Does anyone have an idea what is going wrong here? > > Something we have considered being a problem is that we do have many > interfaces, we have 90 or so, so the LS-Update packets are quite large and > do get fragmented, as we are using a 1500mtu. > Can you give more details about your network ? (config, number of speakers, number of routes ?) I could not reproduce it. Yet, I have a similar problem with ospf6d. I don't understand the details but changing prepare_ls_update() has an impact.
Re: OSPF lsa_check issue
After some more work this morning we have managed to extract the
information from tcpdump of the full LS-Update packet, we couldn't see it
on bsd, but running:
tcpdump -v -r ~/Downloads/ospf.pcap on osx did the trick.
What we are seeing is that a pair of firewalls are both sending updates
like this:
07:16:09.346525 IP (tos 0xc0, ttl 1, id 47473, offset 0, flags [+], proto
OSPF (89), length 1500)
x.x.x.x > ospf-dsig.mcast.net: OSPFv2, LS-Update, length 1480 [len 1672]
Router-ID x.x.x.x, Backbone Area, Authentication Type: simple (1)
Simple text password: dslkfjld, 1 LSA
LSA #1
Advertising Router x.x.x.x, seq 0x806e, age 0s, length 1624
Router LSA (1), LSA-ID: x.x.x.x
Options: [External]
Router LSA Options: [ASBR]
Stub Network: 10.128.32.128, Mask: 255.255.255.128
topology default (0), metric 10
Stub Network: 10.128.9.0, Mask: 255.255.255.128
*{ another 50 or so networks here}*
Each time we get one of these updates the DR logs the lsa_check: bad age.
Another 5 or so seconds later the same LS-Update comes in with the same seq
number. This appears to continue indefinitely. Our only fix appears to be
restarting ospfd on the routers.
Does anyone have an idea what is going wrong here?
Something we have considered being a problem is that we do have many
interfaces, we have 90 or so, so the LS-Update packets are quite large and
do get fragmented, as we are using a 1500mtu.
The fact that ospfd sees the age and complains though makes us think this
is not a problem.
Cheers
Richard
On Mon, May 4, 2020 at 6:12 PM Richard Chivers
wrote:
> Hi,
>
> Following on from the OSPF issue we were seeing in 5.8, we have built a
> vagrant lab with a complete replica of our production network in order to
> test config against 6.6 (latest syspatch applied) and test a number of
> scenarios.
>
> All in all everything has gone well, and other than some minor config
> enhancements, everything is fundamentally working.
>
> The original issue we had was routes not being advertised beyond the DR,
> when there were situations like a network blip or restart of the ospf
> process on another router/firewall.
>
> Since moving to 6.6 we have been able to recreate the same situation we
> have had in production, we do this by doing a "rcctl restart ospfd" on the
> DR, typically a few times.
>
> Eventually other routers start logging as follows:
>
> May 4 15:44:19 va-l1-tun ospfd[75371]: lsa_check: bad age
> May 4 15:44:19 va-l1-tun ospfd[75371]: lsa_check: bad age
> May 4 15:44:24 va-l1-br-02 ospfd[27625]: lsa_check: bad age
> May 4 15:44:24 va-l1-br-02 ospfd[27625]: lsa_check: bad age
> May 4 15:44:24 1 va-l1-tun ospfd[75371]: lsa_check: bad age
>
> If we run a tcpdump using tcpdump -i vio0 -s 1500 -w /tmp/ospf.pcap proto
> ospf, we can then see the ospf hello packets fully in wireshark, but the LS
> update packets are fragmented so we can not see the full detail or what is
> being passed from the relevant neighbor.
>
> We have tried to increase the verbosity of logging using "ospfctl log
> verbose", but still we are unsure which lsa update is incorrect.
>
> The only way we have found to stop these logs from appearing is to "rcctl
> restart ospfd" on various boxes until it stops.
>
> What we are hoping for help with is diagnosing exactly which record has
> the lsa_check: bad age, and understanding whether this should in effect
> clear itself for example.
>
> We have looked at the source code, but do not fully understand the flow
> beyond the check itself in lsa_check.
>
> We are wondering if there is something fundamentally wrong with our
> config, but it is pretty simple. Effectively a set of connected routers in
> a single area with one of the hops having a backup across the internet with
> a GRE tunnel. At most we are only ever 3 hops away between a source and
> destination.
>
> We have also on occasion seen "seq num mismatch, bad flags" messages, but
> these have appeared to clear themselves.
>
> Thanks
>
