aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux/x86_64
diff options
context:
space:
mode:
authorGabor Juhos <juhosg@openwrt.org>2014-01-11 11:15:30 +0000
committerGabor Juhos <juhosg@openwrt.org>2014-01-11 11:15:30 +0000
commit95b66c31118df52b4417fe2e070cbe75aa7d8ade (patch)
treefd5fcd5fd2b190f9bfe09b0209728a2dbcd6ac2d /target/linux/x86_64
parente3ff34b20c9d84d936e6d6481e6f76ce56e12716 (diff)
downloadupstream-95b66c31118df52b4417fe2e070cbe75aa7d8ade.tar.gz
upstream-95b66c31118df52b4417fe2e070cbe75aa7d8ade.tar.bz2
upstream-95b66c31118df52b4417fe2e070cbe75aa7d8ade.zip
ar71xx: ag71xx: increase calculated max frame length value
The r39147 commit introduces a regression: at lease on some routers with ar8216 switch large packets get lost if 802.1q tagged port is used on the interface connected to the aforementioned switch. The r39147 changes code in the way so interface is set to accept packets no longer than max ethernet frame length for a given mtu. Unfortunately ar8216 has a feature: it sends two additional bytes as a packet header and those this header needs to be added to the max frame length. Otherwise long enough packets get lost. The problem only manuifests itself if interface is used in vlan tagged mode. If interface is untagged then ar8216's header fits into space used by 802.1q tag and not packets are lost. Include two additional bytes in the max frame length calculation to fix the issue. This patch is tested and works with Trendnet TEW-632BRP. Signed-off-by Nikolay Martynov <mar.kolya@gmail.com> Patchwork: http://patchwork.openwrt.org/patch/4656/ [juhosg: - simplify the patch to include the additional bytes of the switch header unconditionally, - change subject and update commit message] Signed-off-by: Gabor Juhos <juhosg@openwrt.org> git-svn-id: svn://svn.openwrt.org/openwrt/trunk@39219 3c298f89-4303-0410-b956-a3cf2f4a3e73
Diffstat (limited to 'target/linux/x86_64')
0 files changed, 0 insertions, 0 deletions