lkml.org 
[lkml]   [2004]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subjectaf_packet.c -ERRMSGSIZE logic error for VLAN Support
Date
I guess a RAW packet interface needs to really be just that.  The af_packet.c logic is broken
with VLAN tagging. When I attempt to regenerate packets through ethernet with
AF_PACKET calls via sockaddr_ll request structures, the calculation being performed in
af_packet of:

err = -ERRMSGSIZE
if (len > (dev->mtu + dev->hard_header_len))
goto out_unlock;

...
..

return err;

This is busted with VLAN tags. I am sending packets out of the max length of 1514 with the
additional 4 bytes of VLAN info attached. I am received packets of this size from the
e1000 adapters (1518) from one side of the system and when I attempt to resend them
via af_packet.c through another e1000 adapter with the ame driver code, it bombs since the packet is larger than the mtu (1500) + dev->hard_header_len (14). A RAW packet interface needs to really be raw, and this includes taking into account the size of a VLAN header. I realize this is a driver error since the driver returns these fields from the net_device structure, but it doesn't make much sense for a driver to enforce these limits in raw mode.

manipulation of VLAN tags should be allowed through a raw interface, and the logic in
af_packet.c is what is creating the error. If this an error in the logic or is there some other
method recommended for dealing with the VLAN tagging info.

I would assume for IP and other types of sockets, some sort of sideband is ok for tagging
the packets, but a raw interface should allow raw packet construction and transmission.

Jeff




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.061 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site