Messages in this thread | | | From | "Stuart Summerville (NEC)" <> | Subject | Managing lengths of packets with ethertap... | Date | Thu, 3 Feb 2000 11:20:12 +1100 |
| |
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/
| |