lkml.org 
[lkml]   [2000]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectManaging lengths of packets with ethertap...
Date
Hi all,

I've used the ethertap driver to allow comms to a non-hardware-connected
module, which then spits the raw packets into an independent ip stack. As
that ip stack assumes incoming data (from below) to be on a per-packet
basis, I need for my pseudo driver to properly detect eth packet boundaries
(btw, does ethertap *not* do ethernet packet assembly? ie. ethertap simply
passes raw ip packets...?).

Firstly, I've found several sample uses of ethertap that poll the tap device
with read combinations waiting for packets to be received. If the linux
kernel spits a single packet into that queue (??) then doing a read on
/dev/tap0 will simply grab that packet & squirt it to the other end & the
whole system can assume its one packet. My problem with this is that I don't
see how one can assume that the tap buffer has only one packet at any one
time. Could it not have 1.5 packets worth of data on a single read, in which
case the other end is going to be presented with a fraction of a packet? In
my case, the *other* ip stack requires whole packets be fed to it. If this
is all true, then I presumably need my "other end" driver to do packet
reassembly at ip level. Correct?

Secondly, rather than doing packet re/dis-assembly, my connecting comms
system (that the tap client hooks onto) simply appends to the front of the
packet, a packet length field. The transceivers at each end look for this
byte and then know the size of each packet (Yes I know, this has zero error
recovery potential, but for the task at hand, is sufficient, & means I don't
need to examine packet content). I've looked into how I could change the
ethertap driver to do this, but found myself delving into the netlink source
to find where to make the addition. Can you comment about the likelihood of
there being a suitable place to make the extension - I just not sure where
the last layer of encapsulation (WRT skbuffs) is done before the data is
written to the tap device - no point pre-pending a length field if a
subsequent module/function is going to further encapsulate (or simply
modify) the packet in another skbuf....

TIA, sTu.

_________________________________________________________________________
Stuart Summerville NEC Australia Pty. Ltd.
ph: (+61 3) 9264-3090 Integrated Comm Products (R&D)
fax:(+61 3) 9264-3841 649-655 Springvale Road
e-mail: stuarts@icpdd.neca.nec.com.au Mulgrave, VIC 3170, AUSTRALIA


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

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