From: steve@work.bellingham.wa.us
(Steve Wampler さんからの提言)
メーリングリストがあります。国際的な性格を持つもので、この ML では *英語* だけが使われています。de.alt de.alt.comm.mgetty のようなローカ ルなニュースグループに通じていますが、リストに参加するためには、 mgetty-request@muc.de 宛にメールを送ってください(リストは手動で管理さ れていますので、参加を尋ねる必要があるでしょう)。リストの多くの人のひ とりひとりにメールを送信するためには、mgetty@muc.de 宛にメールを送信し てください。mgetty@muc.de 宛に参加申込を送ってはいけません。多くの人が あなたに管理者へのメッセージのためには mgetty-request を使うようにと返 信するでしょうから。
mgetty@muc.de でのメールの量は週に１つ２つから日に１０程度ですが、開 発活動の動向にもよるでしょう。
mgetty や vgetty の誤動作のために質問があるなら、あなたのログファイ
ルの適切な部分を添付して下さい。ログファイルはいつも 6 のログレベルで
得られます。これらのログファイルのデフォルトのディレクトリは mgetty で
は /tmp/、vgetty では /var/log です。
From: gert@greenie.muc.de (Gert Doering)
受信フォーマット
生の (raw) の G3 データです ( CCITT 標準の T.4 により、1 次元圧縮された もの)。G3 は、GhostScript の "dfaxhigh" または "dfaxlow" ドライバある いは "pbm2g3" プログラムで作ることができます。("dfaxhigh" または "dfaxlow" ドライバは、sendfax + g3cat + g32pbm64 が認識もするけれど、 スキップもしてしまう 64 バイトヘッダーで G3 データを作ります。注意： "pbmplus" 配布物からの pbmtog3 プログラムは T.4 によって妥当な G3 デー タを作りません。正確にするべきで、ラインは 1728 ピクセルよりも短いと、 EOL コードの読み込みがミスされます。それを解決するために patches とい うディレクトリの pbmtog3.p1 でパッチします。 さらによいのは、あなたの ユーティリティを使うことです(パッチは私の pbm2g3 プログラムには *不用* です。パッチされていない pbmtog3 は、たぶん +FHNG:50 あるいは +FHNG:54 エラーコードを出すでしょう。
tiff-G3 データは使用しないでください。 tiff-G3 は、データそのものは コード化された G3 ですが、sendfax にとって必要でない面倒な解析が必要な TIFF ヘッダーの複雑な層に包まれています。TIFF ファイルをファックス送信 すると、sendfax が warning メッセージを出すことになり、恐らく、送信は 失敗になるでしょう。
送信フォーマット
mgetty が FAX_SPOOL_IN に置くファイルは、sendfax が送る現在の CCITT T.4 の raw G3 データと同じフォーマットです。それらを pbm に変換するた めに、g32pbm を使います。X window xwd フォーマットに変換するには、 contrib というディレクトリにある g3toxwd を使います。
ファイルが転送エラーなしに受信されるなら、さらに別のものに変換するこ となく受信したファックスを転送することができます。モデムのなかにはゼロ のビットを埋め込むものもあるので、 g3cat に通すことはいずれにしろお勧 めで、余分のものを取り除き、乱れたラインをきれいにします。
mgetty はなぜ動作中に任意のイメージファイル (TIFF のような) を変換し ないで、生の G3 ファックスファイルだけしか送信しないのですか。
Chris Lewis さんから
私が TIFF について理解していることは、TIFF はそれそのもののフォーマッ トに加えて、他のいくつかのフォーマットを含むことができるということです。 別の言い方をすると、少なくともある程度まで、TIFF は 簡単に別のフォーマッ トにマジックナンバーをつけている方法なので、TIFF を利用できるようにす るコンバータは複合フォーマットを扱うことができるのです。
あなたは確かに G3 を含む TIFF を持つことができます、そして、mgetty はそれを使うことでたくさんのトラブルを持ちたくないのです。しかし、これ は、もし含まれているものが G3 でないなら、mgetty はどうするか？という 質問をあなたに残しています。それを変換しなければなりません。mgetty の 変換速度は class II FAX の転送中断の時間にあわせることができないという 状況に遭遇し、あなたは電話をかけている時間を浪費してしまうことになりま す。受信でも同じことになります。実際のところ、受信あるいは送信するファ イルが G3 以外のものなら、mgetty はそのままの状態を維持できないという のが本当のところです。
別の観点からこのことを考えてみるなら、mgetty は転送プロトコルであり 実行ファイルであることを思いだすべきです。ソフトウェアを変換しません。 mgetty は G3 を読み書きする必要があり、それがすべてです。別のソフトウェ アに変換するのは他にまかせましょう。
さらに Gert Doering さんから
はい、TIFF は複合ファイルフォーマットで、それは非常に多種類のページ データのコード化の方法や、異なったバイトやビットの順序、ひとつのファイ ルで複数ページなどをサポートできます。TIFF は柔軟なフォーマットですが、 それを解析するのは複雑な作業です。
それに比べると、mgetty の g3 ファイルは生の G3 データです。ヘッダー がなく、フォーマットもなく、ファイルのなかから実際のページデータを見つ けるために翻訳コードを取り出す必要もありません。ファイルごとに１ページ であり、もっとも単純です。
TIFF を無視 ( 別のソフトウェアに TIFF 変換をまかせること)することは mgetty と sendfax を単純化し、ユーザインターフェイスをややこしくしませ ん。内部の動きをユーザから隠してしまう faxspool あるいは 同様なツール が使われている限り、すなわち、どのようなファックス端末装置がそのような データを望むかということになります。的確にやるべきです。TIFF サポート から離れれば、mgetty を *シンプル* にします。多くの UNIX プログラムは PBM を読み取ることができますし、G3 を pbm に変換するのはとても簡単でが、 私はまだよい * マルチページ * Tiff から PBM へのコンバータを見たことが ありません。
/dev/tty* 、発信用デバイスに /dev/cua* を使わないのですか。
[ Linux と SunOS を除く大部分の他の Unix 類では、mgetty は tty*
デバイス上に設定されるべきで、そうすると、cua* デバイスが完全に無視
されるはずです。]
From: "Theodore Y. Ts'o" <tytso@mit.edu>
/dev/ttySxx デバイスは完全な POSIX 対応の TTY デバイスです。
あなたが tty デバイスだけを使うように設定しているなら、
/dev/ttySxx を使うべきです。
/dev/cuaXX デバイスは ２つの点で /dev/ttySXX とは
違っています。まず最初に CLOCAL が設定されず、 O_NONBLOCK フラグがデバイスを
オープンするために与えられてなくとも、デバイスをオープンすることができる
ということです。このことは /dev/ttySxx デバイスをオープンするために
POSIXで 義務づけられている (POSIX-mandated ) インターフェースを使わない
プログラムを可能にします。( cu は callout を行い、SunOS に由来します。)
/dev/cuaXX が /dev/ttySXX と異なっている２つ目の点は、
それらが使用されていれば、単純化された kernel ベースでのロック機構を作る
という点です。もし /dev/ttySXX が複数のプロセスでオープンされたなら、
/dev/cuaXX をオープンしようとすると EAGAIN を返します。もし
/dev/cuaXX が複数のプロセスでオープンされたなら、
/dev/ttySXX をオープンしようとすると /dev/cuaXX が閉じられ、
carrier detect line が高くなるまで遮断されるということになります。
これは電話をかけるのにモデムを使っているユーザとログインのために回線 を聞く getty の間で単純なロックアウトをするということなので、たとえば ダイアルアウトと UUCP を使いたいユーザの場合、ダイアルアウトをするマル チタイプのプログラムとの間で調整が必要なら、デバイスは動作しません。
FSSTND が tty ロックファイルを使うために標準の協定を確立する以前に、
私は最初、 cuaXX/ttySXX のロックアウトの機構を実行しました。 現在はそ
の協定があるので、ユーザは tty ロックファイルを使うべきで、
/dev/cuaXX を使う必要はありません。/dev/cuaXX
がまだなくならないひとつの理由は互換性の問題です。
- Ted
[SunOS では、すべては次のように cua* を使うべきです]
From: Gert Doering <gert@muc.de>
２つのデバイス体系は、同時に同じ物理的デバイスにアクセスするマルチプ ロセスを防ぐようになっています。mgetty は O_NDELAY でポートをオープン するので、kernel は tty* 上(mgetty)のプロセスを見て、cua* (uucico、cu など) 上にオープンするのを防ぎます。だから、両方のプログラムに対して同じ デバイス を使わなくてはいけないのです。SunOS ではそれは cua* です。
From: gert@greenie.muc.de
Q: ページを送信した後、+FHNG:50 や +FHNG:54 というエラーコードが出ます。 時々 "page bad, retrain requested" と言われ、そのページを再送します。
A: このエラーは、お使いの端末がページデータを送っている間に、２つのマ シンの間で故障があることを意味しています。+FHNG:50 あるいは +FHNG:54 の場合、おそらく一方の端末がハングアップしているか(そうなるとあなたの モデムは別のページをまったく送ることが出来なくなります)、別の場合だと、 受信機はページにあるデータが不適当であると場合です。
このようになる最も普通の理由は、pbmplus 配布物に由来する pbmtog3 の コピーを使ったということです。それは私のパッチには含まれていません( pbmtog3 プログラムはページヘッダーを必要とします。faxspool にそれぞれ のページの先頭部分が置かれています)。
そうでないなら、フローコントロールの問題か、とてもノイズが多い回線を 使っているというような理由です。受信機と連絡を取り、そのページがちゃん と見えるかどうか、回線に故障がないかどうか、その他関連することを見つけ ましょう。エラーがなければ、フロー制御の設定を見直しましょう。
その他のことにエラーがなければ、 pbmtog3 の 私家版をお使いなのでしょ う (pbm2g3 と言われるもの、あるいは pbmplus のパッチされた版です)。そう ならばモデムのなかで何か壊れたものがあり、私にはわかりません。あなたの ROM バージョンをアップグレードした方がいいでしょう。
Q: ファックスを受信している時、+FCON というメッセージが記録されます。 mgetty は "ファックス受信を開始します" と告げます、fax_wait_for(OK) と なりますが、記録はめちゃくちゃになり、timeout になって数分後に切断して しまいます。
A: あなたはたぶんホストに +FCON を送った後19200 bps にボーレートを切替
えるモデムを使っていて、正常に動作するポート速度が別にあるのでしょう。
policy.h の FAX_RECEIVE_SWITCHBD が定義されているかどうかを
チェックし、それを定義します (もしモデムが速度を変更しないなら、
その設定はできているので、効果は同じになります)。さらによい方法は、
mgetty.config で、runtime を設定することで、switchbd に <nnn>
のエントリーを加えることです。
Q: 私は policy.h で変更したものを保存しましたが、何も変わりません。
A: あなたはたぶん /usr/local/bin/mgetty に mgetty の古い版を
インストールしたのでしょう。そして /etc/init? からこれを呼び出して
いるのではないでしょうか。新しい版では /usr/local/sbin/mgetty
にインストールされます。あなたが コンパイルした mgetty と
/etc/inittab にリストされる mgetty についてタイムスタンプを
チェックしてください。
Q: 私が受信するファックスの半分はあまりに短いのですが、まるですべての second pixcel line をミスしているように見えます。
A: はい、それらはたぶん不足しているのでしょう。fine 解像度 (204x196 dpi)の代わりに、普通の解像度 (204x98 dpi) で受信されています。 ファイルネームを見るとわかります。ff* で始まっているものは fine で、fn* で始まっているものは、ノーマルの解像度です。normal 解像度のものを適当な比率に 拡大するには g32pbm -stretch fn... を使います。
Q: login が "utmp エントリーがありません" と言われます。
A: utmp 部分でうまくいっていないのでしょう。たぶん、login.config
ファイルの設定で /bin/login を呼び出すエントリーに関する utmp 部分で、
- が書かれてないのでしょう。別の理由は、/etc/init
(Linux のユーザだけに該当しますが) がうまく行っていないか、あるいは
/etc/utmp ファイルが損なわれているのでしょう。このような場合は、
マシンをリブートさせます。
Q: mgetty が動作中に私がダイアルアウトをすると、"CONNECT" しないだけでなく、 "+FCO"、 "+FTI:"、 "+FHS:20" となります。
A: mgetty での 2.0 の実行に伴う問題です。すなわち、mgetty が動作してい る間、モデムは "AT+FCLASS=2.0" モードとなり、リモート側でファックスと接 続するように期待します。(class 2 で われわれは、 +FCLASS=0;+FAA=1 に設 定することでこれを回避しましたが、2.0 ではなく、class 2 ではモデム応答 をするでしょう[さらにテストする課題です])。
解決方法：ダイアルアウトするプログラムで、"AT+FCLASS=0" でモデムを初期 化します。たぶん、モデムリセットコマンド (ATZ) でもいいでしょう。
Q: mgetty が始動する時たびに tty デバイスのパーミッションが変更されます。
ダイアルアウトできるように "chmod +w /dev/ttySx" をしなければなりま
せん。
A: それはバグではありません。それが仕様です。あなたはあなたのマシンを
誰でもがダイアルアウト (あなたが払う電話代を考慮して！) できるように望ん
ではいけません。それはセキュリティの問題です。あなたが誰に対してでもダ
イアルアウトを許したいなら、policy.h で
#define FILE_MODE 0666 にします。それはお勧めではありません。
特定のグループにアクセス権を与え、そしてこのグループにダイアルアウトできる
ユーザを置きます。
Q: 私は Linux システムを使っており、/dev/cua1 (mgetty は
/dev/ttyS1 で動いています) でダイアルアウトをしようとすると、
"device busy" (EBUSY) と表示されます。
A: ダイアルインとダイアルアウトには同じデバイスを使いましょう(常時！)
Linux では、/dev/ttySx を使い、SunOS と *BSD では
/dev/cuax を使います。
Q: "gs -sDEVICE=dfaxhigh ..." でファックスファイルを作成し、それを
sendfax で送信すれば、すべてはうまくいきます。"faxspool" を通すと、受
信者側ではエラーになります。"g3cat" プログラムが壊れているのでしょうか。
A: g3cat には問題はありません。本当の問題は "pbmtog3" にあって、インス
トールされた pbmplus 配布物から pbmtog3 を持っているのだと思います。こ
のプログラムは * 壊れて * います。パッチは mgetty/patches/pbmtog3.p
にあります。つまり、pbmtog3 は適当な T.4/G3 ファックスデータを作りません。
したがって、ファックスを受信するマシンは損なわれた行(ページヘッダー)の
あるファックスを受け取ってしまうのでしょう。pbmtog3 にパッチをあてるか、
mgetty の pbm2g3 を使ってください。そのほうがより早く解決するでしょう。
Q: mgetty は FidoNet の電話を受け付けません。ログは次のようになります。
10/30 01:54:54 ##### data dev=ttyS1, pid=3401, caller=none,
conn='38400/V32b 14400/V42b', name='', cmd='/bin/login',
user='**EMSI_INQC816**EMSI_INQC816q.'
10/30 05:31:03 ##### data dev=ttyS1, pid=7238, caller=none,
conn='38400/ZyX 16800/V42b', name='', cmd='/bin/login', user='q.q.q.'
A: -DFIDO を定義して mgetty をコンパイルしましたか。そのようになってい
ないのではないでしょうか。-DFIDO が設定されていないと、mgetty は fido
を判別できません。
Q: バイナリーロックファイルを使うプログラムと ASCII ロックファイルを使う プログラムがあります。mgetty はなぜエラーを出すのでしょうか。両方を 認識することはできないのですか
A: mgetty はシステムのコンフィグレーションが正しくないというエラーを出 すでしょう。このようなエラーメッセージというのは、そのサイト上での *厳 しいコンフィグレーションエラー* を警告してシステム管理者を援助するた めにあるのです。すべてのプログラムが両方のロックタイプを理解できるな ら、そのメッセージがおかしいことになるでしょう。しかし、kermit はいつ も ascii ロックを無視し、uucico は binary ロックを無視するので、状況は * 高度な * エラー状態になるので、システム管理者はこれを見なければなり ません。ロックファイルのタイプがすべて一致するように、モデムを使用する アプリケーションを再コンパイルしてください。
Q: モデムと私は１本の電話回線を使っています。私が電話を取ると、 モデムが私に答えてしまいます。どのようにしたら megetty に取らせることができ ますか。
A: mgetty に SIGUSR1 の信号を送ります。そうすれば、mgetty が電話に応答 します。
Q. １ページしかファックスを送ることができません。 その後はエラーになってしまいます。
A. このようなログがあるでしょう。
> 03/22 19:15:58 yS1 fax_wait_for: string 'OK'** found **
> 03/22 19:15:58 yS1 fax_send: 'AT+FET=0'
> 03/22 19:15:58 yS1 fax_wait_for(OK)
> 03/22 19:15:58 yS1 fax_read_byte: read returned 0: Unknown error
> 03/22 19:15:58 yS1 fax_get_line: cannot read byte, return: Unknown error
> 03/22 19:15:58 ##### failed transmitting f1.g3: +FHS:-4, time=55s
policy.h で FAX_SEND_IGNORE_CARRIER を定義します。
そしてバイナリを再コンパイルします。 ページごとに DCD line を落としてしまう
モデムがあります。あるいは、コンフィグファイルで ''
ignore-carrier true''を定義します。
Q: mgetty のログファイルに、 "WARING 警告: DSR が off です - モデムがオフになっているか、 ケーブルがよくないのでは？ " というメッセージがずっと記録されるのですが。
A: こういうメッセージがあるなら、それは基本的に mgetty は dsr (data set ready) の状態になっていないということです。ケーブルが悪いか、Solaris で mgetty を使っているからです。Solaris は dsr 状態にできません。mgetty を違ったプラットフォームで動かしているなら、ケーブルあるいはモデムの設 定をチェックした方がいいでしょう。
From: Gert Doering <gert@greenie.muc.de>
"無効な"ポストスクリプトを作るプログラムのリストは次のものです。 (Goastscript に不適切なラインの幅で G3 ファイルを作る原因になり、 sendfax に失敗させる原因になります)。
Gert Doering wrote on Sun, 22 Dec 1996 00:26:55 +0100 in message <m0vbaoh-0004B5C@greenie.muc.de>:
おもしろいことに、今日、私は dvipsk 5.58f を試してみました。それはこ のような良くない "setpagedevice" のどんなコマンドも出しません。このよ うな結果から、出来上がったポストスクリプトは正しいページサイズを作りま す。たぶん dvips プログラムを最新のものにアップグレードすれば解決する でしょう。
サポートされている *正確な* 紙のサイズが何なのかを *ghostscript* に 伝えてやる必要があります。(A4 の場合 --- "gs -sPAPERSIZE=a4" と明記す ることで、 dvips が "a4" も同様に使えるようになるのを確かめないといけ ません。
たとえ十分ではないとしても( 違ったプログラムで違った紙サイズの間で不 思議な相互作用があることもあります)、G3 ファイルを "g3cat" (mgetty 0.99 から、96 年以降の版) あるいは "g32pbm badfile.g3 | pbm2g3 >goodfile.g3" で作成している人もあります。後者は明らかに助けになります。
From: felix@escape.vsse.in-berlin.de
ファームウェアを更新したら、モデムをフルリセットします。この件は ZyXEL のドイツ語版マニュアルには書いてありませんが (英語には記述されて ますか？)、いずれにせよリセットしてください。
tcsetattr failed: I/O error" というメッセージが
出るのですがなぜですか。
From: gert@greenie.muc.de
Q: 時々、たいていはユーザがログアウトした後に (すなわち、ハングアップす るかわりにユーザが exit と入力した場合)、mgetty のログファイルに次のよ うなメッセージが記録されます。
09/08 21:26:26 yS2 lowering DTR to reset Modem
09/08 21:26:27 yS2 tcsetattr failed: I/O error
そして、syslog には I/O error メッセージが記録されているのですが。
A: これは Linux と SunOS での特有の問題です。mgtty がスタートした時に、 すでにモデムがリモートと接続状態の場合には、mgetty は DTR を下げること によって (そして、DTR 切断が十分でないと +++ATH を送って) 強制的にハン グアップさせます。これはモデムに DCD (carrier detect) を下げさせること になります。残念なことに、これは Linux kernel においてセキュリティ機構 の誘引になります。その機構はデスクリプタを通じての、それ以降のアクセス を拒否します。これはよく知られたパスワードハック (詳細に説明したくはあ りませんが) を防ぐためです。
モデム初期化中に起こるエラーを告知するという問題について、mgetty は 単純にポートを再度オープンし、そして、モデムとポートをすべて再実行しま す。 なぜならエラーメッセージはミスしていることになり、出し続けますが、害 はありません (.......もう一度試してください)。
(訳注) file descriptor： デバイスファイルや通常ファイルに対して open 操作 などを行ったときにシステムから割り当てられる識別子です。
From: Klaus Lichtenwalder <Lichtenwalder@ACM.org>
mgetty はどんな時に回線上での制御をしているのですか。mgetty の 一生 はどんなものかを考えてみましょう。いつでも (たとえばシステムをブートす ると、init は 記述された run level を参照し、mgetty を始動します) コン トロールしなければならないデバイス上のロックファイルをチェックします。 もしロックファイルがないなら、モデムを初期化し、その回線上に待機します。 キャラクターが届くと、mgetty は読むことはできませんが、最初にロック ファイルをチェックします。
ロックファイルが存在すれば、mgetty はだれかある人やあるものがダイア ルアウトをしたいなら、定期的にロックファイルの存在をチェックします。ロッ クファイルが消失後、デバイスはフリーになり、mgetty は存在するだけにな ります。init によって再始動され、モデム回線は再初期化されます。
ロックファイルが存在しないと、モデムは RING を送ります。そこで、われ われは予期した言葉 ( = RING) をチェックし、われわれの answer_chat を送 ります。もしそれが ファックス電話(そしてモデムがファックスを受信するこ とができて、それらを受信できるようになっているなら)我々はページを得、 保存し、そして完了し、それから上述のように mgetty を再始動します。もし それがデータ接続電話 (私はいま DISTINGIVE_RING と Caller_ID のことは無 視していますが) なら、われわれはログインに進み、応答に対して待機します。 答えが読まれると、login.config ファイルとの対照をチェックし、適切なプ ログラムがmgetty によって実行状態になります。mgetty はその回線にはいな いということです。接続の終了後、他のプロセスが存在すれば、mgetty は init によって再始動します。
From: Gert Doering <gert@greenie.muc.de>
ユーザがモデムをハングさせ正常に logout しない時、mgetty はなぜユーザ シェルを kill しないのですか。 [Mod: あるいは簡単にクラッシュする]
mgetty がどうしてユーザシェルを kill できるでしょうか。ユーザがログ インしている間、mgetty は * 動作していない * のです。
kernel は DCD がモデムドロップ上にある時、SIGHUP シグナルを経由して シェルに合図します。そのとき、シェルは存在しますが、init は mgetty を 再始動します。不運にも、 BASH シェルは多くのバージョンで壊れ、SIGHUP シグナルを無視するので、exit しないというのがひとつの理由です。
別の理由はモデム設定(AT&C0)が不適当な場合です。モデムが起動するとき、 恐らく DCDラインを下げているか (モデムのマニュアルをチェックし てください) シリアルケーブルが正常 (テストするために別のケーブルと交換 してみてください) かを確かめてください。
From: Gert Doering <gert@greenie.muc.de>
自動で ppp 接続をするために /AutoPPP/ オプションを使っているなら、
who リストでユーザネームは表示しません。かわりに AutoPPP や ppp のよう
な何かが表示されます。解決方法： pppd にパッチをしなくてはいけません。
これは mgetty の問題ではなく、mgetty にパッチをすることで解決できませ
ん。pppd にパッチをしているなら、これをどのように動作させるかというこ
とです。lonig.config で pppd に login オプションを与えます。
login.config のなかの/AutoPPP/ に関する行の３つ目の項目を "-"に変更し
ます(例では a_ppp あるいは ppp となっています)。