日本で無料 WiFi が普及しないたったひとつの理由

写真はラオスのなにもない村。でも野良WiFiは飛んでた。

日本では無料公衆無線LANが非常に少ない

海外のカフェやホテルでは無料で WiFi インターネットアクセスが提供されていることが多い。しかし今どき、日本ではあまり普及していない。海外旅行者などは口を揃えて「海外じゃ無料、日本は遅れている」というが、日本のキャリアはケチなのか？

回線が犯罪に使われるとか、何かあったらかなり面倒なことになるから

日本の WiFi インターネットアクセスが有料なのは、本人認証のシステムに必要なコストが大きいからで、回線を無料で提供しないカフェやキャリアがケチなのではない。ユーザから見れば同じことだが、インターネット回線自体よりも認証のシステムにコストがかかりすぎるのである。

無料のインターネットアクセス提供でも特定電気通信役務提供者となるので*1、プロバイダ責任制限法など権利侵害情報の対応では民事*2、警察の犯罪捜査では刑事手続による発信者情報開示請求が行われる。ここで身元が特定できないアクセスを受け入れる、ログが取れないなど設備上の制限を含む発信者情報開示請求に対応しないことが、故意または重過失と見なされる可能性が残る*3 *4。

公衆WiFi提供者への開示請求は、想像以上に頻繁にある

たとえば、日本国内である店舗・サービスをチェーン展開している企業が提供している無料WiFiに関して、1-2ヶ月に一度ほど開示請求があるという。

実際に、ログが残っていない等での開示請求不能ですぐに無料公衆無線LAN提供者自身が追求される可能性は低いのかもしれない。が、少なくとも面倒なことにはなる。ログがあればすぐ提出して済ませるところなのに。

PC遠隔操作マルウェアによる誤認逮捕事件では、IPアドレスを確証とした。現状、日本ではそういう捜査が行われる、ということである。

認証システムは安価な既製品がきわめて少ない

日本は無料 WiFi が少なすぎるとか、別の回線でメールアドレス登録しなきゃいけないのは鶏と卵問題だとか、故に日本は遅れているといわれるが、認証システムつきのWiFi機器は安価な汎用品が少なく、管理も簡単ではない。仮に回線コストだけで無料 WiFi を提供できるような状況なら、おそらくもっとたくさんの無料公衆無線LANが提供されているのではないかと思う。

たとえば喫茶店の個人経営者がインターネットアクセスを無料提供しようとしたとき、安心して導入できる安価なシステムがきわめて少ないのが問題である。

代表的なソリューション FREESPOT は接続性に問題があるように見受けられる。透過プロキシのようなものが入っているようで通信をいじっているように見える。問題が多い。たとえば、HTTP での接続は不安定、SMTP(Submission)で SSL(TLS)接続をするためネゴシエート中に STARTTLS コマンドを発行した瞬間にコネクションが切断されるなど。ログを採取し、不正な利用を防ぐために必要なことかもしれないが、不安定なため通常利用も支障がある状況で、あまり人気がない。

ハードウェアの話になるが、もしも、つながった端末の MACアドレスや Web の接続先をある程度長期間ロギング可能なルータや無線アクセスポイントが安価に販売されていたら、多少は状況がマシになるのかもしれない。また、以上の法的な項目に関しては、弁護士に相談したり都道府県警察本部のサイバー犯罪相談した結果をメモ書きしているだけで、私自身は法律の素人なため、間違いがあれば指摘していただきたく。

ちなみにアジアを旅行するとやたらと暗号化なしの野良 WiFi が飛んでいるが、彼らの回線が誰にでも使えるのは捜査なんてないから。これを「途上国は遅れている」と捉えるか、「そういう捜査なんてそもそも無理なんだし、彼らは遥か未来のサイバー世界に行っちゃってる」と捉えるか。

---

*1:不特定の者が公衆無線LANを用いて特定電気通信を行う場合、公衆無線LANは特定電気通信設備であり、特定電気通信設備を用いて特定電気通信役務を提供することになるので、特定電気通信役務提供者となる。*3も参照

*2:特定電気通信役務提供者の損害賠償責任の制限及び発信者情報の開示に関する法律

*3:「経由プロバイダ事件」平成22年04月08日最高裁判所第一小法廷（平成21(受)1049）

*4:最高裁は賠償責任は否定したが発信者情報の開示をKDDIに求めている

そもそもどうして満充電にしないで使いたいのか

といわれた。

リチウムイオンバッテリは以下の条件が揃ったとき、急激に劣化する。

• 満充電
• 高温(大体45℃以上)

また

• 深放電(過放電)
• 放置

　他にもセルバランスとかあるけども、基本的にはこういったことを起こさず適度に使っていれば、メーカーが謳うように 500 サイクルの寿命を全うできると考えてよい。

　一番まずいのが満充電で高温になること。劣化が非常に早くなるし、運が悪いと即死することもある。ただし、充電量が少ない状態ならば結構熱くなっても割と大丈夫だったりする。だから、満充電のラップトップマシンが高負荷などによって高温になったら、ACアダプタを外してバッテリ駆動に切り替えて放電させるのが理想。でも、面倒だから普通はそんなことしない。

　Let's Note などの ECO モードは「満充電すると寿命が短くなるから80%で充電をやめておく」というが、むしろ「満充電のときに高温になると そこで死を迎えやすいが、満充電でなければ高温になったとしても死ににくい」というニュアンスのほうが近く、またそれがバッテリ本来の寿命だろう。

　リチウムイオンバッテリに興味がないのであれば、寿命を迎えたら交換する使い方が最も賢い。もしもバッテリ自体に興味があれば、(満充電 && 高温) の AND 条件を満たさぬようにすると、寿命を延ばすことができるだろう。さらに興味があれば、BAYSUN のリチウムイオン電池の話 も面白い。

　スマートフォンの充電制御も温度が考慮されている。

　「充電器につないだまま使っていても充電が追いつかなくて、バッテリが減っていってしまう」といった事例では、充電が追いつかないのではなく冷却不足の場合があるように見受けられる。スマートフォンのような機器は、内部温度が上がるとバッテリ保護のために充電を止める、または充電電流を下げる制御を行うことがある。すると、高負荷なアプリを動かすと充電が追いついてないように見える。

　また、外部電源が接続されていて、既に 100% 充電されている状態から高負荷などにより内部が高温になった場合、外部電源は(供給されていても)使用せず、バッテリを満充電状態にしないためにバッテリから使うような制御を行うことがある。これもまた、充電が追いつかないように見えるだろう。

　他にも、たとえばバッテリ内蔵の PND（カーナビ）は高温にさらされやすいため、さらに積極的な放電を行う製品もある。電源がONでないスリープ状態でも、高温になると自動的に内蔵バッテリの放電処理を行う。

　これらの自動的に行われる放電もサイクルにカウントされると考えてよい。ワンサイクルは充放電の浅深にあまり関係がないと考えられており、知らぬ間にバッテリの充電サイクル寿命が削られていっているだろう。

MacBook の AC アダプターと Hyperjuice, Airline Adapter の充電のなぞ追試

この記事の続きです:: id:ektar:20120813

Apple Airline 電源アダプタを買ったのでテストした。電源は手元にあった IBM Thinkpad のACアダプタ(16V/4.5A)がちょうどよかったので、切断してシガーソケット化し、Airline アダプタを接続できるようにした。

　結論は Airline アダプタを使えば、いっさい充電されない。目論見通りで、成功である。OS X v10.7 ではバッテリ残容量にかかわらず、メニューバーは以下のようになる。

　ただし、Mid 2012モデル以降に充電するには MagSafe2 変換 が必要であり、これを使うと(?)LEDの挙動が変わる。実際には充電されていないのに、バッテリが満充電でないときはLEDがオレンジになる。これは MacBook Pro Retina 15inch での例。LEDはオレンジなのに「充電中：いいえ」

　MacBook Pro Mid2009 では MagSafe 変換もいらず、つねにLEDはグリーンになる。

45W ACアダプタの MagSafe 部分のみを流用することで、出力電流が低い TL160K でも Retina MacBook Pro を充電することができる。

モバイルバッテリ TL160K で Retina MacBook Pro を充電してみた #3

電源の能力、充電の可否などは MagSafe コネクタ部によって決まる可能性が高い。

　電源部と MagSafe コネクタ部は単純にV+とGNDだけでつながっている。ここに何らかの情報を載せているとも考えにくい。実際に上記の引用記事ではコネクタ部のみを切断して、ポータブルバッテリーを 45W だと認識させることに成功している。

MacBook の AC アダプターと Hyperjuice, Airline Adapter の充電のなぞ

　写真は去年の気仙沼。AGFA ULTRA50などというビンテージフィルムで撮影

　MacBook の MagSafe コネクタとバッテリの充電はどうも面倒なことがあるようだ。

　Hyperjuice などの外付けバッテリーで駆動した場合、MacBook 本体には電源供給されるものの充電されない現象があるときいた。

　また、MacBook の内蔵バッテリが 100% 満充電になっていなくても充電を停止し、ACアダプタからの給電で動作する方法を探している。どうせACに繋ぎっぱなしにしたら、早々にバッテリーが死ぬのはわかりきっているからだ。Let's Note や Dynabook のように80%で止める機能もない。充電制御は SMC などの低レイヤで行われているので、アプリみたいなレイヤからハックするのも不可能だろう。Hyperjuice で充電されない原因がわかれば、逆に利用できそう。

• MagSafe Airline電源アダプタを使ってコンピュータの電源を得られますが、バッテリーの充電はできません。
• MagSafe Airlineアダプタは自動車のシガレットライター電源には対応していません。
  • 結果は車のエンジンがかかっている時は　「充電できていません」という表示が出ますが　外部電源を供給しているという形で使用できました。

Apple MagSafe Airline 電源アダプタ

　アップルの Magsafe Airline アダプタを使用すると充電ができないらしい。たしか、航空機の座席電源は 5A くらいしかとれないはず*1なので、MacBook pro など大きなラップトップではそれを上回ってしまう可能性があるから、わざと充電できないようにしている可能性がある。

• 13.5V付近から本体の電源アイコンがコンセント表示に変わります。
• 電源は供給されているようですが、充電はされません

Apple MagSafe Airline 電源アダプタ bbs.kakaku.com

　Airline アダプタを車載用に転用するには、下限が 13.5V ではかなり厳しいと思われる（エンジンがかかっているときの公称が 13.8V, かかってないときは 12.0V）。航空機は DC15V。なお16Vのポータブルバッテリーからの供給はOKだが、やはり充電はされないとのこと。

　Hyperjuice 関連のサイトを読むと、単に供給電圧の問題で充電されないという意見が多いように見えるが、MacBook本体とACアダプタは通信しているように見えるので（MacBook 側のシステム情報で接続されている AC アダプタのワット数、シリアル番号などが表示される）、そんなに簡単な話じゃないだろうと思っていた。

---

http://pangea.stanford.edu/~schmitt/magsafe/ が面白かったのでメモがてら超訳

Apple Airline MagSafe アダプタについての注意

　アップルは、Airline MagSafe アダプタは電源を供給するがコンピュータのバッテリーを充電しない、としている。この警告は正しい。以前、この充電されない問題は単に航空機から供給される電圧が低いためかと考えていたが、そうではなく、Airline MagSafe に加えられた電圧と充電されない問題は無関係であることがわかった(Kieran Hervold による報告)。
（略）

MagSafe コネクタについて

PIN(s)	Function
1, 5	V-
2, 4	V+
3	LED/charging control?

　（MagSafe コネクタについている）あの LED はちょっと不思議。V+ へ約 16V 以上が加わるとグリーンに光る。Apple の AC アダプタは、無負荷時には約 6.25V まで落ち、LEDは消える。よくある多機種用のユニバーサル AC アダプタは負荷にかかわらず常に設定した電圧を出力するが、この場合 LED はコンピュータが接続されていなくても点きっぱなしになる。

　MagSafe の LED はコンピュータが充電中であることを知っているときにオレンジになる。したがって、MagSafe の pin 3 (the center pin) で LED の色をコントロールしているのではないかと推測される。pin3 と V- (GND) の抵抗を測ると約 426 kΩ, pin3 と V+ の間は導通は無し。また注目すべきことに、ユニバーサル AC アダプタから電源供給した場合、コンピュータから MagSafe を外しても同じ色のまま点きっぱなしになる。

　Kieran Hervold は MagSafe コネクタを分解した。 コネクタ内部には小さいICがあり、これが LED の色を制御しているのではないか? 同様に Apple Airline MagSafe アダプタはコンピュータにバッテリ充電を無効にするようコントロールしているのではないかと推測される。

Apple MagSafe アダプタの充電ストラテジ

65W アダプタ

自分の知る限り、つねに 16.5V をコンピュータにかけている。

85W アダプタ

85Wアダプタは、負荷によって出力電圧を変えている。最大負荷(充電時など)は 18.5V まで上がる。最小負荷では、16.1V 〜 16.5V。

バッテリが 37% から 100% 充電になるまでの電圧を監視した(スクリーン最大輝度、CPU負荷は低、WiFi はオン)。70%以下では 17.0V 〜 18.1V, 71% になったとき、突然 16.5V まで下がった。充電中以外は、16.1V 〜 16.4V。

---

How to build an auto / airline MagSafe power adapter

結論はまだない。なぜなら Airline MagSafe アダプタは高くて買えない。

---

2012-09-21 続きを書きました id:ektar:20120921

*1:http://en.wikipedia.org/wiki/EmPower_%28aircraft_power_adapter%29

Argyll CMS を使って ubuntu でも液晶モニタのキャリブレーション

ubuntu でもモニタのキャリブレーションできるよ！

2011年8月下旬、秋葉原のショップインバースでジャンクのレッツノート CF-T5 をわずか 8,000円で買った。既に所持している CF-W5（新品で25万くらいで買った）のサブで ubuntu 専用機が欲しいなーと思ってたところだった。

良い買い物をした。買って一ヶ月以上経つけど、なんの故障もなく使えてるし、バッテリーも4時間はもつし、CoreDuoでそれなりに実用的な速度で動く。外観もそんなに悪くない（上の写真を見て）。でも、ひとつ難点があるとすれば、液晶のバックライトが劣化してきて黄色く見えることだ。モニタを何台も並べていると色の違いが気になる。

モニタを校正することにした。Mac や Windows なら市販のモニタキャリブレータが使えるけど、Linux (X) でそのままでは使えない。仮想マシンでも LUT が利用できないので無理だろう。ノートだからモニタを外して別のマシンで校正することもできない。

オープンソースの CMS アプリケーション Argyll Color Management System を試すことにした。ubuntu 11.10 では apt-get で簡単にインストールできる。適合する古い測色器(x-rite DTP94)が手元にあった。

Argyll は CLI ツールだけど、易しい GUI ラッパー Argyll dispcalGUI も出ている。しかし今回は、パッケージの依存関係を解消するのがだるくて使っていない。

argyll パッケージ内の dispcal を使って校正, icm モニタプロファイルを作成する。
dispcal の man はこちら。

% dispcal -v1 -d1 -c1 -o CF-T5_1.icm -O "CF-T5 display icm profile 1st" -qm -yl -t5000 -p 0.5,0.5,0.5 -K c

測色器をつないでから dispcal を実行してね。

画面の真ん中にカラーパッチが表示されるので、そこに測色器をセットする。

Setting up the instrument
 Instrument Type:  DTP94
 Serial Number:    0238xx
 Boot version:     D929
 Software version: DB06
Want projection measurement capability but instrument doesn't support it
so falling back to display mode.
Place instrument on test window.
Hit Esc or Q to give up, any other key to continue:
Display type is LCD
Target white = 5000.000000 degrees kelvin Daylight spectrum
Target white brightness = native brightness
Target black brightness = native brightness
Target advertised gamma = 2.200000

Display adjustment menu:
Press 1 .. 7
1) Black level (CRT: Offset/Brightness)
2) White point (Color temperature, R,G,B, Gain/Contrast)
3) White level (CRT: Gain/Contrast, LCD: Brightness/Backlight)
4) Black point (R,G,B, Offset/Brightness)
5) Check all
6) Measure and set ambient for viewing condition adjustment
7) Continue on to calibration
8) Exit

実行すると測色器が検出され、ディスプレイの輝度やゲインの設定アシスタントモードになる。*1 このノートPC、もはや最大輝度にしても明るくないし、他に何も調整ポイントがないので skip した(7を押す)。

patch 6 of 6
Black = XYZ   0.61   0.65   0.64
Red   = XYZ  29.09  16.87   2.28
Green = XYZ  19.43  32.60   6.82
Blue  = XYZ   9.84  10.67  39.33
White = XYZ  57.48  59.21  47.50
patch 128 of 128
Initial native brightness target = 59.210000 cd/m^2
Had to scale brightness from 59.210000 to 58.371133 to fit within gamut,
corresponding to RGB 0.998531 1.000000 0.947055
Target white value is XYZ 56.676262 58.371133 44.541255
Adjusted target black XYZ 0.61 0.65 0.63, Lab 9.90 -1.26 -3.71
Target black after min adjust: XYZ 0.610 0.650 0.630, Lab 9.904 -1.260 -3.706
Gamma curve input offset = 0.000000, output offset = 0.011136, power = 2.259617
Total Iteration 3, Final Samples = 64 Final Repeat threshold = 0.600000
Creating initial calibration curves...
Doing iteration 1 with 16 sample points and repeat threshold of 1.200000 DE
patch 16 of 16
Brightness error = -1.261133 cd/m^2 (is 57.110000, should be 58.371133)
White point error = 1.024338 deltaE
Maximum neutral error (@ 1.000000) = 1.319932 deltaE
Average neutral error = 0.795555 deltaE
Failed to meet target 1.200000 delta E, got worst case 1.319932
Number of measurements taken = 44
Computing update to calibration curves...
Doing iteration 2 with 32 sample points and repeat threshold of 0.848528 DE
patch 32 of 32
Brightness error = -1.601133 cd/m^2 (is 56.770000, should be 58.371133)
White point error = 0.998361 deltaE
Maximum neutral error (@ 1.000000) = 1.457514 deltaE
Average neutral error = 0.595230 deltaE
Failed to meet target 0.848528 delta E, got worst case 1.457514
Number of measurements taken = 63
Computing update to calibration curves...
Doing iteration 3 with 64 sample points and repeat threshold of 0.600000 DE
patch 64 of 64
Brightness error = -1.991133 cd/m^2 (is 56.380000, should be 58.371133)
White point error = 1.014456 deltaE
Maximum neutral error (@ 1.000000) = 1.669090 deltaE
Average neutral error = 0.483882 deltaE
Failed to meet target 0.600000 delta E, got worst case 1.669090
Number of measurements taken = 219
The instrument can be removed from the screen.
Written calibration file 'c.cal'
Luminance XYZ = 0.000000 58.854391 0.000000
White point XYZ = 0.968459 1.000000 0.790729
Black point XYZ = 0.010818 0.011650 0.011543
Created fast shaper/matrix profile 'lib/CF-T5_1.icm'

どれどれ…見た目 相当ましになってる！

できたプロファイルは以下のようにしても反映できる。

% xcalib CF-T5_1.icm

プロファイルを無効にするには

% xcalib -clear

see also man (1) xcalib : xcalib

もっと酷いガンマカーブを想像してたので、こんなもので収まってるんだなとむしろ感慨深い。少し暗くなったけど、白い画面も気持ち良く見られるようになった。

ちなみに i1 display 2 はなぜか検出されなかった。検索すると使えてるっぽい記述があるので手元の環境の問題かもしれない。関係ないけど xrite 社のサポート電話番号は土曜休みみたいで今日はかからなかったぞ。

*1:測色器が検出されないとエラーで終了するので、/var/log/syslog とかをみて適宜検出されるようにする。測色器の名前と linux とかキーワードで検索すれば解決するかもしれない。udev が何か奪ってるのかも知れない。

NEC IX2015

夏から冬になる。秋がない。写真は沖縄。けっこう寒かった。
デジカメのズームレバーを壊してしまった。

ルータ NEC IX2015 の proxy-dns (DNS cache) に負荷をかけ続けるとルータが再起動する件。

NEC IX2015 を知人の集合住宅(シェアハウス)に設置するために設定し、テストのためしばらく自宅で動かしていた。知人宅は住人が多いため端末数もそれなりに多く、またゲストも多く定期的に訪問する。そんなこともあって気に掛かっていたうちの設定のひとつ DNS proxy/cache で、ちょっと実験のため webalizer の DNS 逆引きでテストしてみようかと思った。webalizer のそれは、設定によってかなりエグい動作をするので、負荷テストのかわりに使用している*1。

結論からいうと正しく対応できなかった。ファームは 8.3.48.

webalizer.conf に設定したのはこれくらい。

DNSChildren  64

IX2015 の関係がありそうなところはこんなもん。IPv4 のみ。

ip ufs-cache max-entries 9600
ip ufs-cache enable
!
dns cache enable
dns cache max-records 255
dns cache lifetime 300
dns ncache lifetime 60
!
proxy-dns ip enable
proxy-dns ip max-sessions 127
proxy-dns ip query-retries 3
proxy-dns ip query-interval 3
!
!
interface FastEthernet0/0.1
  description PPPoE
  encapsulation pppoe
  auto-connect
  ppp binding hoge
  ip address ipcp
  ip tcp adjust-mss auto
  ip napt enable
  ip napt inside list pppoe-napt
  ip napt translation max-entries 32768
  ip napt translation max-entries per-address 2048
  ip filter priv 100 out
  ip filter all-permit 65000 out
  no shutdown

ix2015-sh(config)# sh proxy-dns
Proxy DNS for IPv4 enabled
  Max sessions 127, life time 90 seconds
  Query max retries 3, retransmit interval 3 seconds
  DNS server(s):
    61.207.11.153, dynamic (IPCP), FastEthernet0/0.1, priority 100
    221.113.139.137, dynamic (IPCP), FastEthernet0/0.1, priority 100
Proxy DNS for IPv6 disabled
  Max sessions 32, life time 90 seconds
  Query max retries 4, retransmit interval 5 seconds

この設定では proxy-dns は PPPoE の ipcp でもらってきた DNS サーバに問い合わせる。これで IX2015 の proxy-dns に対して webalizer が激しく逆引きしまくると IX2015 がギブアップする。

ix2015-sh(config)# show memory
Calculating configuration memory size...
Heap memory:
  97% memory used, 3% memory avail
  Total 57241800 bytes
    2117988 bytes free (1934964 clean, 183024 dirty)
    55123812 bytes busy (39964144 reserve, 15159668 dynamic)

ヒープが徐々に消費されてゆき 100% に達してしばらくすると死ぬ。すると、コンソールにこんなのが出る。

ix2015-sh(config)# 

System uptime is  58 minutes

CPU is MPC8270A: PVR = 0x80822014, IMMR[16:31] = 0x0a10

CPU Register Context:
R00   = 0x0000c0e6  R01   = 0x00b5b6b0  R02   = 0x00968830  R03   = 0x0000f5db
R04   = 0x00441f80  R05   = 0x00000000  R06   = 0x006d0000  R07   = 0x006d0000
R08   = 0x006ced50  R09   = 0x03ffee7c  R10   = 0x006ced5c  R11   = 0x0085c598
R12   = 0x44b5ba84  R13   = 0x00000000  R14   = 0x00000000  R15   = 0xac1000fe
R16   = 0xac100101  R17   = 0x00000000  R18   = 0x00870000  R19   = 0x00860000
R20   = 0x00860000  R21   = 0x00b5b6e0  R22   = 0x00880000  R23   = 0x0000649e
R24   = 0x0000aa7e  R25   = 0x0085c598  R26   = 0x0000002e  R27   = 0x00441f80
R28   = 0x00000000  R29   = 0x0000f5db  R30   = 0x0085c598  R31   = 0x0000f5db
CR    = 0x24b5ba44  MSR   = 0x00003030  LR    = 0x000002a0  SRR0  = 0x00178750
SRR1  = 0x0008b032  SPRG0 = 0x03000000  SPRG1 = 0x00000000  SPRG2 = 0xfe00f1cc
SPRG3 = 0x00000001  XER   = 0x00000000  CTR   = 0x00000000  DAR   = 0x00000000
DSISR = 0x00000000  ESR   = 0x00000000  EMR   = 0xff1f0000  ECR   = 0xff1f0000

SIUMCR   = 0x4060c000  TESCR1   = 0x00004200  TESCR2   = 0x00000000
PCI_EACR = 0x00000000  PCI_EDCR = 0x00000000  PCI_ECCR = 0x00000000
SIPNR_H  = 0x40200000  SIPNR_L  = 0xa000c000  SIVEC    = 0x00000000
PDTEA    = 0x010f5d28  LDTEA    = 0x00000000

SDMR     = 0x00        PDTEM    = 0x24        LDTEM    = 0x00

IPSEC_PCI_STS        = 0x02a0        IU_PCI_STS           = 0xffff

Exception Type: machine check (watchdog) (0x00000200)
Exception Stack: PC(SRR0) = 0x00178750, SP(R01) = 0x00b5b6b0

Stack Trace:
F00: 0x00178868  F01: 0x004429c4  F02: 0x001795d8  F03: 0x00163448
F04: 0x0016361c  F05: 0x00562b70  F06: 0x00563114  F07: 0x00027828
F08: 0x00000000  F09: 0x00000000  F10: 0x00000000  F11: 0x00000000
F12: 0x00000000  F13: 0x00000000  F14: 0x00000000  F15: 0x00000000


reboot...


NEC Bootstrap Software
Copyright (c) 2001-2008 NEC Infrontia All Rights Reserved.

%BOOT-INFO: No boot records found, attempting flash load.
%BOOT-INFO: Trying flash load, exec-image [ix2010-ms-8.3.48.ldc].
Loading: ######################################################## [OK]


Starting at 0x20000

Loading configuration file: startup-configuration.
Configuring router subsystems (before IDB proc): done.
Constructing IDB(Interface Database): done.
Configuring router subsystems (after IDB proc): done.
Initializing router subsystems: done.
Starting router subsystems: done.

All router subsystems coming up.



login:

負荷は高くない。

ix2015-sh(config)# sh utilization hi
System utilization per 5 seconds(last 5 minutes): 35/26/27 (peak/low/average)
  (* = average, | = maximum and minimum)
      222222222222222222222222232222222222222222222222222222222222
      887887887788877887888888858898978788987798968878888789988888
  100
   90
   80
   70
   60                          |
   50                          |
   40                          *
   30 *************************|**********************************
   20
   10
     +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
     0s   30s   60s   90s  120s  150s  180s  210s  240s  270s  300s

System utilization per 1 minute(last 46 minutes): 29/25/27 (peak/low/average)
  (* = average, | = maximum and minimum)
      2222222222222222222222222222222222222222222222
      8988888888888888888888888888888888888775555557
  100                                              |
   90                                              |
   80                                              |
   70                                              |
   60  |                                           |
   50  |                |                     |  | |
   40  |            |   ||           |   ||||||  | |
   30 **********************************************
   20                         |              |||||||
   10
     +----+----+----+----+----+----+----+----+----+----+----+----+
     0m   5m  10m  15m  20m  25m  30m  35m  40m  45m  50m  55m  60m

最初は dns cache max-records を増やして 1024 にしていたり ip ufs-cache max-entries 16384 していたので、そのあたりをデフォルトに戻した。けども、死ぬまでの時間稼ぎにはなるものの、そのうちヒープを 100% 食い潰して死んでしまう。

dns cache 自体を無効にすればメモリのお漏らしはほとんどなくなるけど、遅くなるよなあ。

ふつう webalizer 64 並列で逆引きなんてことはしないのだから、多少のお漏らしには目を瞑って dns cache は(少なめでいいから)設定しておいたほうがいい気がする。reboot 自体は速いので、家庭用アクセスルータとしては復帰も一瞬といえる範囲。*2

IX2015 の名誉のために書いておくと、こんな実験をするまでは一度もクラッシュしたことはない。

ix2015-sh(config)# sh version
NEC Portable Internetwork Core Operating System Software
IX Series IX2010 (magellan-sec) Software, Version 8.3.48, RELEASE SOFTWARE
Compiled May 10-Tue-2011 15:33:32 JST #1 by sw-build, coregen-8.3(48)

ROM: System Bootstrap, Version 22.34
System Diagnostic, Version 20.31

System uptime is 31 minutes
System woke up by reload, caused by crash
System started at Oct 13-Thu-2011 22:40:16 JST
System image file is "ix2010-ms-8.3.48.ldc"

Processor board ID <2>
IX2015 (MPC8270A) processor with 65536K bytes of memory.
3 FastEthernet/IEEE 802.3 interfaces
1 ISDN Basic Rate interface
512K bytes of non-volatile configuration memory.
8192K bytes of processor board System flash (Read/Write)

Current configuration is based on "startup-configuration"

This product includes software developed by the OpenSSL Project
for use in the OpenSSL Toolkit (http://www.openssl.org/).

IX シリーズのソフトウェアにはメモリ管理に問題があってクラッシュする、というのをどこかで読んだ記憶がある。また、その問題は 8.4.x などで解決しているらしい(?)けど IX2015 には入らない。

372：afo：2010/06/11(金) 16:35:43 ID:???downup
>>371
この糞スレにいる大多数のファーム乞食はIX2015を使ってる訳で、2015には
適用出来ない8.4系で改善されたとか言われても、それは改善されたとはいわ
無い。

結局IX2015はメモリが足りなくなったら勝手に再起動っつー最悪かつ糞みたいな
バグを放置したまま終了ってことで。

http://2chnull.info/r/network/1269162000/

*1:ちゃんとしたテストは jmeter とか使ったほうがいいかも

*2:クラッシュの際に PPPoE ぶった切ってるだろうから PPPoE の多重接続にひっかかると一瞬じゃないけど

samba

% sudo pdbedit -a -u userhoge

しないと繋がらなかった