Issues with --bind 0.0.0.0 and OneDrive getting eTag mismatch when using IPv6

Suspected Bug
1

What is the problem you are having with rclone?

I suspect there's a problem with the flag --bind when using --bind 0.0.0.0 to bind to IPv4 interface

Run the command 'rclone version' and share the full output of the command.

rclone version

rclone v1.63.1

  • os/version: debian 11.7 (64 bit)
  • os/kernel: 5.10.0-19-amd64 (x86_64)
  • os/type: linux
  • os/arch: amd64
  • go/version: go1.20.6
  • go/linking: static
  • go/tags: none

Which cloud storage system are you using? (eg Google Drive)

Microsoft OneDrive

The command you were trying to run (eg rclone copy /tmp remote:tmp)

rclone sync GDrive: OneDrive: --onedrive-no-versions --onedrive-chunk-size 160M --bind 0.0.0.0 --log-level INFO --log-file /home/sync/sync.log

The rclone config contents with secrets removed.

[OneDrive]                                                                                                                                                                                         type type = onedrive
client_id = xxxx
client_secret = xxxx
token = {"access_token":"xxxx"}
drive_id = xxx
drive_type = business
auth_url = https://login.microsoftonline.com/xxxx/oauth2/v2.0/authorize
token_url = https://login.microsoftonline.com/xxxx/oauth2/v2.0/token

[GDrive]
type = drive
client_id = xxxx
client_secret = xxxx
scope = drive
token = {"access_token":"xxxx"}
root_folder_id = xxxx
team_drive =

A log from the command with the -vv flag

Do not have it handy as it also depends on OeDrive failing with this error:
Failed to copy: resourceModified: The resource has changed since the caller last read it; usually an eTag mismatch

Upon troubleshooting it I saw it a couple of times I did it with -vv flag but unfortunately didn't capture the log entry, but saw the connection closed was with an IPv6 address and therefore started to test if IPv4 fixed it.

I tried --disable-http2 flag as well but that didn't help. I noticed that if I do --bind 0.0.0.0 it will still use IPv6, but if I use --bind "my real ipv4" I do get binded to IPv4 and the eTag mismatch goes away.

I'm trying to recreate the error and will share the logs once I do. But wanted to open the forum post in case other people are having this problem and might try the workaround that is working for me or if somebody might be able to give more information about this.

Thanks!

2

What is the issue/challenge/problem with it using IPV6?

3

My ISP sometimes has issues with IPv6 so I try to route most of my traffic via IPv4.

I also just got throttled and can see it was trying to use IPv6:

2023/08/30 13:16:36 DEBUG : pacer: low level retry 1/10 (error Put "https://xxxx.sharepoint.com/sites/Backup/_api/v2.0/drives/xxxx/items/xxxx/uploadSession?guid='xxxx'&overwrite=True&rename=False&dc=0&tempauth=xxxx": write tcp [xxxx:xxxx:xxx:xxxx::]:38995->[xxxx:xxxx:xxxx::x]:443: write: connection reset by peer)                                                                                                                                            2023/08/30 13:16:36 DEBUG : pacer: Rate limited, increasing sleep to 20ms                                                                                                                      2023/08/30 13:16:43 DEBUG : pacer: Reducing sleep to 15ms

I would expect it to be an IPv4 as the command I tested with was:

rclone sync GDrive: OneDrive: --onedrive-no-versions --onedrive-chunk-size 160M --bind 0.0.0.0 --log-level DEBUG --log-file /home/sync/sync.log -P
4

There is a known enhancement/bug/issue with this already:

as it's been around for a bit of time.

Not sure your issue is related to IPV6 but normal MS throttling as you are not limiting any TPS.

5

As I'm sure you are aware Microsoft has the most undocumented/random rate limits around. I have tried ---tpslimit 5 and still get randomly throttled, sometimes it's copying some big files it will close the connection and rate limit for 5 seconds up to 5 minutes.

During my analysis seems they throttle also based on tenant and not just account, as I have multiple accounts and got throttled heavy when multiple accounts were syncing at the same time. We have since adjusted so they run at different times and helped a lot.

Now, just to explain, my problem/question is why --bind 0.0.0.0 is not binding rclone to IPv4 as expected and to let people know that seems the eTag mismatch (which there seems to be a couple of forum posts around this) seems to be related to Microsoft and their IPv6 servers as it doesn't happen to me using IPv4 and only when using IPv6.

6

See pull request I linked above.

7

This is actually a bug in the go stdlib. Unfortunately the maintainers didn't agree.

I guess I could manually force the tcp4 proto if we see 0.0.0.0 that would be an easy workaround I think.

8

Thanks Nick. I guess I will update my scripts to bind to their respective IPv4 address.

I'll continue to monitor and see if I find any more details on the eTag mismatch using IPv6. I will force a couple of the scripts to use IPv6 and see if they get them while IPv4 do not and report back.

9

The idea of using 0.0.0.0 to force IPv4 wasn't very difficult to implement.

Please give this a go

You can use --bind 0.0.0.0 to force rclone to use IPv4 addresses and --bind ::0 to force rclone to use IPv6 addresses.

v1.64.0-beta.7296.ad204d0dc.fix-bind on branch fix-bind (uploaded in 15-30 mins)

1 Like
10

Hey Nick, been testing and so far seems to be working fine. Amazing work as always, thanks!

11

Thank you for testing :slight_smile:

I've merged this to master now which means it will be in the latest beta in 15-30 minutes and released in v1.64

1 Like
12

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.