search

SylvainTI / ostinato

Automatically exported from code.google.com/p/ostinato
GNU General Public License v3.0
0 stars 0 forks source link

Setting Ethernet II Ethertype #20

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Select Ethernet II in stream editor
2. Ethernet II type follows MAC, but when selected is grayed out
3.

I was hoping to set the Ethernet II type.  Admittedly an odd wish.  We're 
implementing a private datagram type for use in an embedded system.

V0.2 on Windows XP

Thanks in advance for your help.  This looks like a great test tool.

Original issue reported on code.google.com by j...@gibbons.com on 22 Oct 2010 at 11:41

GoogleCodeExporter commented 9 years ago 
Jim,

Currently, the ethertype (and other type fields such as IP protocol type) is 
derived from the subsequent protocol in the frame and not user modifiable.

However, you can use this workaround to setup a custom ethertype -
 * Open the stream editor
 * Goto Protocol Selection tab and select the Advanced mode - replace the Eth II protocol with the UserScript protocol
 * In the Protocol Data tab, configure the script given below as the UserScript
 * Hit Compile
 * Goto Packet View and verify the frame is as you expected.

protocol.protocolFrameSize = function() { return 2; }
protocol.protocolFrameValue = function(index) { return [0x08, 0x00] }

Modify the protocolFrameValue() function above with the ethertype value you 
want. More details and examples of userscripts are at 
http://code.google.com/p/ostinato/wiki/UserScriptHOWTO.

Let me know if the workaround is acceptable for your use case. Meanwhile, I'll 
mark this issue request as a future enhancement.

Regards,
Srivats

Original comment by pstav...@gmail.com on 23 Oct 2010 at 4:00

GoogleCodeExporter commented 9 years ago

Original comment by pstav...@gmail.com on 23 Oct 2010 at 8:36

GoogleCodeExporter commented 9 years ago 
Thank you for your help.  I'm sure that the script would have worked, and I may 
use it in future if I need to control more details of content.  For yesterday's 
test, all I needed was a frame with the intended type word, just to see if the 
recipient's stack would direct it properly.  I managed to do that by deleting 
the ethertype from the protocol, then specifying a repeating word content.  I 
made sure that the word contained the ethertype that I needed in the first 2 
bytes.  The test worked.

I'm probably not your typical user.  Right now, I'm less interested in stress, 
etc., than I am in just achieving functionality on the receiving system.  For 
me, it would be great to be able to compose packet content as a simple string 
of hex bytes.

In any event, your tester definitely got me started, and I'm very grateful for 
that.

Original comment by j...@gibbons.com on 23 Oct 2010 at 3:07

GoogleCodeExporter commented 9 years ago 
Jim,

Good to know that you managed to find a workaround for yourself! A user 
editable packet content hex dump editor is planned for the next release - 0.3

Regards,
Srivats

Original comment by pstav...@gmail.com on 24 Oct 2010 at 7:28

GoogleCodeExporter commented 9 years ago 
The following protocols should be modified to allow overriding of their 
type/length/protocolId fields -
 * Ethernet II
 * 802.3
 * LLC
 * SNAP
 * IPv4

This change will require a bump in the file format version number.

Original comment by pstav...@gmail.com on 24 Oct 2010 at 7:28

GoogleCodeExporter commented 9 years ago 
This issue was closed by revision b1402b1a47.

Original comment by pstav...@gmail.com on 30 Jan 2011 at 11:13

GoogleCodeExporter commented 9 years ago 
which release has this fix ?

Original comment by sundeep....@gmail.com on 29 Mar 2011 at 12:55

GoogleCodeExporter commented 9 years ago 
The next release 0.4 due sometime in April will have this fix. Till that time, 
you need to build from source to get this fix or use the workaround of using a 
hexdump protocol instead of eth2.

Original comment by pstav...@gmail.com on 29 Mar 2011 at 5:47