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.

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

wss://tracker.webtorrent.dev unexpected announce response #981

Open
Jhonfunk opened this issue Sep 27, 2024 · 5 comments
Open

wss://tracker.webtorrent.dev unexpected announce response #981

Jhonfunk opened this issue Sep 27, 2024 · 5 comments

Comments

@Jhonfunk
Copy link

[2024-09-27 14:03:01 +0800 WRN websocketTrackers github.com/anacrolix/torrent/webtorrent tracker-client.go:342]
  tracker client for "wss://tracker.webtorrent.dev": unexpected announce response "{\"failure reason\":\"Invalid request\"}" <*torrent.Client 0xc000191408>
@anacrolix
Copy link
Owner

Interesting thanks. Do you use other wss trackers and do they do it too?

@Jhonfunk
Copy link
Author

@anacrolix
Other wss trackers don't have this problem. But it's a bit strange, so I'm bringing it up. Maybe webtorrent updated its tracker protocol?

@anacrolix
Copy link
Owner

Thanks for following up. If anyone else comes across this behaviour we can start investigating. I think there a few other trackers that work in the meanwhile.

@Jhonfunk Jhonfunk closed this as completed Oct 7, 2024
@SilentBot1
Copy link

Hi @anacrolix and @Jhonfunk,

To comment on this issue, the tracker software I run on wss://tracker.webtorrent.dev is aquatic-ws. The Invalid request response is caused by the default value of AnnounceRequest's Left being -1.

In WebTorrent, when metadata has not been determined, a left of null is sent as the default value.

Aquatic handles parsing the left field as an Option<usize>, effectively allowing either null, a uint32 or uint64 depending on the architecture, and can't be negative, which is why the request fails to be deserialized.

Note: The -1 value does not break bittorrent-tracker, as no validation is performed on left, and OpenWebTorrent parses this as an int64_t from what I can see.

When testing this locally, making Left an *int64 and correcting -1 to nil causes the request to be marshalled as null, fixing the issue and allowing communication with the tracker.

I'm not proficient enough in Go to submit this as a PR, but ensuring an unknown left is null and not -1 fixes this and matches WebTorrent's behaviour.

@anacrolix
Copy link
Owner

Thanks very much!

@anacrolix anacrolix reopened this Nov 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants