C/C++拡張のIntelliSense構成時エラーがどこにも出せそうもないので、ラッパー作成してコマンドを順次とらえると最初が
g++.exe -x c++ -E -dM nulだそうで、cmd.exeでその通りに実行してみると…
cc1plus.exe – エントリポイントが見つかりません
プロシージャエントリポイント clock_gettime64 がダイナミックリンクライブラリ c:\ProgramData\mingw64\mingw64\bin\..\libexec\gcc\x86_64-w64-mingw32\15.2.0\cc1plus.exe から見つかりませんでした。
BUG FIX
•Fixed the call will automatically hang up when the CID scheme is NTT Japan(PDFの目次は表紙と違って西日本w).
なんとありがたいお方(暇人様)… 何人のマニアが狂喜したことでしょう。CARを1としているのかIRを1としているのかでnumber of ringsは変わりそうですが時間できたらぜひasteriskに収容してテスト環境を作りたいです…
2025-12-20 ちょこっと実験環境作って試して1台成功、1台うまくいかずでHT813側はSIPアカウント以外の設定に違いはなさそうというとこまで。なんだろ。
|
1 2 3 |
Dec 20 19:08:10 ht813-xxx HT813 [00:0b:82:xx:xx:xx] [1.0.19.6] GS_ATA: USER.INFO Nuvoton::decodeNTTCidNumber, NTT CID Caller Number =0xxxxxxxxxx, len =10 Dec 20 19:08:16 ht813-xxx HT813 [00:0b:82:xx:xx:xx] [1.0.19.6] GS_ATA: USER.INFO Call(1)::Call, Creating Call object 1 at port 1:0 with digits <sip:xxxxxxxxxxxxxxxxxxxxxx:5060> Dec 20 19:08:16 ht813-xxx HT813 [00:0b:82:xx:xx:xx] [1.0.19.6] GS_ATA: USER.INFO Call(1)::run, Dialing <sip:xxxxxxxxxxxxxxxxxxxxxx:5060>, disableCW =1 |
|
1 2 3 4 |
Dec 20 19:09:54 ht813-yyy HT813 [00:0b:82:yy:yy:yy] [1.0.19.6] GS_ATA: USER.INFO Nuvoton::decodeNTTCidNumber, NTT CID Caller Number =0yyyyyyyyyy, len =11 Dec 20 19:10:00 ht813-yyy HT813 [00:0b:82:yy:yy:yy] [1.0.19.6] GS_ATA: USER.INFO SipSigCtrl::processCallCancelled() on port/ch 1:0, status = CALL_ENDING/CALL_IDLE Dec 20 19:10:00 ht813-yyy HT813 [00:0b:82:yy:yy:yy] [1.0.19.6] GS_ATA: USER.INFO SIPStack(1)::cancelCall: Nothing to cancel at 1:0 Dec 20 19:10:00 ht813-yyy HT813 [00:0b:82:yy:yy:yy] [1.0.19.6] GS_ATA: USER.INFO ATACtrl::processCallCancelled on port 1:0, status = CALL_ENDING/CALL_IDLE |
2025-12-22 設定を動作しているほうからコピーしてみるもCallerIDゲットしてすぐにcancelledで動作せずでしたがFXOも動作している方と差し替えたら動作。FXO差し替えは前回も試しているので設定のどこかに違いがあったのだろか… FXOを元に戻して接続元のNVR500の設定を見たらFAX用にモデムダイアルインの設定がされていてこの信号が極性反転扱いされているようなので、これを外してみごと2台のHT813からasterisk経由PC上のSIP電話までCallerIDが通知できることを確認できました。
nginxでGooglebotの検証という記事を書きましたが、すぐ後にGoogleがGooglebotの範囲を公開しました。BingbotについてもVerify Bingbotの下の方で公開していることに気付き(Googlebotと同時期に公開した模様)それに合わせてシンプルに簡易検証ができるようになったので更新します。
参考: GPT botの範囲: 各botの範囲はお互いに重複している部分があります。
続きを読むしばらくぶりの鍵周りの整理でOpenPGP(GnuPG)の暗号用鍵を更新したり、フォールバック用に長いこと残しっぱなしにしていたOpenSSHのRSAの公開鍵を消して回っているなどしている時に、だいぶ前の話のようですがOpenSSH 8.2でFIDO U2Fがサポートされ、ed25519-skおよびecdsa-skなる-skが付いた鍵タイプが追加されたという話にたどり着きました。
FIDO U2Fということは黒いYubiKey 5 NFCシリーズ(PDF)ではなくて、青いSecurity Keyシリーズ(PDF)でもOKということになことになります。これは試さねば! というわけでmacOSとUbuntuとFreeBSDとCygwinで試してみました。
続きを読むなにやらExcel VBAとかGoogle Apps Scriptなど、普段は触らないものたちを触る機会が多かった1年でした。開発環境がしんどいですが、業務をストレートに機械にやらさせるので、楽しいという本能が出やすくもあります。
それでもって添付ファイルをざっくり削除して場所を確保したいという課題を、個人的には使うことがないOutlookで解くことになりました。
続きを読むFacebookと傘下が死んでいたようですがこの記事の
Internet providers usually update their DNS records every few hours, but they can take several days to fully propagate.
はちょっと何言ってるか良く分かりませんでした。他人のRRをプロバイダがアップデートしている??? いずれにせよ全部の権威サーバ[abcd].ns.facebook.comがAS32934の中にいてサービスを提供しているサーバごとBGPテーブルから消え去ったのでネガティブレスポンスのキャッシュではなくてサーバに到達できないというエラーのキャッシュになります。キャッシュが1000くらい直列になった謎沼の底でもない限り数日かかることはないかと思います。
それはともかく本題のGooglebotの検証方法は公式には
となっています。User-agentも逆引き(rDNS, PTR RR)も詐称したい側が容易に詐称可能です。.google.com や .googlebot.com のA RRやAAAA RRはGoogleの権威サーバを乗っ取るかどこぞのキャッシュサーバを攻略しないといけないため通常は正しい、GoogleはUser-agent詐称しない、という前提のもと検証できることになります。
Apache HTTPDでは HostnameLookups Double と SetEnvIf を組み合わせて検証できます。nginxではNginx HTTP rDNS moduleを使ってできそうです。パッケージになっているディストリビューションが少ないので、配置しなければいけないサーバが多い場合はテスト目的以外で使うにはちょっと躊躇します。
そこでFCrDNS部分をざくっと省略版にしてAS番号で処理することにします。
|
1 2 |
Sep 30 23:06:30 metal postfix/smtp[61376]: 7224324829CA: Server certificate not trusted Sep 30 23:06:31 metal postfix/smtp[61376]: 7224324829CA: to=, relay=x, delay=5.4, delays=0.71/0.09/4.6/0, dsn=4.7.5, status=deferred (Server certificate not trusted) |
|
1 2 3 4 5 6 7 8 9 |
> openssl version OpenSSL 1.0.2u-freebsd 20 Dec 2019 > openssl s_client -showcerts -connect x:25 -starttls smtp CONNECTED(00000003) depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3 verify error:num=10:certificate has expired notAfter=Sep 30 14:01:15 2021 GMT --- |