Gary Thomas wrote:

Jesper Dangaard Brouer wrote:

quoted

On Tue, 2009-03-03 at 05:03 -0700, Gary Thomas wrote:

quoted

Jesper Dangaard Brouer wrote:

quoted

On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote:

quoted

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