Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fails to receive packets over 1500 bytes in length. #89

Closed
colinw-smartrg opened this issue Aug 9, 2019 · 9 comments
Closed

Fails to receive packets over 1500 bytes in length. #89

colinw-smartrg opened this issue Aug 9, 2019 · 9 comments

Comments

@colinw-smartrg
Copy link

Please provide this info. See this link for more info on how to gather debug
info: http://www.candelatech.com/ath10k-bugs.php

Description of the problem (how to configure, how to reproduce, how often it happens).

Software (OS, Firmware version, kernel, driver, etc)

Hardware (NIC chipset, platform, etc)

Logs (dmesg, maybe supplicant and/or hostap)
@colinw-smartrg
Copy link
Author

When Linux wifi device is configured with an MTU above 1500, e.g. 1600, any packet received above 1500 bytes payload gets dropped.

Linux 4.14.134, QCA Dakota 4019.
Firmware:
QCA4019-firmware-5-ct-full-htt-mgt-community-12.bin-lede.009

@colinw-smartrg
Copy link
Author

The issue appears to be the ring buffer size defined by:
HTT_RX_BUF_SIZE 1920
The largest MDSU is
#define HTT_RX_MSDU_SIZE (HTT_RX_BUF_SIZE - (int)sizeof(struct htt_rx_desc))

Which is 1560, and with 60 bytes of overhead, the max payload is 1500.

An MSDU larger than 1560 is possible in the air, and will not be received properly by the driver as the firmware doesn't appear to fragment.

@greearb
Copy link
Owner

greearb commented Aug 9, 2019

Stock driver/firmware has the same issue, or is this CT only problem?

@colinw-smartrg
Copy link
Author

Just tried the stock driver/firmware and see the same issue.

Changing HTT_RX_BUF_SIZE to 2048 ( 1 cache line more ) fixes the issue.

@colinw-smartrg
Copy link
Author

This seems like a firmware issue in that the firmware should create two fragments since the RX_BUF is not big enough for the packet. But I only get one encrypted buffer.

The driver appears to detect the length and appears to send two buffers for decryption as I see two decrypted buffers returned chained in ath10k_htt_rx_handle_amsdu() but ath10k_htt_rx_h_unchain() fails with rx_drop_decap_non_raw_chained. Maybe that is a driver issue as the comment says FIXME.

@greearb
Copy link
Owner

greearb commented Aug 12, 2019

Since this happens in stock firmware/driver, maybe report it to the ath10k mailing list and see if someone will fix the driver? Please also mention that changing the RX_BUF_SIZE to 2048 works around the problem. Maybe just making that larger is the correct fix?

@greearb
Copy link
Owner

greearb commented Sep 16, 2019

I believe this is now fixed by increasing the RX_BUF_SIZE in ath10k-ct driver. Changes should be in upstream OpenWRT now.

@greearb greearb closed this as completed Sep 16, 2019
fengguang pushed a commit to 0day-ci/linux that referenced this issue Feb 6, 2020
@T-X @intel-lab-lkp
ath10k: increase rx buffer size to 2048
a5c9305 
Before, only frames with a maximum size of 1528 bytes could be
transmitted between two 802.11s nodes.

For batman-adv for instance, which adds its own header to each frame,
we typically need an MTU of at least 1532 bytes to be able to transmit
without fragmentation.

This patch now increases the maxmimum frame size from 1528 to 1656
bytes.

Tested with two ath10k devices in 802.11s mode, as well as with
batman-adv on top of 802.11s with forwarding disabled.

Fix originally found and developed by Ben Greear.

Link: greearb/ath10k-ct#89
Link: greearb/ath10k-ct@9e5ab25
Cc: Ben Greear <[email protected]>
Signed-off-by: Linus Lüssing <[email protected]>
ecsv pushed a commit to ecsv/openwrt that referenced this issue Apr 25, 2020
@T-X @ecsv
mac80211: ath10k: increase rx buffer size to 2048
5df2d91 
Before, only frames with a maximum size of 1528 bytes could be
transmitted between two 802.11s nodes.

For batman-adv for instance, which adds its own header to each frame,
we typically need an MTU of at least 1532 bytes to be able to transmit
without fragmentation.

This patch now increases the maxmimum frame size from 1528 to 1656
bytes.

Tested with two ath10k devices in 802.11s mode, as well as with
batman-adv on top of 802.11s with forwarding disabled.

Fix originally found and developed by Ben Greear.

Link: greearb/ath10k-ct#89
Link: greearb/ath10k-ct@9e5ab25
Cc: Ben Greear <[email protected]>
Signed-off-by: Linus Lüssing <[email protected]>
Signed-off-by: Sven Eckelmann <[email protected]>
@ecsv ecsv mentioned this issue Apr 25, 2020
Closed
ecsv added a commit to ecsv/gluon that referenced this issue Apr 25, 2020
@ecsv
mac80211: ath10k: increase rx buffer size to 2048
8f29098 
Before, only frames with a maximum size of 1528 bytes could be
transmitted between two 802.11s nodes.

For batman-adv for instance, which adds its own header to each frame,
we typically need an MTU of at least 1532 bytes to be able to transmit
without fragmentation.

This patch now increases the maxmimum frame size from 1528 to 1656
bytes.

Tested with two ath10k devices in 802.11s mode, as well as with
batman-adv on top of 802.11s with forwarding disabled.

Fix originally found and developed by Ben Greear.

Link: greearb/ath10k-ct#89
Link: greearb/ath10k-ct@9e5ab25
Forwarded: openwrt/openwrt#2959
@ecsv ecsv mentioned this issue Apr 25, 2020
Merged
@adschm
Copy link

adschm commented Apr 25, 2020

@greearb This has been brought up again for OpenWrt since it's still not "fixed" in kernel.
In that context, I wonder why the value 2048 has been chosen, which will allow a little more payload, but seems not much less arbitrary than the previous value. What prevents enabling the full max. MTU of 2304 without fragmentation, before something else will break the 2048 limit again?

@greearb
Copy link
Owner

greearb commented Apr 25, 2020

I haven't tried larger values, but it should be easy enough for someone to test.

jow- pushed a commit to openwrt/openwrt that referenced this issue Apr 26, 2020
@T-X @hauke
mac80211: ath10k: increase rx buffer size to 2048
066ec97 
Before, only frames with a maximum size of 1528 bytes could be
transmitted between two 802.11s nodes.

For batman-adv for instance, which adds its own header to each frame,
we typically need an MTU of at least 1532 bytes to be able to transmit
without fragmentation.

This patch now increases the maxmimum frame size from 1528 to 1656
bytes.

Tested with two ath10k devices in 802.11s mode, as well as with
batman-adv on top of 802.11s with forwarding disabled.

Fix originally found and developed by Ben Greear.

Link: greearb/ath10k-ct#89
Link: greearb/ath10k-ct@9e5ab25
Cc: Ben Greear <[email protected]>
Signed-off-by: Linus Lüssing <[email protected]>
Signed-off-by: Sven Eckelmann <[email protected]>
fblaese added a commit to fblaese/firmware that referenced this issue May 1, 2020
@fblaese
ath10k: Increase buffer to fix >1500 MTU frames
f7c5f94 
The ath10k seems to have an issue with large frames
transmitted over 802.11s. This issue has been worked around
in ath10k-ct. The same patch has now been merged into OpenWrt.

As this might fix mesh issues with ath10k devices, it is backported
to our firmware using a build patch.

Link: openwrt/openwrt@066ec97
Link: greearb/ath10k-ct#89
Link: greearb/ath10k-ct@9e5ab25

Signed-off-by: Fabian Bläse <[email protected]>
Reviewed-by: Adrian Schmutzler <[email protected]>
jow- pushed a commit to openwrt/openwrt that referenced this issue May 4, 2020
@T-X @hauke
mac80211: ath10k: increase rx buffer size to 2048
005adba 
Before, only frames with a maximum size of 1528 bytes could be
transmitted between two 802.11s nodes.

For batman-adv for instance, which adds its own header to each frame,
we typically need an MTU of at least 1532 bytes to be able to transmit
without fragmentation.

This patch now increases the maxmimum frame size from 1528 to 1656
bytes.

Tested with two ath10k devices in 802.11s mode, as well as with
batman-adv on top of 802.11s with forwarding disabled.

Fix originally found and developed by Ben Greear.

Link: greearb/ath10k-ct#89
Link: greearb/ath10k-ct@9e5ab25
Cc: Ben Greear <[email protected]>
Signed-off-by: Linus Lüssing <[email protected]>
Signed-off-by: Sven Eckelmann <[email protected]>
(cherry picked from commit 066ec97)
jollaman999 pushed a commit to jollaman999/openwrt that referenced this issue Jul 10, 2020
@T-X @ish-hcc
mac80211: ath10k: increase rx buffer size to 2048
8332870 
Before, only frames with a maximum size of 1528 bytes could be
transmitted between two 802.11s nodes.

For batman-adv for instance, which adds its own header to each frame,
we typically need an MTU of at least 1532 bytes to be able to transmit
without fragmentation.

This patch now increases the maxmimum frame size from 1528 to 1656
bytes.

Tested with two ath10k devices in 802.11s mode, as well as with
batman-adv on top of 802.11s with forwarding disabled.

Fix originally found and developed by Ben Greear.

Link: greearb/ath10k-ct#89
Link: greearb/ath10k-ct@9e5ab25
Cc: Ben Greear <[email protected]>
Signed-off-by: Linus Lüssing <[email protected]>
Signed-off-by: Sven Eckelmann <[email protected]>
fengguang pushed a commit to 0day-ci/linux that referenced this issue Jan 20, 2021
@T-X
ath10k: increase rx buffer size to 2048
3e6b9cf 
Before, only frames with a maximum size of 1528 bytes could be
transmitted between two 802.11s nodes.

For batman-adv for instance, which adds its own header to each frame,
we typically need an MTU of at least 1532 bytes to be able to transmit
without fragmentation.

This patch now increases the maxmimum frame size from 1528 to 1656
bytes.

Tested with two ath10k devices in 802.11s mode, as well as with
batman-adv on top of 802.11s with forwarding disabled.

Fix originally found and developed by Ben Greear.

Link: greearb/ath10k-ct#89
Link: greearb/ath10k-ct@9e5ab25
Cc: Ben Greear <[email protected]>
Signed-off-by: Linus Lüssing <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
PlaidCat added a commit to ctrliq/kernel-src-tree that referenced this issue Sep 12, 2024
@PlaidCat
ath10k: increase rx buffer size to 2048
412796d 
jira LE-1907
Rebuild_History Non-Buildable kernel-4.18.0-315.el8
commit-author Linus Lüssing <[email protected]>
commit 3e6b9cf

Before, only frames with a maximum size of 1528 bytes could be
transmitted between two 802.11s nodes.

For batman-adv for instance, which adds its own header to each frame,
we typically need an MTU of at least 1532 bytes to be able to transmit
without fragmentation.

This patch now increases the maxmimum frame size from 1528 to 1656
bytes.

Tested with two ath10k devices in 802.11s mode, as well as with
batman-adv on top of 802.11s with forwarding disabled.

Fix originally found and developed by Ben Greear.

Link: greearb/ath10k-ct#89
Link: greearb/ath10k-ct@9e5ab25
	Cc: Ben Greear <[email protected]>
	Signed-off-by: Linus Lüssing <[email protected]>
	Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
(cherry picked from commit 3e6b9cf)
	Signed-off-by: Jonathan Maple <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@greearb @colinw-smartrg @adschm