Re: Browser access to file system on new install OpenBSD missing.
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.
Re: USB audio garbled over time
I solved my issue. I started having this issue on Linux too, again very randomly. Tried a different USB port and everything works. Whatever is happening with the controller on these ports, it doesn't play nicely with audio hardware but the other one does. Pretty sure I went from USB 2.0 to USB 3.0, or 3.1 or whatever number of the 3 or 4 different versions I wound up with on this board. Courtney On 7/1/22 11:09, Courtney wrote: Sure enough, looks like it pauses. Before: name=uaudio0 mode=play,record pause=0 active=1 nblks=16 blksz=480 rate=48000 encoding=s16le play.channels=2 play.bytes=839040 play.errors=0 record.channels=2 record.bytes=839040 record.errors=0 After: name=uaudio0 mode=play,record pause=0 active=1 nblks=16 blksz=480 rate=48000 encoding=s16le play.channels=2 play.bytes=1827840 play.errors=0 record.channels=2 record.bytes=1827840 record.errors=0 How do you unpause it then? Courtney On 6/30/22 21:54, Alexandre Ratchov wrote: On Thu, Jun 30, 2022 at 03:11:18PM -0700, Courtney wrote: Hello everyone, I am running OpenBSD -current branch right now. I have a FiiO E10k plugged into my board. Here is the part of the dmesg when it is connected Jun 30 15:02:48 towerDefense /bsd: uaudio0 at uhub0 port 14 configuration 1 interface 2 "FiiO DigiHug USB Audio" rev 1.10/0.01 addr 6 Jun 30 15:02:48 towerDefense /bsd: uaudio0: class v1, full-speed, sync, channels: 2 play, 2 rec, 3 ctls Jun 30 15:02:48 towerDefense /bsd: audio1 at uaudio0 I have been trying to pinpoint an issue where after a time of being away from my computer, when I come back my audio isn't behaving. I'm not an audio guy so I will probably mess up some terms, sorry. The pitch sounds right but the audio has a lot of static in it. Normally this happens after I walk away from my computer and come back maybe an hour later. It doesn't go into any sleep state, only power efficiency mode that the monitors handle on their own. An rcctl restart sndiod doesn't solve the issue, I have to physically unplug and plug it, then run rcctl restart sndiod and all is back to normal. Nothing appears in the logs for me to report. What can I look at when I encounter this again to see what is being changed (if anything)? Or, maybe my hardware is just progressively giving up the ghost? This has been happening for a while now. When you walk away is it playing? you can run: audioctl -f /dev/audioctl1 to check device state before and after the walk (empty "mode" means it's closed, "pause=0" means it's playing or recording)
OpenBGPD via (WG?) Tunnel Not Learning Routes
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. With best regards, Tobias
Re: OpenBGPD via (WG?) Tunnel Not Learning Routes
Hello Tobias, Next hop Validation to make routes valid ? asks the question is the Next hop reachable... so if you look at the prefixes learned and the next hop... you may need additional routes to make the next hop visible (via an Interior Routing Protocol o) (OSPF RIP / EIGRP) or Static Routes ... Tip to add peering lans / Transit uplink lans to OSPF just add the network to OSPF and set the interface to passive (it is the safest way) (avoid redistribute Connected if you can) once the next hop is pingable in of its self then the routes that point to the next hop should become valid.. I hope this helps, Tom Smyth On Wed, 13 Jul 2022 at 02:38, Tobias Fiebig < tob...@reads-this-mailinglist.com> 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. > > With best regards, > Tobias > > > -- Kindest regards, Tom Smyth.
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.
