Loading ...
Sorry, an error occurred while loading the content.
 

VLAN woes with OpenWRT

Expand Messages
  • ev013
    I ve been trying to configure up virtual interfaces via the built in vlan support in openwrt and was seeing truncated packets inbound (transmitting worked
    Message 1 of 1 , Jun 22, 2008
      I've been trying to configure up virtual interfaces via the built in
      vlan support in openwrt and was seeing truncated packets inbound
      (transmitting worked fine), I posted high level info on this last week.

      I've tracked this down a bit further and I'm hoping someone here has
      some experience with the IXP425 firmware and maybe has some ideas.

      When I enabled debugging options in the device driver I can see that
      ingress packets are being marked with flags '6090', flag bit 0x0080
      (from the Intel programmers guide) means:

      "Deferred filter flag. A value of 0 indicates a normal frame. A value
      of 1 indicates that the NPE would normally have dropped the frame
      due to a filtering operation, but that the frame was preserved and
      presented to the Intel XScale processor client because it contains a
      new source MAC address that must be learned. Furthermore, when
      this flag is set, the only IX_OSAL_MBUF fields that may be
      considered to be valid are ixp_ne_next, ixp_ne_data,
      ixp_ne_dest_mac, and ixp_ne_src_mac." [in other words, the packet is
      truncated]

      Since the Linux driver in OpenWRT is not the Intel Linux driver and
      doesn't use their 'interface library' I suspect that some
      initialization required by the firmware isn't being done. I poked
      through Intel's interface library (the direct message API to the
      firmware that the linux ixp4xx_eth.c driver uses is not documented by
      Intel) and tried a few things:
      1) I tried setting the ingress filtering options
      (VLAN_SETRXTAGMODE) to pass through tags and not filter vlan tagged frames
      2) I tried including all vlans in this ports vlan membership map (8
      vlans at a time, you send a 4k bitmap to the coprocessor).
      3) I tried disabling the rx mac filters (as if promiscuous), this
      did allow reception of frames destined to another mac (as expected)

      None of this helped with tagged ingress frames. The header structure
      is showing the correct vlan, so I think the firmware is interpreting
      these frames correctly.

      Here are some examples showing what the driver is getting from the
      microcode. First a normal ICMP ingress packet, not tagged, with the
      header fields annotated manually (I added the 'foo=' tags):

      Queue 3 -> 1E4A181
      phys=1E4A180: next=0 buf_len=5EA pkt_len=5EA data=01E6D012 destid=FF <
      srcid=10 flags=4014 qos=0 padlen=0 vlan_tci=0 dstmac=0014BF65D831 <
      srcmac=00E081717318
      eth0: eth_poll(1514) 0014BF65D831 00E081717318 0800 45 00 05 DC 24
      87 20 00 40 01 2C 96 01 01 01 01 01 01 01 02 08 00 E0 12 C1 4A 00
      01 BA 40 5D 48 00 00 00 00 AC A6 04 00 00 00 00 00 10 11 12 13 14
      15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A
      ...

      Flags 4014 is totally reasonable, its saying that vlan support is
      enabled in the firmware, this packet is not vlan tagged, and this is a
      non LLC/SNAP style ethernet packet, protocol IP.

      Here's an example of a vlan tagged ICMP ingress packet as seen by the
      driver:

      Queue 3 -> 1E4A121
      phys=1E4A120: next=0 buf_len=3C pkt_len=3C data=01E6C812 destid=FF <
      srcid=10 flags=6090 qos=0 padlen=0 vlan_tci=5 dstmac=0014BF65D831 < src
      mac=00E081717318
      eth0: eth_poll(60) 0014BF65D831 00E081717318 8100 00 05 08 00 45 00 05
      DC 33 BD 20 00 40 01 15 60 05 01 01 01 05 01 01 02 08 00 53 90 AA 4A 00
      01 B5 3E 5D 48 00 00 00 00 4A 2B 0F 00 00 00

      (this was a 1500 byte icmp echo request)

      Flags 6090 indicates this *is* a vlan tagged packet (and the vlan id
      is decoded properly as vlan 5) and it has that 'filtered' bit turned
      on (and no longer decodes as IP, but that's understandable since its
      truncated).

      Any hints/tips/clues as to what to try next would be appreciated. I
      though of trying an older IXP firmware release but Intel disappeared
      them from their download site (you can get 2.4 and 3.0.1 and that's it).

      Has anyone tried importing the Intel linux driver stock? I may try
      this (then instrument the chatter with the microcode to see how the
      setup sequence works) as a last resort, I don't know what it will take
      to port their OSAL layer to the slug.

      Thanks,
      -Eric Varsanyi
    Your message has been successfully submitted and would be delivered to recipients shortly.