Re: MRTG no SNMP

2004-04-02 Thread Colin Alston
Eugene Grosbein wrote: On Thu, Apr 01, 2004 at 03:47:33PM -0300, Eicke Felipe wrote: Is There a way to configure MRTG no SNMP? Yes. Just read its documentation. And this question isn't for this list. I disagree a bit, as this can be quite an interesting topic You can use ipfw counters and wr

Re: MRTG no SNMP

2004-04-02 Thread Eugene Grosbein
On Thu, Apr 01, 2004 at 03:47:33PM -0300, Eicke Felipe wrote: > Is There a way to configure MRTG no SNMP? Yes. Just read its documentation. And this question isn't for this list. Eugene ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailma

Re: [PATCH] TX algorithms, missetting IFF_OACTIVE and if_timer

2004-04-02 Thread Ruslan Ermilov
On Fri, Apr 02, 2004 at 09:03:02AM -0800, Bill Paul wrote: [...] > > To differentiate the case of an empty > > ring from the full ring, some drivers (ste(4), dc(4), and > > nge(4)) have the threshold (6 for dc(4), 3 for ste(4), and > > 2 for nge(4)) to assert the gap between producer and consumer,

Re: IPSec troubles

2004-04-02 Thread Richard Bejtlich
Hello, This thread has been very helpful. I'm using FreeBSD 5.2.1 REL with kernels recompiled to support IPSEC. I've found the "trick" to exclude port 500 UDP packets allows ISAKMP traffic to be exchanged, e.g: spdadd 192.168.20.1[500] 192.168.21.1[500] udp -P out none; spdadd 192.168.21.1[500]

Re: PPTP MTU - SOLVED

2004-04-02 Thread Jay Hall
Yes, you are correct. I had mistyped a route and was trying to add 192.168.40.0/2 instead of 192.168.40.0/24. Thanks for your help. I think I had looked at that long enough that I would have never found the problem. Jay Michael Bretterklieber wrote: Hi, it looks everything is ok, until your

Re: [PATCH] TX algorithms, missetting IFF_OACTIVE and if_timer

2004-04-02 Thread Bill Paul
> Gang, > > I've been wading through several network drivers recently, > learning Bill Paul's code. Specifically, I examined the > following drivers: ste(4), rl(4), dc(4), nge(4), and vr(4). > > They all use the consumer/producer approach for handling TX. > if_start() works with the producer, an

[PATCH] TX algorithms, missetting IFF_OACTIVE and if_timer

2004-04-02 Thread Ruslan Ermilov
Gang, I've been wading through several network drivers recently, learning Bill Paul's code. Specifically, I examined the following drivers: ste(4), rl(4), dc(4), nge(4), and vr(4). They all use the consumer/producer approach for handling TX. if_start() works with the producer, and txeof() works

MRTG no SNMP

2004-04-02 Thread Eicke Felipe
Hi folks, Is There a way to configure MRTG no SNMP? Thanks and Regards. Eicke. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: nfs_getpages: error 70

2004-04-02 Thread Eugene Grosbein
Andrey Alekseyev wrote: > > > I've applied both patches (and defined Z_NFS_EXTENSIONS). > > It does not help. How do I handle it? > > Did you set open_retry_stale sysctl to 1? Ops, mea culpa. I'll try. Eugene ___ [EMAIL PROTECTED] mailing list http://

Re: nfs_getpages: error 70

2004-04-02 Thread Andrey Alekseyev
I've applied both patches (and defined Z_NFS_EXTENSIONS). It does not help. How do I handle it? Did you set open_retry_stale sysctl to 1? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mai

Re: nfs_getpages: error 70

2004-04-02 Thread Eugene Grosbein
[moving to -net from -stable] Andrey Alekseyev wrote: > > > If you'd like, try this patch (it may help for NFSv3 and certain > > usage patterns) > > http://blackflag.ru/patches/open-retry-stale.diff > > In addition you may also try this one: > http://blackflag.ru/patches/nfs_subs.c.diff > > In

Re: BIND: Lookup of CNAME records

2004-04-02 Thread Lutz Petersen
I have installed BIND 9 now, and everything works like a charm. Presumably BIND 8 simply doesn't handle lookups correctly. Crist J. Clark wrote: It looks like "fw" is messed up. Those responses don't carry any authority records. The queries for the root servers are returning "no error" with