netdev - Re: bnx2 vlan issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 1 Apr 2011 19:01:08 -0700
From:	Jesse Gross <jesse@...ira.com>
To:	Seblu <seblu@...lu.net>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: bnx2 vlan issue

On Thu, Mar 24, 2011 at 5:26 PM, Seblu <seblu@...lu.net> wrote:
> On Thu, Mar 24, 2011 at 8:55 PM, Jesse Gross <jesse@...ira.com> wrote:
>> On Thu, Mar 24, 2011 at 5:58 AM, Seblu <seblu@...lu.net> wrote:
>>>> I don't necessarily disagree that there should be a better way to do
>>>> this, though as of the moment the above is probably your best bet.
>>>>
>>>> To me, the most important thing is to have consistent behavior across
>>>> different cards.
>>>
>>> Speaking of that, i've tryed  2.6.38 on my station (dell opitplex 980)
>>> to use the new bridging schema and it doesn't work.
>>> Exactly the case previously described: ip on br0 (eth0+eth1) and ip on
>>> br0.42. eth0 driver is e1000e and eth1 is tg3. br0.42 don't receive
>>> traffic.
>>> I have to open a bug report?
>>
>> The change was deliberate, not an accidental mistake, so don't expect
>> 2.6.38 to suddenly switch back to the previous behavior.  There's no
>> need to file a bug report - the new behavior is known (I was the one
>> who changed it in the first place).  I will look into nicer semantics
>> in the future.
>>
> Maybe i was not enough clear. It seems to me that new behaviour, with
> vlan on top of bridge rather than above interface in bridge is not
> functional.
> In other words, i cannot use vlan and bridge together in 2.6.38 (with e1000e).

Sorry, I misunderstood what you were saying before.  Can you try and
see where the packets are getting lost or improperly handled by
running tcpdump on the various interfaces?  For example, check that
packets are coming in with tags on the physical interfaces, have tags
on the bridge interface, no tag on the vlan interface, etc.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html