Re: syspatch -> no partition found ; any simple fix?
On Thu, Oct 29, 2020 at 8:42 PM Amelia A Lewis wrote: > Heylas, > > So, I ran 6.8 syspatch (patches 002 and 003 together) for three systems > today (yesterday by the time anyone sees this, most likely). Two came > right back up as expected. The third didn't, but as it's local, I could > > . Or if it is entirely impossible that "No active partition" could be the > result of kernel relinking borkage, and it's obvious to someone that > something else (hardware failure showing up on a reboot?) happened, I'd > welcome clues. Thanks. > If you were just running syspatch I'd be worried that a hardware failure showed up on reboot. I'm way out of practice for troubleshooting OpenBSD but booting the installer from a USB drive or CD, dropping to a shell and checking your disk info will answer the hardware question for you.
Re: IPsec and MTU / fragmentation
On Mon, Feb 10, 2020 at 05:15:00PM +, Peter M??ller wrote: > Hello Lucas, > > as far as I understood, setting MTU on encN interfaces is not supported > since it is not mentioned by enc(4) and setting it manually fails: > > > machine# ifconfig enc0 mtu 1500 > > ifconfig: SIOCSIFMTU: Inappropriate ioctl for device > > If you do not want to use GRE tunnels or gif interfaces, I suppose truncating > MSS via pf might be an acceptable but not elegant solution: I have max-mss and reassemble tcp: match in on gre0 scrub (max-mss 1456, reassemble tcp) However still experienced about 5% packet loss when i run speedtest.net through the tunnel. In my instance, the solution for eliminating packet loss over the long distance ipsec/gre tunnel was putting in a queue: queue hfsq-gre0 on gre0 flows 1024 bandwidth $BW_LIMIT max $BW_LIMIT quantum 400 qlimit 1000 default .d.d.
syspatch -> no partition found ; any simple fix?
Heylas,
So, I ran 6.8 syspatch (patches 002 and 003 together) for three systems
today (yesterday by the time anyone sees this, most likely). Two came
right back up as expected. The third didn't, but as it's local, I could
go retry at the console (all three were actually patched and rebooted
via ssh).
It won't start the boot, but displays "No active partition". Checking
online, this message seems to indicate a failed upgrade, with the
bootloader load incomplete, and (because I was distracted, and running
three updates in a state of fatigue), it's actually likely that what I
did was to Ctrl-B D out of tmux before it returned from kernel
relinking, and then hit doas reboot unthinkingly. Anyway, that's my
guess.
Is there a straightforward way to install kernel and bootloader without
requiring a system reinstall? Can I 'upgrade' with an install cd or usb
stick from (broken) 6.8+sp3 to 6.8, and then syspatch it up to date?
I'm trying to avoid full reinstall because that seems likely to wipe
out existing configuration. I figure my fallback is create install
stick/cd (from the other local 6.8, which was successfully updated),
boot from that, pull backups of all the configuration so I don't have
to reconfigure all the services (and double-check sizes and locations
of disk slices on the boot drive, and store that somewhere safe, then
reinstall and copy stuff back (it's all backed up, in fact, but it's
not backed up recently enough for confidence). So ... faster way to fix
my screwup, when I've probably borked my kernel and the bootloader,
somehow?
Or if it is entirely impossible that "No active partition" could be the
result of kernel relinking borkage, and it's obvious to someone that
something else (hardware failure showing up on a reboot?) happened, I'd
welcome clues. Thanks.
Amy!
--
Amelia A. Lewisamyzing {at} talsever.org
Time and trouble will tame an advanced young woman, but an advanced old
woman is uncontrollable by any earthly force.
-- Sir Impey Biggs [Dorothy L. Sayers, "Clouds of
Witness"]
Re: wg(4) listen on a specific interface / address
On Tue, 27 Oct 2020 22:36:38 +0100
Pierre Emeriaud wrote:
> Howdy misc@,
>
> I have a fairly complicated setup with lots of interfaces, a couple of
> rdomains etc.
>
> I'd like wireguard to listen only on an IP address, not all. But if my
> understanding of ifconfig(8) is correct, this doesn't seem possible
> currently:
>
> wgport port
> Set the UDP port that the tunnel operates on. _The
> interface will bind to INADDR_ANY and IN6ADDR_ANY_INIT._
>
> I guess this the reason for the following behaviour?
>
> $ doas ifconfig wg0 wgport 53
> ifconfig: SIOCSWG: Address already in use
> (the error message is generic I guess - but confusing imho)
>
> $ netstat -natfinet | grep 53
> tcp 0 0 127.0.0.1.53 *.*
> LISTEN udp 0 0 127.0.0.1.53 *.*
>
> $ netstat -T1 -natfinet | grep 53
> udp 0 0 127.0.0.1.53 *.*
>
> Is there a way to circumvent this restriction? (is there a reason
> behind it maybe?)
A lot has been said already, however I should clarify things.
wg(4)'s primary goal is to provide a secure network tunnel. We have no
desire to obfuscating or manipulating traffic to bypass restrictive
firewalls, which appears to be what you want to use port 53 for.
Why INADDR_ANY (and IN6ADDR_ANY_INIT)? We listen on all interfaces to
discard any notion of trusting IP addresses and rely entirely on the
crypto to authenticate packets. This ties directly the "roaming" feature
of WireGuard [1]. As Theo mentioned we don't want to monitor for
addressing changes, so INADDR_ANY is correct.
Why no configuration knob for bind address? Well, this is a "simple"
VPN and prides itself on minimising unnecessary configuration while
still achieving it's primary goals. Allowing configuration of the bind
address opens a whole can of complexity worms, including configuration
failure modes and security issues that we don't have consensus on. The
behaviour exhibited on wg(4) is also consistent with implementations of
WireGuard on other platforms. This has been discussed before: [2][3].
Finally, if you want to continue using port 53, bind wg first, then
unwind. Alternatively rdr-to rules will work and I'm guessing your
didn't do any debugging to figure out why your rules weren't working as
expected. If your goal is to bypass restrictive firewalls, you may also
want to add ports 123, 4500, 5060 to your redirect rules, but keep in
mind you're abusing software in ways it wasn't designed for so support
is minimal. I imagine it would look something like the following (with
wg(4) listening on port 53535 on the same rdomain):
pass in on $wan proto udp to (self) \
port { 53, 123, 4500, 5060 } rdr-to 127.0.0.1 port 53535
Cheers,
Matt
[1] https://www.wireguard.com/#built-in-roaming
[2] https://lists.zx2c4.com/pipermail/wireguard/2017-May/001280.html
[3] https://lists.zx2c4.com/pipermail/wireguard/2018-June/003013.html
Re: Impact of 002_icmp6.patch
js-openbsd-m...@webkeks.org wrote: > I just saw > https://ftp.openbsd.org/pub/OpenBSD/patches/6.8/common/002_icmp6.patch.sig, > however, it's unclear from the description and the context around the > patch if this is a read after free or write after free (or both). I think it is fair you can study the code yourself and make your own factual determination. > In the case of a write after free, would this change "Only two remote > holes in the default install, in a heck of a long time!" to three? Or > does it need more than IPv6 being configured? First off, is ipv6 deployment really part of the default install? No, not really it takes some effort to configure v6, it is not natural. It is active on the loopback, but then that's not remote.. But there's a bigger assumption in your mail: We've released the errata as security because it is possibly exploitable or could cause a crash, and we have a rapid fix release process. It was released without even seeing any evidence of a remote crash, nor any evidence of a remote exploit. Incorrect code gets fixed, and if we judge it important we release a fix to the public in expedited fashion, and apparently get judged for doing so. Now that the fix is released and deployed by most openbsd users, we quickly become uncurious and head back to other work. The only conversations related to this are asking how we can harden the mbuf layer to avoid similar issues in the future. I guess many other operating systems would wait weeks or months to collect all the "facts" and make a fancy disclosure, but we shipped source and binary fixes in just over 24 hours. So, is it a remote crash? Possibly, but we'd like to see a packet that causes it. Next after that, is it a remote exploit? I think it is fair to wait for facts. I also think you are a troll.
Impact of 002_icmp6.patch
Hi! I just saw https://ftp.openbsd.org/pub/OpenBSD/patches/6.8/common/002_icmp6.patch.sig, however, it's unclear from the description and the context around the patch if this is a read after free or write after free (or both). In the case of a write after free, would this change "Only two remote holes in the default install, in a heck of a long time!" to three? Or does it need more than IPv6 being configured? -- Jonathan
Re: wg(4) listen on a specific interface / address
> On Oct 29, 2020, at 6:09 PM, Pierre Emeriaud > wrote: > > Le jeu. 29 oct. 2020 à 21:03, Stuart Henderson a > écrit : >> Which DNS server do you have bound on 53? > > unwind > > >>> Is there a reason why wg needs such a large bind? >> Unless/until it gets an option to bind to a specific IP that's all it >> can sanely do. It would definitely be useful IMO. > > This is maybe where it starts to make sense. By binding INADDR_ANY, > this allows wg to accept incoming packets whichever interface they > came from. Maybe to mimic what is done with other tunnels/protocols > operating at L3, while still operating at L4. You can achieve success using pf + routing domains. It’ll work just takes extra effort. I agree a bind IP parameter would be nice, but not a necessity to function. Where one function in the kernel isn’t a jack of all trades (wg) or perfect, another feature can help to achieve the goal (pf + rdomains, the network stack design used by OpenBSD for virtualizing the address and port space).
Re: wg(4) listen on a specific interface / address
Pierre Emeriaud wrote: > Totally agreed. This is because of my stupid idea to share port 53 for > this use. Maybe my understanding of sockets was wrong, but I thought > that applications could use the bind port _if and only_ they weren't > trying to bind the same IP+port, hence my question about this > conflict, which could happen with other ports as well. Such a weird perspective. I guess you've never setup a multhomed machine. INADDR_ANY means all interfaces, so a daemon doesn't need to open a new socket on each interfaces, and listen to the route socket for new interfaces to arrive, or old ones to be disconnected. > Thanks everyone who answered, and if anyone has the definitive answer > about why it wg binds INADDR_ANY, I'd be interested to know. Why does sshd bind to INADDR_ANY? Why does httpd bind to INADDR_ANY? The same reason for wg. It wants to respond to requests on all interfaces. And the loopback is not exempt.
Re: wg(4) listen on a specific interface / address
On 2020/10/29 23:08, Pierre Emeriaud wrote: > Le jeu. 29 oct. 2020 à 21:03, Stuart Henderson a écrit > : > > > > Which DNS server do you have bound on 53? > > unwind > > > > > Is there a reason why wg needs such a large bind? > > > > Unless/until it gets an option to bind to a specific IP that's all it > > can sanely do. It would definitely be useful IMO. > > This is maybe where it starts to make sense. By binding INADDR_ANY, > this allows wg to accept incoming packets whichever interface they > came from. Maybe to mimic what is done with other tunnels/protocols > operating at L3, while still operating at L4. Incoming is one side of it. The other side is the address used for outgoing packets - on a multihomed system it's quite common to bind to a specific port to get the correct source address (which can easily vary between different services running on a machine).
Re: wg(4) listen on a specific interface / address
Le jeu. 29 oct. 2020 à 21:17, Theo de Raadt a écrit : > > Or, don't try to overlay stuff onto a single port. Look, we can tell > what is going on here, you want to tunnel over the least-filtered port > on the internet, but if you do that trying to use that port for another > thing is quite a problem of your own making. Le jeu. 29 oct. 2020 à 23:10, Theo de Raadt a écrit : > > port 53 has a well known use. It is the firstcomer, for a critical service. > > You are abusing that port. Totally agreed. This is because of my stupid idea to share port 53 for this use. Maybe my understanding of sockets was wrong, but I thought that applications could use the bind port _if and only_ they weren't trying to bind the same IP+port, hence my question about this conflict, which could happen with other ports as well. > I could easily argue there is nothing to fix in our kernel. I think I agree, anyhow, this behavior might be intentional, so I'll avoid doing that in the future. Thanks everyone who answered, and if anyone has the definitive answer about why it wg binds INADDR_ANY, I'd be interested to know.
Re: wg(4) listen on a specific interface / address
Pierre Emeriaud wrote: > Le jeu. 29 oct. 2020 à 18:00, Brian Brombacher a écrit > : > > > > > > Then there’s a misconfiguration, wg driver bug, or the driver documentation > > is wrong in ifconfig about wgrtable. > > > > Routing domains are where you can specify multiple conflicting port binds > > and be fine, INADDR_ANY included. > > On that matter there are no issues, only me/my setup. wg has no issues > with binding INADDR_ANY if it is the only software binding on port 53 > _in that rdomain_. The issue I have is when I already have another > software, like a dns resolver here already listening on 127.0.0.1 in > that same rdomain. port 53 has a well known use. It is the firstcomer, for a critical service. You are abusing that port. I could easily argue there is nothing to fix in our kernel.
Re: wg(4) listen on a specific interface / address
Le jeu. 29 oct. 2020 à 21:03, Stuart Henderson a écrit : > > Which DNS server do you have bound on 53? unwind > > Is there a reason why wg needs such a large bind? > > Unless/until it gets an option to bind to a specific IP that's all it > can sanely do. It would definitely be useful IMO. This is maybe where it starts to make sense. By binding INADDR_ANY, this allows wg to accept incoming packets whichever interface they came from. Maybe to mimic what is done with other tunnels/protocols operating at L3, while still operating at L4.
Re: wg(4) listen on a specific interface / address
Le jeu. 29 oct. 2020 à 18:00, Brian Brombacher a écrit : > > > Then there’s a misconfiguration, wg driver bug, or the driver documentation > is wrong in ifconfig about wgrtable. > > Routing domains are where you can specify multiple conflicting port binds and > be fine, INADDR_ANY included. On that matter there are no issues, only me/my setup. wg has no issues with binding INADDR_ANY if it is the only software binding on port 53 _in that rdomain_. The issue I have is when I already have another software, like a dns resolver here already listening on 127.0.0.1 in that same rdomain.
Re: Chromium not starting on Thinkpad R40E with 6.8
On 2020-10-29, Tom Smyth wrote: > Hi Anthony did you manage to try to move the chrome profile directory > so that you start with a fresh profile like As It doesn't get that far, it doesn't even start executing the process.
Re: wg(4) listen on a specific interface / address
Stuart Henderson wrote: > On 2020-10-29, Pierre Emeriaud wrote: > > Le jeu. 29 oct. 2020 à 01:20, Theo de Raadt a écrit : > >> > >> I believe you are running into the restriction that we don't allow an > >> INADDR_ANY:port binding to be done after a ipaddr:port binding has been > >> done. It must be done beforehands. > > > > Sorry Theo, maybe things got lost in translation, but if my > > understanding is correct this is not exactly the case here. wg is > > trying to bind to INADDR_ANY, which fails because a dns daemon (in my > > case) is already bound to 127.0.0.1:53 (in wg_socket_open() -L700 of > > if_wg.c-, sin->sin_addr.s_addr = INADDR_ANY?). > > There are extra restrictions, to prevent some software "stealing" packets > intended for some other software. In userland software that wants to coexist > with other software on the same pprt hut a different bound IP needs to use > SO_REUSEADDR (I forgot exactly how the restriction work though). The problem > you are seeing might be related to this. > > Which DNS server do you have bound on 53? > > > Is there a reason why wg needs such a large bind? > > Unless/until it gets an option to bind to a specific IP that's all it > can sanely do. It would definitely be useful IMO. Or, configure it before the application software. Or, don't try to overlay stuff onto a single port. Look, we can tell what is going on here, you want to tunnel over the least-filtered port on the internet, but if you do that trying to use that port for another thing is quite a problem of your own making.
Re: wg(4) listen on a specific interface / address
On 2020-10-29, Pierre Emeriaud wrote: > Le jeu. 29 oct. 2020 à 01:20, Theo de Raadt a écrit : >> >> I believe you are running into the restriction that we don't allow an >> INADDR_ANY:port binding to be done after a ipaddr:port binding has been >> done. It must be done beforehands. > > Sorry Theo, maybe things got lost in translation, but if my > understanding is correct this is not exactly the case here. wg is > trying to bind to INADDR_ANY, which fails because a dns daemon (in my > case) is already bound to 127.0.0.1:53 (in wg_socket_open() -L700 of > if_wg.c-, sin->sin_addr.s_addr = INADDR_ANY?). There are extra restrictions, to prevent some software "stealing" packets intended for some other software. In userland software that wants to coexist with other software on the same pprt hut a different bound IP needs to use SO_REUSEADDR (I forgot exactly how the restriction work though). The problem you are seeing might be related to this. Which DNS server do you have bound on 53? > Is there a reason why wg needs such a large bind? Unless/until it gets an option to bind to a specific IP that's all it can sanely do. It would definitely be useful IMO.
Qubes OS template
There is any chance that the OpenBSD template for Qubes OS will be made? It would be a big help for OpenBSD followers instead NetBSD.
Re: disk setup question
On Thu, Oct 29, 2020 at 11:08:20AM -0600, Theo de Raadt wrote: > Aleksander De wrote: > > > Are there any downsides or potential issues which may happen when > > extending boundaries for OpenBSD partition on >2TB disk while using > > MBR for booting it at the same time? I need MBR otherwise the machine > > will not boot. BIOS/RAID controller does not support UEFI. > > The BIOS will use the MBR to identify the bootable partition. Then > it will load the PBR sector as code, jump to it, and then load further > bootblock code, and kernel after that. It is important to not have the > root partition in an earlier part of the disk (I'm being intentionally > vague). > > But our bootcode does not care about the partition limits. What happens > is disklabel looks at the MBR partition limits -- when non-MBR > partitions (ie disklabel partitions) are being created, usually during > install. Beyond that, the MBR size is never looked at again. > > Where MBR partition limits can matter, is if you go back to disklabel > again manually to create partitions. It's splitting the disk up. If > you are not careful, you could create overlaps. This mostly happens to > people putting multiple operating systems on a machine. Those people > need to be careful. Everyone else can ignore this. Thank you very much Otto and Theo. -- Aleksander
Re: Issues converting from bridge(4) to switch(4)
I get no output with monitor: prometheus# time switchctl monitor ^C1m27.15s real 0m00.00s user 0m00.00s system I also tried plugging in a different device into em1 while the monitor was running but I didn't get any output. Here is the output of switchd as well, the output continues to grow with incrementing xids. prometheus# switchd -dvv listen on 0.0.0.0:6653 ofrelay_attach: new connection 1.1 ofp_open: new connection 1.1 from switch 0 any > /dev/switch0: version 1_3 type HELLO length 16 xid 0 version bitmap: version 1_0 version 1_3 ofrelay_input_done: connection 1.1: 8 bytes from switch 0 /dev/switch0 > any: version 1_3 type HELLO length 8 xid 1530 any > /dev/switch0: version 1_3 type FEATURES_REQUEST length 8 xid 1 ofrelay_input_done: connection 1.1: 32 bytes from switch 1 /dev/switch0 > any: version 1_3 type FEATURES_REPLY length 32 xid 1 datapath_id 0x264921d244b07e9a nbuffers 0 ntables 254 aux_id 0 \ capabilities 0x0f any > /dev/switch0: version 1_3 type MULTIPART_REQUEST length 16 xid 2 type TABLE_FEATURES flags empty table properties request any > /dev/switch0: version 1_3 type SET_CONFIG length 12 xid 3 flags miss_send_len NO_BUFFER ofrelay_input_done: connection 1.1: 1048 bytes from switch 1 /dev/switch0 > any: version 1_3 type MULTIPART_REPLY length 1048 xid 2 type TABLE_FEATURES flags table features length 1032 tableid <0> name "" metadata match \ 0x write 0x config 0 max_entries 1 INSTRUCTION (length 20): type GOTO_TABLE length 4 type WRITE_META length 4 type WRITE_ACTIONS length 4 type APPLY_ACTIONS length 4 type CLEAR_ACTIONS length 4 INSTRUCTION_MISS (length 20): type GOTO_TABLE length 4 type WRITE_META length 4 type WRITE_ACTIONS length 4 type APPLY_ACTIONS length 4 type CLEAR_ACTIONS length 4 APPLY_ACTIONS (length 20): action POP_VLAN length 4 action PUSH_VLAN length 4 action SET_FIELD length 4 action GROUP length 4 action OUTPUT length 4 APPLY_ACTIONS_MISS (length 20): action POP_VLAN length 4 action PUSH_VLAN length 4 action SET_FIELD length 4 action GROUP length 4 action OUTPUT length 4 WRITE_ACTIONS (length 20): action POP_VLAN length 4 action PUSH_VLAN length 4 action SET_FIELD length 4 action GROUP length 4 action OUTPUT length 4 WRITE_ACTIONS_MISS (length 20): action POP_VLAN length 4 action PUSH_VLAN length 4 action SET_FIELD length 4 action GROUP length 4 action OUTPUT length 4 MATCH (length 136): class OPENFLOW_BASIC type IN_PORT length 4 class OPENFLOW_BASIC type META length 8 class OPENFLOW_BASIC type ETH_DST length 6 class OPENFLOW_BASIC type ETH_SRC length 6 class OPENFLOW_BASIC type ETH_TYPE length 2 class OPENFLOW_BASIC type VLAN_VID length 2 class OPENFLOW_BASIC type VLAN_PCP length 1 class OPENFLOW_BASIC type IP_DSCP length 1 class OPENFLOW_BASIC type IP_ECN length 1 class OPENFLOW_BASIC type IP_PROTO length 1 class OPENFLOW_BASIC type IPV4_SRC length 4 class OPENFLOW_BASIC type IPV4_DST length 4 class OPENFLOW_BASIC type TCP_SRC length 2 class OPENFLOW_BASIC type TCP_DST length 2 class OPENFLOW_BASIC type UDP_SRC length 2 class OPENFLOW_BASIC type UDP_DST length 2 class OPENFLOW_BASIC type SCTP_SRC length 2 class OPENFLOW_BASIC type SCTP_DST length 2 class OPENFLOW_BASIC type ICMPV4_TYPE length 1 class OPENFLOW_BASIC type ICMPV4_CODE length 1 class OPENFLOW_BASIC type ARP_OP length 2 class OPENFLOW_BASIC type ARP_SPA length 4 class OPENFLOW_BASIC type ARP_TPA length 4 class OPENFLOW_BASIC type ARP_SHA length 6 class OPENFLOW_BASIC type ARP_THA length 6 class OPENFLOW_BASIC type IPV6_SRC length 16 class OPENFLOW_BASIC type IPV6_DST length 16 class OPENFLOW_BASIC type IPV6_FLABEL length 4 class OPENFLOW_BASIC type ICMPV6_TYPE length 1 class OPENFLOW_BASIC type ICMPV6_CODE length 1 class OPENFLOW_BASIC type IPV6_ND_TARGET length 16 class OPENFLOW_BASIC type IPV6_ND_SLL length 6 class OPENFLOW_BASIC type IPV6_ND_TLL length 6 class OPENFLOW_BASIC type TUNNEL_ID length 8 WILDCARDS (length 132): class OPENFLOW_BASIC type META length 8 class OPENFLOW_BASIC type ETH_DST length 6 class OPENFLOW_BASIC type ETH_SRC length 6 class OPENFLOW_BASIC type ETH_TYPE length 2 class OPENFLOW_BASIC type VLAN_VID length 2 class OPENFLOW_BASIC type VLAN_PCP length 1 class OPENFLOW_BASIC type IP_DSCP length 1 class OPENFLOW_BASIC type IP_ECN length 1 class OPENFLOW_BASIC type IP_PROTO length 1 class OPENFLOW_BASIC type IPV4_SRC length 4 class OPENFLOW_BASIC type IPV4_DST length 4 class OPENFLOW_BASIC type TCP_SRC length 2 class OPENFLOW_BASIC type TCP_DST length 2 class OPENFLOW_BASIC type UDP_SRC length 2 class OPENFLOW_BASIC type UDP_DST length 2 class OPENFLOW_BASIC type SCTP_SRC length 2 class OPENFLOW_BASIC type SCTP_DST length 2 class OPENFLOW_BASIC
Re: Issues converting from bridge(4) to switch(4)
what output does switchctl monitor give you On Thu, 29 Oct 2020 at 17:16, John McGuigan wrote: > > prometheus$ ifconfig em0 > em0: flags=808843 \ > mtu 1500 > lladdr 00:0d:b9:be:ef:94 > index 1 priority 0 llprio 3 > groups: egress > media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) > status: active > inet 192.168.1.80 netmask 0xff00 broadcast 192.168.1.255 > > prometheus$ ifconfig em1 > em1: flags=8b43 MULTICAST> mtu 1500 > lladdr 00:0d:b9:be:ef:95 > index 2 priority 0 llprio 3 > media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) > status: active > > prometheus$ ifconfig em2 > em2: flags=8b43 MULTICAST> mtu 1500 > lladdr 00:0d:b9:be:ef:96 > index 3 priority 0 llprio 3 > media: Ethernet autoselect (none) > status: no carrier > > prometheus$ cat /etc/hostname.em0 > dhcp > prometheus$ cat /etc/hostname.em1 > up > prometheus$ cat /etc/hostname.em2 > up > > On Thu, Oct 29, 2020 at 11:10 AM Tom Smyth > wrote: > > > > what is your ifconfig em0 > > ifconfig em1 > > ? > > > > On Thu, 29 Oct 2020 at 17:07, John McGuigan wrote: > > > > > > Howdy misc, > > > > > > I have an APU2 with the following configuration under 6.8: > > > > > > em0 = WAN > > > em1 = bridge0 LAN > > > em2 = bridge0 LAN > > > vether = 10.0.0.1 > > > > > > prometheus$ cat /etc/hostname.bridge0 > > > add vether0 > > > add em1 > > > add em2 > > > up > > > > > > prometheus$ cat /etc/hostname.vether0 > > > inet 10.0.0.1 255.255.255.0 10.0.0.255 > > > > > > I have dhcpd listening on vether0 and it works just fine. I have a > > > client connected to em1 and it can ping 10.0.0.1 with no issues. > > > > > > The trouble started when I wanted to implement a switch(4) instead > > > of the bridge(4): > > > > > > I moved /etc/hostname.bridge0 to /etc/hostname.switch0 > > > > > > prometheus$ cat /etc/switchd.conf > > > device "/dev/switch0" > > > > > > switchd was enabled via rcctl > > > > > > When I rebooted the system the client on em1 no longer got a dhcp > > > response and can't ping 10.0.0.1 > > > > > > ifconfig snippet: > > > > > > switch0: flags=41 > > > index 6 llprio 3 > > > groups: switch > > > datapath 0x264921d244b07e9a maxflow 1 maxgroup 1000 > > > vether0 flags=0<> > > > port 7 ifpriority 0 ifcost 0 > > > em1 flags=0<> > > > port 2 ifpriority 0 ifcost 0 > > > em2 flags=0<> > > > port 3 ifpriority 0 ifcost 0 > > > vether0: flags=8943 \ > > > mtu 1500 > > > lladdr fe:e1:ba:d0:0b:ca > > > index 7 priority 0 llprio 3 > > > groups: vether > > > media: Ethernet autoselect > > > status: active > > > inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255 > > > > > > > > > With tcpdump on vether0 I see the arp requests from the client for > > > 10.0.0.1 but vether0 doesn't respond. > > > > > > I see the same arp traffic on switch0 and em1 via tcpdump too. > > > > > > The switch seems to have learned the mac address of the client: > > > > > > prometheus$ switchctl show macs > > > SwitchPortTypeNameInfo > > > 1 2 mac f0:de:f1:23:13:37 age 3s > > > > > > Unfortunately, I don't really know how to dig any deeper at this issue. > > > Does anyone here see a glaring mistake or would be able to nudge me in > > > a better direction? > > > > > > Thanks, > > > > > > John > > > > > > > > > -- > > Kindest regards, > > Tom Smyth. -- Kindest regards, Tom Smyth.
Re: Issues converting from bridge(4) to switch(4)
prometheus$ ifconfig em0 em0: flags=808843 \ mtu 1500 lladdr 00:0d:b9:be:ef:94 index 1 priority 0 llprio 3 groups: egress media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) status: active inet 192.168.1.80 netmask 0xff00 broadcast 192.168.1.255 prometheus$ ifconfig em1 em1: flags=8b43 mtu 1500 lladdr 00:0d:b9:be:ef:95 index 2 priority 0 llprio 3 media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) status: active prometheus$ ifconfig em2 em2: flags=8b43 mtu 1500 lladdr 00:0d:b9:be:ef:96 index 3 priority 0 llprio 3 media: Ethernet autoselect (none) status: no carrier prometheus$ cat /etc/hostname.em0 dhcp prometheus$ cat /etc/hostname.em1 up prometheus$ cat /etc/hostname.em2 up On Thu, Oct 29, 2020 at 11:10 AM Tom Smyth wrote: > > what is your ifconfig em0 > ifconfig em1 > ? > > On Thu, 29 Oct 2020 at 17:07, John McGuigan wrote: > > > > Howdy misc, > > > > I have an APU2 with the following configuration under 6.8: > > > > em0 = WAN > > em1 = bridge0 LAN > > em2 = bridge0 LAN > > vether = 10.0.0.1 > > > > prometheus$ cat /etc/hostname.bridge0 > > add vether0 > > add em1 > > add em2 > > up > > > > prometheus$ cat /etc/hostname.vether0 > > inet 10.0.0.1 255.255.255.0 10.0.0.255 > > > > I have dhcpd listening on vether0 and it works just fine. I have a > > client connected to em1 and it can ping 10.0.0.1 with no issues. > > > > The trouble started when I wanted to implement a switch(4) instead > > of the bridge(4): > > > > I moved /etc/hostname.bridge0 to /etc/hostname.switch0 > > > > prometheus$ cat /etc/switchd.conf > > device "/dev/switch0" > > > > switchd was enabled via rcctl > > > > When I rebooted the system the client on em1 no longer got a dhcp > > response and can't ping 10.0.0.1 > > > > ifconfig snippet: > > > > switch0: flags=41 > > index 6 llprio 3 > > groups: switch > > datapath 0x264921d244b07e9a maxflow 1 maxgroup 1000 > > vether0 flags=0<> > > port 7 ifpriority 0 ifcost 0 > > em1 flags=0<> > > port 2 ifpriority 0 ifcost 0 > > em2 flags=0<> > > port 3 ifpriority 0 ifcost 0 > > vether0: flags=8943 \ > > mtu 1500 > > lladdr fe:e1:ba:d0:0b:ca > > index 7 priority 0 llprio 3 > > groups: vether > > media: Ethernet autoselect > > status: active > > inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255 > > > > > > With tcpdump on vether0 I see the arp requests from the client for > > 10.0.0.1 but vether0 doesn't respond. > > > > I see the same arp traffic on switch0 and em1 via tcpdump too. > > > > The switch seems to have learned the mac address of the client: > > > > prometheus$ switchctl show macs > > SwitchPortTypeNameInfo > > 1 2 mac f0:de:f1:23:13:37 age 3s > > > > Unfortunately, I don't really know how to dig any deeper at this issue. > > Does anyone here see a glaring mistake or would be able to nudge me in > > a better direction? > > > > Thanks, > > > > John > > > > > -- > Kindest regards, > Tom Smyth.
Re: Issues converting from bridge(4) to switch(4)
what is your ifconfig em0 ifconfig em1 ? On Thu, 29 Oct 2020 at 17:07, John McGuigan wrote: > > Howdy misc, > > I have an APU2 with the following configuration under 6.8: > > em0 = WAN > em1 = bridge0 LAN > em2 = bridge0 LAN > vether = 10.0.0.1 > > prometheus$ cat /etc/hostname.bridge0 > add vether0 > add em1 > add em2 > up > > prometheus$ cat /etc/hostname.vether0 > inet 10.0.0.1 255.255.255.0 10.0.0.255 > > I have dhcpd listening on vether0 and it works just fine. I have a > client connected to em1 and it can ping 10.0.0.1 with no issues. > > The trouble started when I wanted to implement a switch(4) instead > of the bridge(4): > > I moved /etc/hostname.bridge0 to /etc/hostname.switch0 > > prometheus$ cat /etc/switchd.conf > device "/dev/switch0" > > switchd was enabled via rcctl > > When I rebooted the system the client on em1 no longer got a dhcp > response and can't ping 10.0.0.1 > > ifconfig snippet: > > switch0: flags=41 > index 6 llprio 3 > groups: switch > datapath 0x264921d244b07e9a maxflow 1 maxgroup 1000 > vether0 flags=0<> > port 7 ifpriority 0 ifcost 0 > em1 flags=0<> > port 2 ifpriority 0 ifcost 0 > em2 flags=0<> > port 3 ifpriority 0 ifcost 0 > vether0: flags=8943 \ > mtu 1500 > lladdr fe:e1:ba:d0:0b:ca > index 7 priority 0 llprio 3 > groups: vether > media: Ethernet autoselect > status: active > inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255 > > > With tcpdump on vether0 I see the arp requests from the client for > 10.0.0.1 but vether0 doesn't respond. > > I see the same arp traffic on switch0 and em1 via tcpdump too. > > The switch seems to have learned the mac address of the client: > > prometheus$ switchctl show macs > SwitchPortTypeNameInfo > 1 2 mac f0:de:f1:23:13:37 age 3s > > Unfortunately, I don't really know how to dig any deeper at this issue. > Does anyone here see a glaring mistake or would be able to nudge me in > a better direction? > > Thanks, > > John > -- Kindest regards, Tom Smyth.
Re: disk setup question
Aleksander De wrote: > Are there any downsides or potential issues which may happen when > extending boundaries for OpenBSD partition on >2TB disk while using > MBR for booting it at the same time? I need MBR otherwise the machine > will not boot. BIOS/RAID controller does not support UEFI. The BIOS will use the MBR to identify the bootable partition. Then it will load the PBR sector as code, jump to it, and then load further bootblock code, and kernel after that. It is important to not have the root partition in an earlier part of the disk (I'm being intentionally vague). But our bootcode does not care about the partition limits. What happens is disklabel looks at the MBR partition limits -- when non-MBR partitions (ie disklabel partitions) are being created, usually during install. Beyond that, the MBR size is never looked at again. Where MBR partition limits can matter, is if you go back to disklabel again manually to create partitions. It's splitting the disk up. If you are not careful, you could create overlaps. This mostly happens to people putting multiple operating systems on a machine. Those people need to be careful. Everyone else can ignore this.
Re: wg(4) listen on a specific interface / address
> On Oct 29, 2020, at 11:21 AM, Pierre Emeriaud > wrote: > > Le jeu. 29 oct. 2020 à 00:09, Brian Brombacher a > écrit : >> >> Scratch that, use the ifconfig wgrtable option to specify separate routing >> domains for the port 53. This lets you initiate many. You still need to >> deal with getting the IP pointing at the right routing domain now. > > I'm already using wgrtable and rdomains, and I can't change the > outside interface to use another rtable. This won't solve the fact > that wg is still trying to bind to INADDR_ANY. > Then there’s a misconfiguration, wg driver bug, or the driver documentation is wrong in ifconfig about wgrtable. Routing domains are where you can specify multiple conflicting port binds and be fine, INADDR_ANY included.
Re: Chromium not starting on Thinkpad R40E with 6.8
Hi Anthony did you manage to try to move the chrome profile directory
so that you start with a fresh profile like As
On Thu, 29 Oct 2020 at 11:26, Anthony Campbell wrote:
>
> On 28 Oct 2020, Stuart Henderson wrote:
> > On 2020-10-28, Anthony Campbell wrote:
> > > I upgraded to the i386 version of 6.8-Release on three different
> > > Thinkpads R40E. On all of them, chromium fails to start, saying "Unable
> > > to allocate memory".
> >
> > How does your datasize limit look? Try bumping it as high as it will go
> > ("infinity" in login.conf, which I think results in 3145728 in ulimit -d)
> > and see if that helps.
> >
> > If it doesn't work at all please let me know so I can disable it on i386
> > and stop wasting time in the i386 bulk builds, it takes about 28 hours to
> > build which is a lot of time tying up the machine if the results are
> > useless :)
> >
> > iridium may do better (at least for a while..)
> >
> >
> Thanks for your reply, Stuart. Increasing the datasize limit as you
> suggested doesn't solve the problem, I'm afraid, but iridium does work
> I'm glad to say. Many thanks.
>
> Anthony
> --
> Anthony Campbellhttps://www.acampbell.uk
>
--
Kindest regards,
Tom Smyth.
Re: suggestion for the installer
it possibly an inline indicator on wired on question which interface do you want to configure em0, em1 (down), em2down) [em0] : but wireless interfaces will always be down before you associate with the AP... that said if using DHCP it is pretty obvious when a link is down... and on a static ip you know how to set it so you know how to run ifconfig to diagnose it... I dont feel that strongly about it ... but i can see it would help in some situation ... so if there is an existing network status line in the installer perhaps appending a lnk down message there would be helpful without impacting someone's terminal (as highlighted by Theo and Nick) All the best, Tom Smyth On Thu, 29 Oct 2020 at 16:10, Theo de Raadt wrote: > > Nick Holland wrote: > > > On 2020-10-29 08:00, Harald Dunkel wrote: > > > Hi folks, > > > > > > do you think it would be possible for the installer to show > > > an eye-catching warning, if "ifconfig" reports "no carrier" > > > for the network port to configure? > > > > > > Just a suggestion, of course > > > Harri > > > > Why? > > What problem are you trying to solve, and how many are you > > planning on making for me in the process? > > > > I often end up setting up OpenBSD systems with no network > > attached. Nothing to warn me about. > > > > I very often install OpenBSD configuring several NICs when > > only one has a network currently. Again, PLEASE don't give > > me three, five or ten bogus warning messages. > > Precisely. vertical screen real-estate is valuable. People > often look up higher at what they've already done, and a warning > would consume 1 line per interface, and reduce the visible context > for a person performing an multi-network install manually, thereby > increasing potential error. > -- Kindest regards, Tom Smyth.
Issues converting from bridge(4) to switch(4)
Howdy misc, I have an APU2 with the following configuration under 6.8: em0 = WAN em1 = bridge0 LAN em2 = bridge0 LAN vether = 10.0.0.1 prometheus$ cat /etc/hostname.bridge0 add vether0 add em1 add em2 up prometheus$ cat /etc/hostname.vether0 inet 10.0.0.1 255.255.255.0 10.0.0.255 I have dhcpd listening on vether0 and it works just fine. I have a client connected to em1 and it can ping 10.0.0.1 with no issues. The trouble started when I wanted to implement a switch(4) instead of the bridge(4): I moved /etc/hostname.bridge0 to /etc/hostname.switch0 prometheus$ cat /etc/switchd.conf device "/dev/switch0" switchd was enabled via rcctl When I rebooted the system the client on em1 no longer got a dhcp response and can't ping 10.0.0.1 ifconfig snippet: switch0: flags=41 index 6 llprio 3 groups: switch datapath 0x264921d244b07e9a maxflow 1 maxgroup 1000 vether0 flags=0<> port 7 ifpriority 0 ifcost 0 em1 flags=0<> port 2 ifpriority 0 ifcost 0 em2 flags=0<> port 3 ifpriority 0 ifcost 0 vether0: flags=8943 \ mtu 1500 lladdr fe:e1:ba:d0:0b:ca index 7 priority 0 llprio 3 groups: vether media: Ethernet autoselect status: active inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255 With tcpdump on vether0 I see the arp requests from the client for 10.0.0.1 but vether0 doesn't respond. I see the same arp traffic on switch0 and em1 via tcpdump too. The switch seems to have learned the mac address of the client: prometheus$ switchctl show macs SwitchPortTypeNameInfo 1 2 mac f0:de:f1:23:13:37 age 3s Unfortunately, I don't really know how to dig any deeper at this issue. Does anyone here see a glaring mistake or would be able to nudge me in a better direction? Thanks, John
Re: Using ports and updates to the release
Thanks Stuart, That was quite a complete answer. I think in my case to be certain any errors I might find using ports are not due to something outdated on my system I should follow your instructions and pull the updated CVS first especially after doing a release upgrade. Regards Ed Gray On Thu, 29 Oct 2020, 10:35 am Stuart Henderson, wrote: > On 2020-10-28, Ed Gray wrote: > > Hi Marc, > > > > Thanks for your reply. I think maybe this belongs to ports more than > misc. > > But it's a general query about releases and ports as well. > > > > My question was actually about updating the ports tree from an older > > release version before trying to use it rather than whether to use ports > or > > packages. > > The ports tree does not install things directly, it *always* builds > packages. > "make install" runs pkg_add to install the locally built package. Unless > you > modify the ports or there's some non-deterministic build behaviour (which > would > usually be considered a bug in the port) there's no difference whether you > build it yourself or use a pre-built package, just an increased chance of > frustration if things don't work (and there are more things that can go > wrong). > > > I installed 6.2 release I believe and later upgraded to 6.6 release. I > > pulled the release version of ports at some point and later tried to > build > > a port which failed due to an outdated dependency. My version of the > ports > > tree was outdated but even the newer 6.6 stable version was also > outdated. > > When I sent my original email 6.6 was still one of the supported releases > > along with 6.7. > > > > I guess my question is if I run 6.x release and want to build port xyz > can > > I expect a port to build using the ports tree that came with the 6.x > > release or must I always use at least the stable version of the ports > tree? > > If you run release X.Y then the supported options are to use a ports tree > with > cvs tag OPENBSD_X_Y_BASE (the tree at the time of release) or OPENBSD_X_Y > (-stable). > > > The following question is then if I have a problem building a port due to > > an outdated dependency on a supported release should I report it as an > > issue with the port even if a newer release of openbsd does not have the > > issue? > > Excepting minor problems (not usually seen for releases but sometimes seen > in > -current) the tree at a particular checkout should be internally > consistent, > the dependencies needed are in that tree. We build complete sets of > packages > on the faster architectures several times a week so problems with this > would > show up. > > If you mean an outdated dependency *on your system* rather than in the > ports > tree then that would be because you haven't updated installed packages > first. > (There will also likely be a mixture of library versions that will cause > conflicts if you build ports with the system in this stage). > > If you really want to build from ports to update your system then you > either > need to deal with figuring out which to build first to avoid incorrect > combinations (noting that some ports cannot be built, or cannot be > *correctly* > built, while an older version of themselves is already installed), or > uninstall > all packages and build the complete set that you want. > > Otherwise the standard procedure is update base, pkg_add -u, cvs up the > ports > tree for the branch that matches the OpenBSD version you're running, and > then > you can expect that versions of dependencies are usually correct (special > case: > if you run a slow architecture with -current snapshots, the package > snapshot > might be too old to be useful, in that case you will need to build a bunch > more yourself). > > >
Re: Chromium not starting on Thinkpad R40E with 6.8
I wrote earlier in ports the same problem
https://marc.info/?l=openbsd-ports=159241946411948=2
Unfortunately, I could not find a solution.
I think chromium is broken on i386
On 2020-10-28, Anthony Campbell wrote:
> I upgraded to the i386 version of 6.8-Release on three different
> Thinkpads R40E. On all of them, chromium fails to start, saying "Unable
> to allocate memory".
How does your datasize limit look? Try bumping it as high as it will go
("infinity" in login.conf, which I think results in 3145728 in ulimit -d)
and see if that helps.
If it doesn't work at all please let me know so I can disable it on i386
and stop wasting time in the i386 bulk builds, it takes about 28 hours to
build which is a lot of time tying up the machine if the results are
useless :)
iridium may do better (at least for a while..)
Re: wg(4) listen on a specific interface / address
On 10/29/20 5:20 PM, Kevin Chadwick wrote: > I believe it actually operates at layer 2/3 below IP and uses the default gw > IP > to decide where to operate for a peer to peer link. I'm not actually sure how that makes any sense as it uses UDP which is layer 4. But this says layer 3 "https://www.wireguard.com/papers/wireguard.pdf;
Re: wg(4) listen on a specific interface / address
On 10/29/20 4:00 PM, Pierre Emeriaud wrote: >>> Is there a reason why wg needs such a large bind? >> I don't know why wg does that, because I haven't looked at the code. >> Your configuration is definately pushing the limits. > Allright many thanks Theo. Maybe Jason can chime in on this topic. I believe it actually operates at layer 2/3 below IP and uses the default gw IP to decide where to operate for a peer to peer link. I could be totally wrong and I just hit some Windows bugs but I had issues getting the Windows clients to work for more than a few seconds on a LAN around 6 months ago and that was my conclusion (designed for easy internet use). I just used OpenSSH tunnels instead?
Re: wg(4) listen on a specific interface / address
Le jeu. 29 oct. 2020 à 16:40, Theo de Raadt a écrit : > > > Is there a reason why wg needs such a large bind? > > I don't know why wg does that, because I haven't looked at the code. > Your configuration is definately pushing the limits. Allright many thanks Theo. Maybe Jason can chime in on this topic. regards pierre
Re: suggestion for the installer
Nick Holland wrote: > On 2020-10-29 08:00, Harald Dunkel wrote: > > Hi folks, > > > > do you think it would be possible for the installer to show > > an eye-catching warning, if "ifconfig" reports "no carrier" > > for the network port to configure? > > > > Just a suggestion, of course > > Harri > > Why? > What problem are you trying to solve, and how many are you > planning on making for me in the process? > > I often end up setting up OpenBSD systems with no network > attached. Nothing to warn me about. > > I very often install OpenBSD configuring several NICs when > only one has a network currently. Again, PLEASE don't give > me three, five or ten bogus warning messages. Precisely. vertical screen real-estate is valuable. People often look up higher at what they've already done, and a warning would consume 1 line per interface, and reduce the visible context for a person performing an multi-network install manually, thereby increasing potential error.
Re: Can't cron sct.
> On 27. Oct 2020, at 16:10, avv. Nicola Dell'Uomo > wrote: > > maybe I'm missing something trivial, but I can't figure out how to cron sct(1) > > My user cron config works and cron log reports sct was executed, but screen > temp doesn't change ... > > Here's my user crontab: > > # $OpenBSD: crontab,v 1.28 2020/04/18 17:22:43 jmc Exp $ > # > # SHELL=/bin/sh > PATH=/bin:/sbin:/usr/bin:/usr/sbin > HOME=/var/log > # > #minute hourmdaymonth wday[flags] command > # > # rotate log files every hour, if necessary > # 3519 * * * touch /home/nicola/sct > > 3519 * * * /usr/local/bin/sct 5000 > > # touch /home/nicola/sct was a test in order to verify I had not > misconfigured crontab. > # cron was tested with SHELL variable defined and then commented out and the > result was the same. FYI, there is a small sctd in the sct package, which probably does exactly what you try to achieve manually here.
Re: wg(4) listen on a specific interface / address
Pierre Emeriaud wrote: > Le jeu. 29 oct. 2020 à 01:20, Theo de Raadt a écrit : > > > > I believe you are running into the restriction that we don't allow an > > INADDR_ANY:port binding to be done after a ipaddr:port binding has been > > done. It must be done beforehands. > > Sorry Theo, maybe things got lost in translation, but if my > understanding is correct this is not exactly the case here. wg is > trying to bind to INADDR_ANY, which fails because a dns daemon (in my > case) is already bound to 127.0.0.1:53 (in wg_socket_open() -L700 of > if_wg.c-, sin->sin_addr.s_addr = INADDR_ANY?). > > Is there a reason why wg needs such a large bind? I don't know why wg does that, because I haven't looked at the code. Your configuration is definately pushing the limits.
Re: wg(4) listen on a specific interface / address
Le jeu. 29 oct. 2020 à 01:20, Theo de Raadt a écrit : > > I believe you are running into the restriction that we don't allow an > INADDR_ANY:port binding to be done after a ipaddr:port binding has been > done. It must be done beforehands. Sorry Theo, maybe things got lost in translation, but if my understanding is correct this is not exactly the case here. wg is trying to bind to INADDR_ANY, which fails because a dns daemon (in my case) is already bound to 127.0.0.1:53 (in wg_socket_open() -L700 of if_wg.c-, sin->sin_addr.s_addr = INADDR_ANY?). Is there a reason why wg needs such a large bind?
Re: wg(4) listen on a specific interface / address
Le jeu. 29 oct. 2020 à 00:09, Brian Brombacher a écrit : > > Scratch that, use the ifconfig wgrtable option to specify separate routing > domains for the port 53. This lets you initiate many. You still need to > deal with getting the IP pointing at the right routing domain now. I'm already using wgrtable and rdomains, and I can't change the outside interface to use another rtable. This won't solve the fact that wg is still trying to bind to INADDR_ANY.
Re: suggestion for the installer
Hi Harald, If im not mistaken when the installer is running when you configure dhcp on the interface t will warn you that it is not receiving any leases. I can see your concerns about the static ip configuration at a guess I think the issue is there is no config on the interfaces so they havent yet been instructed to start or put a config on them... as a workaround when you start up the installer you can select shell or hit c to exit the installer back to a shell and you can can do ifconfig interface name or ifconfig interface_name up and when you are done checking you can run the install to restart the install process I hope this helps a little On Thu, 29 Oct 2020 at 12:06, Harald Dunkel wrote: > > Hi folks, > > do you think it would be possible for the installer to show > an eye-catching warning, if "ifconfig" reports "no carrier" > for the network port to configure? > > Just a suggestion, of course > Harri > -- Kindest regards, Tom Smyth.
Re: suggestion for the installer
On 2020-10-29 08:00, Harald Dunkel wrote: > Hi folks, > > do you think it would be possible for the installer to show > an eye-catching warning, if "ifconfig" reports "no carrier" > for the network port to configure? > > Just a suggestion, of course > Harri Why? What problem are you trying to solve, and how many are you planning on making for me in the process? I often end up setting up OpenBSD systems with no network attached. Nothing to warn me about. I very often install OpenBSD configuring several NICs when only one has a network currently. Again, PLEASE don't give me three, five or ten bogus warning messages. Usually if I'm doing an install, I look to see if the link light on the NIC and the switch port is lit. If I'm using DHCP, I'll quickly know if there's a network problem. Come to think of it, if I'm NOT using DHCP, I'll quickly know, too. If I'm installing to an unknown system, I almost always first drop to (s)hell from the installer, look at my dmesg, look at the network port options and see if I'm plugged into the NIC port I think I am (ifconfig), look at my disks to see if they are recognized as I expect and see if I'm about to clobber something I might consider important. So...I think what you are trying to accomplish can be done as things are without adding to the wonderfully simple OpenBSD installer. Nick.
Correct way to implement an IDS between relayd and httpd
Hello misc users,
I'm trying to have my http SSL protocol to be terminated by relayd, and then
the resulting plain http protocol to be filtered by some WAF before being
passed to httpd
I'm currently trying with suricata since it's in packages, but I'm open to
suggestions.
What would be the correct way to use an IDS between relayd and httpd ?
If anyone had some tips to do it correctly it would be really helpfull.
The goal design is :
[web client WEB TCP443] => [Relayd (public ip)] => [TCP8180 Suricata] =>
[TCP8080 Httpd]
I've currently managed to make relayd "relay to" httpd and it's working great !
However, I'm not to sure how do filtering with an IPS in the middle of relayd
and httpd...
It seems that suricata can be reading both an unix-socket file OR a network
interface
Could be running it :
suricata -i vmx0 -d 8080
=> but I would inspect all the trafic not just the HTTP protocol I got out of
relayd so I think it would be messy ?
=> not sure if it is possible to tell suricata to read from 8180, to filter
dangerous packets, and write output to 8180 per exemple ?
Maybe I could use socat to take relayd output (port TCP 8180) an bind it as a
sock file ?
socat -d -d TCP4-LISTEN:8180,fork UNIX-CONNECT:/var/suricata/suricata.sock
And then read from this socket and give output to httpd :
suricata -c /etc/suricata/suricata.yaml --unix-socket
/var/suricata/suricata.sock -d 8080
But I get an error : - [ERRCODE: SC_ERR_MULTIPLE_RUN_MODE(126)] - more
than one run mode has been specified
Pasted important parts of my working config without suricata in the middle, in
case it helps...
Using OpenBsd 7.8 stable
vi /etc/pf.conf
pass in on egress proto tcp from any to any port 80
pass in on egress proto tcp from any to any port 443
vi /etc/relayd.conf
relay "wwwsecure4" {
listen on $external_ipv4 port 443 tls
protocol wwwsecure
forward to 127.0.0.1 port 8080
}
vi /etc/httpd.conf:
server "preprod.alienconsulting.net" {
listen on 127.0.0.1 port 8080
root "/htdocs/notSoMuchTrustedWebsite"
directory index "index.php"
location "/*.php" {
fastcgi socket "/run/php-fpm.sock"
}
}
Regards,
Romain
Re: disk setup question
On Thu, Oct 29, 2020 at 02:44:39PM +0100, Aleksander De wrote:
> Hi.
>
> Are there any downsides or potential issues which may happen when
> extending boundaries for OpenBSD partition on >2TB disk while using
> MBR for booting it at the same time? I need MBR otherwise the machine
> will not boot. BIOS/RAID controller does not support UEFI.
>
> Here you can see MBR with its 2TB limit:
> # fdisk sd0
> Disk: sd0 geometry: 267349/255/63 [4294961685 Sectors]
> Offset: 0 Signature: 0xAA55
> Starting Ending LBA Info:
> #: id C H S - C H S [ start:size ]
> ---
> 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
> 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
> 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
> *3: A6 0 4 5 - 267342 56 42 [ 256: 4294852544 ] OpenBSD
>
> In disklabel I have extended boundaries ('b' command') in order to be able to
> utilize whole disk - and use big encrypted partition 'e'. I have small
> root partition at the beginning in order to boot from it and access from
> remote via ssh + decrypt big partition manually, then start services.
>
> # disklabel sd0
> # /dev/rsd0c:
> type: SCSI
> disk: SCSI disk
> label: Block Device
> duid: 288724ae82038959
> flags:
> bytes/sector: 512
> sectors/track: 255
> tracks/cylinder: 511
> sectors/cylinder: 130305
> cylinders: 44967
> total sectors: 5859442688
> boundstart: 256
> boundend: 5859442688
> drivedata: 0
>
> 16 partitions:
> #size offset fstype [fsize bsize cpg]
> a: 14724192 256 4.2BSD 2048 16384 12960 # /
> b: 16809362 14724448swap# none
> c: 58594426880 unused
> d: 14724192 31533824 4.2BSD 2048 16384 1
> e: 5813184640 46258048RAID
>
> the same in more human-readable form:
> # disklabel -E sd0
> Label editor (enter '?' for help at any prompt)
> sd0> p g
> OpenBSD area: 256-5859442688; size: 2794.0G; free: 0.0G
> #size offset fstype [fsize bsize cpg]
> a: 7.0G 256 4.2BSD 2048 16384 12960 # /
> b: 8.0G 14724448swap# none
> c: 2794.0G0 unused
> d: 7.0G 31533824 4.2BSD 2048 16384 1
> e: 2771.9G 46258048RAID
>
> I don't need whole 3TB now, just feel better knowing that I can use it safe.
> If it may cause some issues I can keep 2TB limit to OpenBSD partition.
> --
> Aleksander
>
I know of no issue doing that, you should be fine.
-Otto
disk setup question
Hi.
Are there any downsides or potential issues which may happen when
extending boundaries for OpenBSD partition on >2TB disk while using
MBR for booting it at the same time? I need MBR otherwise the machine
will not boot. BIOS/RAID controller does not support UEFI.
Here you can see MBR with its 2TB limit:
# fdisk sd0
Disk: sd0 geometry: 267349/255/63 [4294961685 Sectors]
Offset: 0 Signature: 0xAA55
Starting Ending LBA Info:
#: id C H S - C H S [ start:size ]
---
0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
*3: A6 0 4 5 - 267342 56 42 [ 256: 4294852544 ] OpenBSD
In disklabel I have extended boundaries ('b' command') in order to be able to
utilize whole disk - and use big encrypted partition 'e'. I have small
root partition at the beginning in order to boot from it and access from
remote via ssh + decrypt big partition manually, then start services.
# disklabel sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: Block Device
duid: 288724ae82038959
flags:
bytes/sector: 512
sectors/track: 255
tracks/cylinder: 511
sectors/cylinder: 130305
cylinders: 44967
total sectors: 5859442688
boundstart: 256
boundend: 5859442688
drivedata: 0
16 partitions:
#size offset fstype [fsize bsize cpg]
a: 14724192 256 4.2BSD 2048 16384 12960 # /
b: 16809362 14724448swap# none
c: 58594426880 unused
d: 14724192 31533824 4.2BSD 2048 16384 1
e: 5813184640 46258048RAID
the same in more human-readable form:
# disklabel -E sd0
Label editor (enter '?' for help at any prompt)
sd0> p g
OpenBSD area: 256-5859442688; size: 2794.0G; free: 0.0G
#size offset fstype [fsize bsize cpg]
a: 7.0G 256 4.2BSD 2048 16384 12960 # /
b: 8.0G 14724448swap# none
c: 2794.0G0 unused
d: 7.0G 31533824 4.2BSD 2048 16384 1
e: 2771.9G 46258048RAID
I don't need whole 3TB now, just feel better knowing that I can use it safe.
If it may cause some issues I can keep 2TB limit to OpenBSD partition.
--
Aleksander
suggestion for the installer
Hi folks, do you think it would be possible for the installer to show an eye-catching warning, if "ifconfig" reports "no carrier" for the network port to configure? Just a suggestion, of course Harri
Re: Chromium not starting on Thinkpad R40E with 6.8
On 28 Oct 2020, Stuart Henderson wrote:
> On 2020-10-28, Anthony Campbell wrote:
> > I upgraded to the i386 version of 6.8-Release on three different
> > Thinkpads R40E. On all of them, chromium fails to start, saying "Unable
> > to allocate memory".
>
> How does your datasize limit look? Try bumping it as high as it will go
> ("infinity" in login.conf, which I think results in 3145728 in ulimit -d)
> and see if that helps.
>
> If it doesn't work at all please let me know so I can disable it on i386
> and stop wasting time in the i386 bulk builds, it takes about 28 hours to
> build which is a lot of time tying up the machine if the results are
> useless :)
>
> iridium may do better (at least for a while..)
>
>
Thanks for your reply, Stuart. Increasing the datasize limit as you
suggested doesn't solve the problem, I'm afraid, but iridium does work
I'm glad to say. Many thanks.
Anthony
--
Anthony Campbellhttps://www.acampbell.uk
Re: Using ports and updates to the release
On 2020-10-28, Ed Gray wrote: > Hi Marc, > > Thanks for your reply. I think maybe this belongs to ports more than misc. > But it's a general query about releases and ports as well. > > My question was actually about updating the ports tree from an older > release version before trying to use it rather than whether to use ports or > packages. The ports tree does not install things directly, it *always* builds packages. "make install" runs pkg_add to install the locally built package. Unless you modify the ports or there's some non-deterministic build behaviour (which would usually be considered a bug in the port) there's no difference whether you build it yourself or use a pre-built package, just an increased chance of frustration if things don't work (and there are more things that can go wrong). > I installed 6.2 release I believe and later upgraded to 6.6 release. I > pulled the release version of ports at some point and later tried to build > a port which failed due to an outdated dependency. My version of the ports > tree was outdated but even the newer 6.6 stable version was also outdated. > When I sent my original email 6.6 was still one of the supported releases > along with 6.7. > > I guess my question is if I run 6.x release and want to build port xyz can > I expect a port to build using the ports tree that came with the 6.x > release or must I always use at least the stable version of the ports tree? If you run release X.Y then the supported options are to use a ports tree with cvs tag OPENBSD_X_Y_BASE (the tree at the time of release) or OPENBSD_X_Y (-stable). > The following question is then if I have a problem building a port due to > an outdated dependency on a supported release should I report it as an > issue with the port even if a newer release of openbsd does not have the > issue? Excepting minor problems (not usually seen for releases but sometimes seen in -current) the tree at a particular checkout should be internally consistent, the dependencies needed are in that tree. We build complete sets of packages on the faster architectures several times a week so problems with this would show up. If you mean an outdated dependency *on your system* rather than in the ports tree then that would be because you haven't updated installed packages first. (There will also likely be a mixture of library versions that will cause conflicts if you build ports with the system in this stage). If you really want to build from ports to update your system then you either need to deal with figuring out which to build first to avoid incorrect combinations (noting that some ports cannot be built, or cannot be *correctly* built, while an older version of themselves is already installed), or uninstall all packages and build the complete set that you want. Otherwise the standard procedure is update base, pkg_add -u, cvs up the ports tree for the branch that matches the OpenBSD version you're running, and then you can expect that versions of dependencies are usually correct (special case: if you run a slow architecture with -current snapshots, the package snapshot might be too old to be useful, in that case you will need to build a bunch more yourself).
Re: Chromium not starting on Thinkpad R40E with 6.8
On 28 Oct 2020, Stuart Henderson wrote: > On 2020-10-28, Ashton Fagg wrote: > > Anthony Campbell writes: > > > >> I upgraded to the i386 version of 6.8-Release on three different > >> Thinkpads R40E. On all of them, chromium fails to start, saying "Unable > >> to allocate memory". > >> > >> I suppose these are so ancient that it's hardly surprising (can't be > >> mamy still around), but I thought I'd report it anyway. Here is the > >> dmesg: > > > > Two questions and a suggestion: > > > > 1. How much memory do the machines have? > > > > 2. Can you run chrome from the command line and post what gets put into > > stdout/stderr? > > Both were answered in Anthony's original mail - "Unable to allocate > memory" for your second q, and 2GB for the first (check the dmesg output). > FWIW, firefox runs without problems. -- Anthony Campbellhttps://www.acampbell.uk
