Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Oct 2004 19:17:46 -0400
From:      Brian Fundakowski Feldman <green@freebsd.org>
To:        Luigi Rizzo <luigi@freebsd.org>
Cc:        Andre Oppermann <andre@freebsd.org>
Subject:   Re: Traffic Shaping not working correctly after ipfw coverted to use pfil_hooks API
Message-ID:  <20041026231745.GE93831@green.homeunix.org>
In-Reply-To: <20041026133043.A24138@xorpc.icir.org>
References:  <429af92e041020205510c66168@mail.gmail.com> <4177B899.5EC32F5F@freebsd.org> <429af92e04102114472add0e51@mail.gmail.com> <417835C7.7060808@freebsd.org> <429af92e04102404115bc7bc80@mail.gmail.com> <417BBE2C.A285792B@freebsd.org> <20041026133043.A24138@xorpc.icir.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 26, 2004 at 01:30:43PM -0700, Luigi Rizzo wrote:
> On Sun, Oct 24, 2004 at 04:37:32PM +0200, Andre Oppermann wrote:
> > [bouncing over to Luigi]
> > 
> > Luigi, do you have any idea what might be going wrong here?
> 
> no, sorry... I have to say the ipfw/natd/dummynet configuration is rather
> convoluted here so it is a bit hard to tell whether the
> problem is in dummynet calls or divert sockets.
> 
> I am also confused by the numbers in the initial report:
> 
> > > > >>Vincent Poy wrote:
> > > > >>
> > > > >>>However, after the latest -CURRENT upgrade, it will do 200KB/sec down
> > > > >>>and 52KB/sec up.  If I only download only, then it does show
> > > > >>>650KB/sec.  Normally, when I change the bandwidth to a number lower
> > > > >>>than 480Kbps for the pipe, the download speeds would go up when
> > > > >>>downloading.  However, I have tried in 10kbps steps down to 350kbps
> > > > >>>but it still did not top 200KB/sec in downloading.
> 
> there is a mix of two different notations, Kbps and KB/sec, and
> i cannot make sense of them.
> Finally, I am curious as to why one would mix the upload and download
> traffic, i believe *DSL data rates are independent in the two
> directions unlike analog modems...

In ip_divert.c the behavior may have changed when I implemented diverted
rules, in divert_output(): the cookie (ipfw rule number) can be added
and set to sin->sin_port if the sockaddr_in used for hinting the
interface has a cleared sin->sin_addr field, but has not cleared the
sin->sin_port.  This specifically means for diverted output, and not
loopback, packets could be skipping rules when they shouldn't be.

Could you try modifying that function in src/sys/netinet/ip_divert.c
so that "dt->cookie = sin->sin_port;" changes to
if (sin->sin_addr.s_addr != 0)
	dt->cookie = sin->sin_port;
and see if that changes things?

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green@FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041026231745.GE93831>