On Thu, Jan 08, 2009 at 07:37:40AM -0500, Sebastien Roy wrote:
>
> On Wed, 2009-01-07 at 23:47 -0800, Eric Cheng wrote:
> > On Wed, Jan 07, 2009 at 10:15:49PM -0800, Eric Cheng wrote:
> > > On Thu, Jan 08, 2009 at 12:07:11AM -0500, Sebastien Roy wrote:
> > > > I'm in the process of doing the Clearview iptun and Crossbow merge, and
> > > > one problem I'm having is that mac_datapath_setup() fails in
> > > > mac_flow_add() -> flow_l2_accept_fe() which contains the following:
> > > >
> > > > if (i == fd->fd_mac_len || fd->fd_mac_len < ETHERADDRL)
> > > > return (EINVAL);
> > > >
> > > > IPv4 tunnel "MAC" addresses are 4 bytes, and so this doesn't work. What
> > > > is the intent of this code? How can this be made to work for MAC
> > > > drivers with addresses < 6 bytes?
> > >
> > > the intention was to check if the mac len is a sane value and we
> > > overlooked the < 6 bytes case.
> > > I think you can safely change this check to "fd->fd_mac_len != 0" as
> > > there's no code that assumes the mac len must be >= 6.
> > >
> >
> > sorry, I meant "fd->fd_mac_len == 0".
>
> You mean remove the check entirely? Checking that the MAC length == 0
> would make this code fail for all MAC types except those that have a MAC
> length of 0.
>
sorry for being unclear. I meant to change the existing check you mentioned
above to:
if (i == fd->fd_mac_len || fd->fd_mac_len == 0)
return (EINVAL);
this rejects mac lengths of 0.
for mac types with mac len of 0, mac_flow_add() shouldn't be called
at all since you can't classify a 0 len address. a different mechanism
would be needed we'll figure out what to do when we implement these mac
types.
eric
