web-dev-qa-db-ja.com

NanoPi M4-RK3399:Apache2 + SSL:大量のダウンロードがハングする

Debian 9(NanoPi M4のarmbian)で実行されているApache2のまったく新しいセットアップがあります。 HTTPS経由で大きなファイルをダウンロードしようとするまで、すべて正常に動作します。小さなファイルは正常にダウンロードされますが、大きなファイルはある時点でランダムに失敗するようです。 プレーンHTTPではこの問題を再現できませんwgetの例(ブラウザーでの同じ動作):

wget https://xyz---/test.bin --no-check-certificate
--2019-01-13 18:22:22--  https://xyz---/test.bin
Resolving xyz--- (xyz---)... 85.241.xxx.xxx
Connecting to xyz--- (xyz---)|85.241.xxx.xxx|:443... connected.
WARNING: cannot verify xyz---'s certificate, issued by 'CN=Let\'s Encrypt Authority X3,O=Let\'s Encrypt,C=US':
  Unable to locally verify the issuer's authority.
HTTP request sent, awaiting response... 200 OK
Length: 1073741824 (1,0G) [application/octet-stream]
Saving to: 'test.bin.2'

test.bin.2                      39%[==================>                               ] 403,66M  11,6MB/s    eta 54s

403,66Mに達するまでは正常にダウンロードされていましたが、この時点以降は何も起こりませんでした。サーバー側(error.log)私はこれを取得します:

ssl_engine_io.c(2135): [client 85.243.xxx.xxx:59904] OpenSSL: write 16413/16413 bytes to BIO#5588cd8c50 [mem: 5588a87c23] (BIO dump follows)
core_filters.c(525): [client 85.243.xxx.xxx:59904] core_output_filter: flushing because of THRESHOLD_MAX_BUFFER
core_filters.c(547): (70007)The timeout specified has expired: [client 85.243.xxx.xxx:59904] core_output_filter: writing data to the network
ssl_engine_io.c(2144): [client 85.243.xxx.xxx:59904] OpenSSL: I/O error, 16413 bytes expected to write on BIO#5588cd8c50 [mem: 5588a87c23]
(70007)The timeout specified has expired: [client 85.243.xxx.xxx:59904] AH01993: SSL output filter write failed.

core_output_filter: flushing because of THRESHOLD_MAX_BUFFERを実行しているようですが、それ以外は何も起こりません。時々私はこのエラーにも気づきました:

ssl_engine_io.c(2135): [client 95.239.xxx.xxx:9937] OpenSSL: write 45/45 bytes to BIO#55bd9e23e0 [mem: 55bd9ec213] (BIO dump follows)
ssl_engine_io.c(2144): [client 95.239.xxx.xxx:9937] OpenSSL: I/O error, 5 bytes expected to read on BIO#55bd9e9d80 [mem: 55bd9ec213]

このリクエストを処理するVHostの構成は次のとおりです。

<VirtualHost *:443>
    ServerName xyz---
    ServerAdmin tcb13---
    DocumentRoot /test
    ErrorLog /test/error.log
    CustomLog /test/access.log combined

    SSLEngine on
    SSLCertificateFile /mnt/SU1/letsencrypt/config/live/xyz---/fullchain.pem
    SSLCertificateKeyFile /mnt/SU1/letsencrypt/config/live/xyz---/privkey.pem
    Header always set Strict-Transport-Security "max-age=15768000"

    LogLevel trace6
</VirtualHost>

これはネットワーク関連の問題ではないと確信しています。理由は次のとおりです。

  1. SSLが有効になっている場合にのみ発生します。SSL以外のvhostでは、問題なくダウンロードできます。
  2. 他のプロトコル(FTPおよびSCP)は、同じテストファイルをダウンロードするのに問題なく機能します。
  3. Iperf3でネットワークをテストしている間は問題ありません。

一部のシステム情報

lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 9.6 (stretch)
Release:        9.6
Codename:       stretch

uname -a
Linux testxyz 4.4.162-rk3399 #41 SMP Fri Oct 26 14:03:47 CEST 2018 aarch64 GNU/Linux

Apache2ctl -V | grep -i "Server version"
Server version: Apache/2.4.25 (Debian)
root@testxyz:~# dpkg -l |grep Apache2
ii  Apache2                         2.4.25-3+deb9u6                                       arm64        Apache HTTP Server
ii  Apache2-bin                     2.4.25-3+deb9u6                                       arm64        Apache HTTP Server (modules and other binary files)
ii  Apache2-data                    2.4.25-3+deb9u6                                       all          Apache HTTP Server (common files)
ii  Apache2-utils                   2.4.25-3+deb9u6                                       arm64        Apache HTTP Server (utility programs for web servers)
ii  libapache2-mod-php7.3           7.3.0-2+0~20181217092659.24+stretch~1.gbp54e52f       arm64        server-side, HTML-embedded scripting language (Apache 2 module)

どうすればこれを修正できますか?ありがとうございました。

2
TCB13

このissue統合イーサネットおよびRK3399 CPUの既知の問題に関連していることがわかりました。 USB 3-イーサネットアダプタを使用すると、この問題は発生しません。

RK3399のようなボードでは、再送信とリセットエラーを回避するために、TCP/UDPオフロードを無効にする必要があります。これはすでにAyufanによってRock64とRockPro64Rootfsに実装されており、DietPiもこれを必要としています。

これに対する簡単な修正は、オフロードを無効にすることです。

ethtool -K eth0 rx off tx off

後でethtool --show-offload eth0を使用してオフロードステータスを確認できます。オフロード機能を無効にした後、報告された問題はもうありません。

再起動後も存続するため(およびネットワークの再起動)/etc/network/if-up.d/disable-offloadに次のようなスクリプトを作成できます。

#!/bin/bash
/sbin/ethtool -K eth0 rx off tx off

(ファイルに.shという名前を付けないでください。また、このファイルもchmod + xにしてください)

2
TCB13