Setting Ethernet II Ethertype

[GoogleCodeExporter]

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]

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

• Changed state: Accepted

[GoogleCodeExporter]

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

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

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]

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]

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]

This issue was closed by revision b1402b1a47.

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

• Changed state: Fixed

[GoogleCodeExporter]

which release has this fix ?

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

[GoogleCodeExporter]

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