What steps will reproduce the problem?
1.Ubuntu 10.04, 10/100Mb Ethernet interface, transmit only
2. Frame size 1024, raw 802.3 packets (MAC address and CRC only)
3. Interval set to 0.0 for max wirespeed, single stream, goto start
4. Leave running at 100Mb for 1-2 hours without stopping
We are sending raw, MAC wrapped only packets through a switch/router and then
on to an embedded device with no return packets. MAC address is statically
loaded in the switch to output on desired port. We get 95% plus bandwidth.
We left the test running over lunch, then when we come back no packets are
being sent, and ostinato does not show outgoing packets after clicking start.
Clicking Apply gets error message 'Stop stream first'.
Attached is an 800 line text of the output in the terminal that started
ostinato. It should start around the point that the overflow Tx count occurred.
After failing to get packets sent, we tried stop and start several times, and
Apply, and also delete stream and open stream. Then I killed the drone process
and manually restarted drone from a second window (see second attached file).
At this point it looked like the prior Tx count returned. The number was
approximately 3,349,864,911 bytes sent.
Proper operation was restored after exiting ostinato, verifying that both
ostinato and drone processes were gone, and restarting. This is the second time
that ostinato was unresponsive. The first was when we first came into the lab
in the morning having used ostinato (not sure if it was left transmitting) over
night.
What is the expected output? What do you see instead?
What version and revision of the product are you using (available in the
About dialog)? On what operating system?
Version 74c9dcf830e3@
Ubuntu 10.04LTS
Please provide any additional information below.
Original issue reported on code.google.com by mbush...@gmail.com on 25 Oct 2013 at 10:57
Original issue reported on code.google.com by
mbush...@gmail.comon 25 Oct 2013 at 10:57Attachments: