Johannes Berg wrote: >> The actual problem was meanwhile identified: shorewall happened to >> overwrite the queueing discipline of wmaster0 with pfifo_fast. I found >> the magic knob to tell shorewall to no longer do this (at least until I >> want to manage traffic control that way...), but I still wonder if it is >> an acceptable situation. Currently, the user can intentionally or >> accidentally screw up the stack this way. > > I don't seem to be able to do that: > > # tc qdisc change dev wmaster0 pfifo > RTNETLINK answers: Invalid argument > > # tc qdisc replace dev wmaster0 pfifo > RTNETLINK answers: Invalid argument > > what exactly does shorewall do? > Don't recall... need to re-test... lacking time. :( Just one note: I observed this on a 2.6.19 kernel - in case there is a difference to the latest. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
