netdev - Re: Marvell 88E609x switch?

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

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

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

Date:	Tue, 03 Mar 2009 14:52:23 -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:
> 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?

I found this tag in the 6131 manual - it basically says that it's
a copied packet which was received on VID 0.  Exactly as expected.

> Any pointers on how I can test/debug the "VLAN" (internal routing) setup?

Do you understand where (which register settings) cause packets
which come in on lan1.1 (VID=0 I think, port 0) to be sent on
to the CPU port (10) along with the TO_CPU tag?  I've been through
this document a dozen times and I still don't see where the mapping
that direction happens...

-- 
------------------------------------------------------------
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