Jan Kiszka wrote: > 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. > Now I came across this issue once again. It is still present, I just observed it over the latest rt2x00 tree after updating shorewall and forgetting to fix its config. I redirected tc to some logging filter, and this is what shorewall does when "CLEAR_TC=Yes" is set in shorewall.conf: ... tc qdisc del dev wmaster0 root tc qdisc del dev wmaster0 ingress tc qdisc del dev wlan0 root tc qdisc del dev wlan0 ingress HTH, Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
