Re: dhcpleased and ifstated
Christer Solskogen wrote: > This happens every time with dhcpleased and my ISP and it didn't with > dhclient, and what I do see now, that I didn't see with dhclient, > is that during the negotiation ifconfig says that the interface has > "status: no carrier" for 2-3 seconds. Which explains why I don't get a > DHCPACK within 1 second. Is this specific to a particular network driver? I am suggesting some drivers may have shitty / sloppy coming-up behaviour. Or, that dhcpleased is going to need to be more forgiving. Or maybe as a result of the timeout policy it practices, it works different than dhclient did, and maybe that is not surprising?
Re: Installing sets from /
On 7/13/22 1:11 PM, Vincent Legoll wrote: Hello, I was trying to autoinstall OpenBSD 7.1 on a VM when I stumbled upon something unexpected (to my uneducated eyes) in the installer. What I'm trying to do may very well fall in the "unsupported" basket, just tell me. But still, I think I can at least ask if this is actually intended behavior. When I used the following answers: [...] Location of sets = disk Is the disk partition already mounted = yes Pathname to the sets = / [...] I expected the setup to look at the / (from the ramdisk), but it searched in /mnt2 instead. As a user, I'd expect the response there to be "As would be seen on the running system." As a user, I expect it to go something like this: I put the install sets someplace on the running systemm, say /home/upgrade or /usr/rel. I rebooted into bsd.rd, chose "install" or "upgrade", I expect to answer exactly where I put the files. How the upgrader or installer does the upgrade or install, I really don't care." The installer happens to mount the system hanging off /mnt2, but I shouldn't have to know that. I definitely shouldn't have to include that in my answer (in my opinion) ... Is this in need for a modification, or is it good as-is ? I can submit a patch if you think it is useful. Speaking only for myself, I think it is working exactly as I'd hope right now. I would spend some time thinking about why you are stuffing the install files into the ramdisk rather than from an existing file system or other more supported option. I think the "proper" answers will work better for you all around. Nick.
Re: Browser access to file system on new install OpenBSD missing.
On 7/13/22 12:05 AM, Courtney wrote: This is definitely an unveil issue. Not an issue though, it's by design. If you try to download a file both Firefox and Chromium won't know where to save it. By default, they can read/write to ~/Downloads like others have said. However, I think I know the issue you are encountering. I recall at first use it is a bit persnickety, so when presented with the window so save a file to a location you will see nothing. However, in the top bar if you type ~/Downloads and hit enter it will draw you immediately to the Downloads folder, and there you can hit save. Also as others have said, Midori and Thunderbird don't have this issue because neither of them use unveil. It would be really cool if one day at least Thunderbird did. Courtney On 7/10/22 23:46, Brian Durant wrote: I have a problem with both Firefox and Chromium being unable to access the file system using the "open" dialog. The dialog appears, but no files or directories appear regardless of path. Things function normally however, with both Midori and Thunderbird. I assume that Firefox and Chromium are experiencing a permissions issue, but what causes it and how to rectify it is beyond my capabilities as a new OpenBSD user. Anyone out there that could help me out? Thanks in advance. I have reinstalled the system. It appears to be an issue that depends on which file manager is used to create the directories within the home directory. This time (as with my other computer) I used Xfe to create the directories. Last time, I used PCmanFM and experienced the problem. Firefox works as expected now. Thanks. Brian
Installing sets from /
Hello, I was trying to autoinstall OpenBSD 7.1 on a VM when I stumbled upon something unexpected (to my uneducated eyes) in the installer. What I'm trying to do may very well fall in the "unsupported" basket, just tell me. But still, I think I can at least ask if this is actually intended behavior. When I used the following answers: [...] Location of sets = disk Is the disk partition already mounted = yes Pathname to the sets = / [...] I expected the setup to look at the / (from the ramdisk), but it searched in /mnt2 instead. The error message was helpful: Looked at file:///mnt2// and found no OpenBSD/amd64 [...] After having had a look at install_mounted_fs() in distrib/miniroot/install.sub I can see why it happened like that. But the comments in the install.sub file say that it should "# Accept a valid absolute path.". But as this is only checked after the /mnt2 & /mnt tests, it may do something different whether they contain something related to your answer or not. I managed to workaround this by telling it to use ../ instead of /, and it worked, so I have a solution for my needs. Is this in need for a modification, or is it good as-is ? I can submit a patch if you think it is useful. Thanks -- Vincent Legoll
Re: mSATA in APU2D0
> [...] I have not had time to upgrade any of my APU systems to anything newer > than 6.8, so I > cannot personally attest that mSATA definitely works in 6.9+ This is one reason that incompatibilities sleeps thru: people run old versions of software, the new ones don't reach the specific hardware and are not tested on that specific usage case, then they decide to upgrade 3 versions or more and problems begins to appear. Happy debug time with 3 versions on your neck!
Re: mSATA in APU2D0
On Wed, Jul 6, 2022 at 7:33 AM Jan Stary wrote: > This is current/amd64 on an APU2D0, dmesg below > Everything runs just fine from a SD card. > > My problem is it does not boot with this mSATA disk in. > The leds of the mSATA and the leds of the APU keep blinking, > the console keeps repeating > > PC Engines apu2 > coreboot build 2006 > BIOS version v4.17.0.1 > > and it never gets past that. > It has booted _once_, but not since. > > Without the mSATA, it boots fine. > I have tested the mSATA disk in other machines > and adaptors and it seems to work fine. > > Is this some kind of HW incompatibility? > How can I debug what's happening? > I have run 6.4/amd64, 6.7/amd64, 6.8/amd64 on an APU2E4 from mSATA, and I've run 6.4/amd64 on an APU2D4 from mSATA. All machines worked fine, but I did not have SD cards installed in any of them. The OS install was done directly to the mSATA devices, booting from a USB stick. All of my mSATA devices are small, either 30GB (from PC Engines) or 32GB (Innodisk). using mSATA only I did not have to change anything in the BIOS regarding boot order. I have 3 suggestions: First, there might be a compatibility issue with coreboot. I can confirm that Coreboot build 20170228/SeaBIOS 1.10.0.1 worked for me on both the APU2D4 and the APU2E4. Second, based on the constant rebooting I am guessing that the BIOS is having trouble recognizing and/or loading the boot loader. If you did a UEFI install, try MBR. If it's MBR, make sure your OpenBSD slice is marked active (i.e. the one to boot from). Third, try installing 6.8 to be sure it's not something specific to -current. I would normally suggest 7.0 or 7.1 but I have not had time to upgrade any of my APU systems to anything newer than 6.8, so I cannot personally attest that mSATA definitely works in 6.9+. -ken
Re: OpenBGPD via (WG?) Tunnel Not Learning Routes
Heho, > Looking at the show nexthop output it seem bgpd does not get the RTM_IFINFO > message with the IFP_UP flag set. It still thinks the interface is down. This > is a bug > in wg(4) which probably sends the rt message before applying the flag. This makes a lot of sense; I am sadly not good enough with the codebase to supply a diff, but can test a patch if somebody writes one. With best regards, Tobias -Original Message- From: owner-m...@openbsd.org On Behalf Of Claudio Jeker Sent: Wednesday, 13 July 2022 13:13 To: Stuart Henderson Cc: misc@openbsd.org Subject: Re: OpenBGPD via (WG?) Tunnel Not Learning Routes On Wed, Jul 13, 2022 at 11:01:09AM -, Stuart Henderson wrote: > On 2022-07-13, Tobias Fiebig wrote: > > Heho, > > > > When doing what i described in my message, I get the below messages. > > > > When I set static routes, packet forwarding works fine, i.e.: > > > > gw02.dus01.as59645.net ~ # route add -inet6 2a06:d1c2::/48 > > 2a06:d1c0::dead:beef:c02 add net 2a06:d1c2::/48: gateway > > 2a06:d1c0::dead:beef:c02 > > > > bgp-test.test /etc # route add -inet6 default > > 2a06:d1c0::dead:beef:c01 add net default: gateway > > 2a06:d1c0::dead:beef:c01 > > > > Removing those routes and restarting the BGPD then also leads to a > > successful import of routes, see bgpctl sh nex at the bottom of this mail. > > > > It somehow feels like bgpd does not register that wg0 came up. > > Yes. > > You can check with "route -n monitor" that the route messages are > correctly sent when the interface is brought up, also try running bgpd > in the foreground with debug logging (bgpd -vvvd or so) and see if any > errors/warnings are logged when wg comes up. Looking at the show nexthop output it seem bgpd does not get the RTM_IFINFO message with the IFP_UP flag set. It still thinks the interface is down. This is a bug in wg(4) which probably sends the rt message before applying the flag. > > Let me try if this behavior is the same for other tunnels (eoip). > > Worth a try. Also maybe different between v4 and v6, WireGuard doesn't > really do v6 properly. The v4 part is also not great to be honest. Doing dynamic routing via WireGuard is just close to impossible with the way WireGuard is specified. It is not a simple tunnel but applies some route limits on top which you can't really disable. Also because of multicast issues you can't run ospfd over wg(4) so I had to put a gif tunnel in a wg tunnel to have dynamic routing. -- :wq Claudio
Re: OpenBGPD via (WG?) Tunnel Not Learning Routes
On Wed, Jul 13, 2022 at 11:01:09AM -, Stuart Henderson wrote: > On 2022-07-13, Tobias Fiebig wrote: > > Heho, > > > > When doing what i described in my message, I get the below messages. > > > > When I set static routes, packet forwarding works fine, i.e.: > > > > gw02.dus01.as59645.net ~ # route add -inet6 2a06:d1c2::/48 > > 2a06:d1c0::dead:beef:c02 > > add net 2a06:d1c2::/48: gateway 2a06:d1c0::dead:beef:c02 > > > > bgp-test.test /etc # route add -inet6 default 2a06:d1c0::dead:beef:c01 > > add net default: gateway 2a06:d1c0::dead:beef:c01 > > > > Removing those routes and restarting the BGPD then also leads to a > > successful import of routes, see bgpctl sh nex at the bottom of this mail. > > > > It somehow feels like bgpd does not register that wg0 came up. > > Yes. > > You can check with "route -n monitor" that the route messages are correctly > sent when the interface is brought up, also try running bgpd in the foreground > with debug logging (bgpd -vvvd or so) and see if any errors/warnings are > logged when wg comes up. Looking at the show nexthop output it seem bgpd does not get the RTM_IFINFO message with the IFP_UP flag set. It still thinks the interface is down. This is a bug in wg(4) which probably sends the rt message before applying the flag. > > Let me try if this behavior is the same for other tunnels (eoip). > > Worth a try. Also maybe different between v4 and v6, WireGuard doesn't really > do v6 properly. The v4 part is also not great to be honest. Doing dynamic routing via WireGuard is just close to impossible with the way WireGuard is specified. It is not a simple tunnel but applies some route limits on top which you can't really disable. Also because of multicast issues you can't run ospfd over wg(4) so I had to put a gif tunnel in a wg tunnel to have dynamic routing. -- :wq Claudio
Re: OpenBGPD via (WG?) Tunnel Not Learning Routes
Heho, As mentioned, I gave it a shot with eoip, and that worked as intended. What I noticed though, is that wg0 seems to stick around in bgpd, even after an ifconfig wg0 destroy; I fixed this by using another ip range for transfer and rebooting the downstream to make sure; In any case, with an eoip tunnel, things then worked. Maybe something that is sticky/not handled about wg? With best regards, Tobias ### After removing wg0 (ifconfig wg0 destroy), deconfiguring the peer, reloading bgpd, adding eoip0, and reconfig the peer bgp-test.test /etc # ifconfig wg0 wg0: no such interface bgp-test.test /etc # bgpctl sh nex Flags: * = nexthop valid Nexthop Route Prio Gateway Iface 2a06:d1c0::dead:beef:c01 2a06:d1c0::dead:beef:c01/128 3 connected wg0 (DOWN, unknown) 2a06:d1c0::dead:beef:c02 2a06:d1c0::dead:beef:c02/128 1 connected wg0 (DOWN, unknown) ### Adding an eoip tunnel; New IP range and reboot on downstream before doing 'rcctl bgpd start; mv hostname.eoip0 /etc; sh /etc/netstart eoip0; add peer to bgpd conf, bgpctl reload' bgp-test.test ~ # bgpctl sh nex Flags: * = nexthop valid Nexthop Route Prio Gateway Iface * 2a06:d1c0::dead:beef:d02 2a06:d1c0::dead:beef:d00/120132 connected eoip0 (UP, unknown)
Re: OpenBGPD via (WG?) Tunnel Not Learning Routes
On 2022-07-13, Tobias Fiebig wrote: > Heho, > > When doing what i described in my message, I get the below messages. > > When I set static routes, packet forwarding works fine, i.e.: > > gw02.dus01.as59645.net ~ # route add -inet6 2a06:d1c2::/48 > 2a06:d1c0::dead:beef:c02 > add net 2a06:d1c2::/48: gateway 2a06:d1c0::dead:beef:c02 > > bgp-test.test /etc # route add -inet6 default 2a06:d1c0::dead:beef:c01 > add net default: gateway 2a06:d1c0::dead:beef:c01 > > Removing those routes and restarting the BGPD then also leads to a successful > import of routes, see bgpctl sh nex at the bottom of this mail. > > It somehow feels like bgpd does not register that wg0 came up. Yes. You can check with "route -n monitor" that the route messages are correctly sent when the interface is brought up, also try running bgpd in the foreground with debug logging (bgpd -vvvd or so) and see if any errors/warnings are logged when wg comes up. > Let me try if this behavior is the same for other tunnels (eoip). Worth a try. Also maybe different between v4 and v6, WireGuard doesn't really do v6 properly.
Re: OpenBGPD via (WG?) Tunnel Not Learning Routes
Heho, When doing what i described in my message, I get the below messages. When I set static routes, packet forwarding works fine, i.e.: gw02.dus01.as59645.net ~ # route add -inet6 2a06:d1c2::/48 2a06:d1c0::dead:beef:c02 add net 2a06:d1c2::/48: gateway 2a06:d1c0::dead:beef:c02 bgp-test.test /etc # route add -inet6 default 2a06:d1c0::dead:beef:c01 add net default: gateway 2a06:d1c0::dead:beef:c01 Removing those routes and restarting the BGPD then also leads to a successful import of routes, see bgpctl sh nex at the bottom of this mail. It somehow feels like bgpd does not register that wg0 came up. Let me try if this behavior is the same for other tunnels (eoip). With best regards, Tobias ### Setting up wireguard interface after bgpd had been started bgp-test.test rem # bgpctl sh nex Flags: * = nexthop valid Nexthop Route Prio Gateway Iface 2a06:d1c0::dead:beef:c01 2a06:d1c0::dead:beef:c01/128 3 connected wg0 (DOWN, unknown) 2a06:d1c0::dead:beef:c02 2a06:d1c0::dead:beef:c02/128 1 connected wg0 (DOWN, unknown) bgp-test.test rem # ifconfig wg0 wg0: flags=80c3 mtu 1420 index 6 priority 0 llprio 3 wgport 13720 wgrtable 23 wgpubkey wgpeer wgpka 25 (sec) wgendpoint 2001:4ba0:92f4:3::235 2342 tx: 641944, rx: 7763244 last handshake: 33 seconds ago wgaip 0.0.0.0/0 wgaip ::/0 groups: wg inet6 2a06:d1c0::dead:beef:c02 prefixlen 120 bgp-test.test rem # bgpctl show Neighbor ASMsgRcvdMsgSent OutQ Up/Down State/PrfRcvd 2a06:d1c0::dead:beef:c0 59645 48128 12 0 00:04:06 133825 ### bgpctl sh nex after restarting bgpd bgp-test.test /etc # bgpctl sh nex Flags: * = nexthop valid Nexthop Route Prio Gateway Iface * 2a06:d1c0::dead:beef:c01 2a06:d1c0::dead:beef:c01/128 3 connected wg0 (UP, unknown) * 2a06:d1c0::dead:beef:c02 2a06:d1c0::dead:beef:c02/128 1 connected wg0 (UP, unknown) -Original Message- From: owner-m...@openbsd.org On Behalf Of Stuart Henderson Sent: Wednesday, 13 July 2022 08:14 To: misc@openbsd.org Subject: Re: OpenBGPD via (WG?) Tunnel Not Learning Routes On 2022-07-13, Tobias Fiebig wrote: > Heho, > I am running OpenBGPd (on 7.1+binpatches), and have some tunnel links between > hosts and up/downstreams over wg tunnels. > > I am basically wondering whether the behavior is known/normal and/or happened > to others, or if it is worth it to setup a test-setup to properly debug the > issue/document how it can be reproduced. > > Specifically, I noticed that bgpd will consider routes invalid which it > learns over a (wg?) interface that was not there when bgpd was started; So, > essentially: > > Start bgpd > Create wireguard interface, configure IPs Adjust bgpd config to add > new peer on that if. > bgpctl reload > > -> Session with the peer comes up, bgpd sees the routes, but it lacks the > 'valid' * flag. > > Restarting bgpd resolves this (but also lets all sessions flap). > > I did not see (or missed) something about this in the man page; The same > issue seems to not occur with other Interfaces added later, e.g., vlan. How does "bgpctl sh nex" look, both in the failed situation and the situation where wg was already created? -- Please keep replies on the mailing list.
Re: OpenBGPD via (WG?) Tunnel Not Learning Routes
On 2022-07-13, Tobias Fiebig wrote: > Heho, > I am running OpenBGPd (on 7.1+binpatches), and have some tunnel links between > hosts and up/downstreams over wg tunnels. > > I am basically wondering whether the behavior is known/normal and/or happened > to others, or if it is worth it to setup a test-setup to properly debug the > issue/document how it can be reproduced. > > Specifically, I noticed that bgpd will consider routes invalid which it > learns over a (wg?) interface that was not there when bgpd was started; So, > essentially: > > Start bgpd > Create wireguard interface, configure IPs > Adjust bgpd config to add new peer on that if. > bgpctl reload > > -> Session with the peer comes up, bgpd sees the routes, but it lacks the > 'valid' * flag. > > Restarting bgpd resolves this (but also lets all sessions flap). > > I did not see (or missed) something about this in the man page; The same > issue seems to not occur with other Interfaces added later, e.g., vlan. How does "bgpctl sh nex" look, both in the failed situation and the situation where wg was already created? -- Please keep replies on the mailing list.
