イー・アクセスによるアッカ・ネットワークスの買収をさらに模索中?

あけましておめでとうございます。実は、新年1発目の話題はNGN絡みで行こう、ということで準備を進めていたのだが、本日(正確にはすでに昨日となっているが)、今となっては数少ないADSLウォッチャーとしては見逃せないニュースが舞い込んできた。イー・アクセスがアッカ・ネットワークスに対し、”抜本的経営改革を求め、アッカ社経営体制の変更を提案”したというのである。

1年半ほど前に予言するような記事を書いた者の責任として、1年半前から現在までの状況の変化を簡単にメモしておきたい。

1年半前に書いた記事のサマリーとしては

.ライバルADSL会社による突然の大量株買い付け
.両社が合併した場合の買収メリットの存在
.NTT地域会社のフレッツの純減傾向の記録
.イー・アクセスによるアッカ・ネットワークスの株取得目的が”現時点では”純投資という微妙に不自然な点

といった点だろうか。

この1年半の動き(アッカ)

その後、イー・アクセスは物を言わぬ株主として大株主として居座ることとなる。

その間、アッカ・ネットワークスはといえばモバイルWiMAXの免許取得へ動いていた。その免許取得は叶わぬ夢となったが。また、筆頭株主であったNTTコミュニケーションズはイグナイトグループに株式を譲渡することで持ち株比率を低下させ(19.7→11.7%)、米国イグナイトグループとして8%を取得するに至る。なお、イグナイトグループはIT2000投資事業有限責任組合を通しては、アッカの設立当初からの提携先である。(注1)
また、社長もNTTコムからの社長ではなく、イグナイト主導の人事に刷新された。
 しかし、イグナイトとしてはモバイルWiMAXの免許の取得を前提とした計画を立て、NTTコムより株式を引き受けたと推察されるが、免許取得が叶わぬ後の事業計画は会社側説明を見ても不透明と言わざる得なかった。

この1年半の動き(イー・アクセス)

その後、イー・アクセスでは1.7GHz帯の携帯電話事業者として設立した持分法適用会社(当時は連結対象)のイー・モバイルが2007年3月31日に商用サービスを開始した。

ここで気になる話題がある。イー・モバイルのイー・モバイルADSL無期限セット割キャンペーンだ。
どういったサービスかというと、イー・モバイルの契約ユーザに対し、親会社であるイー・アクセス経由で提供されるADSLサービスを事実上”無償”で”無期限に”提供するというものだ。
キャンペーン期間も非常に長く開業日から2009年2月28日までの申込みにかかる割引だ。あまり例がない。

なぜイー・モバイルはこのようなキャンペーンを行ったのだろうか?
技術的な視点で見ると、イー・モバイルのネットワーク運用効率が改善するメリットが考えられる。

2007年6月22日に行われたイー・モバイルの発表会席上、ユーザのデータ平均転送量が月当たり1.4GB、ヘビーユーザは6~10GBほど利用している、という問答があったという。(注2)
正直言って、バッテリーの制限があるモバイル環境のみでコンスタントにヘビーユーザの転送量を利用するのは難しい。自宅に通信回線を引かずに利用しているケースが想定される。
このヘビーユーザの利用量を平均的なユーザの利用量にすこしでも近づけることが出来ないだろうか?そうすれば、開業当初でネットワークが不十分な同社にとって、無用なコストを掛けた基地局の構築を避けることが出来る。
イー・モバイルとして、1500円(イー・アクセスへの支払いは1200円程度と推定される)のADSLサービス料を負担したとしても、それ以上のメリットがある話となるわけだ。

それが無期限セット割を行っている基本的な理由だと推測される。

だがしかし

それだけでは判断できない問題がある。

1年半前に書いたようなADSLサービスの純減問題は、一見好調そうに見えるイー・アクセスにも重くのし掛かっている。彼らの決算資料によれば2006Q4経過以降、純減に転じている。(ISP事業に分類されるAOLは除外した。)

2006Q4といえば、イー・モバイルが商用サービスを開始した日に1日掛かっている。サービス開始当初に無期限セット割を申し込んだユーザはとこの2006Q4のADSLユーザ数にカウントされたと推測される。

なかなか数字が好きな会社である。パズルのピースを嵌めていく作業は実に面白い。
このユーザ思いの割引サービスは、親会社思いのサービスであるかもしれないわけだ。言い換えれば、イー・モバイルのサービス開始日以降、イー・モバイルの新規ユーザは親会社のADSLサービスの純減を食い止める手段としても利用されているということでもある。

しかし、それでもいずれ本格的に来る純減に備え、なんらかの方策を考えていたに違いない。その対策のひとつがアッカ・ネットワークスの買収オプションだ。

また、今回始めて知ったことであるが、イー・アクセスの事業部門に”デバイス事業”、が増えていた。一体なんだ??と疑問に思ったが、持分法適用会社であるイー・モバイルの通信カード等のメーカーからイー・モバイルに対する卸業務を行っていると推測される。
様々な事情があるのだろうが、Yahoo!BBのモデムが複雑な流通経路でユーザの手元に渡ることになっている一件を思い出した。

また、昨秋からはオープンワイヤレスネットワーク(OpenWin)というモバイルWiMAX事業への少々無理のある参入希望も記憶に新しい。
なぜか長年の確執のあったソフトバンクと共同で無線IPブロードバンドのための子会社を設立するという、イー・アクセスとソフトバンクのADSLに関する確執を知るものには素直には理解に苦しむ参入希望だった。
残念ながら、この新規参入グループも免許を獲得することは出来なかった。これが昨年12月末の話である。

1月16日

ついに戦いの火蓋は切って落とされた。アッカ・ネットワークスは12月決算の会社であり、3月に定時株主総会が開催される。これに先立ち、イー・アクセスは、アッカ社の発行済株式総数の13.10%(2008年1月11日時点)を保有しており、筆頭株主の立場に躍り出た模様だ。
この株主総会に今回、以下のような提案を行うという。

1.(イーアクセスからの)新任取締役4名の選任
小畑至弘氏、大坂宗弘氏、エリック・ガン氏(非常勤)、石田雅之氏(非常勤)
2.現任社外取締役3名の再任
佐藤元信氏(非常勤)、佐々田法男氏(非常勤)、星野隆作氏(非常勤)
3.現任取締役3名の不再任
木村正治氏、湯川英彦氏、廣野公一氏

なかなか面白い提案である。ちなみに、小畑至弘氏はソフトバンクグループの企業である当時のBBテクノロジー(現在はソフトバンクBB)から小畑氏個人を相手取って損害賠償訴訟を起こされた希有の経歴を持つ技術者である。訴訟取り下げで解決した(注4)ということのようだ。当時、TTCのADSLスペクトル管理標準を巡る検討に関する議論について、小畑氏個人に対して訴訟を起こされたということで話題になった。

また、再任する社外取締役は佐藤元信氏がNTTコミュニケーションズ、佐々田法男氏が三井物産、星野隆作氏がイグナイトジャパンにそれぞれ関係している。この3社と敵対する意思がないという表明に見える。

現在の大株主をもう一度確認してみよう。

1位 イー・アクセス株式会社 13.10%
2位 エヌ・ティ・ティ・コミュニケーションズ株式会社 11.7%
3位 三井物産株式会社 10.31%
4位 イグナイトBB投資事業有限責任組合 8.00%
5位 株式会社大和証券グループ本社 3.82%
6位 IT2000投資事業有限責任組合 3.16%
(2007年6月末の名簿より筆者で異動したと思われる部分を訂正した)

三井物産はイー・モバイルの設立の際にも当初より大株主として参画していた程なので、今回の提案を拒否するとは考えにくい。動向の焦点となるのはNTTコミュニケーションズとイグナイトだろう。NTTコミュニケーションズは徐々にアッカと距離を置く戦略を基本としているが、今回の提案に協力するのだろうか。イグナイトについては近年よく見られるような企業乗っ取りでアッカ株を取得したのではなく、設立当初からアッカの経営に参画している。また、最近ではNTTコミュニケーションズより譲渡を受けることで買い増しを行うなどの紳士的な行動を行っている。

しかし、投資ファンドは、投資を行ってその投資に見合う収益を回収出来れば良い。したがって、イー・アクセスの提案でイグナイトが利益を享受を出来ると判断すればあっさりイー・アクセスの提案に乗ってくる可能性がある。

報道機関の取材に対し、イー・アクセスの広報担当は「あくまで株式の保有目的は純投資であり,イー・アクセスとアッカのDSL事業を将来的に統合することなどは現時点では考えていない。株主として事業を立て直し,企業価値を高めてもらいたい」と主張しているようだ。(注3)”現時点”が大好きな会社である。

私見であるが、今となって思えばイー・アクセスの元々のアッカ株式大量保有の背景には2.5GHz帯に関するモバイルWiMAX免許をアッカに取られた場合の保険という戦略もあったのではないかと思うことがある。

WCDMAネットワークをデータ通信に使うのは、徐々に音声サービスを充実させるイー・モバイルにとって重荷になる日がやってくる。その時、掛けるコストを最小限に、発言権を最大に確保するため、アッカの株取得に動いたのではないか。もちろんアッカ単独での免許獲得の可能性を検討したわけではなく、その背後に居るNTTグループを警戒したのだろう。(注5)

そのアッカによる2.5GHz帯モバイルWiMAX免許獲得が叶わない可能性をイー・アクセス首脳陣が悟った時、ソフトバンクと共同で動き出したのがオープンワイヤレスネットワーク(OpenWin)ではないだろうか。
単なる白昼夢かもしれないが、そう考えると非常に納得の行く話に思えてくるのである。また、このオープンワイヤレスネットワーク(OpenWin)は実質的にはイー・アクセス主導(ソフトバンクは事実上の名義貸し)だったという説があるが、ソフトバンクが名義貸しを行ったのは両社が総務省に対して広い意味での”貸し”をつくるためだったと考えると説明を行いやすい。

なぜ2.5GHz帯のモバイルWiMAX免許が貸しなのか?。2.5GHz帯は移動して通信するための周波数帯としてはとても厳しい周波数帯である。しかし、総務省が進めている周波数再編が完了(2012年めど)するまでは、条件の良い空き周波数帯が無いため各社名乗りを上げざる得なかった。
しかし、本命は800MHz帯の新規割り当てと700MHz帯での40MHz分の割り当てである。今回落選した場合でも本命さえ取れれば、イー・アクセス、ソフトバンクにとって問題は無いのかもしれない。でなければ、パフォーマンスのような出資予定の追加紹介(注6)などのニュースリリース等を説明することが出来ない。本来、このような出資については免許申請時に予め計画書に記載しておくのが筋だからだ。

そして、両社ともにモバイルWiMAX免許を取得できなかったことで、1年半以上前からすでに見え隠れしていた、イー・アクセスによるアッカ買収、統合?へのスキームが動き出したことは間違いない。

(筆者注:間違いがありましたらコメントを受け付けておりますのでご示唆くださると幸いです。)

(注1) IT2000投資事業有限責任組合は、株式会社イグナイト・ジャパンと東京海上キャピタル株式会社が共同運営するベンチャーファンドです。

(注2) http://bb.watch.impress.co.jp/cda/news/18543.html

(注3) http://itpro.nikkeibp.co.jp/article/NEWS/20080116/291252/

(注4) http://bb.watch.impress.co.jp/cda/news/1260.html

(注5) なお、イー・アクセス自身もWiMAX/モバイルWiMAXに関する研究、調査を早い段階から行っていた(ニュースリリースでは2005年5月~)経緯がある。

(注6) http://k-tai.impress.co.jp/cda/article/news_toppage/37338.html

Update:2008.1.18 前日投稿の時点では校正が完了していなかったため、不足部分を書き加え、hi様よりご指摘いただいた部分を含めて訂正、校正を行いました。hi様、ご指摘ありがとうございました。

投資勧誘目的の不存在

本情報は、昨日発表されたイー・アクセス株式会社のプレスリリースについて知っていただく為のものであり、読者に対して投資を勧誘するものではありません。また、いかなる証券の投資勧誘を目的としたものでもありません。
また当情報の正確さ・完全性に関していかなる保証をするものではなく、その情報が誤りを含んでいないこと、有用なものであること等は保証いたしません。

| | Comments (2)

オートネゴシエーションの罠

忙しいので小ネタを。NWayですよ。NWay。。。

1.富士通アクセス FA11-M2とRT57iのネゴシエーション

筆者はRT57i(*1)をPPPoEさせるのに用いている。そのRT57iにアッカネットワークスのADSLサービスのためにレンタルされていたFA11-M2を繋いだところ、RT57i側でLAN2の統計情報は(*2)

RT57i>show status lan2
LAN2
Description:
Ethernet Address:               00:a0:de:**:**:**
Operation mode setting:         Auto Negotiation (100BASE-TX Full Duplex)
Maximum Transmission Unit(MTU): 1500 octets
Promiscuous mode:               OFF
Transmitted:                    46821 packets (7254910 octets)
Loss of carrier:                21
Received:                       53162 packets (35236268 octets)
Receive framing error:          24
Receive CRC error:              14

と、Receive framing error,Receive CRC error等の不具合が頻発する事象が発生した。

 これは、ちらっと検索してみたところ、FA11-M2のFAQのひとつのようだ。とくにRT57iとだけで発生しているわけではないらしい。
 解決策としては、両端を100M全2重(100FDX)固定にすると解決する、という情報を得たため、FA11-M2とRT57i共に100M全2重に固定したところ安定状態となった。統計情報はこのような感じ(*2)になった。

RT57i> show status lan2
LAN2
Description:
Ethernet Address:               00:a0:de:**:**:**
Operation mode setting:         100BASE-TX Full Duplex (Link Up)
Maximum Transmission Unit(MTU): 1500 octets
Promiscuous mode:               OFF
Transmitted:                    46821 packets (7254910 octets)
Received:                       53162 packets (35236268 octets)

教訓:
たまにWAN(LAN2)側のshow status lan2の状況くらいは確認すべきだ。
ADSLモデム(or メディアコンバータ)と直結なのに、Transmitted:とReceived:以外のカウンタが動いているときは要注意。

(*1)以前の記事でRT58iを評価用に導入予定と書いたものの時間が無く評価も出来ていない。

2.NECアクセステクニカ WD701CVとRT57iのネゴシエーション

 ところで、筆者の通信回線はADSLを使っているのだが、前回blog記事の経緯によりやむなくアッカネットワークス/So-netからイーアクセス/ニフティの提供する12Mバリュープランへ回線を変更した。

 当blogでも幾度か指摘しているように、アッカとイーアクセスのADSLモデムには残念ながら互換性の欠如がある。また、アッカのモデムは借用品なので返却の必要がある。そこで、NECアクセステクニカ WD701CVへ変更することとなった。当然RT57iとの接続となる。

その際すでに、RT57iのWAN側はFA11-M2の不具合対処のために

lan type lan2 100-fdx

のコマンドを投入済みだった。そのため今更

lan type lan2 auto

に戻すメリットも感じなかったので、WD701CV側を100M全2重(100MFDX)の設定を入れることで作業工数を省くことにした。これが後の惨劇(笑)を引き起こすことになるとは想像し難い話であった。

 ところでイーアクセスの場合、NTT局内工事後の1週間は不用意にADSLモデムの操作をしてはいけない話はご存じだろうか?
 イーアクセスは、この1週間の間、通信回線のADSLリンク状況の統計を取っているようで、リンク断の回数が一定の閾値を越えているようであればノイズマージン等を自動的に上げていき回線を安定化する処置を行うようだ。

逆に言えばADSLモデム絡みで不具合が起きているのが分かっても、気軽にモデムの再起動等を行えないつらい1週間である。

さて惨劇の内容は....

 NTT工事後数日ほどしたときだろうか、通信回線が以前と比べて不安定になっている気がした。またしても帯域制御装置が我が身に忍び寄っているのか??と一瞬頭を過ぎった。正直言って、トラウマになりそうな出来事だっただけに疑心暗鬼になってしまった。しかし、簡単に見えざる手の罠と決めつけるのは良い考えではない。
 今回の事象の特徴は前回と違い、回線がおかしなタイミングがあからさまに体感できる(帯域制御装置によると推測されるケースではなめらかな変化)点である。物理的な接続を調べていくのが先決だろう。

 そうして、早速ADSLモデムのログを確認したところ、"ETHERNET LOCAL-ETHER TX overflow"が散発的に発生していることが確認された。また、RT57i側では

2007/02/10 11:49:58: LANC2: link down
2007/02/10 11:50:01: LANC2: link up (100BASE-TX Full Duplex)

といったように、イーサネットのリンクが不安定になっている事象が幾度も確認された。

ルータとADSLモデムの接続は以下の通りだ。

RT57i/LANC2--(Ethernetコード)--LAN/WD701CV/ADSL--(PSTN回線)

このうち、Ethernetコードは今まで使用していたコードを流用している。コネクタやケーブルが急に劣化することは考えずらい。また、イー・アクセスの開通当初の回線確認期間内ということもあり、正直あまりさわりたくない部分だ。(*3)

物理的な接続を疑う前に論理的な不具合を疑うべきだろう。なお、このタイミングでRT57iのLAN2の統計情報(*2)は

LAN2
Description:
Ethernet Address:               00:a0:de:**:**:**
Operation mode setting:         100BASE-TX Full Duplex (Link Up)
Maximum Transmission Unit(MTU): 1500 octets
Promiscuous mode:               OFF
Transmitted:                    464821 packets (72554910 octets)
Loss of carrier:                21
Received:                       531624 packets (35236268 octets)
Receive framing error:          45
Receive CRC error:              108

といった感じで、正常系では表示されない、Receive framing error,Receive CRC errorといった項目が上がっている。
 なお、LAN側(LAN1)で良く登場するNon support packet receivedについては、TCP/IP以外のブロードキャストパケットを受け取ったときにあっさり表示されるものだ。
特に気にすることはない。

原因の推定

状況から判断すると、ADSLモデムの論理的な間欠故障の可能性が高い。ADSLモデム側の再起動により通信が不安定になる事象は解決するように思えたが、確実に事象が解決した確証が欲しかったため、次の細工を行うことにした。

間欠故障であること、正常性確認のために

宅内のネットワークとADSLモデムは、RT57iを介してIP masquerade経由で直接確認可能となっている。
PC1--RT57i/(IP masquerade)---WD701CV

そこで、PC1を用いてWD701CV宛にfpingというソフトでpingを山ほど送りつけてみた。すると、宅内のネットワークであるにもかかわらず、ping欠けが山ほど発生した。間違いない。RT57iとWD701CVのコネクションがおかしいことが完全に確認された。

そして、WD701CVを再起動させ、同様の条件でpingを山ほど送りつけたところ、今回はpingは安定して到達するようになった。

そして、数日後、またしても同様の事象が観測されるようになった。エスカレーションとしてADSLモデムの再起動を実施し、ADSLモデムのLAN設定をオートネゴシエーションとし、またRT57iの設定については

lan type lan2 auto

を入れた。その結果、同様の事象については完全に発生しなくなった。

教訓:
イーサネットで速度設定を両端固定にすれば解決するなどと甘い幻想を抱いてはいけない。逆に両端オートネゴシエーションにした方が良くなるケースもある。
なお、知人に聞いたところ、NW構築の際もこのようなトラブルはよく経験しているとのことで光M/Cを対向で挿入して装置の相性の悪さを回避したり、スイッチングHUBで同様のことをおこなって誤魔化すケースもあるようだ。

また、回線の安定性チェックにfping(win32版)は絶大な効果があった。ちなみにfpingとはflood pingの略。このビルドの場合、cygwin等を別途必要としないのも便利だ。Etherealと共に基礎的なトラブルシューティングに今後も活躍しそうだ。

(*2)文中のカウンタは後日に雰囲気を再現したものであり、実際の表示とは異なっていた可能性もあります。ご了承ください。

(*3)イー・アクセスの回線確認期間を過ぎていたならば、本文中のping試験、ADSLモデム再起動実施、そのあとのping再試験というフローを実施した後、ADSLモデムとRT57iのLANコネクタ清掃、ケーブル導通確認も行っていただろう。
今回は違うが、特にオフィス環境では、実際にLANコネクタの清掃不良によりエラーが発生するケースもあるという。

| | Comments (0)

帯域制御装置の功罪

 筆者はなかなか記事を書けない今日この頃ですが、皆様如何お過ごしでしょうか。

 さて、今回はさらっと、ピンククマ.net(仮名)の解約記を簡単にまとめておこうかと思う。

解約理由

サポートセンタの回答があまりにコピーペーストで、また信憑性(and 誠意)に欠ける回答だったため。

回線契約

ピンククマ.net(仮名) ACCA12M ADSL回線

経緯

 最近、筆者はストリーミングラジオに関心があり、良く海外のサイトを探索しているのだが、そのサイトのうちでとても気に入ったサイトがあった。ストリーミングフォーマットはMP3でTCPポート番号は8216を使っていた。ちょっと珍しい番号ではある。
 帯域は128kbpsで最近のネットワーク水準ならば普通だろう。
 しばらく聞いていたところ、夜間帯に不安定に途切れるケースが多発したので、ストリーミングバッファを4096KBまで拡大するなどの対策を取ったものの焼け石に水だった。

しかし、筆者の知り合い等に同時間に確認を取って貰うと他のISP(Nifty,OCN,K-Opticom,ODN,plala等)では同様の問題は全く起きないという。

可能性は?

以下にある程度仮説を上げてみた

1.ACCAのアクセス回線(および中継網)の帯域不足?

と思って、国内の同様なストリーミングを受信したところ、安定して受信できる。海外であっても別のサイトの場合、安定して受信できる。
 また、他のISPの契約者にご協力を仰ぎ、このピンククマ.net(仮名)/ACCAのアクセス回線経由で一旦他のISPの回線にSSHで接続し、そこからポートフォワードしてストリーミングを受信したところ、一切問題は発生しなかった。付け加えれば、64KB程度の小さなバッファでも問題が起きることはなかった。

結論
→単純なアクセス回線帯域不足の疑いは極めて薄い。

2.海外側の中継回線もしくはサイト側で帯域幅を確保できていない?

 そもそも経緯を考えれば他の日本のISPで安定してストリーミング放送を受信できている。ちょっと考えずらい仮説ではある。

 しかし、それでも検討してみた。代表例として、niftyとピンククマ.net(仮名)で比較してみたところ、"traceroute"の結果としては、"実はこのサイトへの海外線はVerio東京のルータ以降は完全に同一経路(多分niftyとピンククマ.net(仮名)のトランジットは同じVerioルータ)"というものだった。
 もちろんtracerouteの結果だけでは非対称ルーティングといった可能性もあり、断言はできないが、安定して受信可能なniftyと海外線は同じ可能性は高いだろうことが分かる。

 サイト側での帯域不足というのは、日本のピンククマ.net(仮名)がそのストリーミングラジオ事業者から何らかの理由で恨まれていて、妙に絞っているというちょっと不可思議な事情でもないと考えずらいだろう。
 他のISPでは問題なく受信できているのだから。

結論
→ピンククマ.net(仮名)網外の海外側で不具合のある可能性は低いのでは?

3.ACCA回線のADSL回線部分でエラーレートが高いのでは?

 そんなことはない。40日間稼働させたADSL回線のCRC8エラーのスーパーフレーム数はリンク断時のバーストエラーも含めて5324。一日あたり、100強。1日に100パケット落ちたところで4096KBのストリーミングバッファに壊滅的なダメージを与えるほどのインパクトは到底与えることができない。
 また、SSHでポートフォワードをした際に全く影響が出なかった件を説明しずらくなる。

結論
→ありえない。

4.ピンククマ.net(仮名)網内が夜間輻輳しているのでは?

そうかもしれない・・・・が。仮にそうならば、1のSSH経由でポートフォワードした際に全く問題なかった件が説明できないことになる。また、他のストリーミングラジオは海外の同じ国から(かつ同じVerio経由)のものであっても安定して受信できていたからだ。

結論
→ありえない。

5.東京のVerioとピンククマ.net(仮名)の接続回線が輻輳していた?

これも考えずらい。なぜなら、他のストリーミングラジオは海外の同じ国から(かつ同じVerio経由)のものであっても安定して受信できていたからだ。

結論
→ありえない。

6.帯域制御装置の設定に不具合があるのでは?

 TCP Monitor Plusというツールでストリーミングラジオの帯域の変化をつぶさに観察してみたのだが、あからさまに帯域を押さえ込まれている感触だった。もちろん、ネットワークが空いている時はあまり酷い押さえ方はしないのだが、夜間の良い時間帯になるとガンガン帯域を削ってくれる雰囲気である。
しかし。Port80や443、またストリーミングラジオで一般的な8000番近傍についてはわざとそういう制限は掛けていないようだった。
 しかし、8216番などというちょっと変わったポート番号で放送しているこのラジオについては通信をリアルタイム性のあるものと帯域制御装置は認識していないらしく、ごっそり帯域を削るというのを何度も何度もやるために、せっかくの4096KBという大容量バッファ(笑)も役に立たないのだった。

結論
→もうそれくらいしか可能性残ってない。

行動

帯域を制御する思想自体は別に悪いことではない、と思っているので別になんとも思わないのだが、リアルタイム性を要求する通信にノンリアルタイム的な制御をされるのは実用上差し支えがあるので、サポートにメールを出してみた。
別に、帯域制御装置的に対応をすぐに行うのは(場合によっては)難しいだろうから、改善されなくてもNiftyにポートフォワードさせてもらってラジオを聞けばいいか、と思っていたのであった。

ピンククマ.net(仮名)からの返答

しかし、ピンククマ.net(仮名)からの返答はこちらの想定外の内容であった

********************************************************************
お客さまからのご連絡を受け、お調べいたしましたが、現在のところ
お問い合わせの件に該当する障害h¥情報等はございませんでした。

また、ピンククマ.net(仮名) ADSLでは、特定の通信に対する通信制限等は実施いたしておりません。

このため、他の通信が可能な状況にもかかわらず、特定の通信にのみ
問題が発生する場合は、通信先のセキュリティティや設定による
通信制限、通信経路上の通信障害や混雑、通信制限等が考えられます。

つきましては、問題が発生するネットワークの管理元に現在の状況について
ご確認くださいjますようお願いいたします。

※他のネットワークへの通信の際に、問題は発生していない旨
 お伝えください。

※通信経路等、ピンククマ.net(仮名)以外のネットワークに関しましては、
仕様や設定、通信品質に関しまして、弊社でのご案内、対応は困難となります。
 あらかじめご了承ください。

その他ご不明な点がございましたら、ご遠慮なくお問い合わせください。
今後ともピンククマ.net(仮名)をよろしくお願いいたします。
********************************************************************

と、いうことらしい。0.1秒後、20ページくらいのパワーポイントの資料を返信しようかと思ったものの、0.2秒後には返事を書く気も消失していた。
なぜなら、他のネットワークなら悩まずにちゃんと使えるのだから、ピンクのクマとはお別れのときなんだよね^^、と。

真面目に言うと、自分たちは悪くない、それ以上調査も何も行わない、という態度が許せなかった。(経路も同じ、他のネットワークから見れば正常に使えていることも伝えてこの内容ではわざわざこの会社を選ぶ意味もない。)
しかも、問題が起きているのは大手でSo-netだけなのだから。

ということで、メールを見た瞬間、現在利用しているISPのADSL申し込みを行ったのは言うまでもない。アッカは好きなNSPであったが、そのNSPを利用しているISP大手がこのレベルでは困ったものである。

後日談

ところで、サポートにメールを送ってから10日後くらいから、急に改善され、途切れることはほぼ無くなった。(5日後くらいから様子が変わってきたようだった)
もっとも既に解約手続きは終わっているのでどうしようもないのであるが。

なお、解約時、解約理由のWebフォームにこのサポートからのメールの内容が最低だ、と伝えた後の出来事だった。
仮に対策する意志があるなら、最初の返事でメールで伝えて欲しかった。

さて、今回の件は何が本当の原因だったのか、それは知る由もない。

 しかし、今となって思えば、たとえば、このピンククマ.netはDNS周りの挙動がだめだめだった。(タイムアウト頻発する→原因はDNS負荷分散装置の過負荷・・・(笑))多少ネットワークを分かるユーザなら原因も簡単で対策も簡単に打てる話だろう。
DNS負荷分散装置のIPアドレスでなく、その装置が引きにいってるはずのDNSサーバは正常稼働しているのだから笑えた。

今回も、筆者の推測は当たらずとも遠からずなのだろうとは思うが、それを”通信制限はしていない”などといわれても返事に困る。解約する方が楽である。

それに対しNiftyの一部通信に対し制限は掛けますよ、というポリシーの方がスタンスがはっきりしていて筆者は好感が持てる。

そういえば、今回のトラブルで航空会社の乗務経験者の談を思い出した。
こんな内容だったと思う。

”昔はトラブルがあってもなるだけ事実を伝えないようにしていました。しかし、お客様はどうしても気が付いてしまうものです。最終準備中とアナウンスしても、お客様が機内の窓からエンジンが見えたとき、作業員がエンジンを必死で調整していたらトラブルが起きていることが解ってしまいますね。今は、出来るだけ(自分たちに不利な情報でも)お客様にお伝えするように心がけています。それがお客様に安心して頂くことに繋がるのです。”

| | Comments (3)

迷惑メールをメッセージフィルタで撃退するには?

 最近、山ほどスパムメールが来る。ほんとに良く来る。

 海外からのメールの場合、なかなか送信手段が巧妙で、これはベイジリアンフィルタを用いてフィルタを教育するしか回避手段が無いケースが多い、と思ったりする。
 一方、日本語メールについてはベイジリアンフィルタの日本語対応は満足なレベルに達していないと未だに思う。
文節をどこで区切るか、という部分の実装がベイジリアンフィルタの品質を左右してしまっているようだ。(特にThunderbirdを言及しているが、他のベイジリアンフィルタ採用ソフトでも大同小異な雰囲気もある。)

 しかし、都合の良いことに日本語のスパムメールは技術的なレベルが比較的低い。
 そのため、メールヘッダを参照する単純な固定フィルタでたたき落とせると思えるものがままある。

 今日は、筆者が個人的に設定している固定フィルタをご紹介するので参考にしてみて欲しい。
なお、これらのフィルタ群は実際のスパムメールとそうでないメールの仕分けで一定の実績を誇っているが、今後とも効果がある保証はないし、誤判定される危険があるのはベイジリアンフィルタと同じである。
 基本的には言語的なものではなく、メールヘッダの合理性に欠けるものを排除するだけなので、比較的安心だと思う。

 なお、筆者が使っているのはMozilla Thunderbird(日本語版)のため、その表記に合わせているが、基本的にはヘッダ部が読めて、それに対してフィルタを掛けられるソフトならば特段制限はないと思われる。

 以下を参考に、うまくフィルタを磨いて頂けると幸いだ。また、効果の高いフィルタを思いついた方がいらっしゃれば一報頂けると嬉しい。

1.Message-IDでスパムを判定(いずれかの条件に一致)
Message-ID が次を含む "example.net"

コメント:実際によく届くスパムのMessage-IDのドメインに合わせて設定すると良いだろう。

2.件名でスパムを判定(いずれかの条件に一致)
件名 が次を含む "未承諾広告※"
件名 が次を含む "※未承諾広告"

コメント:言うまでもない。届くたびにバリエーションを増やしている。

3.送信元アドレスの不正(すべての条件に一致)
差出人 が次を含まない "@"
Return-Path が次を含まない "@"

コメント:FromもReturn-Pathも無いメール、仮に正当なものでも読む気が起こりません。

4.hotmailを詐称する不正メール(すべての条件に一致)
Message-ID が次を含む "hotmail"
Message-ID が次を含む "qmail"

コメント:現在のhotmailはqmailを使っていない。

5.yahooを詐称する不正メール(すべての条件に一致)
差出人 が次を含む "yahoo"
Received が次を含まない "yahoo"

コメント:yahooからのメールは基本的にReceivedヘッダのどこかにyahooの文字が出ている。すこしは知恵を使いましょう。>業者

6.HELOが変(いずれかの条件に一致)
Received が次を含む "HELO allabout.co.jp"
Received が次を含む "HELO example.com"
Received が次を含む "HELO hoge"

コメント:HELOにallabout.co.jpなんか使いません。

7.Spammer御用達メーラー(いずれかの条件に一致)

X-Mailer が次を含む "SupperMailer"
X-Mailer が次を含む "BLT-TECH_EXEMAIL_1"
X-Mailer が次で終わる "Microsoft Outlook Express"

コメント:一般ユーザの使うOutlook Expressならばバージョン名がその後に続く。
DLLを直叩きしているようなスパムメールでこうした手合いがそこそこあるようだ。

P.S. Outlook Express 6では上記の設定が出来ないようだ。

| | Comments (0)

イー・アクセスがアッカ・ネットワークスの買収を模索中?

 通信関係の話題としてホットトピックスなので、このブログの趣旨からはそれるが簡単に整理しておこう。

 事の発端は、本日イー・アクセス株式会社(681119)が関東財務局に提出した8/7付 変更報告書(大量保有報告書)の内容だ。正確には大量保有報告書1通とその訂正報告書2通である。(EDINETトレイコード:006GDUBW/006GDUC0/006GDUC1)

 内容は、ライバルであるはずの株式会社 アッカ・ネットワークス 株式(681117)を10.33%(12,827株)を本日付で保有することになった、という趣旨である。

 イー・アクセスがアッカ・ネットワークスに興味を持っているのではないか?という推測は本年6月26日にイー・アクセスが発表した有価証券報告書によっても読みとることが出来る。

投資有価証券->その他有価証券
アッカ・ネットワークス 6000株(4.83%)

 これは平成17年度の有価証券報告書であるが、アッカ・ネットワークスの平成17年度末締めの株主名簿には掲載されていないため、株主名簿の締め日と有価証券報告書の締め日のわずかな隙間を狙って購入したものではないかと推察される。

Update:アッカ(12月決算)とイー・アクセス(3月決算)の期末は違っているので、わずかな隙間を狙う必要は無いようだ。

 4.83%の保有比率というのは、非常に巧妙な数字で財務局へ報告義務の発生する5%よりわずかに下を狙ったものと思われる。そして、ここ数日で一気にアッカ・ネットワークスの10%を占める大株主の名乗りをあげたわけだ。

 10.33%というと、昨年12月末締めのアッカネットワークスの株主名簿を参照すると

1位 NTTコミュニケーションズ 24,489(19.7%)
2位 三井物産 12,820(10.3%)
3位 大和証券SMBC 4,750 (3.8%)
4位 IT2000投資事業組合 3,969 (3.2%)
5位 モルガン・スタンレー・アンド・カンパニー 3,861 (3.1%)

 となっている。三井物産と並ぶ規模の株数を得ていることになる。余談だが、三井物産はTBSやイー・モバイルにも出資している。(TBSはイー・モバイルに出資している)

 今後、この話の行方はどうなるのかは筆者には皆目わからない。

 技術的な側面からの話をするとすれば、通信事業は規模メリットが効いてくる産業の一つであることは間違いない。通信事業は一度、通信設備を構築すると、あとは”ネットワーク全体のランニングコスト+加入者ごとに掛かる従量的な費用”の合計が維持コストとなる。

 ここで、加入者ごとにかかる従量的な費用に対して、ネットワーク全体のランニングコストはネットワーク規模の拡大ほどには増加しない。

 そのため、同業他社の買収によって顧客基盤を増やし、増収増益につなげようとする考え方がある。イー・アクセスとアッカ・ネットワークスの場合、細かい部分のネットワーク構造の差異に目をつぶれば、ほぼ同じネットワーク構造を持っている。そのため、買収(or 合併)に成功した場合のイー・アクセスの得るインセンティブ(増収増益する可能性)は非常に高いと推察する。

 筆者としては、アッカ・ネットワークスには独自路線を貫いて欲しく(以前のblog記事でもご紹介差し上げた通り)、いつも期待のまなざしで見つめている。やはり、健全な競争があってこそ技術のイノベーションが生まれる。たとえばACCAのオートコンフィグモデムなどはとても面白い発想だし人に優しい。また、ADSLの法人向けサービスでは唯一、クオリティが高いサービスを行っているのだから。

 しかし、NTT地域会社のフレッツADSL加入者数が純減に転じた今、ADSL事業の伸びが今後期待しずらいのは明白である。アッカ・ネットワークスが選ぶ選択肢が徐々に狭まりつつある。実質的な規模で言えば、ADSL業界で両社は3位と4位に位置する。商業的には合併は望ましい選択なのかもしれない。(NTT地域会社をひとつの事業者として数えた場合)

 なかなか難しい局面であるが、高品質なネットワークサービスを安価で提供しつづけるためにアッカ・ネットワークスにはさらなる努力していただきたい。....とりあえずモデムの持ち込みをOKして頂けないでしょうか?^^;;;

Update:
初稿時の時点ではイー・アクセスは大量所有報告書を提出したことに対するコメントはしていなかった。8/8(翌日)付けのプレスリリースにてコメントを付けたようだ。これによると、

”イー・アクセスは、自社の業績見通しにおいて今年度も引き続き契約数の純増を見込むなどADSLの市場性を高く評価しており、アッカ・ネットワークスの現在の株価は投資価値があると判断いたしました。今回の株式取得は、現段階においては、市場の状況に対応する「純投資」を目的としたものです。”

と取得理由を説明している。

なお、この取得理由については有価証券報告書にも”純投資”と記載されているため、取得理由については一貫している。ただ、今回のプレスリリースでは”現時点においては”と注釈をつけるなど解釈の余地を残すものとなっている。

また、このさらに翌日(8/9)に、イー・アクセスは第一四半期の決算発表を行っていることも付け加えておきたい。この決算発表においては、イー・アクセスはADSL加入者の引き続きの純増を報告するなど、ADSLの市場環境は引き続き良好なことを強調していた。

Update:2008/1/17 記事中のリンクに適切でないものを発見したため、リンク先の修正(NTT地域会社のニュースリリース)を行いました。文章の変更はありません。また、内容も変わりません。

投資勧誘目的の不存在

本情報は、本日発表されたEDINET情報について知っていただく為のものであり、読者に対して投資を勧誘するものではありません。また、いかなる証券の投資勧誘を目的としたものでもありません。
また当情報の正確さ・完全性に関していかなる保証をするものではなく、その情報が誤りを含んでいないこと、有用なものであること等は保証いたしません。

| | Comments (0)

OP25B(Outbound Port 25 Blocking)について

最近OP25Bという言葉を頻繁に聞くようになった。

 これは、日本のISPでもメジャーになりつつある手法で、自社ネットワークからのメールの送信をある程度規制する手段のことだ。Outbound Port 25 Blockingの略。

 これは悪質なメールを撒く業者が当該ISPを利用してスパムメールをばらまいていることへの大きな意味での対処療法になる。
   身の回りでも、 数日前にSo-netでは規制が始まった。実際に筆者のメールが一通素直に送れなくなった記念に、これまでの経緯と現在の状況をまとめてみることにした。

OP25B以前

 今までは、ISPにスパムメール送信者が居る、との通報を受けた場合、事実関係を確認して、事実であればそのユーザーに警告し、それでも収まらなければISPから契約解除といったフローになっていたように思われる。

 しかしその場合、事実関係を確認することがとても難しい。なぜならば、ISP側はそのユーザがどんなメールを送信していたか知る術が無いのだ。ISPが知っている情報といえば、

1.ユーザID
2.通信開始時間
3.通信終了時間
4.IPアドレス
5.トラフィック量(当該セッションにおける)

くらいが伝統的に分かっている情報だろう。(流行の帯域制御装置等が導入されていると別)

スパムメールの配信を行う場合、通常はISPの所有するメールサーバ経由ではなく、接続したPCからターゲットのメールアドレスに該当するMXを参照してメールを投げる。そのためスパムメールをどれだけの規模でばらまいていたかも含め、ISPには正直よく分からなかった。被害者から通報を元に恐る恐る調査を重ねる、といったところだろうか。

スパマーの逆襲

ISPの弱腰な態度とは裏腹に、仕掛ける側はとてもアグレッシブだ。

ISPのオンラインサインアップを利用してサインアップを行った後、大量にメールを巻き逃げすることに並々ならぬ気合いが入っている。いくら調査を重ねて、契約解除にこぎ着けたとしても、その頃にはスパマーは別のISPや同じISPで新規ユーザーとしてスパムをばらまいていた。

OP25B導入のメリット・デメリット

OP25Bが導入されると、スパマーはオンラインサインアップを利用したメールの投げ逃げが難しくなる。
  また、仮にスパマーがメールを送信しようにも以前のような相手のメールアドレスのMXレコードを参照して、相手のメールサーバにメールを送信することが出来なくなる。

どうしても送信したければ、ISPのメールサーバ経由の送信になるため、ISP側は証拠を握りやすくなる。

すくなくともそのISPがスパマーの巣窟となることは難しくなるため、長期的には良いのではないだろうか。

デメリットは、モバイルユーザに代表されるような接続ISPが頻繁に変更になるユーザの場合、設定変更が要求されることだ。
  たとえば、メールソフトや利用するメールサーバ側双方に設定変更が必要となる。その設定変更が古いメールソフトを利用しているとサポートされていなかったり、メールサーバ側がサポートされていないと結構悲惨だ。

逃げ道はあるのか?

ある。

1.OP25Bの対象とならないアクセス回線を使う

 ISPによってはOP25B対象アクセス回線を確認すると、ACCAやeAccessの回線が規制対象から除外されている。これは、スパマーはオンラインサインアップで”すぐに使える”回線からスパムを投げるケースが多いためだと推測される。

 逆にフレッツ系やダイヤルアップアクセスはほぼ間違いなく規制対象である。

2.モバイル利用時はVPN経由でメールを投げる

 最近は、ヤマハのルータにもついているPPTP機能等を用いて、いつも同じIPアドレスからメール送信をするのも運用をラクにする手段のひとつだと思われる。

3.Submissionポートを使う

 これがラクかもしれない。メールサーバ、メールソフトが素直に対応していればの話ですが。単にPort 587に振れば良いというわけではなくて、SMTP Auth等が必須だったりするところが厄介だろうか。SMTP Authに対応しているソフトとしてはMozilla Thunderbird等がある。

今後について

 今後は、ISPによってはIP25B(Inbound Port 25 Blocking)等の対策も始まっている。今後、”メールサーバ”は固定IPアドレスが必須”という事になっていくかもしれない。

 しかし、ほどほどの規制にして欲しい、というのが正直な筆者の感想である。携帯事業者向けのOP25Bくらいで充分だと思うのだ。

| | Comments (0)

MBR地獄に填る(Thinkpad R50e)

Thinkpad R50eが安かったので買ってみたのだが、過去の機種(HPA機)と比べるとリカバリー方法が若干異なっていて、かなりハマってしまった。20時間くらいは費やしただろうか。
今後のために備忘録を残しておきたい。

経緯

ThinkpadのDisk to Disk機能で用いるサービス区画をバックアップしておこうと考えた。
まず、初期導入のWindows XP Homeを削除し、何も考えずにDriveCopyPlusでバックアップイメージを作成した。(HPAによるリカバリーであると勘違いしていたため、FAT区画を作成しようとした)
DriveCopyPlusで作成したファイルのバックアップを実施した。
(バックアップイメージをネットワーク越しで転送するため、テンポラリでWindows2000をインストールした)

作業終了後、Disk to Diskによるリカバリを実施しようとしたが、Access IBMボタンを押しても立ち上がらず。(MBRがIBMオリジナル以外に書き換えられたためPredesktopがブート不可に陥った)

結論

置き換えられたMBRをIBM製のものに書き戻す必要がある。
書き戻すためにはIBMのbmgr.exeやbmgr32.exeを用いる
書式 bmgr /fbootmbr.bin

禁止事項

IBM Rescue and Recoveryは導入しては”いけない”。初期導入のイメージのリカバリが掛けられなくなるなどの不具合もあり、また削除するとIBM Predesktop Areaごと立ち上がらなくなる可能性がある。

ただし、bmgr.exeやbmgr32.exeがIBM Rescue and Recoveryを導入すると同時に導入されるため、"IBMサービス区画を完全に書き戻す方策を持っているならば”その目的で入れるのは手である。

bmgr.exeやbmgr32.exeはMBRをIBMオリジナルに書き換えるために用いる大切なツールとなる。どうにかして手に入れることが大事。

今後同様の作業をする方へのアドバイス

1. 作業実施前にMBRのバックアップを作成すること
2. ディスクドライブのC/H/SデータとLBAの値を各種ツールで読み出しメモしておくこと
(作業失敗時にはとても有り難いデータとなる)
3. bmgr.exeとbmgr32.exe、同一ディレクトリの中にあるbootmbr.binファイルをどこからか探し出して
 かならず手元に手に入れた状態で実施する
4. DriveCopyPlusでIBMサービス区画のバックアップを作成する場合は先にbmgr.exe /US等して、通常パーティションに戻してからバックアップを取る方がbetterと推測される。
また、作成したファイルが適用可能かどうか先に必ず読み込ませて確認すること

あると嬉しいツール

1.DriveCopyPlus(か同等のツール)
2.MBM 0.38
3.IBM製 bmgr/bmgr32
4.確実に適用可能なサービス区画のイメージ
5.USB接続のフロッピードライブ
6.USB接続のハードディスクドライブ(DriveCopyPlusから直接読み出し可能)

| | Comments (0)

その他のカテゴリー

ADSL | Network | RT57i | RTTips | VoIP | VPN | YAMAHA | パソコン・インターネット | モデム