On Tue, 27 Sep 2016 09:44:41 -0400 (EDT), da...@davemloft.net wrote:
> From: Daniel Borkmann <dan...@iogearbox.net>
> Date: Tue, 27 Sep 2016 12:39:34 +0200
>
> > Any reason why dev_forward_skb() is not preferred over direct
> > netif_receive_skb() you're using? It would, for example, implicitly
> > assure that pkt_type is always PACKET_HOST, etc.
>
> dev_forward_skb() will pull the ethernet header.
>
> And since a direct call to netif_receive_skb() will not, one of these
> two choices won't work properly.
In the patch, I'm issuing a skb_pull_rcsum() prior the netif_receive_skb,
snip:
+ /* If action's target direction differs than filter's direction,
+ * and devices expect a mac header on xmit, then mac push/pull is
+ * needed.
+ */
+ if (at != tcf_mirred_act_direction(m->tcfm_eaction) &&
+ m->tcfm_mac_header_xmit) {
+ if (at & AT_EGRESS) {
+ /* caught at egress, act ingress: pull mac */
+ mac_len = skb_network_header(skb) - skb_mac_header(skb);
+ skb_pull_rcsum(skb2, mac_len);
Existing *egress* mir/red already supported pairing two non-eth devices.
Therefore I allow it for the new *ingress* mir/red as well.
Now, following this premise, the skb_pull_rcsum() shown above is executed
for devices whose xmit is mac_header based.
I've tested both ARPHRD_ETHER devices and some non ARPHRD_ETHER devices.
(an *existing* symmetric skb_push_rcsum() is invoked if packet is caught at
ingress and redirected for egress on a mac_header xmit device)
This was the reason for picking netif_receive_skb() over dev_forward_skb().
Regards,
Shmulik
