NT6 Kernel WindowsのNetwork周辺ヘンテコ挙動。

症状:
デフォルトゲートウェイの設定に何かの拍子で失敗すると、GUI画面で削除出来ない default Gateway = 0.0.0.0 という設定が出来てしまう。結果、外部とは不通になってしまう。

確認方法:
ipconfigで確認すると「デフォルトゲートウェイ 0.0.0.0」という表示が出る。

対処方法:
routeコマンドでこの設定を削除する。
>route -p delete 0.0.0.0 mask 0.0.0.0 0.0.0.0

これだけでは復活しない場合、GUI画面で見えている正しい設定も一度コマンドから削除し、再度コマンドから登録する。以下、192.168.1.254をGatewayにしている場合。

>route -p delete 0.0.0.0 mask 0.0.0.0 192.168.1.254
>route -p add 0.0.0.0 mask 0.0.0.0 192.168.1.254

 ◇

 Vistaの頃から時々出ている症状だが、Win2008・Win7でも無事?発動することがあるバグだということが判明。
 ・・・ホントにVista SEだな>Win7。

 とはいえ、7は兎も角、2008はサーバなんだからさすがにコレはマズくないんか、イロイロと。

Share

Thunderbird で Some messages could not be FETCHed (Failure) とか言われたら。

 さてさて、先日PCの中を少し整理いたしまして。
 Thnderbirdも3.0に今更移行しましたよ。

 とこがこのThunderbird 3.0のIMAP、どうやら一部問題が残っているらしく、時々

 Some messages could not be FETCHed (Failure)

 超訳: うまく読めないメールがあったの (てへっ)

 などと言って同期に失敗することが。
 ちなみにこのメッセージが出るフォルダをSylpheedで開いても全く問題なく読み込めるトコからして、不具合があるのはThunderbirdでしょうな。

 #取り敢えず当方が見た感じ、コケるのは日本語メッセージ、しかも文字化けってるモノっぽいので、文字と制御コードの見分けがつかなくなってる、ってトコかね。

 さて、エラーが出るなら対策が必要ですな。
 検索してみたらimaplibを使う方法を紹介しているblogがあって、とても真正面から正攻法で処理している模様。
 とはいえ、当方のような横着者はもちっとラクをしたいので、以下、そのやり方を。

 ◇

 前提条件として、この方法はIMAPで「ゴミ箱」が設定されているメールサーバでのみ利用可能。
 具体的にはGmail、Google Apps等。他についてはサーバ管理者に訊いてね。

 1.
 問題のエラーを起こすフォルダを開く。
 IMAP同期がコケてるファイルは、大抵の場合 (←「絶対」ではない?)

 ・タイトル若しくは本文が文字化け
 ・正しい時刻でなく、同期コマンドを実行したタイミングの時刻で表示されている

 ということになっている模様。
 この場合、時間順でソートをかければどのメールがトラブルの元になっているかほぼ一発で判別可能。

 2.
 問題を起こしているメールをごみ箱に送る。
 ここではタイトルや本文が文字化けしていても全く気にする必要は無い。

 3.
 Thunderbird以外のIMAP対応MUA、若しくはWebでメールボックスを開く。
 MUAが他に思いつかなければお勧めはSylpheed、Gmailなら普通にWebでログイン。
 ここでごみ箱を確認すれば、トラブルの元になったメールが読める。

 4.
 このメールが必要だと判明した場合でも、そのまま元に戻すとまたコケる。
 仕方ないので、自分宛メールを一通作成し、そこに添付、引用、若しくはテキスト貼付を行う。
 この新規メールを問題メールの代わりに該当フォルダに設置する。

 5.
 問題メールは削除するか、若しくは隔離フォルダに移動して一件落着。

 ◇

 ま、こんなところで。

 とはいえコレ明らかに現行Verの不具合なので、そのうち放っておいてもバージョンアップで直る気もするし。
 問題起こすメール専用の隔離用IMAPフォルダを作って掘って放り込んでおけば、それで事が済むかも。

Share

続・エラい身近にあった2010年問題。

 SEPトラブルの続報。

 どうやら8日午後ぐらいに?Symantec本社のLiveUpdateサーバには2010年の日付のパターンファイル(2010/1/7)も設置されるようになった模様。
 これで、SEPM経由でUpdateをかけていない野良端末では、きちんと2010年の日付のパターンファイルが表示されるようになりましたよ、と。
 ・・・SEPM下にある管理端末では、未だに2009/12/31のままだけど。

 つまり今のLiveUpdateサーバには、中身は一緒でも日付が正しいものと2009/12/31のものと、2種類設置されているってことね。
 
 ・・・さて、SEPMのパッチ、いつ出て来ますかね。

Share

地デジのワナ。

 年が変わってから去年末のネタを書く、その1。

 以前ここでVARDIAのファーストインプレッションを書いたが、その後もVARDIA自体はつつがなく動作しております。
 全く整理されていない使い勝手にも漸く慣れてきましたな。

 が、ここで問題発生。
 時間の経過と共に、地デジがどんどん映らなくなってきてしまったんですよ。

 購入当初は普通に全部映ったのだが、最近ではNHKぐらいしかまともに映らない、という悲惨な状況に。
 画面でアンテナレベルを確認すると、数字が30だ20だ・・・MAX100でコレでは、ねぇ。

 ということで、仕方ないので業者を呼んで見てもらいましたよ。
 まあやりたいこと自体はアンテナのレベルとS/Nの計測なので全然難しいモノではない(当方一応モールス打てます)のだが、専用の測定器はとてもイイお値段で、ひょいと借りれるアテも無いので。
 それに、共聴設備側のトラブルとなったら、コレは業者にお願いするしか無いし。

 ところが・・・業者曰く、レベル的にもS/N的にも全く問題ないらしい。レベルは「適正範囲」上限ギリギリ、S/Nも「全く問題なし」とのこと。

 え゛ー・・・それじゃ何で。

 ということで、ここで業者のおじちゃん(というか正確にはおじいちゃん)が取り出したのは、何と減衰器、ATT、アッテネータ。
 そいつをアンテナ端子とVARDIAの間に突っ込んでみたところ。

 ・・・全chキレイにうつるようになりましたとさ。

 #空電ラインに-20db(16・20・26と試してこれがベストだった。勿論、通電形・帯域非選択タイプ)なんて、RFは微弱信号だと信じていた自分の感覚では「なんと恐ろしい」としか・・・。

 結論。

 ・難視聴対策でCATV再送信を使っているマンション等
 ・東京タワーの近く等、地デジの電波がかなり強い地域で大きなアンテナを使っている場合

 では、入力レベル飽和による歪みや混変調・相互変調発生のせいで、地デジ受信に支障が出ることがある。

 対策は入力レベルを下げること。レベルが高過ぎるので落とせばよろしい、と。
 但し、アッテネータ(減衰器)は普通の量販店では売ってない。
 とはいえ入手はそんなに難しくはなく、通販や電気工事店等では購入可能。

 電気工事屋のおっちゃんが言うには、たまにこんな風に受信障害が出るケースがあるらしい。
 ただ、トラブルを起こすのは激安品が殆どで、国内メーカ品では殆ど聞いたことがない、らしい。

 ということで、東芝VARDIAのユーザは要注意、かも知れない。

 #あ、ちなみに。
  設定メニューに受信感度を落とす設定はあって、当然コレも試しているのだが、全然効きませんでしたよ。
  焼け石に水だった、ってことですかね。

Share

エラい身近にあった2010年問題。

 海外ではカード端末が誤動作したり、ケータイがコケたり、タクシーメータがリセットされたり、と色々な話が聞こえてきましたが。
 まさかこんな身近に2010年問題があったとは、という話。

 というのは、企業クライアントではメジャーなSymantec Endpoint Protectionで、2010年の日付のウィルスパターンファイルを読み込めないという話。

 >Security Content for Symantec Endpoint Protection clients and Symantec Endpoint Protection Managers are dated Dec 31 2009 even when using the latest definitions
 >http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2010010308571348

 日本語速報版の訳はこちら。
 >SEP クライアントと SEPM のウイルス定義ファイルの日付が最新版に更新後も2009/12/31 のままとなっている
 >http://service1.symantec.com/support/inter/entsecurityjapanesekb.nsf/jp_docid/20100105094746949

 要するに、2010年の日付の入った最新パターンファイルを配信したら、受け取る側のバグで古物だと勘違いして捨ててしまうため、いつまでたってもパターンファイルが更新されません、と。
 仕方ないから、2009年12月31日の日付のまま、通し番号だけカウントアップしたパターンファイルを当分配信し続けますよ、と。

 実は当方も会社支給の端末ではモロに該当していたのだが、Symantec本社のフォーラム辺りでは年明けて間もなく話題になっていたので、「あれまあ」としか思っていなかったのだが。

 本日の出先で、この件が思わぬ大騒ぎになっていたので、思わずメモ。
 ・・・まぁそりゃ積極的なアナウンスはされていないし、そもそも日本語説明文章はUSAよりだいぶ遅れてから出たとはいえ、仮にでもIT部門名乗るなら、せめてベンダのKBぐらい確認しろよな・・・。

 #Symantecは不具合情報を出したがらない(出したとしてもKBの隅っこにこっそりとか)上に、日本語リソースが少ない&出ても激遅なのでも有名な会社の一つ。
  あそこが日本語リソース出すのを待つということは、Globalから周回遅れになるということとほぼ同義。

 まあしかしこうなると、個人的には「あたふたしているウチに今度は通し番号がさくっと桁溢れ」なんてオチを期待してしまったり・・・え?黒い?

 #通し番号は元々同一日付内に複数回更新された時にカウントアップされる性質のもので、普段2桁しか使っていないのに、今回は非常事態ということで3桁番号を使っているんだし。慌てついでにsignedとunsignedをミスってみたりとか・・・

Share