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

802.1q / VLAN support: getting truncated packets with ixp4xx_npe driver

Expand Messages
  • ev013
    I ve been trying to set up an OpenWRT based firewall on a slug using Linux s standard vlan support. On VLAN interfaces I m apparently seeing truncated receive
    Message 1 of 1 , Jun 16 7:15 AM
      I've been trying to set up an OpenWRT based firewall on a slug using
      Linux's standard vlan support. On VLAN interfaces I'm apparently
      seeing truncated receive packets. Transmit packets are working as
      expected.

      Details are below, any debugging ideas or suggestions would be
      appreciated.

      -Eric Varsanyi

      Symptoms
      ------------
      1) tcpdump (on the slug) shows truncated packets on the vlan interface
      (with flag 1 set to 0 it shows no packets at all, which I expect); my
      external monitor port dump shows full packets egressing the switch
      toward the slug. I see this with TCP, ICMP and UDP packets. ARP is
      working OK, probably because the packet size is small enough. Example
      attempt at a TCP connection:

      What I see on my external monitor port going toward the slug:

      08:56:21.412281 00:e0:81:21:e6:e6 > 00:e0:81:21:e6:e8, ethertype IPv4
      (0x0800), length 74: 1.1.1.1.53329 > 1.1.1.2.22: S
      441186173:441186173(0) win 5840 <mss 1460,sackOK,timestamp 1508413515
      0,nop,wscale 2>
      0x0000: 4510 003c 6736 4000 4006 cf71 0101 0101 E..<g6@.@..q....
      0x0010: 0101 0102 d051 0016 1a4b f77d 0000 0000 .....Q...K.}....
      0x0020: a002 16d0 60cc 0000 0204 05b4 0402 080a ....`...........
      0x0030: 59e8 904b 0000 0000 0103 0302 Y..K........

      What the SLUG sees with tcpdump locally:

      09:15:45.543726 00:e0:81:21:e6:e6 > 00:e0:81:21:e6:e8, ethertype IPv4
      (0x0800), length 56: truncated-ip - 18 bytes missing! 1.1.1.1.53329 >
      1.1.1.2.22: S 441186173:441186173(0) win 5840 <mss[|tcp]>
      0x0000: 4510 003c 6737 4000 4006 cf70 0101 0101 E..<g7@.@..p....
      0x0010: 0101 0102 d051 0016 1a4b f77d 0000 0000 .....Q...K.}....
      0x0020: a002 16d0 5514 0000 0204 ....U.....

      2) as a cross check I turned debugging on in udhcpc and stuck in some
      extra printfs to show what it is receiving on its raw socket. It
      reports truncated Offer packets in response to a Discover:

      root@OpenWrt:/home# ./udhcpc -i eth0.3 -n
      adapter index 4
      adapter hardware address 00:e0:81:21:e6:e8
      udhcpc (v1.8.2) started
      vfork'ing and execle'ing /usr/share/udhcpc/default.script
      entering raw listen mode
      adapter index 4
      adapter hardware address 00:e0:81:21:e6:e8
      Opening raw socket on ifindex 4
      adding option 0x35
      adding option 0x3d
      adding option 0x3c
      Sending discover...
      adapter index 4
      adapter hardware address 00:e0:81:21:e6:e8
      Waiting on select...
      pkt len=42: 69 00 01 94 87 24 00 00 255 17 25 91 73 205 18 01 71 63
      167 14 00 67 00 68 01 74 113 205 02 01 06 00 12 57 170 149 00 00 00 00
      00 00
      Truncated packet
      adapter index 4
      adapter hardware address 00:e0:81:21:e6:e8
      Waiting on select...

      From the monitor port the offer packet is complete.

      Stuff I've tried
      ------------
      - Turning the header editing flag on and off
      - Different vlan numbers
      - different machine to test against
      - 2 different flavors of tcpdump (when I thought it was just tcpdump
      having an issue), one from Optware (which gets an illegal instruction
      pretty quickly) and one the default you get after a fresh install of
      Kamikaze (which seems to work)
      - All the above tests work OK on the untagged eth0 interface

      Next steps
      ------------
      My current plans are:
      1) try another distro (suggestions?) to see if this is OpenWRT
      specific. I know generic 2.6 vlan support works at least on an x86
      because I'm using it on the existing firewall without issue.
      2) I'm waiting for a 3.3v max232 chip (I only had 5v versions on
      hand), once I get that I'll stick some printfs in the npe and 8021q
      driver and see if I can track it down further

      Test environment
      ------------
      I've tried several configurations, but the simplest one to describe is
      the slug, an x86 linux box (successfully using vlans today), and an Hp
      ProCurve switch. The switch is set up to put the slug and x86 box
      UNtagged into vlan 1 and tagged into vlan 5.

      On the slug and x86 box I do 'vconfig add eth0 5' then ifconfig eth0.5
      up with an address in a /24 (1.1.1.1 and 1.1.1.2).

      A 3rd machine is attached to another port on the switch which is set
      to to mirror traffic from the slug or x86 port (alternately) for
      testing (I'm running tcpdump on this machine).

      Software/Firmware
      ------------
      I started with the binary Kamikaze 7.09 image then when I had problems
      I moved testing to a source build from
      https://svn.openwrt.org/openwrt/trunk (rev 11464, a couple of days old).

      The kernel version is 2.6.25.6 and the Intel IXP firmware is 2.4.
      802.1q support and the npe ethernet driver are built into the kernel
      (not a loadable module).

      Why VLAN's?
      ------------
      I have a managed switch that supports vlan tagging and I use it to
      make 4 virtual interfaces appear on the router (inside, dmz, cable,
      dsl) then use iptables mangling facility with iproute2 to manage the
      traffic. My current firewall (an old x86 box) uses this facility as
      well and I'm having no problems with it (other than it sucks a lot of
      power and is noisy).
    Your message has been successfully submitted and would be delivered to recipients shortly.