I think I understand what's going on, thanks to a small mistake ;-)
I needed to add a 5th nic to the gateway box - this new nic was an
identical mate for another isa in there, so I modified the module
options accordingly.
So, after 10 minutes of trying to figure out why the DSL device was
unwilling to talk to, well, anything - it occurred to me that the new
card was the next address up, hence the modem is *now* on eth4...
I modified the wshaper and re-ran it. Next few hours are spent wondering
why the path between the half-dead server and the replacement is at,
like, DSL speeds :-/
Today, I've dug deeper, and found that eth3 was *still* being shaped
(even though it's now part of a 3-if bridge), and indeed, some bands had
seen traffic!!
However, eth4 was also now shaped, with the same script (makes sense
after reading wshaper again), but the bands are *not* seeing traffic,
even after limiting to half the DSL line speed and upping a 6mb file to
a remote site via scp...
I'm now almost totally convinced that traffic is eluding the filters
because it's *actually* traffic out ppp0 (I'm currently using the Debian
userland pppoe thingy), and I'm tc'ing on eth4 (to which the DSL device
is attached). However earlier in the game, when I tried to shape ppp0,
the kernel would reliably oops after about a minute.
What am I doing wrong?
--
Cheers,
Mattt. icq : 117539757
aboveNetworks www : www.above.nq4u.net
mattt@above.nq4u.net jabber: mattt@jabber.above.nq4u.net
What's got four legs and an arm? A happy Pit Bull...
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
