Re: [net PATCH 1/1] drivers: net: cpsw: Add default vlan for dual emac case also

[Yegor Yefremov <yegorslists@googlemail.com>]

On Wed, Apr 16, 2014 at 3:58 PM, Yegor Yefremov
<yegorslists@googlemail.com> wrote:
> On Wed, Apr 16, 2014 at 7:57 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>> On Tuesday 15 April 2014 07:16 PM, Yegor Yefremov wrote:
>>> On Wed, Apr 9, 2014 at 8:56 PM, David Miller <davem@davemloft.net> wrote:
>>>> From: Mugunthan V N <mugunthanvnm@ti.com>
>>>> Date: Wed, 9 Apr 2014 11:34:40 +0530
>>>>
>>>>> Dual EMAC works with VLAN segregation of the ports, so default vlan needs
>>>>> to be added in dual EMAC case else default vlan will be tagged for all
>>>>> egress packets and vlan unaware switches/servers will drop packets
>>>>> from the EVM.
>>> Hi Mugunthan,
>>>
>>> though this patch fixes drop packets issue, it introduces another
>>> issue. Just connect both interfaces to one switch and configure
>>> different subnets. As soon as you get a broadcast you have an endless
>>> loop and network communication is not possible at all. Before this
>>> patch you could operate as if you had really two independent NICs.
>>>
>>>
>>
>> This patch doesn't add any multicast or unicast entry in the ALE table,
>> so there is no possible way that a broadcast packet is switched within
>> the two external ports, and this patch removes the encapsulation of the
>> default vlan id which is used for internal packet switching inside CPSW
>> switch from host and any packet received from external port will be
>> tagged with port vlan so internal switching will happen with that port
>> vlan-id which will be only that physical port and host port. so the
>> scenario which you mentioned cannot happen theoretically untill you
>> enable bridge between the dual ethernet interface and connect both to
>> the same interface.
>
> Have you tried the described setup? My system is Buildroot on
> am335x-evmsk with almost empty /etc/network/interfaces
>
> # Configure Loopback
> auto lo
> iface lo inet loopback
>
> No bridges:
>
> # brctl show
> bridge name     bridge id               STP enabled     interfaces
>
> And following address setup made manually:
>
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> group default
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 scope host lo
>        valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UP group default qlen 1000
>     link/ether 00:18:31:93:f6:49 brd ff:ff:ff:ff:ff:ff
>     inet 192.168.1.234/24 brd 192.168.1.255 scope global eth0
>        valid_lft forever preferred_lft forever
> 3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
> state DOWN group default qlen 1000
>     link/ether 56:90:76:5b:b5:f3 brd ff:ff:ff:ff:ff:ff
>     inet 192.168.4.234/24 brd 192.168.4.255 scope global eth1
>        valid_lft forever preferred_lft forever
> 4: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
> default qlen 1000
>     link/ether de:ad:be:ef:00:00 brd ff:ff:ff:ff:ff:ff
>
> Routing table:
>
> # ip route show
> 192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.234
> 192.168.4.0/24 dev eth1  proto kernel  scope link  src 192.168.4.234
>
> Same behavior on 3.14.0-rc4-12740-gcc09039-dirty and 3.15.0-rc1-00002-ge0f8779
>
> As soon as insert the cable into eth1, my switch shows very high
> activity and the whole LAN in the company is dead till I remove the
> cable. I have no problems with the version before the fix. I don't
> really know, what happens inside the driver, but could make the same
> setup (best of all in a LAN with many Windows PCs, that send lots of
> broadcast) and let me know if you see the same behavior.

This bug seems to be in 3.12 too. See this thread
(http://e2e.ti.com/support/arm/sitara_arm/f/791/p/338292/1180954.aspx#1180954).

Thanks.

Yegor