Re: [B.A.T.M.A.N.] [RFC 2/5] batman-adv: ELP - creating neighbor structures, updating LQs

From: Andrew Lunn <andrew@lunn.ch>
To: The list for a Better Approach To Mobile Ad-hoc Networking
	<b.a.t.m.a.n@lists.open-mesh.org>
Cc: Marek Lindner <lindner_marek@yahoo.de>
Subject: Re: [B.A.T.M.A.N.] [RFC 2/5] batman-adv: ELP - creating neighbor structures, updating LQs
Date: Fri, 23 Mar 2012 22:22:33 +0100	[thread overview]
Message-ID: <20120323212233.GG5662@lunn.ch> (raw)
In-Reply-To: <1332453075-27999-2-git-send-email-lindner_marek@yahoo.de>

> +static int bat_v_elp_packet_recv(struct sk_buff *skb,
> +				 struct hard_iface *if_incoming)
> +{
> +	struct bat_priv *bat_priv = netdev_priv(if_incoming->soft_iface);
> +	struct batman_elp_packet *elp_packet;
> +	struct hard_iface *primary_if;
> +	struct ethhdr *ethhdr;
> +	bool ret;
> +
> +	ret = check_management_packet(skb, if_incoming, BATMAN_ELP_HLEN);
> +	if (!ret)
> +		return NET_RX_DROP;
> +
> +	/* did we receive a B.A.T.M.A.N. V ELP packet on an interface
> +	 * that does not have B.A.T.M.A.N. V ELP enabled ? */
> +	if (bat_priv->bat_algo_ops->bat_ogm_emit != bat_v_ogm_emit)
> +		return NET_RX_DROP;

Hi Marek

I've not looked at the code, but i assume this can happen because
there is not a per algorithm receive handler? Maybe it makes sense to
have a receive handler in algo structure, which can handle per
algorithm receive functions? The common PDUs can be handled first and
then a call into the algo receive function made to dispatch algo
specific PDUs.

	 Andrew