Hi. yes afaik you''re right: the ipac (for 2.2) and ipac-ng (vor 2.4)
"just"
insert iptables-rules in INPUT/OUTPUT/FORWARD, and so they don''t see
the
"droped/delayed-because-of-shaping" packets..
the only solution i know is ugly and/or unpractiable: read the
interface-stats from /proc/net/dev. but that''s only usable, if
1. you have 1. interface/customer
2. you don''t need to account certain ports
as i said: it''s in most cases no solution...
With Patrick''s imq-devices you can at least compute the
"droped/delayed-because-of-shaping" packets: these imq-devices display
in /proc/net/dev the ammount of packets/bytes that SHOULD have deliverd as
RX, and the actual REALLY ammount of packets/bytes delivered to the
interface as TX.
But that''s not really useful for your setup :(
Greetings
Tobias
> Hello,
>
> A while ago now I had to set up a traffic shaper for the ISP I work
> for, and I used linux and cbq.init to accomplish this. It worked
> reasonably well, too, but after a while and some double-checking it
> turned out that the ipac accounting on the same machine was
> consistently reporting higher usage than was actually the case by
> roughly the same factor (not amount) for every client.
>
> After a lot of thinking about this, the only conclusion I could reach
> that didn''t involve a gross and so far completely undiscovered
> programming flaw in ipac or TCP/IP gremlins was that the difference was
> caused by traffic shaping occuring at the point where packets exit the
> machine while ipac does its accounting of packets at the point where
> they enter.
>
> Am I right, or am I just blowing smoke and moondust, and in either
> case, is there any way to correctly shape and account traffic on one
> machine?
>
> Thanks,
> --
> Rens Houben | opinions are mine
> Resident linux guru and sysadmin | if my employers have one
> Systemec Internet Services. |they''ll tell you themselves
PGP
> public key at http://suzaku.systemec.nl/shadur.key.asc -- new Dec 12
> 2001