Thanks, that explains. Also found some code in proprietary driver which appears to correct the header in certain situations, but it is rather complex. But what it appears to be is that there should be a vlan tag, but there isn’t always. And when there isn’t it should be inserted. But the current bgmac is incorrectly determining the ethertype as the function eth_type_trans won't take this vlan tag into account. Trying some trickery (based upon flags in header of rx frame) to make it work.
-----Original Message----- On 29 April 2015 at 12:51, Hante Meuleman <meule...@broadcom.com> wrote: > Status report: spent lots of time trying to figure out how to use cpu > port 8 and use vlan1ports "0 1 2 3 5 7 8t", and found that I got fooled > by the way I tried to determine if it was working or not. To see if the > switch configuration was working I used to type "ifconfig" and then > see if there were and rx packets. Today I added logging in bgmac to > see if there are any rx interrupts, and to my surprise there are. So it > is possible to get it to work with cpu port 8 but the data is being > dropped by the stack (nothing visible in the counters). This is sample > data that gets received: > > [ 32.759614] bgmac: ETH, len=324, flags=0x01, protocol=0x0008 > [ 32.766714] bgmac: 45 00 01 36 bc f2 40 00 ff 11 19 8a c0 a8 02 96 > [ 32.774796] bgmac: e0 00 00 fb 14 e9 14 e9 01 22 b5 86 00 00 84 00 > [ 32.782892] bgmac: ETH, len=344, flags=0x01, protocol=0xdd86 > [ 32.789989] bgmac: 60 00 00 00 01 22 11 ff fd 1b 72 e5 79 5c 00 00 > [ 32.798077] bgmac: 75 58 39 77 51 db f7 b2 ff 02 00 00 00 00 00 00 Packets received by bgmac are supposed to be VLAN tagged. Are they in your case? I think you're dumping beginning on every packet. Compare dump (early bytes, look for 802.1Q header [0]) when using 5t vs. 8t. [0] http://en.wikipedia.org/wiki/IEEE_802.1Q _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
