The following commands can be used to capture Ethernet frames sent by the Ixia device:
To display details about a captured packet:
show packet port packet
To display details about a captured packet in raw format:
show packet port packet raw
In both examples, just replace port packet with the actual port packet.
IxiaTraffic>show capture
port | frames count
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
7:1 | 27671
7:2 | 27671
IxiaTraffic>show packet 7:1 0 <====== This fails, implying packet count does not start from 0
Error getting frame data for decode.
Unexpected result
Expected: 0
Received: 1
Eval command: captureBuffer getframe 1
Result: 1
Stdout:
Stderr:
Error:
Failed to get packet data.
IxiaTraffic>show packet 7:1 27671 <========== This fails as well...does this mean packet range is 1 through n-1 (n being 27671 here)?
Packet number exceeds the packets count in the buffer
IxiaTraffic>
I can retrieve any other packet within the range 1 to n-1.
Running iTest 4.0.2, connecting to ixia running 5.60
Thanks for reporting this.
I just verified your issue in-house.
We will investigate and get back to you.
-Hosoon
In iTest, we decided to show packets using argument 1 ~ n-1 because we observed the last captured packet could be either empty or incomplete.
We will update the user documentation and improve the response from the show packet command.
You can still try to using the Ixia's TCL API command directly to retrieve the last captured packet if you want.
Thanks,
-Hosoon
I'm not convinced by your argument ('empty or incomplete'). If you can still recall the packet using ixia TCL APIs then iTest's API probably has a bug (?).
Please confirm if this will be addressed in any patch/update in the near future.
iTest does not have its own iTest TCL APIs for Ixia traffic operations. iTest uses Ixia's TclAPI calls to process the Ixia commands.
For example, for iTest command "show packet 1:1 1" we use Ixia's "captureBuffer" Tcl API call ;
Hosoon,
Thanks for quick response. How do I invoke direct ixia TCL APIs? Didn't work in IxiaTraffic session.
Just have to try 'captureBuffer getframe n' followed by 'captureBuffer cget -frame' (?).
Put an "eval" before the command and you can invoke the direct API. ala "eval captureBuffer cget -frame".
If you want to see the exact Tcl API commands are being executed by a command, go into Windows -> Preferences, then under the Session Types, look at IxTraffic and tell it to log commands and responses to the console view, and you'll be able to see the commands in the console view (I believe there's 2-3 total captureBuffer commands it uses to show packets, although it'll print it nicer with the show packet command).
As Hosoon said earlier, that last frame can be pretty unreliable (from the Ixia APIs) and can be captured in a half-done or barely started state depending on how the capture can be stopped, which is why we try to protect people from showing that last frame. It wouldn't be that hard to open it back up if it's really super important to look at every single frame that's captured.
Kevin,
eval worked.
The show packet is much 'nicer' compared to raw output. Gotta find a way to print 'decoded' output of the raw hex packet.
It is indeed super important for us to capture and analyze all frames. Especially for our functional tests, we send a limited number of packets and each one of them needs to be thoroughly analyzed. Inability to have similar output for all packets would mean additional check to see if it is the last packet (and then analyze in a different manner...not real convenient and a bit messy). Maybe I'm pushing my luck too far but is there a way to get decoded output?
I did use log to console and it looks like iTest calls polish up the output.
Yeah, we do polish up the calls so it's a little easier to deal with for people.
Btw, the exact sequence of the calls is (I believe):
captureBuffer get 1 $card $port $frame $frame
captureBuffer getframe 1
captureBuffer cget -frame
That'll get you the encoded output. I think that's the best we can do right now, since I don't think the decoding is exposed anywhere.
That being said, I think I agree with your opinion that it should show all n (and Ixia does start counting at 1 not at 0); we've filed a bug for that, so hopefully thatll be fixed in the next release or so.
After executing 'show packet 7:1 1', we just have to eval
captureBuffer getframe n
captureBuffer cget -frame
to get the last packet. Atleast, that's what I did and was able to see the last packet (raw hex dump).
Thanks for logging it in your system. Hopefully we can get the feature in the next release.
I've heard that this was discussed in Fanfare internally as a bug. Also, I think it was written within this forum that it was a working feature with version 3.2. If so, when can we expect a patch/update? Just because of this, we're having to add extra code every time. Fixing this would help.
What version of iTest are you using right now? I just checked in our bug log, and it should be fixed for 4.1.1.
There's a 4.1.1? Let me check it out. Thanks!
we're at 4.1.0
Wish someone emailed us when there was an update available....
http://forums.fanfaresoftware.com/t5/Announcements/iTest-4-1-1-is-now-available/td-p/20408 . I think if you just subscribe to the announcement forum, you'll get emails for it.
