Don't see any received frames with 0.4.1 development revs xxx3d9 and xxx 6d3

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Using 0.4.1 rev f99d5b97f3d9 or b1420e3a46d3 development code
2. Using a single dual port 10G CNA(Brocade 1020)
3. Configure each CNA port to talk to the other - Just using L1 MAC  (00 00 01 
for port 1,  00 00 02 for port 2 as source / destination)
4. Random pattern payload, 1500 byte size.
5. Simple optical cable going between the two optical CNA ports being used

What is the expected output?
I'd expect to see received frames/ data on the other port from the one I'm 
transmitting from.  Instead - the port that's connected to the transmitting 
port just stays 0 on "Bytes received" and "Frames received" .  The Bytes sent , 
Byte send rate do increment on the transmitting port.

With the released 0.41 Ostinato code, this works fine.

What do you see instead?
Just see 0 on "Bytes Received" and "Frames Received".  If I disconnect the 
optical cable, then the byte and frame "send rate" counters go to zero (with 
the cable installed they go to around 1496000).
The transmitting port Frames Sent / Bytes Sent counters do increment

What version and revision of the product are you using (available in the
About dialog)? Using 0.4.1 rev f99d5b97f3d9 or b1420e3a46d3 

On what operating system? LInux 11.4 (OpenSuse)

Please provide any additional information below.
I've used this 1020 CNA with Ostinato 0.2, 0.3 and 0.41 codes, and this simple 
traffic method works fine (I send data across each port to the other).  I tried 
additional setups with the frame (L2 ethernet II, L3 IPv4) but that had no 
impact.

Going back to the released 0.41 code (rev xxx39e) works fine in the exact same 
system.

Original issue reported on code.google.com by whoehenr...@gmail.com on 12 Oct 2011 at 10:04

[GoogleCodeExporter]

@whoehenr...: Post 0.4.1 release (rev xxx39e), some optimization changes were 
done to improve the performance and as part of it the stats collection logic 
was also changed. Stats are now read from /proc/net/dev. Do the following and 
send me the results -

1. Do 'cat /proc/net/dev' a couple of times while transmit is running in 
Ostinato and see if the Tx/Rx stats are incremented in this file. Send me the 
output.
2. Send me the console log right from when you start Ostinato

Original comment by pstav...@gmail.com on 13 Oct 2011 at 1:32

• Changed state: Reviewed

[GoogleCodeExporter]

Thanks for the quick response.

I did the 'cat /proc/net/dev' and my destination ethernet port (in this case 
eth2) never received anything.  The transmitting port (eth1) does show bytes 
being transmitted).
I repeated this test using the old (released 4.1) Ostinato code and 
/proc/net/dev clearly shows the stats changing and eth2 receives the bytes from 
a transmitting eth1.

As requested - I've attached the Ostinato console log with the new code.  I 
started Ostinato, selected the eth1 port (first port on my 1020 CNA) and 
applied a stream (very simple with just 100byte packet, 1 packet per second 
transmit) and then started and stopped transmision on the eth1 port. 

Please advise on anything else I can provide to assist.

Regards,
 Werner Hoehenrieder

Original comment by whoehenr...@gmail.com on 13 Oct 2011 at 5:28

Attachments:

• ostinato_console-log.txt
• proc_net_dev.txt
• proc_net_dev_old-code.txt

[GoogleCodeExporter]

Werner,

I don't see anything wrong in the console log. I'm assuming you are using the 
same stream for both the latest code and 0.4.1 tests. Can you confirm?

One possibility is that maybe the promisc flag is not correctly set. Please 
send me the following -

1. While transmit is running in both the cases, send me the output of 'ifconfig 
eth1; ifconfig eth2'
2. In the stream that you are sending from eth1 to eth2, configure the 'Dest 
Mac' field to the Mac address of the eth2 interface (you can see the mac 
address when you do a 'ifconfig eth2'). Try with both latest code and 0.4.1 and 
send me the output of 'cat /proc/net/dev' in both cases.

Srivats

Original comment by pstav...@gmail.com on 14 Oct 2011 at 1:55

[GoogleCodeExporter]

Srivats,

I have used the same "stream" for both latest code and 0.4.1 tests - older code 
works fine, newer on doesn't pass on.

More importantly - changing the Dest Mac field to the eth2 interface corrected 
things.  Previously - this didn't need to be exact - but changing even 1 part 
of the address -then the data won't go through.  This makes sense to me - it's 
just that I didn't have to do this previously (I would set eth1 as 0000001 and 
eth2 as 00000002 in source / destination - which worked fine).  No worries 
though - I only have to configure it once and save it.

NOTE:  Do you still want the cat / proc/net/dev data?

One other side question on this.  When Ostinato shows the ethernet ports - they 
all get listed as address 0.0.0.0 ( eth1[0.0.0.0]) ?  I do have IP address's 
assigned to the ports - but it doesn't appear to use them?

Thanks again for your efforts!!

-Werner

Original comment by whoehenr...@gmail.com on 17 Oct 2011 at 4:53

[GoogleCodeExporter]

Werner,

As per Ostinato design, you do not require to change the DstMac - so there is 
some problem.

Looks like the port is not set in "promiscuous mode". Can you send me the 
output of 'ifconfig -a' when the old code is running and when the new code is 
running?

Although you can go ahead with changing the dst mac field, since I'm not able 
to see the problem on my machine, I would really appreciate if you could help 
me with logs and other debug (if required ) so that we can get to the bottom of 
this issue.

Regarding the IP address shown as [0.0.0.0], it is not yet implemented and 
hence it shows like that.

Srivats

Original comment by pstav...@gmail.com on 18 Oct 2011 at 1:30

[GoogleCodeExporter]

Srivats,

More than happy to help you with additional info.

I've attached "ifconfig -a" for the released 0.41 code and also the 3d9 
development release.

Additionally - I forced my 1020 CNA info promisc mode (ifconfig eth1 promisc, 
ifconfig eth2 promisc) and this fixed the traffic issue I was having (ie. it 
allowed Ostinato to work properly without requiring a full MAC address in the 
Source / Dest fields).

Taking a quick look at the ifconfig from older and newer code - I don't see 
that either one indicates "promisc" mode - just multicast.

Hope this helps and please let me know what else I can provide to assist. 

Regards,
 Werner

Original comment by whoehenr...@gmail.com on 18 Oct 2011 at 4:59

Attachments:

• ifconfig-4.1code.txt
• ifconfig-4.1rev3d9.txt

[GoogleCodeExporter]

Thanks Werner! Looks like a problem with promisc although ifconfig doesn't seem 
to show it in both cases. Will try a fix and let you know.

Original comment by pstav...@gmail.com on 20 Oct 2011 at 1:49

• Changed state: Accepted

[GoogleCodeExporter]

This issue was closed by revision e283f258bf75.

Original comment by pstav...@gmail.com on 22 Oct 2011 at 9:26

• Changed state: Fixed

[GoogleCodeExporter]

Werner: Can you update your code from the repository and let me know if the 
problem is fixed for you?

Original comment by pstav...@gmail.com on 23 Oct 2011 at 7:44

[GoogleCodeExporter]

Will do.  Don't have access to that system right now but should be able to test 
this tomorrow morning. 

Original comment by whoehenr...@gmail.com on 23 Oct 2011 at 6:30

[GoogleCodeExporter]

Srivats,

Well I loaded the latest code (0.5  rev xxx27df) and it WORKS GREAT!

I made sure to reset my 1020CNA ethernet ports to non-promiscuous mode, and 
OStinato set them to promiscuous mode and the traffic ran just fine.  In the 
MAC address field for the streams, I just entered 00 .. 01 / 000.. 02 for 
source / destination (instead of the entire MAC address). 

I also noticed that after exiting Ostinato, my ethernet ports were reset to 
non-promiscuous mode - which is good.

One side question - when I set the "Avg bps" to a really large number - it goes 
to a "nan" setting.  Just curious what that means?

Thanks again for your efforts - well done.

-Werner

Original comment by whoehenr...@gmail.com on 24 Oct 2011 at 4:47

[GoogleCodeExporter]

@werner: 'nan' means 'not a number'. Please file a new bug with steps to 
recreate.

Original comment by pstav...@gmail.com on 28 Oct 2011 at 2:17