[Martin Visser <martinvisser99@xxxxxxxxx>]

Herb,

I think think you will find on HP c7000 blades paired with with Virtual Connect modules, the teaming is still done via Windows drivers - HP provides these drivers as part of the standard install. Virtual Connect drivers can present NICs (network interfaces) in different configurations (obviously binding to different VLANs, as well as even setting throughput) on these entities known as FlexNICs. While they have advanced configuration capability, the network interfaces are still presented as NICs, and the drivers need to do the normal interface between hardware and the OS. If you have found an issue you really need to isolate it down to the minimum configuration that causes the issue, and raise the issue through your normal HP .support channels

(Disclaimer: I work for HP, but not in the Windows/Proliant Server business, but in the enterprise network consulting side of things).

Regards, Martin

MartinVisser99@xxxxxxxxx

On 16 September 2014 06:33, Herb Falk <herb@xxxxxxxxxxxx> <Herb@xxxxxxxxxxxx> wrote:

So, a little more detailed.  These are HP Blades and the teaming is done in what they call a Virtual Connect.  The teaming is not done in Windows.  So, I suspect it is an issue between WinPcap and the underpinnings of Windows/Vconnect.  HP says it should work.  Any ideas?



Herbert Falk
Solutions Architect
SISCO, INC.
6605 19 ½ Mile Rd.
Sterling Heights, MI 48314
(586) 254-0020 x-105


                                                                              
"In matters of style, swim with the current;   in matters of principle, stand like a rock." [Thomas Jefferson]


NOTICE: This communication may contain privileged or other confidential information. If you are not the intended recipient, or believe that you have  received this communication in error, please do not print, copy, retransmit,  disseminate, or otherwise use the information. Also,  please indicate to the sender that you have received this communication in error, and delete the copy you received. Thank you.


-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Guy Harris
Sent: Monday, September 15, 2014 3:23 PM
To: Developer support list for Wireshark

Subject: Re: [Wireshark-dev] Question about capturing from multiple interfaces that have the same MAC Address


On Sep 15, 2014, at 11:55 AM, "Herb Falk <herb@xxxxxxxxxxxx>" <Herb@xxxxxxxxxxxx> wrote:

> On Sep 15, 2014, at 11:14 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>
>> On Sep 15, 2014, at 10:44 AM, "Herb Falk <herb@xxxxxxxxxxxx>" <Herb@xxxxxxxxxxxx> wrote:
>>
>>> There appears to be an issue with Wireshark capturing information from interfaces that have the same MAC Address.
>>
>> So what is the issue?  Does capture fail to start?  If so, what error is reported?  Do some packets not get captured?  Do no packets get captured? On what operating system is this?
>
> If Wireshark is left in the Interface/Capture display (not even doing any captures)

Actually, if that's the display with the graphs of packets arrived, it *is* doing a capture, at the libpcap/WinPcap level, it's just counting the packets and then discarding them.

> the system eventually crashes (takes about 2-3 minutes).

If the *system* crashes, that's either an OS bug or, if this is on Windows, either an OS bug or a WinPcap kernel driver bug.

>>> Does somebody know if this is an issue, or where the code for interface/MAC address binding is?
>>
>> What do you mean by "binding"?  Assigning a MAC address to an interface?  Deciding, if both interfaces receive a copy of a given packet, which one gets inserted into the networking code and passed up to libpcap/WinPcap and thus to Wireshark?  In both of those cases, the code is in your OS, and where it is in the OS depends on what OS it is.
>
> There is a little bit more going on.  Consider 4 NICs (a,b,c,d)  they are teamed into 2 pairs (t1 and t2). a & b have the same MAC as does t1. c and d have the same MAC as does t2.  There is another Winpcap application that runs on the box,

OK, so this is Windows, so there's either a bug in the Windows kernel-mode code (NDIS code?) or in the WinPcap driver.

> and it has no problem with the configuration.  My "binding" question was if Wireshark uses the interface to lookup the MAC

It does, but only to *display* the MAC address in the interface details window; it makes a call, through the WinPcap Packet.dll API, to fetch various interface properties, including its "permanent address", and displays them.

> and there are multiple NICs with the same MAC, this could be causing a loop/issue inside of Wireshark.

No, that wouldn't happen.  The MAC address is just 6 octets which it displays.

> Don't know, but would like a pointer to the code so I could step through it.

If the code causing the crash is in WinPcap, you can download the source from

        http://www.winpcap.org/devel.htm

If it's in Windows, you'll have to talk to Microsoft if you want to see the source code....

> Maybe binding was the incorrect word.

It suggests a connection between interface and MAC address deeper than anything done by Wireshark itself, and thus suggests that the issue might be in the Wireshark code rather than in the WinPcap or Windows code.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe