Julian Elischer wrote:
Oleg Sharoyko wrote:
Julian Elischer wrote:
great.. in your simple server, can you do the sockopt on the socket
AFTER you did the listen()?
(just as a test).
Doesn't help. I have also tried to add setsockopt() after accept()
(for a new socket) and in this case the o
Oleg Sharoyko wrote:
Julian Elischer wrote:
great.. in your simple server, can you do the sockopt on the socket
AFTER you did the listen()?
(just as a test).
Doesn't help. I have also tried to add setsockopt() after accept() (for
a new socket) and in this case the only packet that is being
Oleg Sharoyko wrote:
Julian Elischer wrote:
great.. in your simple server, can you do the sockopt on the socket
AFTER you did the listen()?
(just as a test).
Doesn't help. I have also tried to add setsockopt() after accept() (for
a new socket) and in this case the only packet that is being
Julian Elischer wrote:
So there are two possible ways a daemon might assign a fib to a socket
that it is accepting:
1/ the accept socket could take the FIB of the process.
2/ the accept socket could take the fib of the incoming SYN packet.
I chose #1, but it is possible something in changes
Julian Elischer wrote:
great.. in your simple server, can you do the sockopt on the socket
AFTER you did the listen()?
(just as a test).
Doesn't help. I have also tried to add setsockopt() after accept() (for
a new socket) and in this case the only packet that is being sent out
via wrong i
Oleg Sharoyko wrote:
Julian Elischer wrote:
does it still fail if you run it in foreground mode (no daemonizing)?
Yes. I actually test sshd in foreground mode (-D tells sshd to not go
into background). I have also checked a very simple client/server where
server called setsockopt(SO_SETFIB
So there are two possible ways a daemon might assign a fib to a socket
that it is accepting:
1/ the accept socket could take the FIB of the process.
2/ the accept socket could take the fib of the incoming SYN packet.
I chose #1, but it is possible something in changes between 6
and 7 broke th
Julian Elischer wrote:
does it still fail if you run it in foreground mode (no daemonizing)?
Yes. I actually test sshd in foreground mode (-D tells sshd to not go
into background). I have also checked a very simple client/server where
server called setsockopt(SO_SETFIB, 1) and got the same
Oleg Sharoyko wrote:
Julian Elischer wrote:
r61net-fbsdhost-1, / # setfib 1 /usr/sbin/sshd -o 'ListenAddress
195.208.245.229:' -D
Are you running this from inetd?. (doesnt look like it)
No, I run this from shell merely for test purposes. First I tried to
start sshd in a usual way in a
Julian Elischer wrote:
r61net-fbsdhost-1, / # setfib 1 /usr/sbin/sshd -o 'ListenAddress
195.208.245.229:' -D
Are you running this from inetd?. (doesnt look like it)
No, I run this from shell merely for test purposes. First I tried to
start sshd in a usual way in a jail, but came to thi
Oleg Sharoyko wrote:
Hello!
I'm having a trouble with multiple routing tables (FreeBSD 7.2 release).
Either I'm missing something in my setup or packets for daemons started
with setfib are being sent out via the wrong interface.
What I'd like to implement:
em0 - internal management network wit
Hi all,
I attached a patch that solve this problem. I will send a PR as soon
as possible.
Instructions:
Patch the follow files:
/usr/src/sbin/ipfw/ipfw2.c (patch is ipfw2.c.diff)
/usr/src/sbin/ipfw/ipfw2.h (patch is ipfw2.h.diff)
/usr/src/sbin/ipfw/ipv6.c (patch is ipv6.c.diff)
This patch w
Hello!
I'm having a trouble with multiple routing tables (FreeBSD 7.2 release).
Either I'm missing something in my setup or packets for daemons started
with setfib are being sent out via the wrong interface.
What I'd like to implement:
em0 - internal management network with ip address 10.2.5.2/2
Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).
The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.
S Tracker
14 matches
Mail list logo