投稿者: osakanataro

投稿日:

公衆無線LAN ワイヤレスゲートとWi2の比較(2014/10/01改訂)

この記事について「公衆無線LANサービスで使えるアクセスポイントのメモ 2019/08/28版」にて情報更新しています。

公衆無線LANサービスで「ワイヤレスゲート(Wireless Gate)」と「Wi2 300」というのがある。

去年、どっちも加入していたので、比較記事を書いた。
→ WirelessGateで使える公衆無線LANのSSID(2013/04/23)

で・・・2014年10月現在の情報では、いろいろ変更点がある。

まず、「Wi2preminum」が2014/10/1から、Wi2 300通常契約ユーザで使えなくなりました。

2011/06/29から「プレミアムエリアお試しキャンペーン」としてWi2 300通常契約ユーザであれば使用でできていましたが、その「お試し」が終了しました。
今後は、Wi2premiumを使いたい場合は、「ワンタイムプラン」の申し込みが都度必要になります。
つまり、プレミアムエリアを使いたい場合は従量課金になります。

これにより、Wi2で契約するための利点が無くなりました。
Wi2プレミアムエリアはau Wi-Fiと一緒に展開していたようで、結構数が増えていたのですが、それが一気に消えた感じです。（私が使っている範囲だと、Wi2通常エリアがほぼ0%だったので、一気に使えなくなりました）

・WI2:新たなSSID：Wi2premiumのお知らせ(2011/06/29)
・WI2:Wi2 300「プレミアムエリアお試しキャンペーン」の終了について(2014/03/12)
・WI2:Wi2「プレミアムエリアお試しキャンペーン」の新規受け付け終了について(2014/03/12)

次に、ソフトバンクがやっている「BBモバイルポイント」に新SSID「mobilepoint2」が出来ました。
いままでのmobilepointではセキュリティ上不安があったのを、ようやくセキュリティ強化したアクセスポイントを増やしていく、といったところなんでしょう。
Wi2 300については、mobilepoint2対応がされていますが、ワイヤレスゲートについては不明です。

・WI2:モバイルポイントの新SSID「mobilepoint2」への対応について(2014/08/28)

また、調査したところ、ワイヤスレゲートは、東海道新幹線N700系車内無線LANに、BBモバイルポイントエリアとして対応していることが分かりました。
・WG:Q. 東海道新幹線N700系車両内の無線LANサービスには対応していますか？→BBモバイルポイントエリアとして対応
・BBモバイルポイント対応プロバイダリスト

これらの新しい情報を元にリストを更新すると、以下のようになりました。

サービス名称 ESS-ID 暗号化 Wireless Gate Wi2 300
BBモバイルポイント mobilepoint WEP ○ ○
BBモバイルポイント mobilepoint2 WPA2 PSK ? ○
Wi2 300 オプションエリア Wi2premium_club WPA/WPA2 PSK × △1
Wi2 300 オプションエリア Wi2premium なし × △1
Wi2 300 Wi2_club WPA/WPA2 PSK ○ ○
Wi2 300 Wi2 なし ○ ○
Wi2 Wi-Fiスクエア wifi_square なし ? ○
UQ WiFi UQ_Wi-Fi WEP △2 △3
eoモバイル　Wi-Fiスポット eo WEP ○ ×
eoモバイル　Wi-Fiスポット eo_WPA2/AES WPA/WPA2 PSK ○ ×
N700系新幹線車内 mobilepointを標準料金で利用 UQ Wi-Fiを追加料金で利用

△1:ワンタイムプランを追加料金で契約。通期契約無し
△2:一部のエリアで利用可能。「新型成田エクスプレスエリア」「スーパーひたち」「フレッシュひたち」のみ利用可(根拠)
△3:一部のエリアで利用可能。新幹線車内と待合室では利用不可(根拠)

おまけ

「Wi2 300 マイページ」で「MACアドレス登録」を行うと、登録したMACアドレスの機械はWi2エリアでのログイン作業が不要になります。
５台まで登録できますので有効活用しましょう。
といっても、同時利用は１台ですけどね。

投稿日:

Windowsバッチファイルでping応答の違いで動作をかえる

Windowsバッチファイルで、指定IPアドレスから応答がなくなったら次の作業を実施する、という処理をやりたかったので作った。

普通にping実行時のERRORLEVELを見ればいいか、と思っていたが、試験した環境では応答があってもなくてもERRORLEVEL0だったので判別ができなかった・・・

調べたところ「otnx.jpのコマンド別/ping」に調査した結果と回避方法があったのでそれを使った。

ちなみにotnx.jpではfindで「bytes=32」を引っかけていたが、日本語環境だと「 バイト数 =32」になってしまう。しかし、バッチには日本語文字列を書きたくなかったので、その後ろにある「ms TTL=」の方を引っかけるようにした。

・停止待ちバッチファイル

応答がなかったら終了。
応答があったら３回繰り返す 

@echo off

set COUNT=0

:error
set /a COUNT=COUNT+1
echo %COUNT%
if "%COUNT%" == "3" goto errorout
ping -n 1 IPアドレス | find "ms TTL=" > NUL
if ERRORLEVEL 1 goto notrespond
timeout /t 5  > nul
goto error

:notrespond
echo host stopped
goto end

:errorout
echo host not stop

:end

・起動待ちバッチファイル

ping応答があるまで待機する
３回繰り返してもping応答がなければ諦める

@echo off

set COUNT=0

:error
set /a COUNT=COUNT+1
if "%COUNT%" == "3" goto errorout
ping -n 1 IPアドレス | find "ms TTL=" > NUL
if ERRORLEVEL 1 goto error

echo host working
goto end

:errorout
echo host not working

:end
投稿日:

Windows上でperlを使って日本語ファイル名を操作する(メモ

slashdot.jpの「Perlはゾンビだ」に、日本語Windows環境において、perlを使って日本語ファイル名を操作する時の注意点がまとめられていたので、引用＆備忘録化。

過去にperlスクリプトを作る際、ファイル内に書かれた日本語の操作に関することはWindows/Linuxで動作が共通化できたものの、「日本語ファイル名の取り扱い」について、Windows上での動作がいまいち分からず、面倒になり、NASに該当ファイル群を置き、Linuxで処理する、ということをしたことがある。

その時に受けた感じからすると、以下の解説は非常に納得がいくモノだった。

「Anonymous Coward の書き込み (#2628619) 」より

コマンドラインからの引数取得とかファイル操作とかのたびに
@ARGV = map { decode(‘cp932’, $_) } @ARGV; とか
open my $fh, ”, encode(‘cp932’, $filename) or die $!; とか
@files = map { decode(‘cp932’, $_) } readdir($d); とか
if (-f encode(‘cp932’, $filename)) とか
mkdir encode(‘cp932’, $filename); とかソース全体にわたって書かなければならないこと。

これが面倒だと思わない奴はWindows上でPerlを本気で使ったことがないとしか思えない。少なくとも小飼弾はMac使っているようだし。つーか面倒だと思わないならそもそもどうして開祖が「怠惰はプログラマの美徳」とか言ってる言語なんか使ってるの?

56億7千万歩ほど譲ってこれは面倒ではないということにしても、Windows以外の環境への移植性がまったくない。Windows上でシステムロケールを変えただけで動作がおかしくなる。当然どんな環境で動くかわからないモジュール内では使えない。
まあいちおうこれには対処の方法があって、
use Encode::Locale;
@ARGV = map { decode(locale, $_) } @ARGV; とか
open my $fh, ”, encode(locale_fs, $filename) or die $!; とか
@files = map { decode(locale_fs, $_) } readdir($d); とか
if (-f encode(locale_fs, $filename)) とか
mkdir encode(locale_fs, $filename); とかさらに呪文を積み増しすればいいらしい。
MacやLinuxでこんなことわざわざしてる奴いないと思うけど。つーか忘れてもたいてい問題なく動くからWindows以外の環境で正しく書くのが超困難。だから結局Windowsに移植する奴が貧乏クジを引かされる。Windows上ですら、localeとlocal_fsが違う環境があるというバグを知らずに踏んでも気づかない。

しかし実はEncode::Locale;使ってもまだ不十分で、システムロケール(日本語版ならシフトJIS)で表せない文字を含んだファイル名が扱えない。いちおうWin32::Unicode::Fileというモジュールがあるようだが、ファイル読み書きをモジュール内で独自に行なっているので信じられないほど遅くて捨てた。Win32::Longnameというモジュールがちょっとはマシなようだが、どちらにしてもまたも移植性がなくなる。

自分で書くコードは上記の面倒じゃないことにした書き換えを「するだけで」済むとしても、File::compareのような超基本的モジュールすらいまだに非対応。

Perlでこのへんが改善される見込みはまったくなさそうなので、自分はPythonの勉強を始めた。

そして、(#2630401) より

> ・PerlをUTF-8ベース(CP65001)でPerlを動かす
> ことだと思います。

Console CPはファイル名で使われるコードページにはまったく影響を与えない。Encode::Localeでもlocale_fsとconsole_inとconsole_outが別々に定義されている(そう、APIレベルではコンソール入力と出力さえ異なる可能性がある)。Perlの仕様をまともにするためにあなたのような知ったかぶりバカをマサカリで殴って回るよりコストがかからないに違いないからPythonの勉強を始めたの。

> 普通のコマンドプロンプト(SJIS)ベースでは不可能。

Windowsにはコンソール入出力にもワイド文字APIがあり、それを使えば可能(リダイレクトやパイプが絡むとこっちの都合だけでエンコーディングを決められないけどそれはCygwinでも同じだし)。もちろん今あるPerlでは不可能だがそれは実装の手抜きにすぎない。そもそもCygwinはどうやってUTF-8文字を受け付けるコンソールを実現してると思ってるの?

> ・UTF-8 な cygwin の環境を構築し、その上で Perl を使う

Cygwinはパスの扱いが特殊すぎて、結局普通のアプリとパス名をやりとりする際にパスの変換/逆変換が必要なので、面倒だとか移植性ゼロだとかいう問題は何も解決しない。Perlがmsvcrt使うのやめて、UTF-8←→UTF-16LE変換を行ってワイド文字API呼び出して、Encode::LocaleはあたかもロケールがUTF-8であるかのようにふるまってくれるのが一番いいのだが、それを実現するために投入するコストを考えるとすでにまともな処理している言語の乗り換えにコストを振り向けたほうがどう考えても省エネ。

> ・@ARGVやファイル名を、スクリプト本体内のデータ処理と混ぜない

それを面倒と思わないなら以下略

投稿日:

RoundCubeは次の1.1でIE8とFirefox 3.6のサポートを切る

Webmailソフトの「RoundCube」に、version 1.0.1が出ていたのに気がついて、アップデート。

ついでに、「System Requirements」を確認・・・

Internet Explorer 6 (Windows 2000/XP) – not supported since Roundcube 1.1
Internet Explorer 7 (Windows XP) – requires legacy_browser plugin since Roundcube 1.1
Internet Explorer 8 (Windows XP/7) – requires legacy_browser plugin since Roundcube 1.1
Firefox 3.6 (Windows XP, Linux) – requires legacy_browser plugin since Roundcube 1.1

おや？
次のバージョン 1.1から、古いブラウザのサポートをやめるようです。

RoundCube 1.1から、内部で使用しているjQueryのバージョンを2.xに変更するようで、そのjQuery 2.xがこれらのブラウザをサポートしていない(jQuery 2.0 Releasedより)ということに起因する変更点である模様です。

とりあえずは、legacy_browser pluginを使うという、救済処置がIE6以外にはあるようです。

投稿日:

中華SoCベンダLeadcoretechからFDD/TDD-LTE対応のCortex-A7 6コアのLC1860が2014年Q3登場予定

最近、新製品の発表してないけど、どうするのかなぁ？と思っていた中華SoCベンダのLeadcore Technology(联芯科技有限公司)。
久々に新製品の発表をしていた模様

面向移动互联网及大数据联芯科技3S战略深耕4G市场 (2014/06/25)

5モード対応(TDD-LTE/FDD-LTE/TD-SCDMA/WCDMA/GSM)のスマートフォン向けSoCとして、LC1860というのを出す予定。
Cortex-A7 6コアで、4.0インチ～4.7インチクラスのスマートフォンをターゲットとしている。

2014Q3に製品がリリース予定とのこと。

され・・・どんな製品が出てくることやら？