Re: openvpn in rdomain hangs
Chris Cappuccio chris at nmedia.net writes: Giancarlo Razzolini [grazzolini at gmail.com] wrote: I've used rdomains, but not for this. In this case I would use mpath and pf only. I really do not see the need for using rdomains in this case. It introduces too much complexity for a simple thing. That's nice. But what about the problem? Hi, Did you find a solution as I have the same issue ? Thanks
Re: openvpn in rdomain hangs
Giancarlo Razzolini [grazzol...@gmail.com] wrote: I've used rdomains, but not for this. In this case I would use mpath and pf only. I really do not see the need for using rdomains in this case. It introduces too much complexity for a simple thing. That's nice. But what about the problem?
openvpn in rdomain hangs
hi misc, i'm trying to run OpenBSD with two default gateways, one for openvpn and another for everything else. openvpn is in rdomain 1 and everything works fine. OpenBSD 5.5-beta (GENERIC.MP) #284: Mon Feb 3 07:57:32 MST 2014 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP # cat hostname.em1 !echo starting em1 rdomain 1 group vpn inet yy.yy.yy.yy/28 !/sbin/route -T 1 add default yy.yy.yy.default !echo -n starting sshd in rdomain 1 !route -T 1 exec /etc/rc.d/sshd start echo . !echo -n starting openvpn in rdomain 1 !install -d -o _openvpn -g _openvpn -m 0755 /var/run/openvpn /sbin/route -T 1 exec /usr/local/sbin/openvpn --daemon --config /etc/openvpn/server.conf echo . # cat hostname.tun0 !echo starting tun0 up 10.100.16.1 10.100.16.2 netmask 0x !route add 10.100.16.0/24 10.100.16.2 however, openvpn cannot be restarted in multi-user mode. it hangs in get_default_gateway(). http://www.openssh.com/cgi-bin/cvsweb/ports/net/openvpn/patches/patch-src_openvpn_route_c?rev=1.2;content-type=text%2Fplain ktrace shows that read(2) to routing socket does not return. 10068 openvpn CALL socket(PF_ROUTE,SOCK_RAW,0) 10068 openvpn RET socket 3 10068 openvpn CALL sigprocmask(SIG_BLOCK,~0) 10068 openvpn RET sigprocmask 0 10068 openvpn CALL mprotect(0x10ee093000,0x2000,0x3PROT_READ|PROT_WRITE) 10068 openvpn RET mprotect 0 10068 openvpn CALL mprotect(0x10ee093000,0x2000,0x1PROT_READ) 10068 openvpn RET mprotect 0 10068 openvpn CALL sigprocmask(SIG_SETMASK,0) 10068 openvpn RET sigprocmask ~0x10100SIGKILL|SIGSTOP 10068 openvpn CALL write(0x3,0x10ee1949c0,0x80) 10068 openvpn GIO fd 3 wrote 128 bytes \M^@\0\^E\^D\0\0\0\0\0\0\0\0\^E\0\0\0\^C\0\0\0\0\0\0\0\0\0\0\0\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^P\^B\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^P\^B\ \0\0\0\0\0\0\0\0\0\0\0\0\0\000 10068 openvpn RET write 128/0x80 10068 openvpn CALL sigprocmask(SIG_BLOCK,~0) 10068 openvpn RET sigprocmask 0 10068 openvpn CALL mprotect(0x10ee093000,0x2000,0x3PROT_READ|PROT_WRITE) 10068 openvpn RET mprotect 0 10068 openvpn CALL mprotect(0x10ee093000,0x2000,0x1PROT_READ) 10068 openvpn RET mprotect 0 10068 openvpn CALL sigprocmask(SIG_SETMASK,0) 10068 openvpn RET sigprocmask ~0x10100SIGKILL|SIGSTOP 10068 openvpn CALL read(0x3,0x10ee1949c0,0x260) when invoked from hostname.em1 during boot, read(2) immediately returned with ESRCH. according to route(4), messages written to the socket should be returned. how can read(2) be blocked? the behavior is same on 5.4, 5.3 and current. -- Tomoyuki Sakurai
Re: openvpn in rdomain hangs
Em 05-02-2014 07:09, Tomoyuki Sakurai escreveu: hi misc, i'm trying to run OpenBSD with two default gateways, one for openvpn and another for everything else. openvpn is in rdomain 1 and everything works fine. OpenBSD 5.5-beta (GENERIC.MP) #284: Mon Feb 3 07:57:32 MST 2014 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP # cat hostname.em1 !echo starting em1 rdomain 1 group vpn inet yy.yy.yy.yy/28 !/sbin/route -T 1 add default yy.yy.yy.default !echo -n starting sshd in rdomain 1 !route -T 1 exec /etc/rc.d/sshd start echo . !echo -n starting openvpn in rdomain 1 !install -d -o _openvpn -g _openvpn -m 0755 /var/run/openvpn /sbin/route -T 1 exec /usr/local/sbin/openvpn --daemon --config /etc/openvpn/server.conf echo . # cat hostname.tun0 !echo starting tun0 up 10.100.16.1 10.100.16.2 netmask 0x !route add 10.100.16.0/24 10.100.16.2 however, openvpn cannot be restarted in multi-user mode. it hangs in get_default_gateway(). http://www.openssh.com/cgi-bin/cvsweb/ports/net/openvpn/patches/patch-src_openvpn_route_c?rev=1.2;content-type=text%2Fplain ktrace shows that read(2) to routing socket does not return. 10068 openvpn CALL socket(PF_ROUTE,SOCK_RAW,0) 10068 openvpn RET socket 3 10068 openvpn CALL sigprocmask(SIG_BLOCK,~0) 10068 openvpn RET sigprocmask 0 10068 openvpn CALL mprotect(0x10ee093000,0x2000,0x3PROT_READ|PROT_WRITE) 10068 openvpn RET mprotect 0 10068 openvpn CALL mprotect(0x10ee093000,0x2000,0x1PROT_READ) 10068 openvpn RET mprotect 0 10068 openvpn CALL sigprocmask(SIG_SETMASK,0) 10068 openvpn RET sigprocmask ~0x10100SIGKILL|SIGSTOP 10068 openvpn CALL write(0x3,0x10ee1949c0,0x80) 10068 openvpn GIO fd 3 wrote 128 bytes \M^@\0\^E\^D\0\0\0\0\0\0\0\0\^E\0\0\0\^C\0\0\0\0\0\0\0\0\0\0\0\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^P\^B\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^P\^B\ \0\0\0\0\0\0\0\0\0\0\0\0\0\000 10068 openvpn RET write 128/0x80 10068 openvpn CALL sigprocmask(SIG_BLOCK,~0) 10068 openvpn RET sigprocmask 0 10068 openvpn CALL mprotect(0x10ee093000,0x2000,0x3PROT_READ|PROT_WRITE) 10068 openvpn RET mprotect 0 10068 openvpn CALL mprotect(0x10ee093000,0x2000,0x1PROT_READ) 10068 openvpn RET mprotect 0 10068 openvpn CALL sigprocmask(SIG_SETMASK,0) 10068 openvpn RET sigprocmask ~0x10100SIGKILL|SIGSTOP 10068 openvpn CALL read(0x3,0x10ee1949c0,0x260) when invoked from hostname.em1 during boot, read(2) immediately returned with ESRCH. according to route(4), messages written to the socket should be returned. how can read(2) be blocked? the behavior is same on 5.4, 5.3 and current. I've used rdomains, but not for this. In this case I would use mpath and pf only. I really do not see the need for using rdomains in this case. It introduces too much complexity for a simple thing. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC