Guido van Rooij wrote:
>If you do not reload the filter rules, but look at what ipfstat says
>about rule hits, you might get a clue on where things are blocked
>(if at all).
I did that, see below.
>I think what happens is that the tun0 device is loaded as kld when
>you first run ppp. And in fact that the initial ipf loading gives errors
No, during my tests kldstat output is:
Id Refs Address Size Name
1 3 0xc0100000 1b64b0 kernel
2 1 0xc09ef000 10000 linux.ko
3 1 0xc0a11000 3000 daemon_saver.ko
In my kernel config I have:
pseudo-device tun # Packet tunnel.
>about the fact that there is no such device as tun0.
>Reloading the filter rules fixes that and since tun0 is loaded and stays
>loaded, you'll never encounter any problems again.
>
>Try kldload if_tun before loading the rules at boot time and sees
>if the problem goes away.
>
>If this doesn't solve it, walk over to my room tomorrow and we'll
>look further.
I repeated the test I described a few days ago, but this time I also
looked at the kldstat output (remains the same during the whole test)
and ipfstat -hi/-ho.
1. Fresh reboot; start dialin to company; try to ping a host on the
company network, it says no route to host. ipfstat -hi/-ho output
does not show any tun0 activity:
0 pass in quick on tun0 from any to any
0 pass out quick on tun0 from any to any
2. Type the ipf.reload command which unloads and reloads the same filter
rules (see previous mail). Ping the host again, this works. ipfstat
-hi/-ho now shows activity on the tun0 device:
5 pass in quick on tun0 from any to any
15 pass out quick on tun0 from any to any
3. Shut down the dialin connection.
4. Start new dialin connection, this one works without any further
actions.
5. Goto 3.
Arjan
--
Arjan de Vet, Eindhoven, The Netherlands <[EMAIL PROTECTED]>
URL: http://www.iae.nl/users/devet/ for PGP key: finger [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message