Hi.
I've done some more digging and came up with following:
- The problem only appears when eth0 is used as vlan tagged port -
the frame is longer in this case.
- TEW-632BRP has a ar8216 switch chip. This chip seem to have nice
'feature' of adding two byte header to each packet that arrives on
router's interface. This header is handled by ar8216 switch driver
(ar8216_mangle_{tx,rx} function), so ag71xx ethernet driver never sees
this header.
Unfortunately it looks like that 2 byte packet header is included
into packet length calculation. The net result is that when we have
tagged interface 'ag71xx_max_frame_len' returns exactly max ethernet
frame size for a given mtu. It doesn't take that additional header
into account. So, if interface is non-tagged we are fine -
'ag71xx_max_frame_len' still includes length of 802.1q header (4
bytes) - this is more than enough for ar816's header to fit in. But if
interface is tagged there is no place to spare and packet becomes too
large and dropped.
Before r39147 the MFL register was set to some large value (~1540)
which is more than enough to handle ar8216 header and 802.1q header at
the same time.
I think it is a regression - before it was possible to use vlans
(yeah, vlans on ar8216 ar weird, but useful in some cases), now tagged
interface cannot handle standard mtu of 1500.
I'm not exactly sure how to properly fix this issue. ag71xx_main.c
doesn't really have an appropriate knowlegde what switch chip is
present. So I think there are two options:
- Always add 2 extra bytes in 'ag71xx_max_frame_len'. This doesn't
seem like to much an overhead for platforms that do not use this
header. On the other hand this may reduce max achievable MTU on some
platforms - not sure how important this is.
- Add new flag to platform data that makes 'ag71xx_max_frame_len'
add 2 bytes for platforms where this flag is set. This is more code,
but should reduce impact to only platforms that are affected by this
issue.
I would appreciate if somebody could let me know what approach has
better chances to be applied. I can prepare a patch and test it on my
router. Unfortunately I do not have other hardware available.
Thanks!
2013/12/25 Nikolay Martynov <mar.ko...@gmail.com>:
> Hi.
>
> It looks like recent changes to trunk introduce a regression on TEW632BRP.
>
> The problem: when image build from current trunk is flashed into
> device one cannot connect to it with ssh and internet connection
> though it is not stable.
>
> Further investigation shows that problem is caused by the fact that
> large (i.e. size of MTU) ethernet packets do not reach device. Setting
> MTU to 1498 on PC and router fixes connectivity issues.
>
> I was able to bisec this regression to commit r39147.
>
> Also, It looks like that the following change (applied to head)
> fixes the problem on this platform:
>
> diff --git
> a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
> b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
> index 715c1ce..615c7eb 100644
> ---
> a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
> +++
> b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
> @@ -30,7 +30,10 @@ MODULE_PARM_DESC(msg_level, "Message level
> (-1=defaults,0=none,...,16=all)");
>
> static inline unsigned int ag71xx_max_frame_len(unsigned int mtu)
> {
> - return ETH_HLEN + VLAN_HLEN + mtu + ETH_FCS_LEN;
> + unsigned int max_frame_len = ETH_HLEN + VLAN_HLEN + mtu + ETH_FCS_LEN;
> + max_frame_len += 2;
> + return max_frame_len;
> }
>
> Unfortunately I was not able to come up with proper explanation of
> what's going on and this change seems rather crude, so I'm not sending
> a patch that can be applied. This is just to illustrate the problem.
>
> Also, just a note: I have eth0 setup with vlans, not yet sure if
> this is related to the problem or not, but I guess it is not the most
> common config.
>
> I'll be happy to assist further testing.
>
> Thanks! Merry Christmas!
>
> --
> Martynov Nikolay.
> Email: mar.ko...@gmail.com
--
Martynov Nikolay.
Email: mar.ko...@gmail.com
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
