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

Antonio Quartulli ordex at autistici.org
Sat Mar 24 09:14:08 CET 2012


On Fri, Mar 23, 2012 at 10:22:33 +0100, Andrew Lunn wrote:
> > +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.

Does this mean that you want to support multiple algorithms at the same time?
I don't think it is a good idea..

Cheers,


-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.open-mesh.org/pipermail/b.a.t.m.a.n/attachments/20120324/db4eb294/attachment.pgp>


More information about the B.A.T.M.A.N mailing list