Hi,
On Sun, 21 Feb 2021 19:18:48 +0100
Radek wrote:
>> The interface which terminate the tunnel has "192.168.4.254".
>> Right?
> Do you mean the other end of the tunnel? It is 10.109.4.254
> interface pppx0 address 10.109.4.254 ipcp IPCP
Sorry, "192.168.4.244" should have been "10.109.4.254".
>
This came through to me from the list with “no content”, so I’m trying again.
——
My box has three interfaces, dc0 to manage, em0 and em1 for bridging external
LAN to internal LAN.
hostname.em0: up
hostname.em1: up
hostname.bridge0: add em0 add em1 up
Bridge works, traffi
On Sat, Feb 20, 2021 at 04:17:11PM -0600, Eric Zylstra wrote:
> -But-
> make one simple change to filter on the bridge0 interface—
>
> pf.conf:
> filtered = "{ bridge0 }”
> not_filtered = "{ lo, dc0, em0, em1 }”
> block log on $filtered
> set skip on $not_filtered
>
> `doas
On Sun, Feb 21, 2021 at 1:38 PM Stuart Henderson wrote:
> I don't honestly think it's worth going to the trouble of disabling.
> Look at the other software you run which isn't enabled in OpenBSD by
> default - that's where your attack surface is ;)
Also look at your hardware, and look at the docu
Thanks for your reply Maurice,
I tried the read-only driver on an earlier version maybe 6.6 and it
crashed. I wasn't able to debug it myself but I suppose it could have been
my external hard drive, the NTFS version or a particular file that caused
that issue as it happened with a large data copy a
Hello,
> The interface which terminate the tunnel has "192.168.4.254".
> Right?
Do you mean the other end of the tunnel? It is 10.109.4.254
interface pppx0 address 10.109.4.254 ipcp IPCP
> How about if you configure the npppd-users
>
> rdk:
> :password=pasword:\
> :framed-ip-address=10.1
Thanks Stuart, appreciate your time on this, and explanation of
the sndiod design
it was a case of I dont understand, dont use so I just disable.
and then I proceeded to ask out of turn shouldn't everyone else disable because
I dont understand or use it my self :/
Re attack surface / risk of ot
On 2021-02-21, Tom Smyth wrote:
> my thinking is by having the service off by default would reduce the
> default attack surface of the OS ?
The attack surface is tiny.
sndiod has a pair of processes each run as their own dedicated uid, one
in a chroot jail containing no files and pledged to not
If you are planning to deploy many systems in the near future and your
deployment script is very invovled then you might want to consider
building your own release and using that to install instead.
This way you don't need to append your deployment script to either
/install.site or /etc/rc.firstti
Hi folks,
thanks for everyone who replied on and off list,
I had not considered the console only user who uses audio also...
(I had not even considered this so pardon my ignorance folks,
and thanks to Sebastian, Abel, and David for replying on and off list
I guess Ill just add rcctl disable sndio
Hi,
Has anyone had experience using NTFS with OpenBSD and if so any
pointers particularly around performance and any problems encountered?
I realise NTFS is probably not used by many people but I have an
external drive which is formatted with it.
It would be useful to know if anyone is using the
On Sun, Feb 21, 2021 at 8:39 AM Tom Smyth
wrote:
> Hi Sebastian
> I get users want to listen to audio but if the only hardware is a buzzer
> and the user is not running x what are the chances they are using audio on
> the console only ?
>
> I can keep running
> rcctl disable sndiod
> Post install
Hi Sebastian
I get users want to listen to audio but if the only hardware is a buzzer
and the user is not running x what are the chances they are using audio on
the console only ?
I can keep running
rcctl disable sndiod
Post install
I thought linking audio support on by default to x would make se
Hello,
On Sat, 20 Feb 2021 21:14:24 +0100
Radek wrote:
> I have a router with VPN server (npppd). LAN net is 10.109.3.0/24, gw
> 10.109.3.254, the VPN net is 10.109.4.0/24, gw 10.109.4.254.
> If the client is conencted to VPN all client's traffic to 10.0.0.0/8 goes via
> 10.109.4.254
>
> clien
Tom Smyth(tom.sm...@wirelessconnect.eu) on 2021.02.21 04:08:48 +:
> Hello,
>
> I was wondering should sndiod (default) startup be determined based on
> whether or not
> it the install is a typical headless install (off) or an install for
> a user machine with running X
>
> is there a reason
On 2021-02-20, Eric Zylstra wrote:
> -But- make one simple change to filter on the bridge0 interface--
> pf.conf:
>
> filtered = "{ bridge0 }"
> not_filtered = "{ lo, dc0, em0, em1 }"
> block log on $filtered
> set skip on $not_filtered
>
>
>> doas pfctl -f /etc/pf.conf
>
>> doas pfctl -sr
>
> blo
17 matches
Mail list logo
