On Sat, 2005-01-01 at 19:24, Patrick McHardy wrote:
> jamal wrote:
> > I want to understand the repurcasssions instead of blindly setting. Let
> > users complain, thats why the printk exists. For example what does
> > input_dev mean for netbios or a 802.3ad interface? You already saw one,
> > xfrm, where there was no need to reset.
> What's special about netbios ? For 802.3ad, I would expect input_dev
> to hold the virtual device through which the packet entered the stack,
> just what iptables -i would match. For xfrm - there is no need but its
> also not wrong.
This is exactly why i am not just setting things arbitraliy at input.
Different _types_ of devices that need different _types_
of treatment (with dependency of where they are in the path as well).
Tunnels are not the same as ethernet are not the same as atm devices are
not the same as ppp-based devices. Heck some of these things dont even
Note, one could claim that if you remove the printk there is already
a central place to set things. However, I need to know when people use
this path what the circumstances are - at some point we will get rid of
the printk. At some point it may be you are right, lets just put it all
in one spot - but for now just leave it as is.
> > in some cases the pointers are swapped. You cant just blindly
> > set skb->input_dev = skb->dev at the input - that would be violating the
> > intent; think reinjecting packets (and look at mirred as a sample of
> > apps to come that do this).
> I don't know your intent, but I assumed it was to match the incoming
> interface as the networking stack sees it. Why would the pointers be
> swapped ? Please give me an example. mirred does:
> skb2->dev = dev;
> skb2->input_dev = skb->dev;
> So on input input_dev is the incoming interface of the original packet,
> on output it is the outgoing interface of the original packet. Doesn't
> make much sense to me, the original packet came the same way both times.
The current mirred does only egress redirection - it doesnt do ingress
redirection, nor socket redirection yet. The TODO list in the file says
it will at some point. I have some code - but its not clean enough to
include - those for example will matter in this case. I dont want to
rule it out to be specific just for those few apps i have.
The architecture allows arbitrary loops between arbitrary number of
actions and netdevices in a policy topology. The input could appear more
than once in such a topology at arbitrary points.
I am attaching an old version of the dummy device, which i am hoping to
propose as a replacement for IMQ at some point; its has an example of
such usage. I havent really added any hooks for contracking action in
the path in which dummy is to be found etc, but I hope it helps make my
point. At some point i will document all the features.
An example policy:
on eth0: match filter at ingress/egress then
action mirred egress redirect dev dummy0.
dummy0 reinjects at ingress/egress.
More complex: on dummy0 add more interesting rules to do further
Description: Text Data