HylaFAXがRunning and idleなのに受信できない――T.30 T1 timeoutの原因を追った記録

HylaFAXの構築で最も時間がかかったのは、Web画面でもAI連携でもありません。

既存番号の回線をそのまま使える構成にしても、モデムとHylaFAXの通信条件が合わなければ受信は成立しません。

FAX通信そのものを安定させることでした。

モデムは認識され、faxstat -sでは次のように表示されます。

HylaFAX scheduler on debian: Running
Modem ttyS0 (+81.957.XXXXXX): Running and idle

別のFAX機から電話をかけると、モデムは着信へ応答します。

それでも、原稿は受信できませんでした。

発生していたログ

受信ログは、概ね次の流れでした。

ANSWER: FAX CONNECTION
RECV FAX: begin
AT+FRH=3
MODEM <Empty line>
No sender protocol (T.30 T1 timeout)

電話回線へ応答し、「FAX CONNECTION」までは進んでいます。

しかし、相手側のFAX機とT.30手順を開始する段階で、期待するデータが返らずタイムアウトしていました。

「待機正常」と「通信成功」は別物

Running and idleという表示を見ると、設定は終わったように感じます。

実際には、確認できているのは次の範囲です。

• HylaFAXのスケジューラが動いている
• faxgettyがモデムを開けている
• モデムへ初期化コマンドを送れる
• モデムが待機状態になっている

FAX通信が成功するには、さらに次の条件が必要です。

• FAX Classの選択が正しい
• 端末とモデム間の通信速度が適切
• フロー制御がモデム設定と一致している
• モデムの応答タイミングがHylaFAXと合っている
• 電話回線と相手機の条件でT.30通信が成立する

そのため、ステータス画面だけではなく、通信セッションのログを読む必要があります。

最初に疑ったこと

1. FAX Class

FAXモデムにはClass 1、Class 2、Class 2.0などがあります。

Class 1では、FAX通信手順の多くをHylaFAX側が制御します。Class 2系では、モデム側がより多くの処理を担当します。

ME5614D2の設定をClass 1系とClass 2系で試しましたが、今回の環境ではClass 1を中心に詰めた方が安定しました。

ModemType: Class1
Class1Cmd: AT+FCLASS=1

「モデムが対応しているClass」と「HylaFAXがそのモデムを安定して制御できるClass」は、必ずしも同じではありません。

2. シリアル通信速度

端末とモデム間のModemRateも変更して検証しました。

高速にすればよいわけではありません。FAX回線上の通信速度と、サーバーからモデムへ送るシリアル速度は別です。

今回の受信確認時は、次の設定を中心に使用しました。

ModemRate: 19200

3. フロー制御

ソフトウェアフロー制御のxonxoffと、ハードウェアフロー制御のrtsctsを検証しました。

最終的には、モデム初期化側のAT&K3と合わせ、RTS/CTSを使用しました。

ModemFlowControl: rtscts
ModemReadyCmds:   AT&K3S92=11

HylaFAX側だけを変更しても、モデム側のフロー制御設定と一致していなければ意味がありません。

編集した設定を、本当にfaxgettyが読んでいるか

今回、特に注意が必要だったのが設定ファイルの参照先です。

DebianのHylaFAXは、スプールディレクトリを中心に構成されています。環境によって、/etc/hylafax/と/var/spool/hylafax/etc/がシンボリックリンクやパッケージ固有の配置で結ばれています。

設定ファイルを編集したのに動作が変わらない場合は、次を確認します。

readlink -f /etc/hylafax/config.ttyS0
readlink -f /var/spool/hylafax/etc/config.ttyS0

sudo systemctl cat faxgetty@ttyS0.service
sudo systemctl restart faxgetty@ttyS0.service
sudo journalctl -u faxgetty@ttyS0.service -n 200 --no-pager

重要なのは、「編集したファイル」ではなく、「実行中のプロセスが読んだ設定」です。

設定変更後は、ログに出るモデム初期化コマンドを見て、期待したATコマンドが実際に送られているか確認します。

受信テストは層を分けて確認する

FAX受信を一つの処理として見ると、原因が分からなくなります。

私は次の層に分けて確認しました。

1. 電話回線：着信しているか
2. モデム：指定回数で応答しているか
3. faxgetty：受信セッションを開始しているか
4. T.30：相手側と制御信号を交換できているか
5. 受信ファイル：recvqにTIFFができているか
6. 取込処理：Webシステムへ登録されているか

例えば、FAX機から見れば送信失敗でも、HylaFAX側では電話に応答してログが作成されています。

逆に、通信とTIFF保存は成功しているのに、受信後フックや権限の問題でWeb画面へ出ないこともあります。

Caller IDとTSIは別問題だった

受信が成功した後、次に問題になったのが送信元番号の取得でした。

受信ログを確認すると、次のような状態がありました。

• HylaFAXの送信元番号欄が空
• データベースのsource_numberがNULL
• REMOTE TSIが空文字

これはWeb画面の表示ミスではありません。HylaFAXの受信時点で、番号を取得できていませんでした。

ME5614D2のCaller ID設定

モデムへ問い合わせると、Caller ID機能は対応していました。

AT+VCID?
0

AT+VCID=?
(0-2)

AT+VCID?が0だったため、Caller IDは無効でした。

有効化には、モデム初期化時に次のコマンドを追加します。

AT+VCID=1

ただし、ここでCallIDPatternを推測で設定するのは避けました。

モデムが実際にどの形式で番号を返すかをログで確認し、その形式に合わせて設定すべきだからです。

Caller ID対応と、HylaFAXが番号を保存できることは別です。まず実際のモデム出力を確認し、その後にパターンを設定します。

TSIが空になることもある

TSIは相手側FAX機が送信する識別情報です。

相手側の設定によっては、番号が登録されていなかったり、会社名だけだったり、空だったりします。

そのため、送信元判定をTSIだけに依存することはできません。

最終的なシステムでは、Caller ID、TSI、原稿内OCR、アドレス帳を組み合わせて扱うことにしました。

最終的に確認した状態

受信試験では、次を一つずつ確認しました。

• faxgetty@ttyS0.serviceがactive
• faxstat -sがRunning and idle
• 指定したリング回数でモデムが応答
• T.30通信が開始される
• recvqにTIFFが保存される
• 受信後フックが実行される
• Web受信箱へ登録される

どこまで成功したかを明確にすることで、通信問題とWebアプリ問題を分離できました。

トラブル時の確認順序

1. systemctl status faxgetty@ttyS0でサービスを確認する
2. faxstat -sでモデム状態を確認する
3. 着信時のjournalとHylaFAX通信ログを確認する
4. FAX Classとフロー制御を確認する
5. 実際に参照されているconfig.ttyS0を確認する
6. recvqにファイルができたか確認する
7. 受信後フックとWeb取込ログを確認する

一度に複数の設定を変えると、何が効いたのか分からなくなります。

変更前の設定を保存し、一項目ずつ変更して、同じ送信元からテストする方が結果を比較しやすくなります。

この記事で分かったことと、一般化できないこと

T.30 T1 timeoutは一つの原因だけで起きるエラーではありません。この記事で扱うのは、ME5614D2、Debian、今回の電話回線で行った切り分けです。別のモデムや回線では、同じ設定が正解になるとは限りません。

まとめ

HylaFAXでは、モデムが認識され、Running and idleになっていても、FAX通信が成功するとは限りません。

今回の問題では、FAX Class、通信速度、フロー制御、モデム初期化、設定ファイルの参照先、Caller ID、TSIを別々に確認する必要がありました。

特に重要だったのは、ステータス表示ではなく、通信ログと実際に作成された受信ファイルを見ることです。

次回は、受信できるようになったFAXを、FaxDispatchから自作Web管理画面へ取り込み、PDF化、メール転送、送信状態同期まで行った仕組みを紹介します。