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
How can I remove sets installed by sysupgrade?
Thanks to the OpenBSD team for their awesome software! I have been running an Openbsd router for a few years now, mostly following current. Today I decided to try out sysupgrade rather than going through the usual manual process. I've read up on it a few times and it seemed pretty straightforward. I ran it and found too late that it installed all the x*, Comp and Game sets, which were not part of the original install. Unfortunately this overfilled my /usr partition and I'm getting errors on boot. Is there a simple way to uninstall these sets? I need the space but would much rather not start over from scratch. I did find an email (too late) on this list about how there is no way to tell sysupgrade to just upgrade an existing system without adding everything else too. As a grateful user of free software I would also like to ask, is that an option that might find its way into the system sometime? Thanks, Judah
Re: How can I remove sets installed by sysupgrade?
Thanks for the replies and ideas. I was introduced to OpenBSD after an acquaintance had their home router compromised in 2016 and I started looking into network hardening/security. In my research trying to find the best firewall that didn't require purchasing commercial hardware/licensing I found PF and OpenBSD so I started learning. My reasoning behind NOT installing the X, Comp and Game sets have little to do with saving space, although I am using an 8GB SSD. I learned in my research that one of the most fundamental ways to improve network/system security is to minimize the attack surface by not installing unneeded software. If it isn't installed, any potential vulnerabilities, known or not, are irrelevant. My router is headless. I have never run into an issue where I have needed anything from the X sets, and don't compile anything from source so I don't need that, and I certainly don't play games on it so I don't need that either. Therefore it seems like sound logic to not have those bits and bytes present on the system so any mis-configurations/bugs/vulnerabilities cannot impact my network security. I am running a couple of OpenVPN servers which some friends and family rely on, using DNSCrypt-Proxy, experimenting with Wireguard, playing around with certificates and authentication, and since I use a variety of automation/embedded devices which have dubious or no security of their own I rely on my firewall to prevent them from "phoning home" if they come or become compromised. I've slowly built my pf.conf, tables and anchors to a point I'm pretty happy with. I also have experimented with running OpenBSD with a read-only filesystem as just another layer of defense and annoyance for any potential invader although I'm not currently doing so. I'm sure with my limited although always expanding knowledge that there are still many ways my network could be compromised but I'm doing my best to at least plug the easily filled holes and adding any unused stuff feels like a step backwards. My router is not unbootable but I am not sure how secure it is anymore because on boot I get several failures related to being "Out of space" and also the kernel relink fails, which I understand is a significant part of what makes OpenBSD more secure. All of my partitions have at least 75% free space, except /usr which after the sysupgrade is listed by df as being filled to 104% capacity. I'm not even sure how that's possible. This is just a personal system and if I screw it up no one is harmed except me and my users, and anyone else who might be attacked by my compromised system I guess, but it took me a long time to get it set up this way and I don't particularly look forward to having to rebuild it from scratch or how long it will be before I find the time to do so. That being said, I realize there is plenty I do not know, and as a rule I experiment with making changes on a VM and observing the results until I feel like I have a solid grasp on what will occur before pushing anything to my live system, which sometimes takes months due to life, work and family, but reading the sysupgrade manpage there is nothing which even hints that any software which was explicitly rejected during the original install will be installed anyway by this tool. In the interest of protecting others from the same mistake I hope that a simple sentence explaining that it also installs any previously rejected sets could be added there. It looks like my best chance to be certain I have the router in the state I think I do will be to do a fresh install and then use sysupgrade using a variation of the script Leo mentioned in his email on 7/9/19: #!/bin/sh sysupgrade -n rm /home/_sysupgrade/x* rm /home/_sysupgrade/game* reboot Thanks again, Judah > Marcus MERIGHI writes: >> please do *not* copy/paste/run this command! >> something along these lines for the sets you did not want: >> >> $ ftp -MVo- $(> tzf - | xargs rm >> >> you are aware that it is recommended to run with all sets? > Despite previous posts requesting assistance with not doing so, I second > this recommendation to anyone not able to construct that ftp/tar/rm > command from first principles (and with a clear need to do so). > > Patronisation aside, your computer's storage is a lot cheaper than the > mental effort required to deal with a system that's non-standard but > only by having a few bits wasted by their _complete lack of use_. > > FilesystemUsedMounted on > > The system proper is tiny: > > /dev/sd0a 148M/ > /dev/sd0e 860M/usr > /dev/sd0h 203M/usr/X11R6 > /dev/sd0g70.9M/var > > The user/development environment is little bigger: > > /dev/sd0i 4.7G/usr/local > /dev/sd0m 1.1G/usr/obj > /dev/sd0l 685M/usr/ports > /dev/sd0j 1.0G/usr/src > /dev/sd0k 688M/usr/xenocara > /dev/sd0n 2.0K/usr/x
sysupgrade failure logs
Hello folks, I am having an issue with sysupgrade and I have had trouble finding the source of the problem so I hope someone here might be able and willing to point me in the right direction. I have 6 small systems running OpenBSD -current and I have a basic script which upgrades to the latest snapshot weekly. The systems are all relatively similar. Three are the exact same piece of hardware, two are slightly different, and one is a VM configured to match the first three as closely as possible with virtual hardware. The script checks the current kernel version, (e.g. "GENERIC.MP#302") logs it, runs sysupgrade, and after the reboot it checks the kernel version again. If it is different it logs it as a "success" and if it is still the same it logs it as a failure. All 6 systems were configured using the same autoinstall configuration and the upgrade script is identical on each unit. However, two of the three identical units always fail. When I remote into either system and manually run the upgrade script it also fails. I was able to get onsite with one of them where I connected a monitor and keyboard and manually ran the script to observe the results but oddly enough it succeeded so I learned nothing actionable. However it continues to fail the weekly upgrade. I have confirmed that the script permissions are identical on the working and nonworking units. The 4 units that successfully upgrade leave a mail message with a log of the upgrade process. However I have been unable to find any record or log on the systems that are failing to help me figure out why this isn't working. The only difference I can identify between the systems is that "auto_upgrade.conf" and "bsd.upgrade" are both present in "/" on the two systems that fail, but are properly removed on the 4 that succeed. I would appreciate any suggestions of what else I can try or check to figure out what is causing this issue. Thanks Judah
Re: sysupgrade failure logs
Thanks to each of you for your replies, Lesson 1: always get machines
with remote console access. It wil save the day some day and help in
diagnosing issues. Having remote console access would be sweet, but
unfortunately that goes far beyond the hobbyist price point I currently
have to work with. On the system that succeeded when you were watching
on the console, did automaic sysupgardes started to work after that? It
did not. This unit still fails the weekly upgrade. In general, my guess
would be a boot.conf contents that prevent the automatic upgrade to
work. Or maybe you have very old bootloaders on the failing mahcines. I
do not have an /etc/boot.conf file on any of these systems. Both the
units having issues are less than 12 months old so I wouldn't think the
bootloader age would be an issue. I have both older and newer units that
are working correctly. Are there major recent changes you are aware of
that might lead to something like this? BTW, kernel # cannot be used to
identify a kernel. Interesting. When I realized two of my machines were
still on old snapshots it seemed like a a simple metric to use for
tracking this. The actual number isn't really as relevant to me at this
point as the fact that it does or does not change. Could the update be
partially and/or completely succeeding and the kernel # staying the
same? In my limited experience following -current for the last 4+ years
every snapshot comes with a different #. -Otto
Care to show a script ? otherwise it looks like rather lengthy
mathematical problem with quite some variables.
The script is very basic. I didn't show it originally because I know from reading
various threads in the past that many of the folks on this list find a
"non-default" install abhorrent and I wasn't interested in dragging that into
this. However, here are the complete script contents:
#!/bin/sh
# Fetch current system version
CURRENT=`uname -a | awk '{print $4}'`
# download latest snapshot but do not install
doas sysupgrade -n -s
# Delete unwanted sets
doas rm /home/_sysupgrade/x*
doas rm /home/_sysupgrade/g*
doas rm /home/_sysupgrade/c*
# Log System Time
year=`date +%Y`
month=`date +%m`
day=`date +%d`
hour=`date +%H`
minute=`date +%M`
second=`date +%S`
echo "System Snapshot upgrade started from $CURRENT at $hour:$minute:$second on
$month/$day/$year" >> /home/$USER/systemLog
doas reboot
I have a separate script that runs on each boot which checks if an
upgrade attempt was the last logged item and fetches the current system version
to compare. If it is the same it logs a failure. If it is different it logs the
new version #. Either way it emails me the results. This script is running on
all 6 systems.
.
What are the permissions on the bsd.upgrade that's left behind? If they
are still +x then your issue is with the boot loader, maybe that
boot.conf otto suggested. If they are -x then the boot loader started
the install kernel but something went wrong. The permissions of the
left-behind bsd.upgrade are -rw--- 1 root
On 14 February 2021 18:02:07 CET, Judah Kocher wrote:
Hello folks,
I am having an issue with sysupgrade and I have had trouble finding the
source of the problem so I hope someone here might be able and willing
to point me in the right direction.
I have 6 small systems running OpenBSD -current and I have a basic
script which upgrades to the latest snapshot weekly. The systems are
all
relatively similar. Three are the exact same piece of hardware, two are
slightly different, and one is a VM configured to match the first three
as closely as possible with virtual hardware.
The script checks the current kernel version, (e.g. "GENERIC.MP#302")
logs it, runs sysupgrade, and after the reboot it checks the kernel
version again. If it is different it logs it as a "success" and if it
is
still the same it logs it as a failure.
All 6 systems were configured using the same autoinstall configuration
and the upgrade script is identical on each unit. However, two of the
three identical units always fail. When I remote into either system and
manually run the upgrade script it also fails. I was able to get onsite
with one of them where I connected a monitor and keyboard and manually
ran the script to observe the results but oddly enough it succeeded so
I
learned nothing actionable. However it continues to fail the weekly
upgrade. I have confirmed that the script permissions are identical on
the working and nonworking units.
The 4 units that successfully upgrade leave a mail message with a log
of
the upgrade process. However I have been unable to find any record or
log on the systems that are failing to help me figure out why this
isn't
working. The only difference I can identify between the systems is that
"auto_upgrade.conf" and "bsd.upgrade" are both present in "/" on the
two
syste
Re: sysupgrade failure logs
I had this nicely formatted when I sent it, but it seems to have been
reformatted elsewhere in transit. Hopefully this helps but if not I will
leave it be.
On 2/14/21 6:27 PM, Judah Kocher wrote:
Thanks to each of you for your replies,
Lesson 1: always get machines with remote console access. It wil save
the day some day and help in diagnosing issues.
Having remote console access would be sweet, but unfortunately that goes
far beyond the hobbyist price point I currently have to work with.
On the system that succeeded when you were watching on the console,
did automaic sysupgardes started to work after that?
It did not. This unit still fails the weekly upgrade.
In general, my guess would be a boot.conf contents that prevent the
automatic upgrade to work. Or maybe you have very old bootloaders on
the failing mahcines.
I do not have an /etc/boot.conf file on any of these systems. Both the
units having issues are less than 12 months old so I wouldn't think the
bootloader age would be an issue. I have both older and newer units that
are working correctly. Are there major recent changes you are aware of
that might lead to something like this?
BTW, kernel # cannot be used to identify a kernel.
Interesting. When I realized two of my machines were still on old
snapshots it seemed like a a simple metric to use for tracking this. The
actual number isn't really as relevant to me at this point as the fact
that it does or does not change. Could the update be partially and/or
completely succeeding and the kernel # staying the same? In my limited
experience following -current for the last 4+ years every snapshot comes
with a different #.
-Otto
Care to show a script ? otherwise it looks like rather lengthy
mathematical problem with quite some variables.
The script is very basic. I didn't show it originally because I
know from reading various threads in the past that many of the folks on
this list find a "non-default" install abhorrent and I wasn't interested
in dragging that into this. However, here are the complete script contents:
#!/bin/sh
# Fetch current system version
CURRENT=`uname -a | awk '{print $4}'`
# download latest snapshot but do not install
doas sysupgrade -n -s
# Delete unwanted sets
doas rm /home/_sysupgrade/x*
doas rm /home/_sysupgrade/g*
doas rm /home/_sysupgrade/c*
# Log System Time
year=`date +%Y`
month=`date +%m`
day=`date +%d`
hour=`date +%H`
minute=`date +%M`
second=`date +%S`
echo "System Snapshot upgrade started from $CURRENT at
$hour:$minute:$second on $month/$day/$year" >> /home/$USER/systemLog
doas reboot
I have a separate script that runs on each boot which checks if an
upgrade attempt was the last logged item and fetches the current
system version to compare. If it is the same it logs a failure. If it
is different it logs the new version #. Either way it emails me the
results. This script is running on all 6 systems.
.
What are the permissions on the bsd.upgrade that's left behind? If
they are still +x then your issue is with the boot loader, maybe that
boot.conf otto suggested. If they are -x then the boot loader started
the install kernel but something went wrong.
The permissions of the left-behind bsd.upgrade are -rw--- 1 root
On 14 February 2021 18:02:07 CET, Judah Kocher
wrote:
Hello folks,
I am having an issue with sysupgrade and I have had trouble finding the
source of the problem so I hope someone here might be able and willing
to point me in the right direction.
I have 6 small systems running OpenBSD -current and I have a basic
script which upgrades to the latest snapshot weekly. The systems are
all
relatively similar. Three are the exact same piece of hardware, two are
slightly different, and one is a VM configured to match the first three
as closely as possible with virtual hardware.
The script checks the current kernel version, (e.g. "GENERIC.MP#302")
logs it, runs sysupgrade, and after the reboot it checks the kernel
version again. If it is different it logs it as a "success" and if it
is
still the same it logs it as a failure.
All 6 systems were configured using the same autoinstall configuration
and the upgrade script is identical on each unit. However, two of the
three identical units always fail. When I remote into either system and
manually run the upgrade script it also fails. I was able to get onsite
with one of them where I connected a monitor and keyboard and manually
ran the script to observe the results but oddly enough it succeeded so
I
learned nothing actionable. However it continues to fail the weekly
upgrade. I have confirmed that the script permissions are identical on
the working and nonworking units.
The 4 units that successfully upgrade leave a mail message with a log
of
the upgrade process. However I have been unable to find any record or
log on the systems that are failing to help me figure out
Re: sysupgrade failure logs
Hello Theo, I never for a moment intended to convey that anyone "owed" me support of any kind for my outside-the-box use of this tool. While I don't understand your vitriolic response to someone else's application of your software for their own personal use in a way you do not condone, you are certainly entitled to be as outraged as you please. I remain grateful for the work you and others put into the OpenBSD operating system. It has been made clear on multiple occasions that use of sysupgrade with anything other than default responses is heretical and cancel-culture worthy but I don't mind breaking things while experimenting and do not blame anyone else when this happens, nor do I particularly care if anyone else is bothered by it as long as no actual harm is being done. If anyone cares to read my original query from an intellectually honest perspective I think they would be hard pressed to respond as you have. I never claimed my "sysupgrade use was completely normal" nor did I blame the sysupgrade tool for the issue I am attempting to diagnose. I did not mention my usage of it because logically it does not seem to be relevant and I was concerned it would become an excuse for people to fly off the handle. I only had and still only have one question. Does sysupgrade leave any kind of logging behind which could help me to pinpoint why it is failing on one system while working on another apparently identical system? If the answer is no, that's easy enough to say. If the answer is yes, that's also easy enough if anyone is willing to share where those logs would be found. If the answer is, "Maybe, but no one owes you that information" that is also perfectly true while kind of pointless to even bother saying, although a world where people only offer help to others when there is a financial obligation would be a dismal place indeed. I did not and do not expect anyone else to solve my problem for me. If you have reason to believe that my "mis-"usage of sysupgrade has anything at all to do with this issue, I'd be curious to know how you would explain it working on 4 out of 6 systems. Since it seems unlikely that the exact same tool would work two different ways on two identical systems then logically I would assume that some subtle difference exists between them and was hopeful that any records of the sysupgrade process would help me identify that difference. I have been using this script on these and other less similar systems ever since the sysupgrade tool was released with no issues, and therefore I think it's reasonable to to conclude that using it this way, while not officially sanctioned, has nothing to do with what's going on in this particular case. Thank you again for your work on OpenBSD, including sysupgrade. To everyone else on the mailing list, I do not apologize for asking a question but I do apologize for the drama it provoked. Judah On 2/14/21 6:44 PM, Theo de Raadt wrote: You are outside the box, by changing tons of stuff. People who operate inside the box won't be able to help you. And it is even less likely when you are dishonest in the original email. You claimed your sysupgrade use was completely normal, but it isn't. It is far from normal. When we get reports like this where people "touch the insides", both Florian and I regret that sysupgrade ever arrived in the system. We want to delete sysupgrade. Or, every month or so change the internals so that it will delete some people's machines. Does sysupgrade recommend what you do? No. But you do it. Do you understand the concept of "you own all the pieces"?
Re: 7.3 -> 7.4 WireGuard AllowedIPs stopped working
Hello Pierre, Silly question perhaps but are you trying to run this with the Allowed IPs commented out as shown in your example? If you remove the '#' from the front of that line does it work? I can confirm that wireguard is working just fine for me after the update to 7.4 on multiple devices, including one with a practically identical configuration to what you shared. Judah On 10/22/23 11:56, Pierre Peyronnel wrote: Hi there, Since upgrading from 7.3 to 7.4 my wireguard setup stopped working. Now, it might be me. Still here's what I have. Stripping down wg0.conf, I have this message as soon as I add a [Peer] section and its public key: bsd# cat /etc/wireguard/wg0.conf [Interface] PrivateKey = (hidden by me) ListenPort = 51820 [Peer] PublicKey = (hidden by me) #PresharedKey = (hidden by me) #AllowedIPs = 10.x.x.10/32 # wg setconf wg0 /etc/wireguard/wg0.conf Unable to modify interface: Address family not supported by protocol family Trying to set it up manually, I get the following result: bsd# ifconfig wg0 wgpeer '(hidden by me)' wgpsk '(hidden by me)' wgaip '10.x.x.10/32' bsd# wg interface: wg0 public key: (hidden by me) private key: (hidden) listening port: 51820 peer: (hidden by me) preshared key: (hidden) allowed ips: (none) I see no way of setting the AllowedIPs anymore. I did not see any change in 7.4 that cloud explain the behaviour or require a change in my configuration I'd be grateful for feedback. Thanks ! Pierre -- Judah Kocher Assistant Chief Cochranville Fire Company 484-266-9257
Pkg_add Python version and LibreSSL seem to be incompatible in OpenBSD 7.3
After updating one of my routers to OpenBSD 7.3, my python scripts that update various public DNS records when my public IP changes started failing with generic segfaults. I did see the note in the OpenBSD Upgrade Guide about 3.10 being the new default so I ran pkg_add -u which updated python to 3.10 and now the same scripts fail but with this error: ImportError: urllib3 v2.0 only supports OpenSSL 1.1.1+, currently the 'ssl' module is compiled with LibreSSL 3.7.2. See: https://github.com/urllib3/urllib3/issues/2168 The included github link mentions that older versions of SSL are no longer usable with the urllib library but makes no mention of LibreSSL. Some web searching has not turned up any details around this. I also do not see python 3.9 as an installable option via pkg_add, just 3.10 and 3.11. Does this mean that installing python via pkg_add installs a python version that is incompatible with LibreSSL? When I look at the info for the OpenSSL package it includes this warning: This package is not intended for general-purpose use in OpenBSD - it is present for test/comparison purposes, and occasionally to provide support for applications which cannot be made compatible with LibreSSL (mostly due to use of removed APIs); in the latter case care must be taken - it will conflict if library dependencies use LibreSSL libraries. What would be the best way to resolve this issue? I would guess that plenty of others are using python with OpenBSD so there must be a recommended resolution, but I have not found it documented anywhere yet. Thanks! Judah
Re: Pkg_add Python version and LibreSSL seem to be incompatible in OpenBSD 7.3
Thank you Otto! pip install urllib3==1.26.15 replaced the v2 version with the latest non v2 version, and now my scripts work again. On 5/14/23 14:34, Otto Moerbeek wrote: On Sun, May 14, 2023 at 12:25:28PM -0400, Judah Kocher wrote: After updating one of my routers to OpenBSD 7.3, my python scripts that update various public DNS records when my public IP changes started failing with generic segfaults. I did see the note in the OpenBSD Upgrade Guide about 3.10 being the new default so I ran pkg_add -u which updated python to 3.10 and now the same scripts fail but with this error: ImportError: urllib3 v2.0 only supports OpenSSL 1.1.1+, currently the 'ssl' module is compiled with LibreSSL 3.7.2. See: https://github.com/urllib3/urllib3/issues/2168 The included github link mentions that older versions of SSL are no longer usable with the urllib library but makes no mention of LibreSSL. Some web searching has not turned up any details around this. I also do not see python 3.9 as an installable option via pkg_add, just 3.10 and 3.11. Does this mean that installing python via pkg_add installs a python version that is incompatible with LibreSSL? When I look at the info for the OpenSSL package it includes this warning: This package is not intended for general-purpose use in OpenBSD - it is present for test/comparison purposes, and occasionally to provide support for applications which cannot be made compatible with LibreSSL (mostly due to use of removed APIs); in the latter case care must be taken - it will conflict if library dependencies use LibreSSL libraries. What would be the best way to resolve this issue? I would guess that plenty of others are using python with OpenBSD so there must be a recommended resolution, but I have not found it documented anywhere yet. Thanks! Judah The problem is very likely a version of urllib3 installed via pip, and has little to do with the python version itself. -Otto -- Judah Kocher Assistant Chief Cochranville Fire Company 484-266-9257
Re: Is a commercial wireless router a security risk if it is behind an OpenBSD router with pf?
I was in the same position about 18 months ago when I reached the
conclusion that I didn't trust my RT-AC88U. I spent about a month
teaching myself iptables before learning about OpenBSD and PF and never
looked back. I have read and reread OpenBSD for Dummies and The Book of
PF multiple times, and spent many an hour on the OpenBSD website as well
as lurking on this mailing list filling in holes from outdated material.
I am using a mini PC from Qotom for my router and I took an old D-Link
router, set it to AP mode, disabled the DHCP server and connected it to
one NIC on it's own subnet as guest wifi. All traffic not heading to the
internet is blocked so guests never even see my network. {And thanks to
queuing, which I finally figured out, they have no idea how fast my
internet speed actually is :) } For the ASUS unit, like you I wasn't
willing to give up the wifi speeds so I set it to AP mode, disabled the
DHCP server, and am using dhcpd address reservation on the Router to
assign it an address that I block in the firewall.
Any devices connected to it have their own IPs that pass through just
fine, but traffic originating from the router itself gets nowhere. I did
a factory reset and flashed the latest Merlin Firmware when I made this
change and it has never been exposed to the internet since. Even if it
does get compromised somehow I believe this should keep it from phoning
home or otherwise causing meaningful harm.
The only "issue" is that I can't automatically update firmware. That
seems to me the lesser of evils. I check fairly regularly for updates
and can easily update it manually when required and I think this setup
also makes running older firmware a bit less of a liability.
Good luck!
Judah
On 1/24/19 5:55 PM, John Page wrote:
> This is my first attempt at a router. Liberally borrowing from tutorials
> and reading Absolute OpenBSD, 2nd Edition and Building Linux and OpenBSD
> Firewalls, I decided on installing OpenBSD 6.4 on a PC Engines apu4. I
> had previously been using an Asus RT-86U as both my router and wireless
> access point. The apu4 can have wireless capability, but OpenBSD does
> not support 802.11ac while the Asus does. So I decided to connect the
> Asus to em3 of the apu4 so my wireless Windows 10 computers (both of
> which have .ac) and Android phones could connect to the Asus instead of
> the apu4 main router. Below is my stab at a network diagram (borrowed
> and adapted) and the contents of my configuration files (again, borrowed
> and adapted).
>
> My question is: OK, I understand that people more knowledgeable than I
> am say that commercially available consumer-grade routers are not
> secure. However, will I still have security risks associated with using
> the Asus router when it is behind the OpenBSD/apu4 router?
> Also, any suggestions or comments would be appreciated.
> Thanks
> John
> apu4 router (running OpenBSD 6.4 -stable)
> --→
> the internal interface
> .-.---.
> | | em3 | -→ Asus router -→ Windows 10 and
> | bridge0 | (no ip) | (RT-AC86U) Android clients
> | '---'
> | | em2 | static (fixed) via MAC address
>
> '--. | (no ip) | -→ 192.168.1.3 OpenBSD only
> | vether0 | '---'
> | dhcpd | | em1 | static (fixed) via MAC address
>
> | 192.168.1.1 | | (no ip) | -→ 192.168.1.2 OpenBSD only
> '---^--'--'---'
> |
> v
> em0
> dhcp
> ^
> |
> Arris Surfboard SB8200
> Cable Modem DOCSIS 3.1
> (external interface)
> |
> v
> .-,( ),-.
> -( )-.
> ( Internet )
> '-( ).-'
> '--.( ).'
> _/etc_/hostname.bridge0
> add vether0
> add em1
> add em2
> add em3
> blocknonip vether0
> blocknonip em1
> blocknonip em2
> blocknonip em3
> up
> _/etc_/hostname.vether0
> inet 192.168.1.1 255.255.255.0 192.168.1.255
> _/etc/dhcpd.conf_
> option domain-names-servers 192.168.1.1;
> subnet 192.168.1.0 netmask 255.255.255.0 {
> option routers 192.168.1.1;
> range 192.168.1.4 192.168.1.254;
> host x1carbon {
> fixed-address 192.168.1.2;
> hardware ethernet xx:xx:xx:xx:xx:xx;
> }
> host optiplex790 {
> fixed-address 192.168.1.3;
> hardware ethernet xx:xx:xx:xx:xx:xx;
> }
> }
> _/var/unbound/etc/unbound.conf_
> server:
> interface: 192.168.1.1
> interface: 127.0.0.1
> do-ip6: no
> access-control: 192.168.1.0/24 allow
> do-not-query-localhost: no
> hide-identity: yes
> hide-version: yes
> forward-zone:
> name: "."
> forward-addr: 127.0.0.1@40
> _/etc/rc.conf.local_
> dhcpd_flags="vether0"
> unbound_flags=""
> dnscrypt_proxy
> dnscrypt_proxy_flags="-l /_dev/_null -R dnscrypt.ca-1 -a 127.0.0.1:40"
> sndiod_flags=NO
> apmd_flags="-A"
> _/etc/dhclient.conf_
> ignore domain-name-servers
> /etc/fstab (this is the only change from the default)
>
> /dev/sd0a
