aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux/brcm2708
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
commit30ebad2dee1bc348c9b8234f0649a0b8f7a9cb40 (patch)
tree555454f57f17f292ed38ea5566700bd16de362c7 /target/linux/brcm2708
parent2d2254c9ce47b2978465aff5b62c2d997ebf0dd3 (diff)
downloadupstream-30ebad2dee1bc348c9b8234f0649a0b8f7a9cb40.tar.gz
upstream-30ebad2dee1bc348c9b8234f0649a0b8f7a9cb40.tar.bz2
upstream-30ebad2dee1bc348c9b8234f0649a0b8f7a9cb40.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> SVN-Revision: 39219
Diffstat (limited to 'target/linux/brcm2708')
0 files changed, 0 insertions, 0 deletions