Client requests indefinitely on storage write errors

[JockeyWang]

Resolution

See #889 (comment), and continue the discussion at #891

---

I am a qBittorrent user. To keep alive some torrents, I always keeps my qBittorrent online.
Recently, I found my upload stream reaches much higher than usual. Then I found some peers using github.com/anacrolix/torrent, and they request several torrents continously, brings upload stream hundreds times than torrents' itself.
In my opinion, this should be a bug on github.com/anacrolix/torrent, which leads to infinity request to peers.
Wish you can found it.

For example:
magnet:?xt=urn:btih:e7268b2b2a4c6457ba0c4e40f35b206a08b5cc39&dn=%5BNekomoe%20kissaten%5D%5BAyakashi%20Triangle%5D%5B06%5D%5B1080p%5D%5BCHS%5D.mp4&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce
In this torrent, some IP always request this.

--- Chinese Version, I am sorry that some words is beyond me. ----
我使用qBittorrent并长期保种。
最近我发现qBittorrent的上传流量明显高于平时，并且我发现有些使用github.com/anacrolix/torrent的用户在持续请求个别种子，产生了几百倍于其大小的上传流量。
我想github.com/anacrolix/torrent一定有BUG，使得用户持续对其它用户发起请求。
希望能尽快解决这个问题。

[Magma5]

Noticed some reddit posts about it, just wanted to post here for reference. I personally have also noticed this types of peer leeching from me infinitely, and the transferred data far exceeded the size of the torrent. Apparently it appears on many Anime torrents, both Chinese subs and from English sites. I know it might not be a problem with this library but rather some downstream user, but still wanted to report here as I'm not sure what kind of users are using this client.

Only a guess: It could be some type of shared IP/seedbox/debrid/cloud storage service, (for example 115 NetDisk or PikPak) using Go in the backend, and somehow misconfigured the client so it leeches forever but does not actually save any data or make any progress.

If it helps, the IP leeching from me is from 1.180.0.0/14

https://redd.it/192c0nt

https://redd.it/190ysgr

Chinese Explaination for OP：看起来有不少人遇到这个问题，我截个图汇报一下，不一定是这个客户端问题，猜测是某个离线下载服务部署出了问题，等更多人来汇报的话看看能不能解决吧

[anacrolix]

Thanks for the report. A few years ago there was a bug that could result in downloading continuously. I think your guesses about broken seedboxes or bad downstream clients are accurate. I'll check into specific details when I get time, cheers.

[slowlearnerLspeedup]

I already baned these names called anacrolix bt clients.
What waste of time. They just downloaded some files that sized only 2 or 3 GB, but I had to upload hundreds of times more than the original!!!
This is crazy.
Unbelievable!

[festoney8]

The same here. It consumed hundreds GB of my qbittorrent upload traffic.
I found that peer from ip route 1.180.0.0/14 and 36.102.0.0/16, that means possibly there is a distribution of torrent software with bug, or something more harmful.

[serfreeman1337]

I've taken a look at its traffic, and it seems like it requests already requested pieces.

Wireshark screenshots

[anacrolix]

I already baned these names called anacrolix bt clients. What waste of time. They just downloaded some files that sized only 2 or 3 GB, but I had to upload hundreds of times more than the original!!! This is crazy. Unbelievable!

Please do not ban entire clients (at least include a version in case it's related to a bug). It's heavy handed, and easy to spoof. It's easy for users and developers to react by not revealing their true client names and versions and the situation is worse for everyone. Ban IP addresses that have bad actors, and if you do ban a client, be sure to include the full client string.

[anacrolix]

Just to clarify, the bug I mentioned I believe was when the user ran out of disk space, it would retry indefinitely in a loop. It reports an error message but if the user has spun up a client and is not paying attention it could cause this. It was fixed a long time ago if it is indeed that issue.

The client name that people are reporting is concerning. It doesn't appear to be a downstream client, they seem to be running the provided demo utility. The code that derives this is

torrent/version/version.go

Line 42 in 7308c68

DefaultExtendedHandshakeClientVersion = fmt.Sprintf(

. I welcome anyone else's insight here.

[WhiteCoffee9834]

该问题我也有遇到,我已经屏蔽了1.180.X.X这个IP段

[slowlearnerLspeedup]

I already baned these names called anacrolix bt clients. What waste of time. They just downloaded some files that sized only 2 or 3 GB, but I had to upload hundreds of times more than the original!!! This is crazy. Unbelievable!

Please do not ban entire clients (at least include a version in case it's related to a bug). It's heavy handed, and easy to spoof. It's easy for users and developers to react by not revealing their true client names and versions and the situation is worse for everyone. Ban IP addresses that have bad actors, and if you do ban a client, be sure to include the full client string.

I will unblock them as soon as this bug gets fixed.

[anacrolix]

For example:
magnet:?xt=urn:btih:e7268b2b2a4c6457ba0c4e40f35b206a08b5cc39&dn=%5BNekomoe%20kissaten%5D%5BAyakashi%20Triangle%5D%5B06%5D%5B1080p%5D%5BCHS%5D.mp4&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce
In this torrent, some IP always request this.

I didn't have any luck with this link. I did see a lot of peers in China but most of them disappeared quickly. Nobody wanted to download (qBitTorrent or anacrolix/torrent). I wonder if the peers in question are targeting users in specific regions.

[Seele-xier]

I've also encountered a similar issue. I use qBitTorrent, and it detected a client called anacrolix/torrent that kept downloading continuously, even completing over 400 downloads of the same file in one night.

我也遇到了类似的问题，我使用qBitTorrent，检测到有个名叫anacrolix/torrent的客户端一直在下载，甚至一晚上对同一个文件完整地下载了400多次。

[sugarkingdom]

same problem. some active resources:

1.180.25.246
magnet:?xt=urn:btih:79dacd1c361c4992d535a9e33e9ad1ad926d5049&dn=%5BLilith-Raws%5D%20Oshi%20no%20Ko%20-%2009%20%5BBaha%5D%5BWEB-DL%5D%5B1080p%5D%5BAVC%20AAC%5D%5BCHT%5D%5BMP4%5D.mp4&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Fopentracker.i2p.rocks%3A6969%2Fannounce&tr=udp%3A%2F%2Fopen.demonii.com%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A6969%2Fannounce&tr=http%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr=udp%3A%2F%2Fopen.stealth.si%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Fexodus.desync.com%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.auctor.tv%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.tiny-vps.com%3A6969%2Fannounce&tr=udp%3A%2F%2Fp4p.arenabg.com%3A1337%2Fannounce&tr=udp%3A%2F%2Fuploads.gamecoast.net%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker1.bt.moack.co.kr%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.theoks.net%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.skyts.net%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.moeking.me%3A6969%2Fannounce&tr=udp%3A%2F%2Fretracker01-msk-virt.corbina.net%3A80%2Fannounce&tr=udp%3A%2F%2Fopentracker.io%3A6969%2Fannounce&tr=udp%3A%2F%2Fopen.tracker.ink%3A6969%2Fannounce

1.180.24.227
magnet:?xt=urn:btih:18b7eac31fc650e5a30f88487dcde4037d052abc&dn=%5BLilith-Raws%5D%20Oshi%20no%20Ko%20-%2008%20%5BBaha%5D%5BWEB-DL%5D%5B1080p%5D%5BAVC%20AAC%5D%5BCHT%5D%5BMP4%5D.mp4&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Fopentracker.i2p.rocks%3A6969%2Fannounce&tr=udp%3A%2F%2Fopen.demonii.com%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A6969%2Fannounce&tr=http%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr=udp%3A%2F%2Fopen.stealth.si%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Fexodus.desync.com%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.auctor.tv%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.tiny-vps.com%3A6969%2Fannounce&tr=udp%3A%2F%2Fp4p.arenabg.com%3A1337%2Fannounce&tr=udp%3A%2F%2Fuploads.gamecoast.net%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker1.bt.moack.co.kr%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.theoks.net%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.skyts.net%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.moeking.me%3A6969%2Fannounce&tr=udp%3A%2F%2Fretracker01-msk-virt.corbina.net%3A80%2Fannounce&tr=udp%3A%2F%2Fopentracker.io%3A6969%2Fannounce&tr=udp%3A%2F%2Fopen.tracker.ink%3A6969%2Fannounce

[Simple-Tracker]

I plan to use this regular expression and block the relevant client if it matches. I applied an aggressive version matching because I wasn't quite sure what the next version would be.
If possible, I would like to know the specific highest version, this helps to precisely reduce the impact on users.
Hope this issue will be fixed soon ;)

Regex: "anacrolix/torrent v?([0-1].([0-9]|[0-3][0-9]).[0-9]?[0-9]?|unknown)"
Block version range: anacrolix/torrent unknown, anacrolix/torrent 1.0 to anacrolix/torrent 1.39.99
My search suggested it might be this commit: 8025d15

[tuxayo]

Bad news for anyone wanting to ban a specific version, I got a case of a client using the devel one.

And a previous comment also show this version: #889 (comment)

bugged peer ip is 1.180.25.97
my client is qbittorrent

[anacrolix]

@tuxayo I think it's fine to ban that exact string on your own torrent client installation (github.com/anacrolix/torrent (devel) (anacrolix/torrent unknown)). For the most part people developing on anacrolix/torrent won't be bothered (unless it's banned by default for other common clients which I test against). That string should also only matches the demo client, which again, shouldn't bother many users. It's still preferable to ban the IP range people are reporting from China however.

[festoney8]

The same here. It consumed hundreds GB of my qbittorrent upload traffic. I found that peer from ip route 1.180.0.0/14 and 36.102.0.0/16, that means possibly there is a distribution of torrent software with bug, or something more harmful.

Just ban single IP doesn't work, I recognized several different IP from 1.180.24.0/24.
So I banned IP range 1.180.24.0/24, 1.180.25.0/24, 36.102.218.0/24 in my client, it works pretty well these days.

[WhiteCoffee9834]

The same here. It consumed hundreds GB of my qbittorrent upload traffic. I found that peer from ip route 1.180.0.0/14 and 36.102.0.0/16, that means possibly there is a distribution of torrent software with bug, or something more harmful.

Just ban single IP doesn't work, I recognized several different IP from 1.180.24.0/24. So I banned IP range 1.180.24.0/24, 1.180.25.0/24, 36.102.218.0/24 in my client, it works pretty well these days.

请问在 qBittorrent Enhanced Edition 里面要怎么屏蔽 IP 段,虽然有过滤文件可以选择,但那个过滤文件不知道该如何编写

[RaySibay]

I encountered the same problem yesterday. It's crazy, when I found the problem, this bad client had downloaded more than 300GB data.
Recently, some Chinese ISP is using the ratio of upload flow to download traffic to detect PCDN, maybe it is related to this matter.

---

我遇到了相同的问题，当我发现问题时，这个客户端已经下载了超过300GB的数据。
最近中国ISP在利用上传流量与下载流量之比检测PCDN，也许是与这件事有关的黑产。

[JockeyWang]

Here are some IPs I encountered:
1.180.24.2
1.180.24.220
1.180.24.225
1.180.25.84
1.180.25.131
1.180.25.210
1.180.25.216
36.102.218.131
36.102.218.132
36.102.218.222
221.203.6.54
221.203.6.58
221.203.6.60
240e:918:8008:3::61
240e:918:8008:4::224
It is easy to see the IPv4 IPs are in 1.180.24.0/23, 36.102.218.0/24 and 221.203.6.0/24, I am still observing IPv6 IPs range, may be 240e:918:8008::0/48.
Mostly they request 2.3MB/s from my computer.
Moveover, how to write a rule to ban IPv6 range?

[festoney8]

The same here. It consumed hundreds GB of my qbittorrent upload traffic. I found that peer from ip route 1.180.0.0/14 and 36.102.0.0/16, that means possibly there is a distribution of torrent software with bug, or something more harmful.

Just ban single IP doesn't work, I recognized several different IP from 1.180.24.0/24. So I banned IP range 1.180.24.0/24, 1.180.25.0/24, 36.102.218.0/24 in my client, it works pretty well these days.

请问在 qBittorrent Enhanced Edition 里面要怎么屏蔽 IP 段,虽然有过滤文件可以选择,但那个过滤文件不知道该如何编写

Create a TXT file, write these lines, and rename it to ipfilter.dat, then choose it in qb

1.180.24.0-1.180.24.255
1.180.25.0-1.180.25.255
36.102.218.0-36.102.218.255

[anacrolix]

I've added a likely fix (bdcb6c9, on master) for errors during download that might be the cause of this problem for the bad peers people are seeing. It will be included in v1.53.3 and above.

Due to golang/go#50603, users running the cmd/torrent utility from source will always show github.com/anacrolix/torrent (devel) (anacrolix/torrent unknown) for their extended handshake client version. Is it possible to discriminate against clients based on their peer IDs instead? In this case I can bump -GT0003- for big protocol fixes like this.

If anyone is testing anacrolix/torrent for this issue, please try with the fix above. Unfortunately existing clones of anacrolix/torrent out there will need to be updated to include the fix, if you operate one of those, please give it a try.

[muzirinai]

The same here. It consumed hundreds GB of my qbittorrent upload traffic. I found that peer from ip route 1.180.0.0/14 and 36.102.0.0/16, that means possibly there is a distribution of torrent software with bug, or something more harmful.

Just ban single IP doesn't work, I recognized several different IP from 1.180.24.0/24. So I banned IP range 1.180.24.0/24, 1.180.25.0/24, 36.102.218.0/24 in my client, it works pretty well these days.

请问在 qBittorrent Enhanced Edition 里面要怎么屏蔽 IP 段,虽然有过滤文件可以选择,但那个过滤文件不知道该如何编写

Create a TXT file, write these lines, and rename it to ipfilter.dat, then choose it in qb

1.180.24.0-1.180.24.255
1.180.25.0-1.180.25.255
36.102.218.0-36.102.218.255

请问ipv6的屏蔽规则如何编写 May I ask how to write the blocking rules for IPv6

[tuxayo]

By any chance, does anyone know how to find which seedbox provider (or something like that) operates the clients at 1.180.24.0/24 & co? To tell them to upgrade, who knows what is their update schedule.

[Moredistant]

我也发现这个傻逼，我感觉这傻逼就是故意的，不可能这么久还没发现自己下载不完吧？月初就发现他了，我还以为是那个种子问题，我直接禁IP，禁完种子也删了。刚刚又看见这个傻逼在下家里蹲吸血鬼，上传流量都超过种子大小了，还在那里死劲下

[Dokupe999]

221.203.6.58:24958
221.203.6.60:4590
221.203.6.60:7753

[Moredistant]

I encountered the same problem yesterday. It's crazy, when I found the problem, this bad client had downloaded more than 300GB data. Recently, some Chinese ISP is using the ratio of upload flow to download traffic to detect PCDN, maybe it is related to this matter.

我遇到了相同的问题，当我发现问题时，这个客户端已经下载了超过300GB的数据。 最近中国ISP在利用上传流量与下载流量之比检测PCDN，也许是与这件事有关的黑产。

你这么一说，我就觉得应该是某些人因为宽带上传流量太大被运营商怀疑PCDN后清退，怀恨在心蓄意制造有BUG的客户端，想拉其他正常用户下水，让运营商乱封号

[WhiteCoffee9834]

I encountered the same problem yesterday. It's crazy, when I found the problem, this bad client had downloaded more than 300GB data. Recently, some Chinese ISP is using the ratio of upload flow to download traffic to detect PCDN, maybe it is related to this matter.
我遇到了相同的问题，当我发现问题时，这个客户端已经下载了超过300GB的数据。 最近中国ISP在利用上传流量与下载流量之比检测PCDN，也许是与这件事有关的黑产。

你这么一说，我就觉得应该是某些人因为宽带上传流量太大被运营商怀疑PCDN后清退，怀恨在心蓄意制造有BUG的客户端，想拉其他正常用户下水，让运营商乱封号

如果是这样的话,那这个issue就无解了
往坏的的方面想,对整个BT做种环境还会产生大的负面影响

[bordeauxlink]

我昨天应该也出现了类似的问题，当时瞄了眼没注意，很奇怪为什么还在下载
原来不是我一个人的问题

[Moredistant]

怀恨在心蓄意制造有BUG的客户端，想拉其他正常用户下水，让运营商乱封号

I encountered the same problem yesterday. It's crazy, when I found the problem, this bad client had downloaded more than 300GB data. Recently, some Chinese ISP is using the ratio of upload flow to download traffic to detect PCDN, maybe it is related to this matter.
我遇到了相同的问题，当我发现问题时，这个客户端已经下载了超过300GB的数据。 最近中国ISP在利用上传流量与下载流量之比检测PCDN，也许是与这件事有关的黑产。

你这么一说，我就觉得应该是某些人因为宽带上传流量太大被运营商怀疑PCDN后清退，怀恨在心蓄意制造有BUG的客户端，想拉其他正常用户下水，让运营商乱封号

如果是这样的话,那这个issue就无解了 往坏的的方面想,对整个BT做种环境还会产生大的负面影响

大概率就是这样了，因为这个行为已经持续超过一个星期了，就算是BUG也早该发现了吧。真特么坏种

[sorayuki]

221.203.6.58:24958 221.203.6.60:4590 221.203.6.60:7753

I'm here to append one

221.203.6.54

It's better to ban a range. The submask is 255.255.248.0. I dont' know whether to ban a /24 subnet or /21

1.180.24.0-1.180.24.255
1.180.25.0-1.180.25.255
36.102.218.0-36.102.218.255
221.203.6.1-221.203.6.255

[Simple-Tracker]

这些 IP 段到底是偶然还是必然是一个不可知问题.
至少, 就上面看到的 IP 段中, 有内蒙古的但也有辽宁的 IP 地址, 且来自不同运营商, 屏蔽客户端很方便, 但也不完全合理, 从汇报数据判断并解决也许不错.
就我而言, 我不太愿意相信屏蔽 IP 段是一个可持续的做法, 可以说这只能是一个临时做法, 因为你无法保证这种客户端不会越来越多.
由于此问题, 最近有一些 qBittorrent 客户端屏蔽器已经更新来应对此问题. 不过除此之外, 你还可以使用 qBittorrent-Enhanced-Edition 解决此问题, 这是一个 qBittorrent 的分支版本, 其自带客户端屏蔽功能.
对了, 补充一下, 标题的 qBittorrent users 显然是有问题的, 因为不只是 qBittorrent 用户才看得到.

Whether these IP segments are accidental or inevitable is an unknowable question.
At least, as far as the IP segments seen above come from different regions (for the time being, China) and from different ISPs, blocking clients is very convenient, but it is not entirely reasonable. A better solution is to look for unreasonable data issues from the client data itself and automatically determine and resolve them.

As far as I'm concerned, I'm not willing to believe that blocking IP segments is a sustainable approach. It can be said that this can only be a temporary approach, because you can't guarantee that there won't be more and more such clients.

As this issue arises, some qbittorrent client blockers have recently been updated to address this issue either by name or mechanism. Alternatively, you can also try qBittorrent-Enhanced-Edition, which is a forked version of qbittorrent.

[1265578519]

有复现

在工信部官网查询ip地址信息，只能查到是家庭宽带，并不是服务器使用的，没有什么有参考价值的信息
http://ipwhois.cnnic.cn/index.jsp

要是有心人可以通过ip预留的电话去滥用报告试试，应该能查出来是谁在乱搞

不过我刚刚测试了，百度网盘这几天确实重新开放了离线下载，实测不是百度网盘，百度网盘的ip地址是 113.24.224.46 端口2002，不要错怪百度了

[tuxayo]

@Simple-Tracker

As far as I'm concerned, I'm not willing to believe that blocking IP segments is a sustainable approach. It can be said that this can only be a temporary approach, because you can't guarantee that there won't be more and more such clients.

There are chances the issue will be fix: #889 (comment)

So not reason to have more and more problematic peers.

[karuboniru]

要是有心人可以通过ip预留的电话去滥用报告试试，应该能查出来是谁在乱搞

The contact information from Whois usually points to ISP or something like that. So I won't expect contacting them will do any help.

While I believe this can just cases where people left some unattended downloader that happens to encounter the bug mentioned here. (Believe me, it is not until I came across this issue that I noticed those leechers are taking ~40MB/s bandwidth from me)

By any chance, does anyone know how to find which seedbox provider (or something like that) operates the clients at 1.180.24.0/24 & co? To tell them to upgrade, who knows what is their update schedule.

Those ip addresses are supposed to be located in Mainland China, where not many seed box services are available.

Whether these IP segments are accidental or inevitable is an unknowable question.

As far as I'm concerned, I'm not willing to believe that blocking IP segments is a sustainable approach. It can be said that this can only be a temporary approach, because you can't guarantee that there won't be more and more such clients.

Well, if this is just due to the bug just got fixed here, appearence of new such leechers won't be a concern. Those misbehaving client should restore as they are rolling to newer release of this library.

While if this is some kind of deliberate attack to the bittorrent network, banning ip range would be the best approach until bittorrent software authors implement a way to address such malicious behavior. Since it is very easy to spoof things like client id, if you have the intension.

[anacrolix]

I encountered the same problem yesterday. It's crazy, when I found the problem, this bad client had downloaded more than 300GB data. Recently, some Chinese ISP is using the ratio of upload flow to download traffic to detect PCDN, maybe it is related to this matter.
我遇到了相同的问题，当我发现问题时，这个客户端已经下载了超过300GB的数据。 最近中国ISP在利用上传流量与下载流量之比检测PCDN，也许是与这件事有关的黑产。

你这么一说，我就觉得应该是某些人因为宽带上传流量太大被运营商怀疑PCDN后清退，怀恨在心蓄意制造有BUG的客户端，想拉其他正常用户下水，让运营商乱封号

@Moredistant it may be a genuine bug. I do know that anacrolix/torrent is popular in China, but I don't know why a ton of servers there would be running the demo client, that's odd.

[anacrolix]

Per #889 (comment), please upgrade to master if you are using anacrolix/torrent, by using go get github.com/anacrolix/torrent@master, or pulling master in your git repo. Let me know if the issue is resolved.

If you are a BitTorrent user affected by this issue, please do one or more of these things, in descending order of preference:

1. Block the client version string github.com/anacrolix/torrent (devel) (anacrolix/torrent unknown).
2. Ban the IP subnets mentioned above.
3. As a last resort if you can't do 1.: Block the -GT0003- peer ID. Do not do this permanently for a client implementation as it will block a lot of existing legitimate users. I will upgrade the peer ID when I have confirmed this fix or release the next version of anacrolix/torrent.

I have created a discussion to track further information so this issue can focus on the fixes to anacrolix/torrent.

[anacrolix]

The issue relating to infinite requests on storage write errors is resolved. The ongoing leeching issue by bad peers is in the discussion. If anacrolix/torrent adds defenses against that behaviour (assuming it doesn't already) it will be a separate issue.

[anacrolix]

Please keep discussion of workarounds for other clients to #891.