Messages in this thread |  | | From | Bart De Schuymer <> | Subject | Re: bridge-netfilter patch | Date | Tue, 17 Sep 2002 21:10:06 +0200 |
| |
> net/ipv4/ip_output.c:ip_fragment() > In this function the copy of the Ethernet frame is added for each > fragment (by the br-nf patch). > > 'output' callback arg to ip_fragment() must generate correct hardware > headers when necessary. This hack usage of it via netfilter, in this > weird bridging case, is violating this requirement. > > Normally ip_finish_output2() is going to make this. > > If it can't do the job properly, pass instead a routine that can do > what netfilter needs.
Aha. In our case, the output function is net/bridge/br_forward.c:__dev_queue_push_xmit(). This is because __br_forward_finish() (same file) uses this as okfn. Remember the IP hooks are "faked" on the bridge hooks, so functions attached to NF_IP_POST_ROUTING are called when the IP packet/frame passes the NF_BR_POST_ROUTING hook. They are not called earlier. All of this assuming that the destination device according to the routing table is a (logical) bridge device. If not, the packets go through the IP code and netfilter hooks normally.
So, what if we were to add the following code to the start of __dev_queue_push_xmit():
if (skb->protocol == __constant_htons(ETH_P_IP)) { struct dst_entry *dst = skb->dst; if (hh) { read_lock_bh(&hh->hh_lock); memcpy(skb->data - 16, hh->hh_data, 16); read_unlock_bh(&hh->hh_lock); } }
hh being NULL for an unfragmented IP packet and else non-NULL? Do realize that I (I can't speak for Lennert ofcourse) am not very familiar to the workings of the IP code.
Then we can remove the memcpy from ip_fragment(). Does that make sense?
-- cheers, Bart
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |