Don't set MTU on socket #4
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks for sharing! Is the acl_send_data hack still necessary after removing the MTU option? |
|
Yes it is. On the other hand, removing the acl_send_data hack and setting the MTU doesn't work; write() still errors out with "invalid packet size" or something. So the only combination that works is acl_send_data + default MTU |
This was referenced Nov 15, 2020
Open
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I have spent some time debugging this :) I was trying to use the proxy between a PS4 and a Dual Shock. Everything seemed to be fine, except that after the PS4 sent its "big" SDP packet (797 bytes), nothing happened and the outgoing connection to the PS4 on HID PSMs timed out.
Removing the MTU option fixed this. My guess (I'm no BT expert) is that the PS4 did not like a "fragmented" packet that wasn't actually fragmented (since the MTU was 1024, ace_send_data only had to call writev once). Now everything works fine. This is only a problem the first time the proxy is used with a given BTADDR of course, since subsequent connexions do not trigger the PS4 -> DS SDP stuff.