netdev
[Top] [All Lists]

Re: patch: tunnels not setting inputdev

To: hadi@xxxxxxxxxx
Subject: Re: patch: tunnels not setting inputdev
From: Patrick McHardy <kaber@xxxxxxxxx>
Date: Sun, 02 Jan 2005 01:24:08 +0100
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxx, Wichert Akkerman <wichert@xxxxxxxxx>
In-reply-to: <1104622406.1049.450.camel@jzny.localdomain>
References: <1104513392.1048.316.camel@jzny.localdomain> <41D5941C.8060001@trash.net> <1104523892.1047.338.camel@jzny.localdomain> <41D6CB87.8040205@trash.net> <1104622406.1049.450.camel@jzny.localdomain>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5
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.

I can't see the problem with
redirected packets, just set skb->input_dev = skb->dev in
netif_receive_skb, this should have exactly the same effect as
setting it in the drivers or the mirred action.

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.

Regards
Patrick

<Prev in Thread] Current Thread [Next in Thread>