[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 03 Mar 2009 06:30:31 -0700
From: Gary Thomas <gary@...assoc.com>
To: jdb@...x.dk
CC: Jesper Dangaard Brouer <hawk@...u.dk>,
Lennert Buytenhek <buytenh@...tstofly.org>,
netdev <netdev@...r.kernel.org>
Subject: Re: Marvell 88E609x switch?
Gary Thomas wrote:
> Jesper Dangaard Brouer wrote:
>> On Tue, 2009-03-03 at 05:03 -0700, Gary Thomas wrote:
>>> Jesper Dangaard Brouer wrote:
>>>> On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote:
>>>>> Any ideas how I might troubleshoot why packets that come
>>>>> into lan1.1 (port 0) aren't being pushed to the CPU port?
>>>> The switch supports port monitoring, with seperate ingress and egress
>>>> mapping, thus you could place another PC on another port and direct
>>>> traffic towards that, and by tcpdump inspecting ingress and egress on
>>>> the different physical ports... Thats how I debugged it once...
>>> I'm a bit fuzzy on this - could you explain in a bit more detail?
>> You basically set the monitor destination port via REG_GLOBAL reg 0x1A
>> "Monitor Control".
>>
>> /* Register: Monitor Control (0x1A)
>> -------------------------
>> bit 15:12= Ingress Monitor Dest
>> bit 11:8 = Egress Monitor Dest
>> bit 7:4 = ARP Dest
>> bit 3:0 = Reserved
>> */
>>
>> Then you configure the port register 0x08 "port control2", that this
>> port is to be monitored: bit5=monitor_egress and bit4=monitor_ingress.
>>
>> /* Register: Port Control 2 (0x8)
>> ------------------------
>> bit 15 = IgnoreFSC: Force good FSC in frame
>> bit 14 = VTU_prio_override : VTU setting overrides prio
>> bit 13 = ATU_SA_prio_overrite: ATU SA setting overrides prio
>> bit 12 = ATU_DA_prio_overrite: ATU DA setting overrides prio
>> bit 11:10 = 802.1Q mode
>> [00] = <Disabled>: use VLANtable only
>> [01] = <Fallback>: fallback to VLANTable
>> [10] = <Check> : drop on miss (eq. not in VTU)
>> [11] = <Secure> : drop on miss and membership violation
>> bit 9 = Discard Tagged
>> bit 8 = Discard Untagged
>> bit 7 = MapDA: Map using DA hits
>> bit 6 = Default Forward (normal switch operation)
>> bit 5 = Monitor egress
>> bit 4 = Monitor ingress
>> bit 3:0 = CPU port
>> */
>>
>>
>> Reading through the "Monitor Control" register description, there is a
>> interesting description about the "ARPdest" setting... Could you try to
>> set it to the CPU port and see if that helps?
>>
>
> It's already set this way (sans bits 4&5)
> REG_WRITE(REG_GLOBAL, 0x1a, (ds->cpu_port * 0x1100) | 0x00f0);
>
> I tried turning on bit 4 on port 0 (lan1.1). Now I can see what's
> coming into that port, but it doesn't look right:
>
> Here's the ARP going out:
>
> 13:46:29.348449 00:1d:11:81:00:00 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x4000), length 46:
> 0x0000: ffff ffff ffff 001d 1181 0000 4000 0000
> 0x0010: 0806 0001 0800 0604 0001 001d 1181 0000
> 0x0020: c0a8 0cbc 0000 0000 0000 c0a8 0c12
>
> Here's the ARP reply coming back:
>
> 13:46:29.348907 00:1e:c9:2f:73:6c > 00:1d:11:81:00:00, ethertype Unknown (0x8004), length 64:
> 0x0000: 001d 1181 0000 001e c92f 736c 8004 0000
> 0x0010: 0806 0001 0800 0604 0002 001e c92f 736c
> 0x0020: c0a8 0c12 001d 1181 0000 c0a8 0cbc 0000
> 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
>
> I understand the 0x4000 DSA tag going out, but what's the 0x8004?
>
Note: without the extra monitor bit (#4), I don't see these packets
get back to my ethernet device. Maybe the tag says something of why?
Any pointers on how I can test/debug the "VLAN" (internal routing) setup?
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists