とあるコードの内部で32bit floatなPCMを扱っているのに対し、これを扱えないsndioからどうアプローチしたもんかな…と、テストデータを作ってsoxに食わせて変換前後のデータを見ていました。結局のところデータはsignedを前提にして、16bitなら32768で割れ、ってことなんですね（8bitの場合は128で割る、24bitの場合は8388608で割る、32bitの場合は2147483648で割る、でいいのかな？）。

イマドキのFPUなら8bit/16bit/32bitでの計算速度は変わらないはずなのでいちいち8bitに落とす理由はないし、32bit/24bitまで振らなくても（通信系のアプリケーションなので極端な高音質は求められることはなくデータの入力元/出力先は16bitのデバイスが大半である以上）16bitあれば十分と判断しています。どこかの時点でsndioと実際に組み合わせて動かせたら良いのですが…

JG1UAA（移動しない局）の再開局は受理され、然るべき手数料も納付したのでそのうち変更申請を書いてJumboSPOTも再び使えるようにしたいですねえ。55.3kg(22:35)

netcatがあれば試せるので特にコードを書く必要は無さそうですねと04-Aug-2024に書いているとはいえ、作っちゃったんですよね…超漢字の上でLPD→rawに変換するやつ。あの時にこれがあれば良かったんじゃないの、というモヤモヤを引きずったままというのも精神衛生上良くないですから。

RFC1179を見るに、command 02 (Receive a printer job)からsubcommandの受け付けに移行した後はTCP/IPのコネクションを切断するまでの間はsubcommandの受け付けを継続するという動作になっているので、状態遷移とリソースの確保/解放はちょっと面倒です。適当なフラグで状態管理を行うか、C++で書いて例外を使う方が良いのか悩んではみたものの、今回は今まで使ったことのないsetjmp()/longjmp()を使ってみることにしました。ほんとにこの使い方で良いのかなーという不安はあるので、単に動いたからokで終わらせるのではなくもう少し見直しが必要かもしれません。

あと、今回はディスクアクセスを行わずネットワークのみを使うものだったため、一つのコードでOpenBSD上でも超漢字でも動かせるようなものを書くという実験も行っています。ソケット周りを<btron/bsocket.h>が来ても良いようにso_なんとかでラップするだけかと思っていましたが、意外と違いがあるので簡単にはいきません。しかし一番引っかかったのはprintf("%lld %s\n", long longな変数, 文字列を示すchar *);で例外を吐いて落ちたことで、printf()は%lldを知らない（%ldなら知ってる）？…なんとなくそんな感じがします。

さて、これで超漢字はLPDだけでなくrawも喋れるようになったはずですが、喋れるようになったところで今使っているBrother MFC-J880Nには（プリンタイメージドライバが）対応しません。これは以前書いたPCL→GhostPCLによるPDF化で回避することになります。56.3kg(20:40)

lprもどき→CUPS-lpd→lpdもどきの処理はできるのですが、lprもどき→OpenBSD-lpd→CUPS-lpd→lpdもどきではできないという問題があります。tcpdumpのログを読むのも良いのですが、なんか疲れそうなのでpcap形式で記録したものをWiresharkに食わせてみることにしました。

CUPS-lpd側のLPD responseの後にOpenBSD-lpdがFINパケットを送って切断しており、これによりlpdもどきへ印刷ジョブが送られないようです。/var/log/syslogのCUPS-lpdに関する部分を抜粋すると、こうでしょうか。

2024-08-11T11:37:39.779901+09:00 emeraude systemd[1]: Started cups-lpd@12-192.168.0.141:515-192.168.0.111:649.service - CUPS LPD server (192.168.0.111:649).
2024-08-11T11:37:39.804955+09:00 emeraude cups-lpd[4007]: Connection from ::ffff:192.168.0.111 (IPv6 [v1.::ffff:192.168.0.111])
2024-08-11T11:37:39.805043+09:00 emeraude cups-lpd[4007]: Receive print job for test-framboise
2024-08-11T11:37:39.806845+09:00 emeraude cups-lpd[4007]: Closing connection
2024-08-11T11:37:39.807544+09:00 emeraude systemd[1]: cups-lpd@12-192.168.0.141:515-192.168.0.111:649.service: Main process exited, code=exited, status=1/FAILURE
2024-08-11T11:37:39.807739+09:00 emeraude systemd[1]: cups-lpd@12-192.168.0.141:515-192.168.0.111:649.service: Failed with result 'exit-code'.
     

lprもどきの代わりに超漢字からOpenBSD-lpd宛にジョブを投げると問題なく処理できることから、lprもどきに問題があるようです。ジョブの投げ方は超漢字と同じにしているため、違うところがあるとすると…CUPS-lpd宛にジョブを投げた際にTCP/IPのTIME_WAIT待ちを回避するためのSO_LINGERの設定ということで、これを削除することで動くようになりました（OpenBSD-lpdでは元々TIME_WAIT待ちは発生しません）。

TIME_WAITに対するSO_REUSEPORTやshutdown()の効果が無かったのでSO_LINGERを使ってみたのですが、安易に使うなということは確かそうです。55.8kg(04:30)

lpdもどきがあるなら、lprもどきも欲しいな、ということで作りました。おかげでlpdもどきのヘンなコードも一掃できました。

27-jul-2024の妙な（control fileが主張されているサイズより1byte多い）点については、RFC1179の理解不足でした。control file/data fileどちらとも、"Once all of the contents have been delivered, an octet of zero bits is sent as an indication that the file being sent is complete."ということで、データ転送が完了したことを示す0x00が付加されているだけでした。

26-Aug-2016頃に購入したBrother MFC-J880Nは今でも稼働していて、デバイスのweb pageを見たところ特にlprでジョブを投げられるようには見えなかったのですが…Nmapでポートスキャンをかけてみると80(http), 23(telnet), 21(ftp), 443(https), 631(ipp), 9100(raw), 515(lpd)が開いているようです。Windows上でファイルに出力したイメージデータをlprもどきで試しに投げてみたところ、印刷することができました。

そういえば8年前のプリンタはともかく、イマドキのプリンタだとPDFファイルを投げ込むと印刷してくれるのでしょうか？今のところMFC-J880Nが壊れる気配はないのでイマドキのプリンタに触れる機会は先のことになりそうですし、その時のお楽しみとして取っておきますけど。

折角なので、07-Mar-2005のHP DeskJet 5850で使っていたJetDirect(port 9100)が気になっていたので少し調べてみました。Bye CUPS: Printing with netcat(Aug-03-2021)を見るに、nc netlaser 9100 < sample.txtやnc 192.168.1.226 9100 < file.pdfで印刷できたということは…難しいプロトコルはなく単純にデータを丸投げ、ですか。netcatがあれば試せるので特にコードを書く必要は無さそうですね。

JG1UAAの移動しない局に関しては、とりあえずIC-7200のみで開局申請を行ってきました。必要に応じJumboSPOTを追加する予定です。57.2kg(22:30)

移動しない局の方のJG1UAA、再免許申請出してたしそろそろ局免受け取るか…と思って電子申請Lite開いてみたら、申請出した時期が数日早かったために補正依頼が来ていて申請無効→局免切らす状態になってました。半年以上経過した状態で気付くなんてお前何やってるんだって話なんですけど。

移動する局が生きているのでコールを切らす状態にはなっていないのですが、これはちょっとやっちゃったなーとヘコんでいます。

出費を抑えたいのでこのままの状態にしたいというのが本音なのですが、今すぐに空中線（アンテナ）を撤去することも難しい状況なのでこの状態を放置すると違法局狩り・不法局狩りの餌食になるのは確実。なのでちゃっちゃと開局申請を書いてくることにします（「無線局免許を受けていない場合、電波発射の有無にかかわらず電波を出せる状態となっていれば、電波法第4条違反になり不法無線局の開設罪にあたります」がその論拠ですが、だとするとアンテナ一体型の通信モジュールは所持するだけで狩りの餌食になりますね…こんなんでワイヤレス人材の育成なんてできるんでしょうか？）。

でも一番ショックなのはPOCSAGに対応した状態で使えるように、JumboSPOTの申請をもう一回やり直さないといけないことなんですよね。保証認定の費用がかかるのもあるし、「今​後​総​務​本​省​の​見​解​に​変​動​が​み​ら​れ​た​際​（​例​え​ば​、​無​線​設​備​規​則​の​定​め​る​基​準​に​合​致​し​な​い​場​合​な​ど​）​は​、​当​該​送​信​機​の​使​用​が​で​き​な​く​な​る​可​能​性​が​あ​る」という補足事項付きなのでこの部分の解釈が変わり運用不可になる可能性もありますので。

しっかし、何故気付かずに放置しちゃったかな…再免許申請出したしもう大丈夫、という油断があったことは確かなので、次は気をつけるようにします。56.9kg(07:55)