Julian Elischer wrote:
Rajkumar S wrote:
On Sat, May 24, 2008 at 6:09 AM, Julian Elischer <[EMAIL PROTECTED]>
wrote:
subject says it all really..
I am using pf and rtable to setfib and get an pfctl: DIOCADDRULE:
Device busy when trying to load "pass in quick on fxp0 from any to any
keep state rtable 1"
I'm not really familiar with the pf syntax
as I didn't do that part of the patch (max laier (CC'd) did)
and I don't use pf.
Max may be able to see if the patch to the pf code ahs an error.
I can successfully load "pass in quick on fxp0 all flags S/SA keep
state rtable 0" I am testing on FreeBSD CURRENT.
My routing tables are:
[EMAIL PROTECTED] /etc]# setfib -0 netstat -nrf inet
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif
Expire
default 192.168.3.100 UGS 0 2025 fxp0
127.0.0.1 127.0.0.1 UH 0 0 lo0
192.168.3.0/24 link#1 UC 0 0 fxp0
192.168.3.54 00:40:f4:b7:d7:ee UHLW 1 40 fxp0
1179
192.168.3.100 00:80:48:38:1a:df UHLW 2 149 fxp0
1173
192.168.4.0/24 link#1 UC 0 0 fxp0
192.168.4.4 00:80:48:1f:48:26 UHLW 1 141 fxp0
1120
192.168.5.0/24 link#3 UC 0 0 rue0
[EMAIL PROTECTED] /etc]# setfib -1 netstat -nrf inet
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif
Expire
default 192.168.5.4 UGS 0 13 rue0
127.0.0.1 127.0.0.1 UH 0 0 lo0
192.168.3.0/24 link#1 UC 0 0 fxp0
192.168.3.54 00:40:f4:b7:d7:ee UHLW 1 0 fxp0
1176
192.168.3.100 00:80:48:38:1a:df UHLW 1 5 fxp0
1170
192.168.4.0/24 link#1 UC 0 0 fxp0
192.168.4.4 00:80:48:1f:48:26 UHLW 1 0 fxp0
1117
192.168.5.0/24 link#3 UC 0 0 rue0
btw, does the rtable syntax allow to set route for packets generated
by the pf host itself (like packets from squid). The catch is that
they cannot be matched via a "pass in" rule, they are matched only on
a "pass out" rule.
I don't know about pf, but in ipfw it definitely can be any packet at
any time, but the outgoing packets have already made their routing
decision before they hit the firewall so even though a table is
associated with the packet, it's too late :-/ it has to be associated
with the socket itself to really have effect.
For this reason I'm considering whether to add a 'reroute' ipfw rule
that forces a redo of the routing decision... it may not work as
expected however.. (it would be too late to change the selected src
address).
Thanks and regards,
raj
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
