Re: SACK (and PF) wierdness

2004-11-23 Thread Daniel Hartmeier
Pawel kindly supplied a tcpdump of an entire connection. We identified the point where pf drops the packet because it sees a violation of the advertised sequence window. I think we can show that there is some problem with the TCP code, possibly related to SACK. Hence, I'd like to ask anyone famila

run multicast daemon on vlan interface

2004-11-23 Thread edrt
Hi All, I tried running pimd and forwarding multicast traffic on vlan interface with a freebsd derived kernel, but it seems that kernel failed to receive multicast traffic on the vlan interface. I guess the reason partly lies in vlan_ioctl's SIOCSIFFLAGS handler doesn't take care IFF_ALLMULTI f

Re: Large NAT: ipf/ipnat, pf - opinions?

2004-11-23 Thread Stephane Raimbault
You mention diffrent ways to fine-tune pf. I'm particularly interested in the number of states. I have a situation where I'm running pf around 8000 states and the box seems to perform quite beautifully, I have increased the max states to 100K to cover large peaks which can occur, however I have

Re: resolving routes externally

2004-11-23 Thread James
On Tue, Nov 23, 2004 at 08:49:19PM -0500, James wrote: > On Tue, Nov 23, 2004 at 10:36:46AM -0800, Bruce M Simpson wrote: > [ snip ] > > > > If I understand correctly, you want the kernel to queue packets until > > layer 2 address resolution is complete. Right now we don't do this. If > > there is

Re: resolving routes externally

2004-11-23 Thread James
On Tue, Nov 23, 2004 at 10:36:46AM -0800, Bruce M Simpson wrote: [ snip ] > > If I understand correctly, you want the kernel to queue packets until > layer 2 address resolution is complete. Right now we don't do this. If > there is no route to a destination, packets will be dropped. The KAME ipv6

Re: resolving routes externally

2004-11-23 Thread Bruce M Simpson
On Tue, Nov 23, 2004 at 11:05:06AM +0200, Martin Eugen wrote: > At the beginning my intention was to use the routing sockets > mechanisms, and say, to issue a 'missing route' message to some > userland daemon capable of resolving those complex addresses (the > resolving mechanism is generally a loo

Re: FAST_IPSEC vs IPSEC performanc

2004-11-23 Thread Sam Leffler
On Tuesday 23 November 2004 01:04 am, Michael Vince wrote: > Hey all. > > I have been googling around the Internet for information about IPSEC and > FAST_IPSEC for freebsd on the Internet and wondered what gives best > performance > when I came across this http://people.freebsd.org/~pjd/netperf/ >

Re: resolving routes externally

2004-11-23 Thread Martin Eugen
On Tue, 23 Nov 2004 14:52:36 +0100, Joerg Sonnenberger <[EMAIL PROTECTED]> wrote: > On Tue, Nov 23, 2004 at 11:42:39AM -0200, Jo?o Carlos Mendes Lu?s wrote: > > >So I started to look at the ARP > > >code, but it of course lacks the kernel - userland communication > > >interface. I would appreciate

Re: Running into an mbuf leak with bridging and tap

2004-11-23 Thread Maksim Yevmenkin
Robert, I'm running an ethernet over TCP bridge using a combination of the native ethernet bridge support and the tap driver. Basically, a daemon sits on /dev/tapX and bridges ethernet frames using a small header over a TCP connection. The bridge support is loaded as a kld, as is the tap support,

Re: resolving routes externally

2004-11-23 Thread Joerg Sonnenberger
On Tue, Nov 23, 2004 at 11:42:39AM -0200, Jo?o Carlos Mendes Lu?s wrote: > >So I started to look at the ARP > >code, but it of course lacks the kernel - userland communication > >interface. I would appreciate any ideas about what would be the easier > >way to implement such a thing where the kernel

Re: resolving routes externally

2004-11-23 Thread João Carlos Mendes Luís
Martin Eugen wrote: Hi there, I'm currently trying to implement some networking protocols in the kernel. I would like to ask a few questions, but first, let me explain some details about those protocols: the network is composed of smaller subnets connected through gateways. Hosts have a fairly com

Re: Running into an mbuf leak with bridging and tap

2004-11-23 Thread Olivier Nicole
> I'm running an ethernet over TCP bridge using a combination of the native > ethernet bridge support and the tap driver. Basically, a daemon sits on > /dev/tapX and bridges ethernet frames using a small header over a TCP Yup i think I have seen the same thing while I was using a combination of v

Running into an mbuf leak with bridging and tap

2004-11-23 Thread Robert Watson
I'm running an ethernet over TCP bridge using a combination of the native ethernet bridge support and the tap driver. Basically, a daemon sits on /dev/tapX and bridges ethernet frames using a small header over a TCP connection. The bridge support is loaded as a kld, as is the tap support, and bo

please test: miibus GE ony PHY detection

2004-11-23 Thread Bjoern A. Zeeb
Please test: ! ! With the changes from mii.h rev 1.4 to adopt NetBSD checks ! using BMSR_MEDIAMASK it was missed that in rev 1.26 of mii.c ! in NetBSD there had been another change: ! ! : When probing for a PHY, look at the EXTSTAT bit in the BMSR, as well, ! : not just the media mask. This p

FAST_IPSEC vs IPSEC performanc

2004-11-23 Thread Michael Vince
Hey all. I have been googling around the Internet for information about IPSEC and FAST_IPSEC for freebsd on the Internet and wondered what gives best performance when I came across this http://people.freebsd.org/~pjd/netperf/ It has some nice graphs / figures on performance of IPSEC and FAST_IPS

resolving routes externally

2004-11-23 Thread Martin Eugen
Hi there, I'm currently trying to implement some networking protocols in the kernel. I would like to ask a few questions, but first, let me explain some details about those protocols: the network is composed of smaller subnets connected through gateways. Hosts have a fairly complex global addresses

Re: gif4) & AltQ

2004-11-23 Thread Eric Masson
> "Max" == Max Laier <[EMAIL PROTECTED]> writes: Hello Max, Max> Very true. It's more worthwhile to classify on gif and queue on Max> the real interface. How would you achieve this setup ? I can only think about this way (assuming gif0 tunnel packets flow thru ep1) : ext_if="ep1" tunnel_