* am335x: no multicast reception over VLAN
@ 2016-03-16 15:05 Yegor Yefremov
2016-03-29 4:00 ` Mugunthan V N
0 siblings, 1 reply; 27+ messages in thread
From: Yegor Yefremov @ 2016-03-16 15:05 UTC (permalink / raw)
To: netdev; +Cc: linux-omap, N, Mugunthan V, drivshin, grygorii.strashko
I have an am335x based board using CPSW in Dual EMAC mode. Without
VLAN IDs I can receive and send multicast packets [1]. When I create
VLAN ID:
ip link add link eth1 name eth1.100 type vlan id 100
ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth1.100
route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
I can successfully send multicast packets, but not receive them. On
the other side of the Ethernet cable I've used Pandaboard. Pandaboard
could both receive and send multicast packets via VLAN.
This setup was tested with both 3.18.21 and 4.5 kernels.
Any idea?
[1] https://pymotw.com/2/socket/multicast.html
Regards,
Yegor
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
2016-03-16 15:05 am335x: no multicast reception over VLAN Yegor Yefremov
@ 2016-03-29 4:00 ` Mugunthan V N
0 siblings, 0 replies; 27+ messages in thread
From: Mugunthan V N @ 2016-03-29 4:00 UTC (permalink / raw)
To: Yegor Yefremov, netdev; +Cc: linux-omap, drivshin, grygorii.strashko
Hi Yegor
On Wednesday 16 March 2016 08:35 PM, Yegor Yefremov wrote:
> I have an am335x based board using CPSW in Dual EMAC mode. Without
> VLAN IDs I can receive and send multicast packets [1]. When I create
> VLAN ID:
>
> ip link add link eth1 name eth1.100 type vlan id 100
> ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth1.100
> route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
>
> I can successfully send multicast packets, but not receive them. On
> the other side of the Ethernet cable I've used Pandaboard. Pandaboard
> could both receive and send multicast packets via VLAN.
Are you trying multicast tx/rx on eth1 or eth1.100?
>
> This setup was tested with both 3.18.21 and 4.5 kernels.
>
> Any idea?
>
> [1] https://pymotw.com/2/socket/multicast.html
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
@ 2016-03-29 4:00 ` Mugunthan V N
0 siblings, 0 replies; 27+ messages in thread
From: Mugunthan V N @ 2016-03-29 4:00 UTC (permalink / raw)
To: Yegor Yefremov, netdev; +Cc: linux-omap, drivshin, grygorii.strashko
Hi Yegor
On Wednesday 16 March 2016 08:35 PM, Yegor Yefremov wrote:
> I have an am335x based board using CPSW in Dual EMAC mode. Without
> VLAN IDs I can receive and send multicast packets [1]. When I create
> VLAN ID:
>
> ip link add link eth1 name eth1.100 type vlan id 100
> ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth1.100
> route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
>
> I can successfully send multicast packets, but not receive them. On
> the other side of the Ethernet cable I've used Pandaboard. Pandaboard
> could both receive and send multicast packets via VLAN.
Are you trying multicast tx/rx on eth1 or eth1.100?
>
> This setup was tested with both 3.18.21 and 4.5 kernels.
>
> Any idea?
>
> [1] https://pymotw.com/2/socket/multicast.html
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
2016-03-29 4:00 ` Mugunthan V N
(?)
@ 2016-03-29 5:21 ` Yegor Yefremov
2016-03-29 11:05 ` Grygorii Strashko
-1 siblings, 1 reply; 27+ messages in thread
From: Yegor Yefremov @ 2016-03-29 5:21 UTC (permalink / raw)
To: Mugunthan V N; +Cc: netdev, linux-omap, drivshin, grygorii.strashko, ml
Hi Mugunthan,
On Tue, Mar 29, 2016 at 6:00 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
> Hi Yegor
>
> On Wednesday 16 March 2016 08:35 PM, Yegor Yefremov wrote:
>> I have an am335x based board using CPSW in Dual EMAC mode. Without
>> VLAN IDs I can receive and send multicast packets [1]. When I create
>> VLAN ID:
>>
>> ip link add link eth1 name eth1.100 type vlan id 100
>> ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth1.100
>> route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
>>
>> I can successfully send multicast packets, but not receive them. On
>> the other side of the Ethernet cable I've used Pandaboard. Pandaboard
>> could both receive and send multicast packets via VLAN.
>
> Are you trying multicast tx/rx on eth1 or eth1.100?
I'm trying multicast tx/rx on eth1.100.
eth1 has no problems.
Yegor
>> This setup was tested with both 3.18.21 and 4.5 kernels.
>>
>> Any idea?
>>
>> [1] https://pymotw.com/2/socket/multicast.html
>>
>
> --
> Regards
> Mugunthan V N
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
2016-03-29 5:21 ` Yegor Yefremov
@ 2016-03-29 11:05 ` Grygorii Strashko
0 siblings, 0 replies; 27+ messages in thread
From: Grygorii Strashko @ 2016-03-29 11:05 UTC (permalink / raw)
To: Yegor Yefremov, Mugunthan V N; +Cc: netdev, linux-omap, drivshin, ml
On 03/29/2016 08:21 AM, Yegor Yefremov wrote:
> Hi Mugunthan,
>
> On Tue, Mar 29, 2016 at 6:00 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>> Hi Yegor
>>
>> On Wednesday 16 March 2016 08:35 PM, Yegor Yefremov wrote:
>>> I have an am335x based board using CPSW in Dual EMAC mode. Without
>>> VLAN IDs I can receive and send multicast packets [1]. When I create
>>> VLAN ID:
>>>
>>> ip link add link eth1 name eth1.100 type vlan id 100
>>> ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth1.100
>>> route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
>>>
>>> I can successfully send multicast packets, but not receive them. On
>>> the other side of the Ethernet cable I've used Pandaboard. Pandaboard
>>> could both receive and send multicast packets via VLAN.
>>
>> Are you trying multicast tx/rx on eth1 or eth1.100?
>
> I'm trying multicast tx/rx on eth1.100.
>
> eth1 has no problems.
>
it'd be nice if will be able to post here output fom commands:
# switch-config -d [git://git.ti.com/switch-config/switch-config.git v4.1]
# ifconfig -a
# tcpdump -e -f -Q in -i eth0
# tcpdump -e -f -Q in -i eth0.100
--
regards,
-grygorii
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
@ 2016-03-29 11:05 ` Grygorii Strashko
0 siblings, 0 replies; 27+ messages in thread
From: Grygorii Strashko @ 2016-03-29 11:05 UTC (permalink / raw)
To: Yegor Yefremov, Mugunthan V N; +Cc: netdev, linux-omap, drivshin, ml
On 03/29/2016 08:21 AM, Yegor Yefremov wrote:
> Hi Mugunthan,
>
> On Tue, Mar 29, 2016 at 6:00 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>> Hi Yegor
>>
>> On Wednesday 16 March 2016 08:35 PM, Yegor Yefremov wrote:
>>> I have an am335x based board using CPSW in Dual EMAC mode. Without
>>> VLAN IDs I can receive and send multicast packets [1]. When I create
>>> VLAN ID:
>>>
>>> ip link add link eth1 name eth1.100 type vlan id 100
>>> ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth1.100
>>> route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
>>>
>>> I can successfully send multicast packets, but not receive them. On
>>> the other side of the Ethernet cable I've used Pandaboard. Pandaboard
>>> could both receive and send multicast packets via VLAN.
>>
>> Are you trying multicast tx/rx on eth1 or eth1.100?
>
> I'm trying multicast tx/rx on eth1.100.
>
> eth1 has no problems.
>
it'd be nice if will be able to post here output fom commands:
# switch-config -d [git://git.ti.com/switch-config/switch-config.git v4.1]
# ifconfig -a
# tcpdump -e -f -Q in -i eth0
# tcpdump -e -f -Q in -i eth0.100
--
regards,
-grygorii
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
2016-03-29 11:05 ` Grygorii Strashko
(?)
@ 2016-03-29 12:35 ` Yegor Yefremov
2016-03-29 12:44 ` Grygorii Strashko
-1 siblings, 1 reply; 27+ messages in thread
From: Yegor Yefremov @ 2016-03-29 12:35 UTC (permalink / raw)
To: Grygorii Strashko; +Cc: Mugunthan V N, netdev, linux-omap, drivshin, ml
On Tue, Mar 29, 2016 at 1:05 PM, Grygorii Strashko
<grygorii.strashko@ti.com> wrote:
> On 03/29/2016 08:21 AM, Yegor Yefremov wrote:
>> Hi Mugunthan,
>>
>> On Tue, Mar 29, 2016 at 6:00 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>> Hi Yegor
>>>
>>> On Wednesday 16 March 2016 08:35 PM, Yegor Yefremov wrote:
>>>> I have an am335x based board using CPSW in Dual EMAC mode. Without
>>>> VLAN IDs I can receive and send multicast packets [1]. When I create
>>>> VLAN ID:
>>>>
>>>> ip link add link eth1 name eth1.100 type vlan id 100
>>>> ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth1.100
>>>> route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
>>>>
>>>> I can successfully send multicast packets, but not receive them. On
>>>> the other side of the Ethernet cable I've used Pandaboard. Pandaboard
>>>> could both receive and send multicast packets via VLAN.
>>>
>>> Are you trying multicast tx/rx on eth1 or eth1.100?
>>
>> I'm trying multicast tx/rx on eth1.100.
>>
>> eth1 has no problems.
>>
>
> it'd be nice if will be able to post here output fom commands:
> # switch-config -d [git://git.ti.com/switch-config/switch-config.git v4.1]
> # ifconfig -a
> # tcpdump -e -f -Q in -i eth0
> # tcpdump -e -f -Q in -i eth0.100
Which kernel/branch do you want me to test?
git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git and ti-rt-linux-4.1.y?
So far I was using vanilla kernel.
Yegor
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
2016-03-29 12:35 ` Yegor Yefremov
@ 2016-03-29 12:44 ` Grygorii Strashko
0 siblings, 0 replies; 27+ messages in thread
From: Grygorii Strashko @ 2016-03-29 12:44 UTC (permalink / raw)
To: Yegor Yefremov; +Cc: Mugunthan V N, netdev, linux-omap, drivshin, ml
On 03/29/2016 03:35 PM, Yegor Yefremov wrote:
> On Tue, Mar 29, 2016 at 1:05 PM, Grygorii Strashko
> <grygorii.strashko@ti.com> wrote:
>> On 03/29/2016 08:21 AM, Yegor Yefremov wrote:
>>> Hi Mugunthan,
>>>
>>> On Tue, Mar 29, 2016 at 6:00 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>>> Hi Yegor
>>>>
>>>> On Wednesday 16 March 2016 08:35 PM, Yegor Yefremov wrote:
>>>>> I have an am335x based board using CPSW in Dual EMAC mode. Without
>>>>> VLAN IDs I can receive and send multicast packets [1]. When I create
>>>>> VLAN ID:
>>>>>
>>>>> ip link add link eth1 name eth1.100 type vlan id 100
>>>>> ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth1.100
>>>>> route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
>>>>>
>>>>> I can successfully send multicast packets, but not receive them. On
>>>>> the other side of the Ethernet cable I've used Pandaboard. Pandaboard
>>>>> could both receive and send multicast packets via VLAN.
>>>>
>>>> Are you trying multicast tx/rx on eth1 or eth1.100?
>>>
>>> I'm trying multicast tx/rx on eth1.100.
>>>
>>> eth1 has no problems.
>>>
>>
>> it'd be nice if will be able to post here output fom commands:
>> # switch-config -d [git://git.ti.com/switch-config/switch-config.git v4.1]
>> # ifconfig -a
>> # tcpdump -e -f -Q in -i eth0
>> # tcpdump -e -f -Q in -i eth0.100
>
> Which kernel/branch do you want me to test?
>
> git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git and ti-rt-linux-4.1.y?
>
> So far I was using vanilla kernel.
Your branch (but better 4.5 kernels (or 4.4)).
Just when you've done with configuration run cmds 1&2,
and when you run your use-case - run cmds 2&3 on receiver side (grap ~5-10 packets).
then stop test and run cmd 1 again.
After all could you provide your console output here, pls.
--
regards,
-grygorii
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
@ 2016-03-29 12:44 ` Grygorii Strashko
0 siblings, 0 replies; 27+ messages in thread
From: Grygorii Strashko @ 2016-03-29 12:44 UTC (permalink / raw)
To: Yegor Yefremov; +Cc: Mugunthan V N, netdev, linux-omap, drivshin, ml
On 03/29/2016 03:35 PM, Yegor Yefremov wrote:
> On Tue, Mar 29, 2016 at 1:05 PM, Grygorii Strashko
> <grygorii.strashko@ti.com> wrote:
>> On 03/29/2016 08:21 AM, Yegor Yefremov wrote:
>>> Hi Mugunthan,
>>>
>>> On Tue, Mar 29, 2016 at 6:00 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>>> Hi Yegor
>>>>
>>>> On Wednesday 16 March 2016 08:35 PM, Yegor Yefremov wrote:
>>>>> I have an am335x based board using CPSW in Dual EMAC mode. Without
>>>>> VLAN IDs I can receive and send multicast packets [1]. When I create
>>>>> VLAN ID:
>>>>>
>>>>> ip link add link eth1 name eth1.100 type vlan id 100
>>>>> ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth1.100
>>>>> route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
>>>>>
>>>>> I can successfully send multicast packets, but not receive them. On
>>>>> the other side of the Ethernet cable I've used Pandaboard. Pandaboard
>>>>> could both receive and send multicast packets via VLAN.
>>>>
>>>> Are you trying multicast tx/rx on eth1 or eth1.100?
>>>
>>> I'm trying multicast tx/rx on eth1.100.
>>>
>>> eth1 has no problems.
>>>
>>
>> it'd be nice if will be able to post here output fom commands:
>> # switch-config -d [git://git.ti.com/switch-config/switch-config.git v4.1]
>> # ifconfig -a
>> # tcpdump -e -f -Q in -i eth0
>> # tcpdump -e -f -Q in -i eth0.100
>
> Which kernel/branch do you want me to test?
>
> git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git and ti-rt-linux-4.1.y?
>
> So far I was using vanilla kernel.
Your branch (but better 4.5 kernels (or 4.4)).
Just when you've done with configuration run cmds 1&2,
and when you run your use-case - run cmds 2&3 on receiver side (grap ~5-10 packets).
then stop test and run cmd 1 again.
After all could you provide your console output here, pls.
--
regards,
-grygorii
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
2016-03-29 12:44 ` Grygorii Strashko
@ 2016-03-30 5:33 ` Mugunthan V N
-1 siblings, 0 replies; 27+ messages in thread
From: Mugunthan V N @ 2016-03-30 5:33 UTC (permalink / raw)
To: Grygorii Strashko, Yegor Yefremov; +Cc: netdev, linux-omap, drivshin, ml
On Tuesday 29 March 2016 06:14 PM, Grygorii Strashko wrote:
> On 03/29/2016 03:35 PM, Yegor Yefremov wrote:
>> On Tue, Mar 29, 2016 at 1:05 PM, Grygorii Strashko
>> <grygorii.strashko@ti.com> wrote:
>>> On 03/29/2016 08:21 AM, Yegor Yefremov wrote:
>>>> Hi Mugunthan,
>>>>
>>>> On Tue, Mar 29, 2016 at 6:00 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>>>> Hi Yegor
>>>>>
>>>>> On Wednesday 16 March 2016 08:35 PM, Yegor Yefremov wrote:
>>>>>> I have an am335x based board using CPSW in Dual EMAC mode. Without
>>>>>> VLAN IDs I can receive and send multicast packets [1]. When I create
>>>>>> VLAN ID:
>>>>>>
>>>>>> ip link add link eth1 name eth1.100 type vlan id 100
>>>>>> ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth1.100
>>>>>> route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
>>>>>>
>>>>>> I can successfully send multicast packets, but not receive them. On
>>>>>> the other side of the Ethernet cable I've used Pandaboard. Pandaboard
>>>>>> could both receive and send multicast packets via VLAN.
>>>>>
>>>>> Are you trying multicast tx/rx on eth1 or eth1.100?
>>>>
>>>> I'm trying multicast tx/rx on eth1.100.
>>>>
>>>> eth1 has no problems.
>>>>
>>>
>>> it'd be nice if will be able to post here output fom commands:
>>> # switch-config -d [git://git.ti.com/switch-config/switch-config.git v4.1]
>>> # ifconfig -a
>>> # tcpdump -e -f -Q in -i eth0
>>> # tcpdump -e -f -Q in -i eth0.100
>>
>> Which kernel/branch do you want me to test?
>>
>> git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git and ti-rt-linux-4.1.y?
>>
>> So far I was using vanilla kernel.
>
> Your branch (but better 4.5 kernels (or 4.4)).
> Just when you've done with configuration run cmds 1&2,
> and when you run your use-case - run cmds 2&3 on receiver side (grap ~5-10 packets).
> then stop test and run cmd 1 again.
>
> After all could you provide your console output here, pls.
>
>
To use command 1, you need TI kernel [1] as it won't build with vanilla
kernel.
[1]: git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git ti-linux-4.1.y
Regards
Mugunthan V N
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
@ 2016-03-30 5:33 ` Mugunthan V N
0 siblings, 0 replies; 27+ messages in thread
From: Mugunthan V N @ 2016-03-30 5:33 UTC (permalink / raw)
To: Grygorii Strashko, Yegor Yefremov; +Cc: netdev, linux-omap, drivshin, ml
On Tuesday 29 March 2016 06:14 PM, Grygorii Strashko wrote:
> On 03/29/2016 03:35 PM, Yegor Yefremov wrote:
>> On Tue, Mar 29, 2016 at 1:05 PM, Grygorii Strashko
>> <grygorii.strashko@ti.com> wrote:
>>> On 03/29/2016 08:21 AM, Yegor Yefremov wrote:
>>>> Hi Mugunthan,
>>>>
>>>> On Tue, Mar 29, 2016 at 6:00 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>>>> Hi Yegor
>>>>>
>>>>> On Wednesday 16 March 2016 08:35 PM, Yegor Yefremov wrote:
>>>>>> I have an am335x based board using CPSW in Dual EMAC mode. Without
>>>>>> VLAN IDs I can receive and send multicast packets [1]. When I create
>>>>>> VLAN ID:
>>>>>>
>>>>>> ip link add link eth1 name eth1.100 type vlan id 100
>>>>>> ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth1.100
>>>>>> route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
>>>>>>
>>>>>> I can successfully send multicast packets, but not receive them. On
>>>>>> the other side of the Ethernet cable I've used Pandaboard. Pandaboard
>>>>>> could both receive and send multicast packets via VLAN.
>>>>>
>>>>> Are you trying multicast tx/rx on eth1 or eth1.100?
>>>>
>>>> I'm trying multicast tx/rx on eth1.100.
>>>>
>>>> eth1 has no problems.
>>>>
>>>
>>> it'd be nice if will be able to post here output fom commands:
>>> # switch-config -d [git://git.ti.com/switch-config/switch-config.git v4.1]
>>> # ifconfig -a
>>> # tcpdump -e -f -Q in -i eth0
>>> # tcpdump -e -f -Q in -i eth0.100
>>
>> Which kernel/branch do you want me to test?
>>
>> git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git and ti-rt-linux-4.1.y?
>>
>> So far I was using vanilla kernel.
>
> Your branch (but better 4.5 kernels (or 4.4)).
> Just when you've done with configuration run cmds 1&2,
> and when you run your use-case - run cmds 2&3 on receiver side (grap ~5-10 packets).
> then stop test and run cmd 1 again.
>
> After all could you provide your console output here, pls.
>
>
To use command 1, you need TI kernel [1] as it won't build with vanilla
kernel.
[1]: git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git ti-linux-4.1.y
Regards
Mugunthan V N
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
2016-03-30 5:33 ` Mugunthan V N
(?)
@ 2016-03-30 8:35 ` Yegor Yefremov
2016-03-30 16:52 ` Mugunthan V N
-1 siblings, 1 reply; 27+ messages in thread
From: Yegor Yefremov @ 2016-03-30 8:35 UTC (permalink / raw)
To: Mugunthan V N; +Cc: Grygorii Strashko, netdev, linux-omap, drivshin, ml
On Wed, Mar 30, 2016 at 7:33 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
> On Tuesday 29 March 2016 06:14 PM, Grygorii Strashko wrote:
>> On 03/29/2016 03:35 PM, Yegor Yefremov wrote:
>>> On Tue, Mar 29, 2016 at 1:05 PM, Grygorii Strashko
>>> <grygorii.strashko@ti.com> wrote:
>>>> On 03/29/2016 08:21 AM, Yegor Yefremov wrote:
>>>>> Hi Mugunthan,
>>>>>
>>>>> On Tue, Mar 29, 2016 at 6:00 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>>>>> Hi Yegor
>>>>>>
>>>>>> On Wednesday 16 March 2016 08:35 PM, Yegor Yefremov wrote:
>>>>>>> I have an am335x based board using CPSW in Dual EMAC mode. Without
>>>>>>> VLAN IDs I can receive and send multicast packets [1]. When I create
>>>>>>> VLAN ID:
>>>>>>>
>>>>>>> ip link add link eth1 name eth1.100 type vlan id 100
>>>>>>> ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth1.100
>>>>>>> route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
>>>>>>>
>>>>>>> I can successfully send multicast packets, but not receive them. On
>>>>>>> the other side of the Ethernet cable I've used Pandaboard. Pandaboard
>>>>>>> could both receive and send multicast packets via VLAN.
>>>>>>
>>>>>> Are you trying multicast tx/rx on eth1 or eth1.100?
>>>>>
>>>>> I'm trying multicast tx/rx on eth1.100.
>>>>>
>>>>> eth1 has no problems.
>>>>>
>>>>
>>>> it'd be nice if will be able to post here output fom commands:
>>>> # switch-config -d [git://git.ti.com/switch-config/switch-config.git v4.1]
>>>> # ifconfig -a
>>>> # tcpdump -e -f -Q in -i eth0
>>>> # tcpdump -e -f -Q in -i eth0.100
>>>
>>> Which kernel/branch do you want me to test?
>>>
>>> git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git and ti-rt-linux-4.1.y?
>>>
>>> So far I was using vanilla kernel.
>>
>> Your branch (but better 4.5 kernels (or 4.4)).
>> Just when you've done with configuration run cmds 1&2,
>> and when you run your use-case - run cmds 2&3 on receiver side (grap ~5-10 packets).
>> then stop test and run cmd 1 again.
>>
>> After all could you provide your console output here, pls.
>>
>>
>
> To use command 1, you need TI kernel [1] as it won't build with vanilla
> kernel.
>
> [1]: git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git ti-linux-4.1.y
# uname -a
Linux buildroot 4.1.18 #1 SMP Wed Mar 30 09:48:37 CEST 2016 armv7l GNU/Linux
# switch-config -d
cpsw hw version 1.12 (0)
0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
unreg_mcast = 0x1, member_list = 0x3
1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
no super, port_mask = 0x3
2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
persistant, port_num = 0x0, Secure
3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
unreg_mcast = 0x1, member_list = 0x7
4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
no super, port_mask = 0x3
5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
unreg_mcast = 0x1, member_list = 0x5
6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
no super, port_mask = 0x5
7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
persistant, port_num = 0x0, Secure
8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
no super, port_mask = 0x5
9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
unreg_mcast = 0x1, member_list = 0x5
10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
persistant, port_num = 0x0
11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
f, no super, port_mask = 0x5
12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
no super, port_mask = 0x5
13 : type: mcast, vid = 2, addr = 01:00:5e:03:1d:47, mcast_state = f,
no super, port_mask = 0x5
# ifconfig -a
can0 Link encap:UNSPEC HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
NOARP MTU:16 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:165
eth0 Link encap:Ethernet HWaddr 74:6A:8F:00:16:12
inet addr:192.168.254.254 Bcast:0.0.0.0 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:175
eth1 Link encap:Ethernet HWaddr 74:6A:8F:00:16:13
inet addr:192.168.1.233 Bcast:0.0.0.0 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:245 errors:0 dropped:0 overruns:0 frame:0
TX packets:123 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:40995 (40.0 KiB) TX bytes:14086 (13.7 KiB)
eth1.100 Link encap:Ethernet HWaddr 74:6A:8F:00:16:13
inet addr:192.168.100.2 Bcast:192.168.100.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:65 errors:0 dropped:0 overruns:0 frame:0
TX packets:51 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:8369 (8.1 KiB) TX bytes:6340 (6.1 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:344 (344.0 B) TX bytes:344 (344.0 B)
# tcpdump -e -f -Q in -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
00:47:40.240731 06:15:4d:85:61:1e (oui Unknown) > 01:00:5e:03:1d:47
(oui Unknown), ethertype 802.1Q (0x8100), length 65: vlan 100, p 0,
ethertype IPv4, 192.168.100.1.59870 > 224.3.29.71.10000: UDP, length
19
00:47:45.259285 06:15:4d:85:61:1e (oui Unknown) > 74:6a:8f:00:16:13
(oui Unknown), ethertype 802.1Q (0x8100), length 60: vlan 100, p 0,
ethertype ARP, Reply 192.168.100.1 is-at 06:15:4d:85:61:1e (oui
Unknown), length 42
# tcpdump -e -f -Q in -i eth1.100
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1.100, link-type EN10MB (Ethernet), capture size 262144 bytes
00:48:52.477500 06:15:4d:85:61:1e (oui Unknown) > 01:00:5e:03:1d:47
(oui Unknown), ethertype IPv4 (0x0800), length 61: 192.168.100.1.54382
> 224.3.29.71.10000: UDP, length 19
00:48:57.486437 06:15:4d:85:61:1e (oui Unknown) > 74:6a:8f:00:16:13
(oui Unknown), ethertype ARP (0x0806), length 56: Reply 192.168.100.1
is-at 06:15:4d:85:61:1e (oui Unknown), length 42
What does "no super" mean and where can I see the "--fwd-state <value
0-3>" value/description?
Yegor
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
2016-03-30 8:35 ` Yegor Yefremov
@ 2016-03-30 16:52 ` Mugunthan V N
0 siblings, 0 replies; 27+ messages in thread
From: Mugunthan V N @ 2016-03-30 16:52 UTC (permalink / raw)
To: Yegor Yefremov; +Cc: Grygorii Strashko, netdev, linux-omap, drivshin, ml
On Wednesday 30 March 2016 02:05 PM, Yegor Yefremov wrote:
> On Wed, Mar 30, 2016 at 7:33 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>> On Tuesday 29 March 2016 06:14 PM, Grygorii Strashko wrote:
>>> On 03/29/2016 03:35 PM, Yegor Yefremov wrote:
>>>> On Tue, Mar 29, 2016 at 1:05 PM, Grygorii Strashko
>>>> <grygorii.strashko@ti.com> wrote:
>>>>> On 03/29/2016 08:21 AM, Yegor Yefremov wrote:
>>>>>> Hi Mugunthan,
>>>>>>
>>>>>> On Tue, Mar 29, 2016 at 6:00 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>>>>>> Hi Yegor
>>>>>>>
>>>>>>> On Wednesday 16 March 2016 08:35 PM, Yegor Yefremov wrote:
>>>>>>>> I have an am335x based board using CPSW in Dual EMAC mode. Without
>>>>>>>> VLAN IDs I can receive and send multicast packets [1]. When I create
>>>>>>>> VLAN ID:
>>>>>>>>
>>>>>>>> ip link add link eth1 name eth1.100 type vlan id 100
>>>>>>>> ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth1.100
>>>>>>>> route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
>>>>>>>>
>>>>>>>> I can successfully send multicast packets, but not receive them. On
>>>>>>>> the other side of the Ethernet cable I've used Pandaboard. Pandaboard
>>>>>>>> could both receive and send multicast packets via VLAN.
>>>>>>>
>>>>>>> Are you trying multicast tx/rx on eth1 or eth1.100?
>>>>>>
>>>>>> I'm trying multicast tx/rx on eth1.100.
>>>>>>
>>>>>> eth1 has no problems.
>>>>>>
>>>>>
>>>>> it'd be nice if will be able to post here output fom commands:
>>>>> # switch-config -d [git://git.ti.com/switch-config/switch-config.git v4.1]
>>>>> # ifconfig -a
>>>>> # tcpdump -e -f -Q in -i eth0
>>>>> # tcpdump -e -f -Q in -i eth0.100
>>>>
>>>> Which kernel/branch do you want me to test?
>>>>
>>>> git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git and ti-rt-linux-4.1.y?
>>>>
>>>> So far I was using vanilla kernel.
>>>
>>> Your branch (but better 4.5 kernels (or 4.4)).
>>> Just when you've done with configuration run cmds 1&2,
>>> and when you run your use-case - run cmds 2&3 on receiver side (grap ~5-10 packets).
>>> then stop test and run cmd 1 again.
>>>
>>> After all could you provide your console output here, pls.
>>>
>>>
>>
>> To use command 1, you need TI kernel [1] as it won't build with vanilla
>> kernel.
>>
>> [1]: git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git ti-linux-4.1.y
>
> # uname -a
> Linux buildroot 4.1.18 #1 SMP Wed Mar 30 09:48:37 CEST 2016 armv7l GNU/Linux
>
> # switch-config -d
> cpsw hw version 1.12 (0)
> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
> unreg_mcast = 0x1, member_list = 0x3
>
> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x3
> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
> persistant, port_num = 0x0, Secure
> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
> unreg_mcast = 0x1, member_list = 0x7
> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x3
> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
> unreg_mcast = 0x1, member_list = 0x5
> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x5
> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0, Secure
> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x5
> 9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
> unreg_mcast = 0x1, member_list = 0x5
> 10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0
> 11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
> f, no super, port_mask = 0x5
> 12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
> no super, port_mask = 0x5
> 13 : type: mcast, vid = 2, addr = 01:00:5e:03:1d:47, mcast_state = f,
> no super, port_mask = 0x5
I don't see multicast entry added to ALE table for 01:00:5e:03:1d:47,
can you run the receive command in background/another terminal and get
the dump when receiving on eth1 and eth1.100 as well and don't enable
tcpdump as it will put the switch in promiscuous mode.
>
> # ifconfig -a
> can0 Link encap:UNSPEC HWaddr
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
> NOARP MTU:16 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:10
> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
> Interrupt:165
>
> eth0 Link encap:Ethernet HWaddr 74:6A:8F:00:16:12
> inet addr:192.168.254.254 Bcast:0.0.0.0 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
> Interrupt:175
>
> eth1 Link encap:Ethernet HWaddr 74:6A:8F:00:16:13
> inet addr:192.168.1.233 Bcast:0.0.0.0 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:245 errors:0 dropped:0 overruns:0 frame:0
> TX packets:123 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:40995 (40.0 KiB) TX bytes:14086 (13.7 KiB)
>
> eth1.100 Link encap:Ethernet HWaddr 74:6A:8F:00:16:13
> inet addr:192.168.100.2 Bcast:192.168.100.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:65 errors:0 dropped:0 overruns:0 frame:0
> TX packets:51 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:8369 (8.1 KiB) TX bytes:6340 (6.1 KiB)
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> UP LOOPBACK RUNNING MTU:65536 Metric:1
> RX packets:4 errors:0 dropped:0 overruns:0 frame:0
> TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:344 (344.0 B) TX bytes:344 (344.0 B)
>
> # tcpdump -e -f -Q in -i eth1
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
> 00:47:40.240731 06:15:4d:85:61:1e (oui Unknown) > 01:00:5e:03:1d:47
> (oui Unknown), ethertype 802.1Q (0x8100), length 65: vlan 100, p 0,
> ethertype IPv4, 192.168.100.1.59870 > 224.3.29.71.10000: UDP, length
> 19
> 00:47:45.259285 06:15:4d:85:61:1e (oui Unknown) > 74:6a:8f:00:16:13
> (oui Unknown), ethertype 802.1Q (0x8100), length 60: vlan 100, p 0,
> ethertype ARP, Reply 192.168.100.1 is-at 06:15:4d:85:61:1e (oui
> Unknown), length 42
>
> # tcpdump -e -f -Q in -i eth1.100
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1.100, link-type EN10MB (Ethernet), capture size 262144 bytes
> 00:48:52.477500 06:15:4d:85:61:1e (oui Unknown) > 01:00:5e:03:1d:47
> (oui Unknown), ethertype IPv4 (0x0800), length 61: 192.168.100.1.54382
>> 224.3.29.71.10000: UDP, length 19
> 00:48:57.486437 06:15:4d:85:61:1e (oui Unknown) > 74:6a:8f:00:16:13
> (oui Unknown), ethertype ARP (0x0806), length 56: Reply 192.168.100.1
> is-at 06:15:4d:85:61:1e (oui Unknown), length 42
You had received these packets as tcpdump will enable promiscuous mode
so that you receive all the packets from the wire.
>
> What does "no super" mean and where can I see the "--fwd-state <value
> 0-3>" value/description?
Multicast supervisory packets are designated by the super bit in the
table entry. Supervisory packets are not dropped due to rate limiting,
OUI, or VLAN processing.
You can get the documentation in TRM under title "Multicast Forward
State (MCAST_FWD_STATE)" for forward state description.
Regards
Mugunthan V N
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
@ 2016-03-30 16:52 ` Mugunthan V N
0 siblings, 0 replies; 27+ messages in thread
From: Mugunthan V N @ 2016-03-30 16:52 UTC (permalink / raw)
To: Yegor Yefremov; +Cc: Grygorii Strashko, netdev, linux-omap, drivshin, ml
On Wednesday 30 March 2016 02:05 PM, Yegor Yefremov wrote:
> On Wed, Mar 30, 2016 at 7:33 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>> On Tuesday 29 March 2016 06:14 PM, Grygorii Strashko wrote:
>>> On 03/29/2016 03:35 PM, Yegor Yefremov wrote:
>>>> On Tue, Mar 29, 2016 at 1:05 PM, Grygorii Strashko
>>>> <grygorii.strashko@ti.com> wrote:
>>>>> On 03/29/2016 08:21 AM, Yegor Yefremov wrote:
>>>>>> Hi Mugunthan,
>>>>>>
>>>>>> On Tue, Mar 29, 2016 at 6:00 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>>>>>> Hi Yegor
>>>>>>>
>>>>>>> On Wednesday 16 March 2016 08:35 PM, Yegor Yefremov wrote:
>>>>>>>> I have an am335x based board using CPSW in Dual EMAC mode. Without
>>>>>>>> VLAN IDs I can receive and send multicast packets [1]. When I create
>>>>>>>> VLAN ID:
>>>>>>>>
>>>>>>>> ip link add link eth1 name eth1.100 type vlan id 100
>>>>>>>> ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth1.100
>>>>>>>> route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
>>>>>>>>
>>>>>>>> I can successfully send multicast packets, but not receive them. On
>>>>>>>> the other side of the Ethernet cable I've used Pandaboard. Pandaboard
>>>>>>>> could both receive and send multicast packets via VLAN.
>>>>>>>
>>>>>>> Are you trying multicast tx/rx on eth1 or eth1.100?
>>>>>>
>>>>>> I'm trying multicast tx/rx on eth1.100.
>>>>>>
>>>>>> eth1 has no problems.
>>>>>>
>>>>>
>>>>> it'd be nice if will be able to post here output fom commands:
>>>>> # switch-config -d [git://git.ti.com/switch-config/switch-config.git v4.1]
>>>>> # ifconfig -a
>>>>> # tcpdump -e -f -Q in -i eth0
>>>>> # tcpdump -e -f -Q in -i eth0.100
>>>>
>>>> Which kernel/branch do you want me to test?
>>>>
>>>> git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git and ti-rt-linux-4.1.y?
>>>>
>>>> So far I was using vanilla kernel.
>>>
>>> Your branch (but better 4.5 kernels (or 4.4)).
>>> Just when you've done with configuration run cmds 1&2,
>>> and when you run your use-case - run cmds 2&3 on receiver side (grap ~5-10 packets).
>>> then stop test and run cmd 1 again.
>>>
>>> After all could you provide your console output here, pls.
>>>
>>>
>>
>> To use command 1, you need TI kernel [1] as it won't build with vanilla
>> kernel.
>>
>> [1]: git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git ti-linux-4.1.y
>
> # uname -a
> Linux buildroot 4.1.18 #1 SMP Wed Mar 30 09:48:37 CEST 2016 armv7l GNU/Linux
>
> # switch-config -d
> cpsw hw version 1.12 (0)
> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
> unreg_mcast = 0x1, member_list = 0x3
>
> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x3
> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
> persistant, port_num = 0x0, Secure
> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
> unreg_mcast = 0x1, member_list = 0x7
> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x3
> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
> unreg_mcast = 0x1, member_list = 0x5
> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x5
> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0, Secure
> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x5
> 9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
> unreg_mcast = 0x1, member_list = 0x5
> 10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0
> 11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
> f, no super, port_mask = 0x5
> 12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
> no super, port_mask = 0x5
> 13 : type: mcast, vid = 2, addr = 01:00:5e:03:1d:47, mcast_state = f,
> no super, port_mask = 0x5
I don't see multicast entry added to ALE table for 01:00:5e:03:1d:47,
can you run the receive command in background/another terminal and get
the dump when receiving on eth1 and eth1.100 as well and don't enable
tcpdump as it will put the switch in promiscuous mode.
>
> # ifconfig -a
> can0 Link encap:UNSPEC HWaddr
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
> NOARP MTU:16 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:10
> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
> Interrupt:165
>
> eth0 Link encap:Ethernet HWaddr 74:6A:8F:00:16:12
> inet addr:192.168.254.254 Bcast:0.0.0.0 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
> Interrupt:175
>
> eth1 Link encap:Ethernet HWaddr 74:6A:8F:00:16:13
> inet addr:192.168.1.233 Bcast:0.0.0.0 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:245 errors:0 dropped:0 overruns:0 frame:0
> TX packets:123 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:40995 (40.0 KiB) TX bytes:14086 (13.7 KiB)
>
> eth1.100 Link encap:Ethernet HWaddr 74:6A:8F:00:16:13
> inet addr:192.168.100.2 Bcast:192.168.100.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:65 errors:0 dropped:0 overruns:0 frame:0
> TX packets:51 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:8369 (8.1 KiB) TX bytes:6340 (6.1 KiB)
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> UP LOOPBACK RUNNING MTU:65536 Metric:1
> RX packets:4 errors:0 dropped:0 overruns:0 frame:0
> TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:344 (344.0 B) TX bytes:344 (344.0 B)
>
> # tcpdump -e -f -Q in -i eth1
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
> 00:47:40.240731 06:15:4d:85:61:1e (oui Unknown) > 01:00:5e:03:1d:47
> (oui Unknown), ethertype 802.1Q (0x8100), length 65: vlan 100, p 0,
> ethertype IPv4, 192.168.100.1.59870 > 224.3.29.71.10000: UDP, length
> 19
> 00:47:45.259285 06:15:4d:85:61:1e (oui Unknown) > 74:6a:8f:00:16:13
> (oui Unknown), ethertype 802.1Q (0x8100), length 60: vlan 100, p 0,
> ethertype ARP, Reply 192.168.100.1 is-at 06:15:4d:85:61:1e (oui
> Unknown), length 42
>
> # tcpdump -e -f -Q in -i eth1.100
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1.100, link-type EN10MB (Ethernet), capture size 262144 bytes
> 00:48:52.477500 06:15:4d:85:61:1e (oui Unknown) > 01:00:5e:03:1d:47
> (oui Unknown), ethertype IPv4 (0x0800), length 61: 192.168.100.1.54382
>> 224.3.29.71.10000: UDP, length 19
> 00:48:57.486437 06:15:4d:85:61:1e (oui Unknown) > 74:6a:8f:00:16:13
> (oui Unknown), ethertype ARP (0x0806), length 56: Reply 192.168.100.1
> is-at 06:15:4d:85:61:1e (oui Unknown), length 42
You had received these packets as tcpdump will enable promiscuous mode
so that you receive all the packets from the wire.
>
> What does "no super" mean and where can I see the "--fwd-state <value
> 0-3>" value/description?
Multicast supervisory packets are designated by the super bit in the
table entry. Supervisory packets are not dropped due to rate limiting,
OUI, or VLAN processing.
You can get the documentation in TRM under title "Multicast Forward
State (MCAST_FWD_STATE)" for forward state description.
Regards
Mugunthan V N
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
2016-03-30 16:52 ` Mugunthan V N
@ 2016-03-30 19:47 ` Peter Korsgaard
-1 siblings, 0 replies; 27+ messages in thread
From: Peter Korsgaard @ 2016-03-30 19:47 UTC (permalink / raw)
To: Mugunthan V N
Cc: Yegor Yefremov, Grygorii Strashko, netdev, linux-omap, drivshin, ml
>>>>> "Mugunthan" == Mugunthan V N <mugunthanvnm@ti.com> writes:
Hi,
> You had received these packets as tcpdump will enable promiscuous mode
> so that you receive all the packets from the wire.
FYI, you can use the -p option to tcpdump to not put the interface into
promiscuous mode.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
@ 2016-03-30 19:47 ` Peter Korsgaard
0 siblings, 0 replies; 27+ messages in thread
From: Peter Korsgaard @ 2016-03-30 19:47 UTC (permalink / raw)
To: Mugunthan V N
Cc: Yegor Yefremov, Grygorii Strashko, netdev, linux-omap, drivshin, ml
>>>>> "Mugunthan" == Mugunthan V N <mugunthanvnm@ti.com> writes:
Hi,
> You had received these packets as tcpdump will enable promiscuous mode
> so that you receive all the packets from the wire.
FYI, you can use the -p option to tcpdump to not put the interface into
promiscuous mode.
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
2016-03-30 19:47 ` Peter Korsgaard
@ 2016-03-31 6:37 ` Mugunthan V N
-1 siblings, 0 replies; 27+ messages in thread
From: Mugunthan V N @ 2016-03-31 6:37 UTC (permalink / raw)
To: Peter Korsgaard
Cc: Yegor Yefremov, Grygorii Strashko, netdev, linux-omap, drivshin, ml
On Thursday 31 March 2016 01:17 AM, Peter Korsgaard wrote:
>>>>>> "Mugunthan" == Mugunthan V N <mugunthanvnm@ti.com> writes:
>
> Hi,
>
> > You had received these packets as tcpdump will enable promiscuous mode
> > so that you receive all the packets from the wire.
>
> FYI, you can use the -p option to tcpdump to not put the interface into
> promiscuous mode.
>
Thanks for the information Peter Korsgaard.
Yegor, can you provide tcpdump using -p as well in Grygorii commands.
Regards
Mugunthan V N
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
@ 2016-03-31 6:37 ` Mugunthan V N
0 siblings, 0 replies; 27+ messages in thread
From: Mugunthan V N @ 2016-03-31 6:37 UTC (permalink / raw)
To: Peter Korsgaard
Cc: Yegor Yefremov, Grygorii Strashko, netdev, linux-omap, drivshin, ml
On Thursday 31 March 2016 01:17 AM, Peter Korsgaard wrote:
>>>>>> "Mugunthan" == Mugunthan V N <mugunthanvnm@ti.com> writes:
>
> Hi,
>
> > You had received these packets as tcpdump will enable promiscuous mode
> > so that you receive all the packets from the wire.
>
> FYI, you can use the -p option to tcpdump to not put the interface into
> promiscuous mode.
>
Thanks for the information Peter Korsgaard.
Yegor, can you provide tcpdump using -p as well in Grygorii commands.
Regards
Mugunthan V N
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
2016-03-31 6:37 ` Mugunthan V N
(?)
@ 2016-03-31 7:52 ` Yegor Yefremov
2016-03-31 10:02 ` Mugunthan V N
2016-04-01 12:09 ` Grygorii Strashko
-1 siblings, 2 replies; 27+ messages in thread
From: Yegor Yefremov @ 2016-03-31 7:52 UTC (permalink / raw)
To: Mugunthan V N
Cc: Peter Korsgaard, Grygorii Strashko, netdev, linux-omap, drivshin, ml
[-- Attachment #1: Type: text/plain, Size: 6225 bytes --]
On Thu, Mar 31, 2016 at 8:37 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
> On Thursday 31 March 2016 01:17 AM, Peter Korsgaard wrote:
>>>>>>> "Mugunthan" == Mugunthan V N <mugunthanvnm@ti.com> writes:
>>
>> Hi,
>>
>> > You had received these packets as tcpdump will enable promiscuous mode
>> > so that you receive all the packets from the wire.
>>
>> FYI, you can use the -p option to tcpdump to not put the interface into
>> promiscuous mode.
>>
>
> Thanks for the information Peter Korsgaard.
>
> Yegor, can you provide tcpdump using -p as well in Grygorii commands.
Before VLAN configuration:
# switch-config -d
cpsw hw version 1.12 (0)
0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
unreg_mcast = 0x0, member_list = 0x3
1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
no super, port_mask = 0x3
2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
persistant, port_num = 0x0, Secure
3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
unreg_mcast = 0x0, member_list = 0x7
4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
no super, port_mask = 0x3
5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
unreg_mcast = 0x0, member_list = 0x5
6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
no super, port_mask = 0x5
7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
persistant, port_num = 0x0, Secure
8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
no super, port_mask = 0x5
After VLAN configuration:
# switch-config -d
cpsw hw version 1.12 (0)
0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
unreg_mcast = 0x0, member_list = 0x3
1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
no super, port_mask = 0x3
2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
persistant, port_num = 0x0, Secure
3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
unreg_mcast = 0x0, member_list = 0x7
4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
no super, port_mask = 0x3
5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
unreg_mcast = 0x0, member_list = 0x5
6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
no super, port_mask = 0x5
7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
persistant, port_num = 0x0, Secure
8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
no super, port_mask = 0x5
9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
unreg_mcast = 0x0, member_list = 0x5
10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
persistant, port_num = 0x0
11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
f, no super, port_mask = 0x5
12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
no super, port_mask = 0x5
During mulitcast receive:
# switch-config -d
cpsw hw version 1.12 (0)
0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
unreg_mcast = 0x0, member_list = 0x3
1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
no super, port_mask = 0x3
2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
persistant, port_num = 0x0, Secure
3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
unreg_mcast = 0x0, member_list = 0x7
4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
no super, port_mask = 0x3
5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
unreg_mcast = 0x0, member_list = 0x5
6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
no super, port_mask = 0x5
7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
persistant, port_num = 0x0, Secure
8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
no super, port_mask = 0x5
9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
unreg_mcast = 0x0, member_list = 0x5
10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
persistant, port_num = 0x0
11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
f, no super, port_mask = 0x5
12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
no super, port_mask = 0x5
13 : type: mcast, vid = 2, addr = 01:00:5e:03:1d:47, mcast_state = f,
no super, port_mask = 0x5
14 : type: ucast, vid = 100, addr = 66:22:04:bc:90:26, ucast_type =
untouched , port_num = 0x2
After multicast receive use case:
# switch-config -d
cpsw hw version 1.12 (0)
0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
unreg_mcast = 0x0, member_list = 0x3
1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
no super, port_mask = 0x3
2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
persistant, port_num = 0x0, Secure
3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
unreg_mcast = 0x0, member_list = 0x7
4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
no super, port_mask = 0x3
5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
unreg_mcast = 0x0, member_list = 0x5
6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
no super, port_mask = 0x5
7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
persistant, port_num = 0x0, Secure
8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
no super, port_mask = 0x5
9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
unreg_mcast = 0x0, member_list = 0x5
10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
persistant, port_num = 0x0
11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
f, no super, port_mask = 0x5
12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
no super, port_mask = 0x5
15 : type: ucast, vid = 100, addr = 66:22:04:bc:90:26, ucast_type =
untouched , port_num = 0x2
Both tcpdumps with -p option showed no packets. If I execute ping, I
can see related ICMP packets. addr = 66:22:04:bc:90:26 is PandaBoards
MAC.
Btw I've attached my test scripts (mcastr.py - multicast receiver and
mcastt.py - multicast transmitter). Could you reproduce my setup?
Thanks.
Yegor
[-- Attachment #2: mcastr.py --]
[-- Type: text/plain, Size: 821 bytes --]
import socket
import struct
import sys
multicast_group = '224.3.29.71'
server_address = ('', 10000)
# Create the socket
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
# Bind to the server address
sock.bind(server_address)
# Tell the operating system to add the socket to the multicast group
# on all interfaces.
group = socket.inet_aton(multicast_group)
mreq = struct.pack('4sL', group, socket.INADDR_ANY)
sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)
# Receive/respond loop
while True:
print >>sys.stderr, '\nwaiting to receive message'
data, address = sock.recvfrom(1024)
print >>sys.stderr, 'received %s bytes from %s' % (len(data), address)
print >>sys.stderr, data
print >>sys.stderr, 'sending acknowledgement to', address
sock.sendto('ack', address)
[-- Attachment #3: mcastt.py --]
[-- Type: text/plain, Size: 1075 bytes --]
import socket
import struct
import sys
message = 'very important data'
multicast_group = ('224.3.29.71', 10000)
# Create the datagram socket
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
# Set a timeout so the socket does not block indefinitely when trying
# to receive data.
sock.settimeout(0.2)
# Set the time-to-live for messages to 1 so they do not go past the
# local network segment.
ttl = struct.pack('b', 1)
sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, ttl)
try:
# Send data to the multicast group
print >>sys.stderr, 'sending "%s"' % message
sent = sock.sendto(message, multicast_group)
# Look for responses from all recipients
while True:
print >>sys.stderr, 'waiting to receive'
try:
data, server = sock.recvfrom(16)
except socket.timeout:
print >>sys.stderr, 'timed out, no more responses'
break
else:
print >>sys.stderr, 'received "%s" from %s' % (data, server)
finally:
print >>sys.stderr, 'closing socket'
sock.close()
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
2016-03-31 7:52 ` Yegor Yefremov
@ 2016-03-31 10:02 ` Mugunthan V N
2016-04-01 12:09 ` Grygorii Strashko
1 sibling, 0 replies; 27+ messages in thread
From: Mugunthan V N @ 2016-03-31 10:02 UTC (permalink / raw)
To: Yegor Yefremov
Cc: Peter Korsgaard, Grygorii Strashko, netdev, linux-omap, drivshin, ml
On Thursday 31 March 2016 01:22 PM, Yegor Yefremov wrote:
> On Thu, Mar 31, 2016 at 8:37 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>> On Thursday 31 March 2016 01:17 AM, Peter Korsgaard wrote:
>>>>>>>> "Mugunthan" == Mugunthan V N <mugunthanvnm@ti.com> writes:
>>>
>>> Hi,
>>>
>>> > You had received these packets as tcpdump will enable promiscuous mode
>>> > so that you receive all the packets from the wire.
>>>
>>> FYI, you can use the -p option to tcpdump to not put the interface into
>>> promiscuous mode.
>>>
>>
>> Thanks for the information Peter Korsgaard.
>>
>> Yegor, can you provide tcpdump using -p as well in Grygorii commands.
>
> Before VLAN configuration:
>
> # switch-config -d
> cpsw hw version 1.12 (0)
> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
> unreg_mcast = 0x0, member_list = 0x3
> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x3
> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
> persistant, port_num = 0x0, Secure
> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
> unreg_mcast = 0x0, member_list = 0x7
> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x3
> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x5
> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0, Secure
> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x5
>
> After VLAN configuration:
>
> # switch-config -d
> cpsw hw version 1.12 (0)
> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
> unreg_mcast = 0x0, member_list = 0x3
> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x3
> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
> persistant, port_num = 0x0, Secure
> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
> unreg_mcast = 0x0, member_list = 0x7
> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x3
> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x5
> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0, Secure
> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x5
> 9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0
> 11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
> f, no super, port_mask = 0x5
> 12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
> no super, port_mask = 0x5
>
> During mulitcast receive:
>
> # switch-config -d
> cpsw hw version 1.12 (0)
> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
> unreg_mcast = 0x0, member_list = 0x3
> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x3
> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
> persistant, port_num = 0x0, Secure
> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
> unreg_mcast = 0x0, member_list = 0x7
> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x3
> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x5
> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0, Secure
> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x5
> 9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0
> 11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
> f, no super, port_mask = 0x5
> 12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
> no super, port_mask = 0x5
> 13 : type: mcast, vid = 2, addr = 01:00:5e:03:1d:47, mcast_state = f,
> no super, port_mask = 0x5
> 14 : type: ucast, vid = 100, addr = 66:22:04:bc:90:26, ucast_type =
> untouched , port_num = 0x2
I could see multicast address 01:00:5e:03:1d:47 is added to ALE table at
index 13, but it is added for VLAN id 2 ie eth1, did you ran the test
for eth1 or eth1.100?
Regards
Mugunthan V N
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
@ 2016-03-31 10:02 ` Mugunthan V N
0 siblings, 0 replies; 27+ messages in thread
From: Mugunthan V N @ 2016-03-31 10:02 UTC (permalink / raw)
To: Yegor Yefremov
Cc: Peter Korsgaard, Grygorii Strashko, netdev, linux-omap, drivshin, ml
On Thursday 31 March 2016 01:22 PM, Yegor Yefremov wrote:
> On Thu, Mar 31, 2016 at 8:37 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>> On Thursday 31 March 2016 01:17 AM, Peter Korsgaard wrote:
>>>>>>>> "Mugunthan" == Mugunthan V N <mugunthanvnm@ti.com> writes:
>>>
>>> Hi,
>>>
>>> > You had received these packets as tcpdump will enable promiscuous mode
>>> > so that you receive all the packets from the wire.
>>>
>>> FYI, you can use the -p option to tcpdump to not put the interface into
>>> promiscuous mode.
>>>
>>
>> Thanks for the information Peter Korsgaard.
>>
>> Yegor, can you provide tcpdump using -p as well in Grygorii commands.
>
> Before VLAN configuration:
>
> # switch-config -d
> cpsw hw version 1.12 (0)
> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
> unreg_mcast = 0x0, member_list = 0x3
> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x3
> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
> persistant, port_num = 0x0, Secure
> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
> unreg_mcast = 0x0, member_list = 0x7
> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x3
> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x5
> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0, Secure
> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x5
>
> After VLAN configuration:
>
> # switch-config -d
> cpsw hw version 1.12 (0)
> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
> unreg_mcast = 0x0, member_list = 0x3
> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x3
> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
> persistant, port_num = 0x0, Secure
> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
> unreg_mcast = 0x0, member_list = 0x7
> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x3
> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x5
> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0, Secure
> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x5
> 9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0
> 11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
> f, no super, port_mask = 0x5
> 12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
> no super, port_mask = 0x5
>
> During mulitcast receive:
>
> # switch-config -d
> cpsw hw version 1.12 (0)
> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
> unreg_mcast = 0x0, member_list = 0x3
> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x3
> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
> persistant, port_num = 0x0, Secure
> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
> unreg_mcast = 0x0, member_list = 0x7
> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x3
> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x5
> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0, Secure
> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x5
> 9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0
> 11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
> f, no super, port_mask = 0x5
> 12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
> no super, port_mask = 0x5
> 13 : type: mcast, vid = 2, addr = 01:00:5e:03:1d:47, mcast_state = f,
> no super, port_mask = 0x5
> 14 : type: ucast, vid = 100, addr = 66:22:04:bc:90:26, ucast_type =
> untouched , port_num = 0x2
I could see multicast address 01:00:5e:03:1d:47 is added to ALE table at
index 13, but it is added for VLAN id 2 ie eth1, did you ran the test
for eth1 or eth1.100?
Regards
Mugunthan V N
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
2016-03-31 10:02 ` Mugunthan V N
(?)
@ 2016-03-31 10:16 ` Yegor Yefremov
-1 siblings, 0 replies; 27+ messages in thread
From: Yegor Yefremov @ 2016-03-31 10:16 UTC (permalink / raw)
To: Mugunthan V N
Cc: Peter Korsgaard, Grygorii Strashko, netdev, linux-omap, drivshin, ml
On Thu, Mar 31, 2016 at 12:02 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
> On Thursday 31 March 2016 01:22 PM, Yegor Yefremov wrote:
>> On Thu, Mar 31, 2016 at 8:37 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>> On Thursday 31 March 2016 01:17 AM, Peter Korsgaard wrote:
>>>>>>>>> "Mugunthan" == Mugunthan V N <mugunthanvnm@ti.com> writes:
>>>>
>>>> Hi,
>>>>
>>>> > You had received these packets as tcpdump will enable promiscuous mode
>>>> > so that you receive all the packets from the wire.
>>>>
>>>> FYI, you can use the -p option to tcpdump to not put the interface into
>>>> promiscuous mode.
>>>>
>>>
>>> Thanks for the information Peter Korsgaard.
>>>
>>> Yegor, can you provide tcpdump using -p as well in Grygorii commands.
>>
>> Before VLAN configuration:
>>
>> # switch-config -d
>> cpsw hw version 1.12 (0)
>> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
>> unreg_mcast = 0x0, member_list = 0x3
>> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x3
>> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
>> unreg_mcast = 0x0, member_list = 0x7
>> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x3
>> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
>> unreg_mcast = 0x0, member_list = 0x5
>> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x5
>> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x5
>>
>> After VLAN configuration:
>>
>> # switch-config -d
>> cpsw hw version 1.12 (0)
>> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
>> unreg_mcast = 0x0, member_list = 0x3
>> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x3
>> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
>> unreg_mcast = 0x0, member_list = 0x7
>> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x3
>> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
>> unreg_mcast = 0x0, member_list = 0x5
>> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x5
>> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x5
>> 9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
>> unreg_mcast = 0x0, member_list = 0x5
>> 10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
>> persistant, port_num = 0x0
>> 11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
>> f, no super, port_mask = 0x5
>> 12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
>> no super, port_mask = 0x5
>>
>> During mulitcast receive:
>>
>> # switch-config -d
>> cpsw hw version 1.12 (0)
>> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
>> unreg_mcast = 0x0, member_list = 0x3
>> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x3
>> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
>> unreg_mcast = 0x0, member_list = 0x7
>> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x3
>> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
>> unreg_mcast = 0x0, member_list = 0x5
>> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x5
>> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x5
>> 9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
>> unreg_mcast = 0x0, member_list = 0x5
>> 10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
>> persistant, port_num = 0x0
>> 11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
>> f, no super, port_mask = 0x5
>> 12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
>> no super, port_mask = 0x5
>> 13 : type: mcast, vid = 2, addr = 01:00:5e:03:1d:47, mcast_state = f,
>> no super, port_mask = 0x5
>> 14 : type: ucast, vid = 100, addr = 66:22:04:bc:90:26, ucast_type =
>> untouched , port_num = 0x2
>
> I could see multicast address 01:00:5e:03:1d:47 is added to ALE table at
> index 13, but it is added for VLAN id 2 ie eth1, did you ran the test
> for eth1 or eth1.100?
My routing table looks as follows:
# route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
# ip route show
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.233
192.168.100.0/24 dev eth1.100 proto kernel scope link src 192.168.100.2
192.168.254.0/24 dev eth0 proto kernel scope link src 192.168.254.254
224.0.0.0/3 dev eth1.100 scope link
so multicast packets should go via eth1.100
Yegor
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
2016-03-31 7:52 ` Yegor Yefremov
@ 2016-04-01 12:09 ` Grygorii Strashko
2016-04-01 12:09 ` Grygorii Strashko
1 sibling, 0 replies; 27+ messages in thread
From: Grygorii Strashko @ 2016-04-01 12:09 UTC (permalink / raw)
To: Yegor Yefremov, Mugunthan V N
Cc: Peter Korsgaard, netdev, linux-omap, drivshin, ml
On 03/31/2016 10:52 AM, Yegor Yefremov wrote:
> On Thu, Mar 31, 2016 at 8:37 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>> On Thursday 31 March 2016 01:17 AM, Peter Korsgaard wrote:
>>>>>>>> "Mugunthan" == Mugunthan V N <mugunthanvnm@ti.com> writes:
>>>
>>> Hi,
>>>
>>> > You had received these packets as tcpdump will enable promiscuous mode
>>> > so that you receive all the packets from the wire.
>>>
>>> FYI, you can use the -p option to tcpdump to not put the interface into
>>> promiscuous mode.
>>>
>>
>> Thanks for the information Peter Korsgaard.
>>
>> Yegor, can you provide tcpdump using -p as well in Grygorii commands.
>
> Before VLAN configuration:
>
> # switch-config -d
> cpsw hw version 1.12 (0)
> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
> unreg_mcast = 0x0, member_list = 0x3
> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x3
> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
> persistant, port_num = 0x0, Secure
> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
> unreg_mcast = 0x0, member_list = 0x7
> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x3
> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x5
> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0, Secure
> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x5
>
> After VLAN configuration:
>
> # switch-config -d
> cpsw hw version 1.12 (0)
> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
> unreg_mcast = 0x0, member_list = 0x3
> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x3
> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
> persistant, port_num = 0x0, Secure
> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
> unreg_mcast = 0x0, member_list = 0x7
> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x3
> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x5
> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0, Secure
> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x5
> 9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0
> 11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
> f, no super, port_mask = 0x5
> 12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
> no super, port_mask = 0x5
>
> During mulitcast receive:
>
> # switch-config -d
> cpsw hw version 1.12 (0)
> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3, unreg_mcast = 0x0, member_list = 0x3
> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f, no super, port_mask = 0x3
> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type = persistant, port_num = 0x0, Secure
> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0, unreg_mcast = 0x0, member_list = 0x7
unreg_mcast = 0x0 means unregistered multicast packets will be dropped
> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f, no super, port_mask = 0x3
> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5, unreg_mcast = 0x0, member_list = 0x5
unreg_mcast = 0x0
> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f, no super, port_mask = 0x5
> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type = persistant, port_num = 0x0, Secure
> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f, no super, port_mask = 0x5
> 9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5, unreg_mcast = 0x0, member_list = 0x5
unreg_mcast = 0x0
> 10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type = persistant, port_num = 0x0
> 11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state = f, no super, port_mask = 0x5
> 12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f, no super, port_mask = 0x5
> 13 : type: mcast, vid = 2, addr = 01:00:5e:03:1d:47, mcast_state = f, no super, port_mask = 0x5
This is requested mcast address, but it's registered for vid=2 (propagated through .ndo_set_rx_mode())
> 14 : type: ucast, vid = 100, addr = 66:22:04:bc:90:26, ucast_type = untouched , port_num = 0x2
[...]
>
> Both tcpdumps with -p option showed no packets. If I execute ping, I
> can see related ICMP packets. addr = 66:22:04:bc:90:26 is PandaBoards
> MAC.
>
> Btw I've attached my test scripts (mcastr.py - multicast receiver and
> mcastt.py - multicast transmitter). Could you reproduce my setup?
>
I was able to reproduce an issue with your script. As I understand, when cpsw receive the
mcast packet with dst_address=01:00:5e:03:1d:47 and vid=100 it hits
the case:
"if (Multicast packet) # destination address not found
then portmask is the logical “AND” of unreg_mcast_flood_mask and vlan_member_list
then goto Egress process"
and as result packet is dropped (you can check eth1 statistic # ethtool -S eth1).
Unfortunately, I was no able to configure mcast address properly in dual mac mode :(,
but probably Mugunthan can comment here - mcast addressess are offloaded to cpsw from
Net core through .ndo_set_rx_mode() and struct netdev_hw_addr doesn't contain any
information about vlan and cpsw uses default port vlan, which is vid=2 for eth1 in
dual mac mode.
As W/A the allmulti flag can be used:
# ifconfig eth1.100 allmulti
--
regards,
-grygorii
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
@ 2016-04-01 12:09 ` Grygorii Strashko
0 siblings, 0 replies; 27+ messages in thread
From: Grygorii Strashko @ 2016-04-01 12:09 UTC (permalink / raw)
To: Yegor Yefremov, Mugunthan V N
Cc: Peter Korsgaard, netdev, linux-omap, drivshin, ml
On 03/31/2016 10:52 AM, Yegor Yefremov wrote:
> On Thu, Mar 31, 2016 at 8:37 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>> On Thursday 31 March 2016 01:17 AM, Peter Korsgaard wrote:
>>>>>>>> "Mugunthan" == Mugunthan V N <mugunthanvnm@ti.com> writes:
>>>
>>> Hi,
>>>
>>> > You had received these packets as tcpdump will enable promiscuous mode
>>> > so that you receive all the packets from the wire.
>>>
>>> FYI, you can use the -p option to tcpdump to not put the interface into
>>> promiscuous mode.
>>>
>>
>> Thanks for the information Peter Korsgaard.
>>
>> Yegor, can you provide tcpdump using -p as well in Grygorii commands.
>
> Before VLAN configuration:
>
> # switch-config -d
> cpsw hw version 1.12 (0)
> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
> unreg_mcast = 0x0, member_list = 0x3
> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x3
> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
> persistant, port_num = 0x0, Secure
> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
> unreg_mcast = 0x0, member_list = 0x7
> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x3
> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x5
> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0, Secure
> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x5
>
> After VLAN configuration:
>
> # switch-config -d
> cpsw hw version 1.12 (0)
> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
> unreg_mcast = 0x0, member_list = 0x3
> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x3
> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
> persistant, port_num = 0x0, Secure
> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
> unreg_mcast = 0x0, member_list = 0x7
> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x3
> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
> no super, port_mask = 0x5
> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0, Secure
> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
> no super, port_mask = 0x5
> 9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
> unreg_mcast = 0x0, member_list = 0x5
> 10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
> persistant, port_num = 0x0
> 11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
> f, no super, port_mask = 0x5
> 12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
> no super, port_mask = 0x5
>
> During mulitcast receive:
>
> # switch-config -d
> cpsw hw version 1.12 (0)
> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3, unreg_mcast = 0x0, member_list = 0x3
> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f, no super, port_mask = 0x3
> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type = persistant, port_num = 0x0, Secure
> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0, unreg_mcast = 0x0, member_list = 0x7
unreg_mcast = 0x0 means unregistered multicast packets will be dropped
> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f, no super, port_mask = 0x3
> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5, unreg_mcast = 0x0, member_list = 0x5
unreg_mcast = 0x0
> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f, no super, port_mask = 0x5
> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type = persistant, port_num = 0x0, Secure
> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f, no super, port_mask = 0x5
> 9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5, unreg_mcast = 0x0, member_list = 0x5
unreg_mcast = 0x0
> 10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type = persistant, port_num = 0x0
> 11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state = f, no super, port_mask = 0x5
> 12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f, no super, port_mask = 0x5
> 13 : type: mcast, vid = 2, addr = 01:00:5e:03:1d:47, mcast_state = f, no super, port_mask = 0x5
This is requested mcast address, but it's registered for vid=2 (propagated through .ndo_set_rx_mode())
> 14 : type: ucast, vid = 100, addr = 66:22:04:bc:90:26, ucast_type = untouched , port_num = 0x2
[...]
>
> Both tcpdumps with -p option showed no packets. If I execute ping, I
> can see related ICMP packets. addr = 66:22:04:bc:90:26 is PandaBoards
> MAC.
>
> Btw I've attached my test scripts (mcastr.py - multicast receiver and
> mcastt.py - multicast transmitter). Could you reproduce my setup?
>
I was able to reproduce an issue with your script. As I understand, when cpsw receive the
mcast packet with dst_address=01:00:5e:03:1d:47 and vid=100 it hits
the case:
"if (Multicast packet) # destination address not found
then portmask is the logical “AND” of unreg_mcast_flood_mask and vlan_member_list
then goto Egress process"
and as result packet is dropped (you can check eth1 statistic # ethtool -S eth1).
Unfortunately, I was no able to configure mcast address properly in dual mac mode :(,
but probably Mugunthan can comment here - mcast addressess are offloaded to cpsw from
Net core through .ndo_set_rx_mode() and struct netdev_hw_addr doesn't contain any
information about vlan and cpsw uses default port vlan, which is vid=2 for eth1 in
dual mac mode.
As W/A the allmulti flag can be used:
# ifconfig eth1.100 allmulti
--
regards,
-grygorii
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
2016-04-01 12:09 ` Grygorii Strashko
@ 2016-04-05 6:11 ` Mugunthan V N
-1 siblings, 0 replies; 27+ messages in thread
From: Mugunthan V N @ 2016-04-05 6:11 UTC (permalink / raw)
To: Grygorii Strashko, Yegor Yefremov
Cc: Peter Korsgaard, netdev, linux-omap, drivshin, ml, David Miller
On Friday 01 April 2016 05:39 PM, Grygorii Strashko wrote:
> On 03/31/2016 10:52 AM, Yegor Yefremov wrote:
>> On Thu, Mar 31, 2016 at 8:37 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>> On Thursday 31 March 2016 01:17 AM, Peter Korsgaard wrote:
>>>>>>>>> "Mugunthan" == Mugunthan V N <mugunthanvnm@ti.com> writes:
>>>>
>>>> Hi,
>>>>
>>>> > You had received these packets as tcpdump will enable promiscuous mode
>>>> > so that you receive all the packets from the wire.
>>>>
>>>> FYI, you can use the -p option to tcpdump to not put the interface into
>>>> promiscuous mode.
>>>>
>>>
>>> Thanks for the information Peter Korsgaard.
>>>
>>> Yegor, can you provide tcpdump using -p as well in Grygorii commands.
>>
>> Before VLAN configuration:
>>
>> # switch-config -d
>> cpsw hw version 1.12 (0)
>> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
>> unreg_mcast = 0x0, member_list = 0x3
>> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x3
>> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
>> unreg_mcast = 0x0, member_list = 0x7
>> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x3
>> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
>> unreg_mcast = 0x0, member_list = 0x5
>> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x5
>> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x5
>>
>> After VLAN configuration:
>>
>> # switch-config -d
>> cpsw hw version 1.12 (0)
>> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
>> unreg_mcast = 0x0, member_list = 0x3
>> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x3
>> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
>> unreg_mcast = 0x0, member_list = 0x7
>> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x3
>> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
>> unreg_mcast = 0x0, member_list = 0x5
>> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x5
>> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x5
>> 9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
>> unreg_mcast = 0x0, member_list = 0x5
>> 10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
>> persistant, port_num = 0x0
>> 11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
>> f, no super, port_mask = 0x5
>> 12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
>> no super, port_mask = 0x5
>>
>> During mulitcast receive:
>>
>> # switch-config -d
>> cpsw hw version 1.12 (0)
>> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3, unreg_mcast = 0x0, member_list = 0x3
>> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f, no super, port_mask = 0x3
>> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type = persistant, port_num = 0x0, Secure
>> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0, unreg_mcast = 0x0, member_list = 0x7
>
> unreg_mcast = 0x0 means unregistered multicast packets will be dropped
>
>> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f, no super, port_mask = 0x3
>> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5, unreg_mcast = 0x0, member_list = 0x5
>
> unreg_mcast = 0x0
>
>> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f, no super, port_mask = 0x5
>> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type = persistant, port_num = 0x0, Secure
>> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f, no super, port_mask = 0x5
>> 9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5, unreg_mcast = 0x0, member_list = 0x5
>
> unreg_mcast = 0x0
>
>> 10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type = persistant, port_num = 0x0
>> 11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state = f, no super, port_mask = 0x5
>> 12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f, no super, port_mask = 0x5
>> 13 : type: mcast, vid = 2, addr = 01:00:5e:03:1d:47, mcast_state = f, no super, port_mask = 0x5
>
> This is requested mcast address, but it's registered for vid=2 (propagated through .ndo_set_rx_mode())
>
>> 14 : type: ucast, vid = 100, addr = 66:22:04:bc:90:26, ucast_type = untouched , port_num = 0x2
>
> [...]
>>
>> Both tcpdumps with -p option showed no packets. If I execute ping, I
>> can see related ICMP packets. addr = 66:22:04:bc:90:26 is PandaBoards
>> MAC.
>>
>> Btw I've attached my test scripts (mcastr.py - multicast receiver and
>> mcastt.py - multicast transmitter). Could you reproduce my setup?
>>
>
> I was able to reproduce an issue with your script. As I understand, when cpsw receive the
> mcast packet with dst_address=01:00:5e:03:1d:47 and vid=100 it hits
> the case:
> "if (Multicast packet) # destination address not found
> then portmask is the logical “AND” of unreg_mcast_flood_mask and vlan_member_list
> then goto Egress process"
>
> and as result packet is dropped (you can check eth1 statistic # ethtool -S eth1).
>
> Unfortunately, I was no able to configure mcast address properly in dual mac mode :(,
> but probably Mugunthan can comment here - mcast addressess are offloaded to cpsw from
I was able to add mcast address for eth0/eth1, but not finding a way to
add mcast entries to eth1.100 interface. I gone through Linux network
stack and didn't find a way where stack asks the driver to add mcast
address for vlan interfaces. *_Network Experts_* can help us here.
> Net core through .ndo_set_rx_mode() and struct netdev_hw_addr doesn't contain any
> information about vlan and cpsw uses default port vlan, which is vid=2 for eth1 in
> dual mac mode.
>
>
>
> As W/A the allmulti flag can be used:
>
> # ifconfig eth1.100 allmulti
For now this is the only possible option that can be used.
Regards
Mugunthan V N
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
@ 2016-04-05 6:11 ` Mugunthan V N
0 siblings, 0 replies; 27+ messages in thread
From: Mugunthan V N @ 2016-04-05 6:11 UTC (permalink / raw)
To: Grygorii Strashko, Yegor Yefremov
Cc: Peter Korsgaard, netdev, linux-omap, drivshin, ml, David Miller
On Friday 01 April 2016 05:39 PM, Grygorii Strashko wrote:
> On 03/31/2016 10:52 AM, Yegor Yefremov wrote:
>> On Thu, Mar 31, 2016 at 8:37 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>> On Thursday 31 March 2016 01:17 AM, Peter Korsgaard wrote:
>>>>>>>>> "Mugunthan" == Mugunthan V N <mugunthanvnm@ti.com> writes:
>>>>
>>>> Hi,
>>>>
>>>> > You had received these packets as tcpdump will enable promiscuous mode
>>>> > so that you receive all the packets from the wire.
>>>>
>>>> FYI, you can use the -p option to tcpdump to not put the interface into
>>>> promiscuous mode.
>>>>
>>>
>>> Thanks for the information Peter Korsgaard.
>>>
>>> Yegor, can you provide tcpdump using -p as well in Grygorii commands.
>>
>> Before VLAN configuration:
>>
>> # switch-config -d
>> cpsw hw version 1.12 (0)
>> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
>> unreg_mcast = 0x0, member_list = 0x3
>> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x3
>> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
>> unreg_mcast = 0x0, member_list = 0x7
>> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x3
>> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
>> unreg_mcast = 0x0, member_list = 0x5
>> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x5
>> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x5
>>
>> After VLAN configuration:
>>
>> # switch-config -d
>> cpsw hw version 1.12 (0)
>> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
>> unreg_mcast = 0x0, member_list = 0x3
>> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x3
>> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
>> unreg_mcast = 0x0, member_list = 0x7
>> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x3
>> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
>> unreg_mcast = 0x0, member_list = 0x5
>> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>> no super, port_mask = 0x5
>> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
>> persistant, port_num = 0x0, Secure
>> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
>> no super, port_mask = 0x5
>> 9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
>> unreg_mcast = 0x0, member_list = 0x5
>> 10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
>> persistant, port_num = 0x0
>> 11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
>> f, no super, port_mask = 0x5
>> 12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
>> no super, port_mask = 0x5
>>
>> During mulitcast receive:
>>
>> # switch-config -d
>> cpsw hw version 1.12 (0)
>> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3, unreg_mcast = 0x0, member_list = 0x3
>> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f, no super, port_mask = 0x3
>> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type = persistant, port_num = 0x0, Secure
>> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0, unreg_mcast = 0x0, member_list = 0x7
>
> unreg_mcast = 0x0 means unregistered multicast packets will be dropped
>
>> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f, no super, port_mask = 0x3
>> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5, unreg_mcast = 0x0, member_list = 0x5
>
> unreg_mcast = 0x0
>
>> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f, no super, port_mask = 0x5
>> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type = persistant, port_num = 0x0, Secure
>> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f, no super, port_mask = 0x5
>> 9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5, unreg_mcast = 0x0, member_list = 0x5
>
> unreg_mcast = 0x0
>
>> 10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type = persistant, port_num = 0x0
>> 11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state = f, no super, port_mask = 0x5
>> 12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f, no super, port_mask = 0x5
>> 13 : type: mcast, vid = 2, addr = 01:00:5e:03:1d:47, mcast_state = f, no super, port_mask = 0x5
>
> This is requested mcast address, but it's registered for vid=2 (propagated through .ndo_set_rx_mode())
>
>> 14 : type: ucast, vid = 100, addr = 66:22:04:bc:90:26, ucast_type = untouched , port_num = 0x2
>
> [...]
>>
>> Both tcpdumps with -p option showed no packets. If I execute ping, I
>> can see related ICMP packets. addr = 66:22:04:bc:90:26 is PandaBoards
>> MAC.
>>
>> Btw I've attached my test scripts (mcastr.py - multicast receiver and
>> mcastt.py - multicast transmitter). Could you reproduce my setup?
>>
>
> I was able to reproduce an issue with your script. As I understand, when cpsw receive the
> mcast packet with dst_address=01:00:5e:03:1d:47 and vid=100 it hits
> the case:
> "if (Multicast packet) # destination address not found
> then portmask is the logical “AND” of unreg_mcast_flood_mask and vlan_member_list
> then goto Egress process"
>
> and as result packet is dropped (you can check eth1 statistic # ethtool -S eth1).
>
> Unfortunately, I was no able to configure mcast address properly in dual mac mode :(,
> but probably Mugunthan can comment here - mcast addressess are offloaded to cpsw from
I was able to add mcast address for eth0/eth1, but not finding a way to
add mcast entries to eth1.100 interface. I gone through Linux network
stack and didn't find a way where stack asks the driver to add mcast
address for vlan interfaces. *_Network Experts_* can help us here.
> Net core through .ndo_set_rx_mode() and struct netdev_hw_addr doesn't contain any
> information about vlan and cpsw uses default port vlan, which is vid=2 for eth1 in
> dual mac mode.
>
>
>
> As W/A the allmulti flag can be used:
>
> # ifconfig eth1.100 allmulti
For now this is the only possible option that can be used.
Regards
Mugunthan V N
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: am335x: no multicast reception over VLAN
2016-04-05 6:11 ` Mugunthan V N
(?)
@ 2016-04-05 6:22 ` Yegor Yefremov
-1 siblings, 0 replies; 27+ messages in thread
From: Yegor Yefremov @ 2016-04-05 6:22 UTC (permalink / raw)
To: Mugunthan V N
Cc: Grygorii Strashko, Peter Korsgaard, netdev, linux-omap, drivshin,
ml, David Miller
Grygorii, Mugunthan,
On Tue, Apr 5, 2016 at 8:11 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
> On Friday 01 April 2016 05:39 PM, Grygorii Strashko wrote:
>> On 03/31/2016 10:52 AM, Yegor Yefremov wrote:
>>> On Thu, Mar 31, 2016 at 8:37 AM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>>> On Thursday 31 March 2016 01:17 AM, Peter Korsgaard wrote:
>>>>>>>>>> "Mugunthan" == Mugunthan V N <mugunthanvnm@ti.com> writes:
>>>>>
>>>>> Hi,
>>>>>
>>>>> > You had received these packets as tcpdump will enable promiscuous mode
>>>>> > so that you receive all the packets from the wire.
>>>>>
>>>>> FYI, you can use the -p option to tcpdump to not put the interface into
>>>>> promiscuous mode.
>>>>>
>>>>
>>>> Thanks for the information Peter Korsgaard.
>>>>
>>>> Yegor, can you provide tcpdump using -p as well in Grygorii commands.
>>>
>>> Before VLAN configuration:
>>>
>>> # switch-config -d
>>> cpsw hw version 1.12 (0)
>>> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
>>> unreg_mcast = 0x0, member_list = 0x3
>>> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>>> no super, port_mask = 0x3
>>> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
>>> persistant, port_num = 0x0, Secure
>>> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
>>> unreg_mcast = 0x0, member_list = 0x7
>>> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
>>> no super, port_mask = 0x3
>>> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
>>> unreg_mcast = 0x0, member_list = 0x5
>>> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>>> no super, port_mask = 0x5
>>> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
>>> persistant, port_num = 0x0, Secure
>>> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
>>> no super, port_mask = 0x5
>>>
>>> After VLAN configuration:
>>>
>>> # switch-config -d
>>> cpsw hw version 1.12 (0)
>>> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3,
>>> unreg_mcast = 0x0, member_list = 0x3
>>> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>>> no super, port_mask = 0x3
>>> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type =
>>> persistant, port_num = 0x0, Secure
>>> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0,
>>> unreg_mcast = 0x0, member_list = 0x7
>>> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f,
>>> no super, port_mask = 0x3
>>> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5,
>>> unreg_mcast = 0x0, member_list = 0x5
>>> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f,
>>> no super, port_mask = 0x5
>>> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type =
>>> persistant, port_num = 0x0, Secure
>>> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f,
>>> no super, port_mask = 0x5
>>> 9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5,
>>> unreg_mcast = 0x0, member_list = 0x5
>>> 10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type =
>>> persistant, port_num = 0x0
>>> 11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state =
>>> f, no super, port_mask = 0x5
>>> 12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f,
>>> no super, port_mask = 0x5
>>>
>>> During mulitcast receive:
>>>
>>> # switch-config -d
>>> cpsw hw version 1.12 (0)
>>> 0 : type: vlan , vid = 1, untag_force = 0x3, reg_mcast = 0x3, unreg_mcast = 0x0, member_list = 0x3
>>> 1 : type: mcast, vid = 1, addr = ff:ff:ff:ff:ff:ff, mcast_state = f, no super, port_mask = 0x3
>>> 2 : type: ucast, vid = 1, addr = 74:6a:8f:00:16:12, ucast_type = persistant, port_num = 0x0, Secure
>>> 3 : type: vlan , vid = 0, untag_force = 0x7, reg_mcast = 0x0, unreg_mcast = 0x0, member_list = 0x7
>>
>> unreg_mcast = 0x0 means unregistered multicast packets will be dropped
>>
>>> 4 : type: mcast, vid = 1, addr = 01:00:5e:00:00:01, mcast_state = f, no super, port_mask = 0x3
>>> 5 : type: vlan , vid = 2, untag_force = 0x5, reg_mcast = 0x5, unreg_mcast = 0x0, member_list = 0x5
>>
>> unreg_mcast = 0x0
>>
>>> 6 : type: mcast, vid = 2, addr = ff:ff:ff:ff:ff:ff, mcast_state = f, no super, port_mask = 0x5
>>> 7 : type: ucast, vid = 2, addr = 74:6a:8f:00:16:13, ucast_type = persistant, port_num = 0x0, Secure
>>> 8 : type: mcast, vid = 2, addr = 01:00:5e:00:00:01, mcast_state = f, no super, port_mask = 0x5
>>> 9 : type: vlan , vid = 100, untag_force = 0x0, reg_mcast = 0x5, unreg_mcast = 0x0, member_list = 0x5
>>
>> unreg_mcast = 0x0
>>
>>> 10 : type: ucast, vid = 100, addr = 74:6a:8f:00:16:13, ucast_type = persistant, port_num = 0x0
>>> 11 : type: mcast, vid = 100, addr = ff:ff:ff:ff:ff:ff, mcast_state = f, no super, port_mask = 0x5
>>> 12 : type: mcast, vid = 2, addr = 01:80:c2:00:00:21, mcast_state = f, no super, port_mask = 0x5
>>> 13 : type: mcast, vid = 2, addr = 01:00:5e:03:1d:47, mcast_state = f, no super, port_mask = 0x5
>>
>> This is requested mcast address, but it's registered for vid=2 (propagated through .ndo_set_rx_mode())
>>
>>> 14 : type: ucast, vid = 100, addr = 66:22:04:bc:90:26, ucast_type = untouched , port_num = 0x2
>>
>> [...]
>>>
>>> Both tcpdumps with -p option showed no packets. If I execute ping, I
>>> can see related ICMP packets. addr = 66:22:04:bc:90:26 is PandaBoards
>>> MAC.
>>>
>>> Btw I've attached my test scripts (mcastr.py - multicast receiver and
>>> mcastt.py - multicast transmitter). Could you reproduce my setup?
>>>
>>
>> I was able to reproduce an issue with your script. As I understand, when cpsw receive the
>> mcast packet with dst_address=01:00:5e:03:1d:47 and vid=100 it hits
>> the case:
>> "if (Multicast packet) # destination address not found
>> then portmask is the logical “AND” of unreg_mcast_flood_mask and vlan_member_list
>> then goto Egress process"
>>
>> and as result packet is dropped (you can check eth1 statistic # ethtool -S eth1).
>>
>> Unfortunately, I was no able to configure mcast address properly in dual mac mode :(,
>> but probably Mugunthan can comment here - mcast addressess are offloaded to cpsw from
>
> I was able to add mcast address for eth0/eth1, but not finding a way to
> add mcast entries to eth1.100 interface. I gone through Linux network
> stack and didn't find a way where stack asks the driver to add mcast
> address for vlan interfaces. *_Network Experts_* can help us here.
>
>> Net core through .ndo_set_rx_mode() and struct netdev_hw_addr doesn't contain any
>> information about vlan and cpsw uses default port vlan, which is vid=2 for eth1 in
>> dual mac mode.
>>
>>
>>
>> As W/A the allmulti flag can be used:
>>
>> # ifconfig eth1.100 allmulti
>
> For now this is the only possible option that can be used.
Thanks for working on this issue and finding this workaround.
I've attached an USB-to-Ethernet adapter (pagasus driver) to the same
system and could successfully send/receive multicasts over VLAN
interface (eth2.100).
Yegor
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2016-04-05 6:22 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-16 15:05 am335x: no multicast reception over VLAN Yegor Yefremov
2016-03-29 4:00 ` Mugunthan V N
2016-03-29 4:00 ` Mugunthan V N
2016-03-29 5:21 ` Yegor Yefremov
2016-03-29 11:05 ` Grygorii Strashko
2016-03-29 11:05 ` Grygorii Strashko
2016-03-29 12:35 ` Yegor Yefremov
2016-03-29 12:44 ` Grygorii Strashko
2016-03-29 12:44 ` Grygorii Strashko
2016-03-30 5:33 ` Mugunthan V N
2016-03-30 5:33 ` Mugunthan V N
2016-03-30 8:35 ` Yegor Yefremov
2016-03-30 16:52 ` Mugunthan V N
2016-03-30 16:52 ` Mugunthan V N
2016-03-30 19:47 ` Peter Korsgaard
2016-03-30 19:47 ` Peter Korsgaard
2016-03-31 6:37 ` Mugunthan V N
2016-03-31 6:37 ` Mugunthan V N
2016-03-31 7:52 ` Yegor Yefremov
2016-03-31 10:02 ` Mugunthan V N
2016-03-31 10:02 ` Mugunthan V N
2016-03-31 10:16 ` Yegor Yefremov
2016-04-01 12:09 ` Grygorii Strashko
2016-04-01 12:09 ` Grygorii Strashko
2016-04-05 6:11 ` Mugunthan V N
2016-04-05 6:11 ` Mugunthan V N
2016-04-05 6:22 ` Yegor Yefremov
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.