Claudio Jeker wrote:
> Ping is a bit of a special case since it runs with user _ping when started
> as root. So by the time the SO_RTABLE is issued it does not have the privs
> to do it. The ping -V option only works when used in rdomain 0.
Maybe we can drop privs a little later if we started
On Mon, Mar 18, 2019 at 11:27:40PM +0100, Pierre Emeriaud wrote:
> Hello Claudio,
>
> Le lun. 18 mars 2019 à 23:07, Claudio Jeker a écrit :
> >
> > > lg(rdomain1)$ doas ping -V0 1.1.1.1
> > > ping: setsockopt SO_RTABLE: Operation not permitted
> >
> > This is expected behaviour. From
Hello Claudio,
Le lun. 18 mars 2019 à 23:07, Claudio Jeker a écrit :
>
> > lg(rdomain1)$ doas ping -V0 1.1.1.1
> > ping: setsockopt SO_RTABLE: Operation not permitted
>
> This is expected behaviour. From setrtable(2):
>
> Only the superuser is allowed to change the process routing table if
On Mon, Mar 18, 2019 at 10:10:26PM +0100, Pierre Emeriaud wrote:
> Hello,
>
> As explain in another mail to bugs@ ("rcctl issue with rdomains"), my
> shell is spawn from a sshd running in rtable 1.
>
> lg(rdomain1)$ id -R
> 1
>
> I can't however use `ping -V` to set the rtable I'm interested
Hello,
As explain in another mail to bugs@ ("rcctl issue with rdomains"), my
shell is spawn from a sshd running in rtable 1.
lg(rdomain1)$ id -R
1
I can't however use `ping -V` to set the rtable I'm interested in:
lg(rdomain1)$ ping -V0 1.1.1.1
ping: setsockopt SO_RTABLE: Operation not
I don't know if this is a known/expected behavior or a bug, and I
wanted your input on this. This is on 6.4-stable.
I have two sshd daemons running. One (sshd_public) in rdomain 0
(public internet), another (sshd_private) in rdomain 1 (private lan).
If I use rcctl to restart sshd_public while
On Sat, Jan 12, 2019 at 12:28:04PM -0700, martian67 wrote:
>
> > Are you implying that these panics do not occur if your athn(4) hostap
> > is in 11a/g mode instead of 11n? That would be useful to know.
> >
>
> Sorry I was not more explicit with my testing, running an ifconfig
> random up/down
