[ovs-dev] [PATCH] Process RARP packets with ethertype 0x8035 similar to ARP packets.
Jesse Gross
jesse at nicira.com
Thu Nov 1 23:46:47 UTC 2012
On Wed, Oct 31, 2012 at 5:20 PM, Mehak Mahajan <mmahajan at nicira.com> wrote:
> diff --git a/NEWS b/NEWS
> index f5d7f9e..ab629d0 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -38,6 +38,8 @@ post-v1.8.0
> - The autopath action.
> - Interface type "null".
> - Numeric values for reserved ports (see "ovs-ofctl" note above).
> + - The data in the RARP packets can now be matched in the same way as the
> + data in ARP packets.
We should bring this over to the Debian changelog as well.
> v1.8.0 - xx xxx xxxx
> diff --git a/datapath/flow.c b/datapath/flow.c
> index c70daee..c90f23b 100644
> --- a/datapath/flow.c
> +++ b/datapath/flow.c
> @@ -725,7 +725,8 @@ int ovs_flow_extract(struct sk_buff *skb, u16 in_port, struct sw_flow_key *key,
> }
> }
>
> - } else if (key->eth.type == htons(ETH_P_ARP) && arphdr_ok(skb)) {
> + } else if ((key->eth.type == htons(ETH_P_ARP) ||
> + key->eth.type == htons(ETH_P_RARP)) && arphdr_ok(skb)) {
> struct arp_eth_header *arp;
>
> arp = (struct arp_eth_header *)skb_network_header(skb);
> @@ -1173,7 +1174,8 @@ int ovs_flow_from_nlattrs(struct sw_flow_key *swkey, int *key_lenp,
> if (err)
> return err;
> }
> - } else if (swkey->eth.type == htons(ETH_P_ARP)) {
> + } else if (swkey->eth.type == htons(ETH_P_ARP) ||
> + swkey->eth.type == htons(ETH_P_RARP)) {
> const struct ovs_key_arp *arp_key;
>
> if (!(attrs & (1 << OVS_KEY_ATTR_ARP)))
> @@ -1361,7 +1363,8 @@ int ovs_flow_to_nlattrs(const struct sw_flow_key *swkey, struct sk_buff *skb)
> ipv6_key->ipv6_tclass = swkey->ip.tos;
> ipv6_key->ipv6_hlimit = swkey->ip.ttl;
> ipv6_key->ipv6_frag = swkey->ip.frag;
> - } else if (swkey->eth.type == htons(ETH_P_ARP)) {
> + } else if (swkey->eth.type == htons(ETH_P_ARP) ||
> + swkey->eth.type == htons(ETH_P_RARP)) {
I don't understand why these are so far indented. It seems better to
just line them up with the key in the previous line.
I only skimmed the userspace portions but the kernel pieces otherwise
seem fine to me.
More information about the dev
mailing list