auひかりのホームゲートウェイを置換する その8 (2017/01/28) [ネットワーク機器]
安定して使えています。とりあえずこの使い方は正解のようです。
そうそう、補足しておきます。DHCPv6 pdでISPからIPv6ネットワーク委譲してもらうにあたり、当初はHGWの代わりにCISCOルータを接続するということでDUIDの偽装（？）をやっていましたが、その7では該当設定は解除（削除）しています。真似される方はご参考までに。
ところで、パソコンのipconfig /allを見ると、IPv6のDNSサーバが割り当てられていないことに気付きました。パソコンをHGWに接続する以前の接続形態だとIPv6のDNSがアサインされていたので、どこか設定を漏らしているのでしょうか。
とりあえずISPからDNS情報をもらえていることを確認しました。
しかもDHCPv6のプール設定内のimport dns-serverもきちんと設定してあります。おかしい。どこもおかしくないのにおかしい。っと、インターネットを検索。
Windows10 Anniversary Update 後、DHCPv6 サーバから DNS サーバが設定されない
http://www.himmelst.mydns.jp/archives/645
らしいですね。Windows10の不具合っぽいです。
そうそう、補足しておきます。DHCPv6 pdでISPからIPv6ネットワーク委譲してもらうにあたり、当初はHGWの代わりにCISCOルータを接続するということでDUIDの偽装（？）をやっていましたが、その7では該当設定は解除（削除）しています。真似される方はご参考までに。
ところで、パソコンのipconfig /allを見ると、IPv6のDNSサーバが割り当てられていないことに気付きました。パソコンをHGWに接続する以前の接続形態だとIPv6のDNSがアサインされていたので、どこか設定を漏らしているのでしょうか。
とりあえずISPからDNS情報をもらえていることを確認しました。
Router#show ipv6 dhcp interface
GigabitEthernet0/4 is in client mode
Prefix State is OPEN (0)
Information refresh timer expires in 23:54:00
Renew will be sent in 00:09:00
Address State is IDLE
List of known servers:
Reachable via address: FE80::xxxx:xxxx:xxxx:xxxx
DUID: xxxxxxxxxxxxxxxxxxxx
Preference: 0
Configuration parameters:
IA PD: IA ID 0x00070001, T1 900, T2 1440
Prefix: 24xx:xxxx:xxxx:2::/64
preferred lifetime 1800, valid lifetime 3600
expires at Jan 28 2017 09:23 PM (3241 seconds)
DNS server: 2001:268:FD07:4::1
DNS server: 2001:268:FD08:4::1
Information refresh time: 0
Prefix name: DHV6-PD-PREFIX
Prefix Rapid-Commit: disabled
Address Rapid-Commit: disabled
Vlan1 is in server mode
Using pool: DH6PL_au
Preference value: 0
Hint from client: ignored
Rapid-Commit: disabledしかもDHCPv6のプール設定内のimport dns-serverもきちんと設定してあります。おかしい。どこもおかしくないのにおかしい。っと、インターネットを検索。
Windows10 Anniversary Update 後、DHCPv6 サーバから DNS サーバが設定されない
http://www.himmelst.mydns.jp/archives/645
らしいですね。Windows10の不具合っぽいです。
auひかりのホームゲートウェイを置換する その7 (2017/01/26) [ネットワーク機器]
auひかりのインターネット接続仕様はよく分からないので、やり方を変えることにしました。とりあえずCISCOルータをHGWのLAN側にぶら下げ、さらにCISCOルータのスイッチポートに別のネットワークセグメントを作ることにします。
HGW：
・ほぼ初期構成
・LAN側にCISCOルータをぶらさげる
・CISCOルータのLAN側に設定した新規NWアドレスを、スタティックルートで設定
CISCOルータ：
・LAN側に新規VLANを作成
・新規VLANにIPv4アドレスをアサイン
・LAN側でDHCPサーバを動作させる
ま、ここまでは普通です。PCを接続し、問題なく使えることを確認しました。
ここでふと疑問に思ったのです。CISCOルータをISPに繋ぐにあたり、DHCPv6 pdのコンフィグを作り込んだが、そのコンフィグを適用したらどうなるのだろう、と。なお、HGWのLAN側IPv6の設定は、設定4 [RA:プレフィックス配布 DHCPv6:プレフィックス/IPv6アドレス配布]を選択してあります。
結果。新規の/64グローバルアドレスが払い出されました。
ちょっとびっくりしました。もともとHGWに/64のグローバルアドレスを委譲されていますが、（連番ではあるものの）それとは異なる/64が新規に割り当てられたのです。サブネットではありません。
このままパソコンを繋げば、DHCPv6のアドレスをCISCOルータから払い出されることでしょう。が、よく考えてみて下さい。HGW視点に立ってみれば、自分の配下に新たなIPv6セグメントが委譲されたことなど知らないはずなのです。ましてやルーティングテーブルもないのです。
…でも、パソコンからIPv6でインターネットに繋がりました。
意外とステキな仕様なんですね、auひかりって。私がauひかりを導入してから5年以上経ちますが、当時からこんな仕様だったのでしょうか。この接続形態が安定するのであれば、CISCOを一番有効活用できる接続形態なのではないでしょうか。
なお私の推測ですが、HGWがDHCPv6 pdに関するパケットををISPにプロキシ中継しているような気がします。その結果、ネットワークアドレスはISP承認の正規IPv6ネットワークアドレスが新規払い出され、HGWはそのやりとりをスヌーピングすることで、新設委譲セグメントの存在を知り、自動的にルーティングテーブルが生成されたのではないでしょうか。
とりあえずやましい使い方はしていないはずなので、怒られるようなことはないと信じています。（どうせIPv6アドレスなんて湯水のごとく余ってるでしょうし）
HGW：
・ほぼ初期構成
・LAN側にCISCOルータをぶらさげる
・CISCOルータのLAN側に設定した新規NWアドレスを、スタティックルートで設定
CISCOルータ：
・LAN側に新規VLANを作成
・新規VLANにIPv4アドレスをアサイン
・LAN側でDHCPサーバを動作させる
ま、ここまでは普通です。PCを接続し、問題なく使えることを確認しました。
ここでふと疑問に思ったのです。CISCOルータをISPに繋ぐにあたり、DHCPv6 pdのコンフィグを作り込んだが、そのコンフィグを適用したらどうなるのだろう、と。なお、HGWのLAN側IPv6の設定は、設定4 [RA:プレフィックス配布 DHCPv6:プレフィックス/IPv6アドレス配布]を選択してあります。
結果。新規の/64グローバルアドレスが払い出されました。
ちょっとびっくりしました。もともとHGWに/64のグローバルアドレスを委譲されていますが、（連番ではあるものの）それとは異なる/64が新規に割り当てられたのです。サブネットではありません。
このままパソコンを繋げば、DHCPv6のアドレスをCISCOルータから払い出されることでしょう。が、よく考えてみて下さい。HGW視点に立ってみれば、自分の配下に新たなIPv6セグメントが委譲されたことなど知らないはずなのです。ましてやルーティングテーブルもないのです。
…でも、パソコンからIPv6でインターネットに繋がりました。
意外とステキな仕様なんですね、auひかりって。私がauひかりを導入してから5年以上経ちますが、当時からこんな仕様だったのでしょうか。この接続形態が安定するのであれば、CISCOを一番有効活用できる接続形態なのではないでしょうか。
なお私の推測ですが、HGWがDHCPv6 pdに関するパケットををISPにプロキシ中継しているような気がします。その結果、ネットワークアドレスはISP承認の正規IPv6ネットワークアドレスが新規払い出され、HGWはそのやりとりをスヌーピングすることで、新設委譲セグメントの存在を知り、自動的にルーティングテーブルが生成されたのではないでしょうか。
とりあえずやましい使い方はしていないはずなので、怒られるようなことはないと信じています。（どうせIPv6アドレスなんて湯水のごとく余ってるでしょうし）
auひかりのホームゲートウェイを置換する その6 (2017/01/22) [ネットワーク機器]
謎仕様で不通になる問題についてです。EAPOLを透過するスイッチでずっとキャプチャをしていたのですが、通信が復旧する際に何も残らなかったので、ユニキャスト系の何かが影響しているようです。そうなると、TAPでも挟んでキャプチャし続けるしか解析手段はなさそうですね…。今のうちの環境ではどうにもならないです。
さてさて、DHCPv6 pdに関する設定です。これはCISCOに参考ページがあるので、その通り設定するだけでOKでした。https://supportforums.cisco.com/ja/document/12364026
さてさて、DHCPv6 pdに関する設定です。これはCISCOに参考ページがあるので、その通り設定するだけでOKでした。https://supportforums.cisco.com/ja/document/12364026
ipv6 unicast-routing ipv6 dhcp pool DH6PL_au import dns-server ! interface GigabitEthernet0/4 ipv6 address autoconfig default ipv6 enable ipv6 dhcp client pd DHV6-PD-PREFIX ! interface Vlan100 ipv6 address DHV6-PD-PREFIX ::254/64 ipv6 enable ipv6 nd other-config-flag ipv6 dhcp server DH6PL_au
auひかりのホームゲートウェイを置換する その5 (2017/01/21) [ネットワーク機器]
また新たな謎仕様です。
IEEE802.1X認証（EAPOL）とMAC認証以外に、何かあるようです。
現象としては、会社から帰宅してインターネットのWebページを閲覧すると1時間ぐらいは普通に使えるのですが、その後急に不通になるのです。
・DHCPはリース時間内
・IEEE802.1X認証はOK（有効時間内）
・ケーブルを抜線、再接続してもダメ
・放置しておくと直る（15分～30分ぐらい）
・HGWにWANケーブルを接続し、ちょっと通信させると直る
なんなんでしょうね。
IEEE802.1X認証（EAPOL）とMAC認証以外に、何かあるようです。
現象としては、会社から帰宅してインターネットのWebページを閲覧すると1時間ぐらいは普通に使えるのですが、その後急に不通になるのです。
・DHCPはリース時間内
・IEEE802.1X認証はOK（有効時間内）
・ケーブルを抜線、再接続してもダメ
・放置しておくと直る（15分～30分ぐらい）
・HGWにWANケーブルを接続し、ちょっと通信させると直る
なんなんでしょうね。
タグ：auひかり
auひかりのホームゲートウェイを置換する その4 (2017/01/20) [ネットワーク機器]
前回、HGWが一定時間で謎の認証をやっている書きましたが、倉庫で眠っていたバカHUB（BUFFALO LSW3-GT-8NS）があったので、WAN側に挟んでEAPOLをキャプチャしてみることにしました。LSW3-GT-8NSがEAPOL透過に対応しているかは分かりませんが、バカHUBなのでおそらく透過するのではと思ってます。もし透過しなければ、パナソニックESネットワークス製のOAタップでも買おうかな。
※メーカーサイトで確認したらEAPOL透過対応と記載がありました
http://buffalo.jp/products/catalog/network/lsw3-gt-8ns/
キャプチャは成功。無事、EAPOLフレームがキャプチャできました。
ざっとフレーム内部を見てみると、どうやらEAP-MD5で認証しているようですね。
だからと言って何か進展する訳ではないですが、ちょっとずつ仕様が明らかになっていっています。
※メーカーサイトで確認したらEAPOL透過対応と記載がありました
http://buffalo.jp/products/catalog/network/lsw3-gt-8ns/
キャプチャは成功。無事、EAPOLフレームがキャプチャできました。
ざっとフレーム内部を見てみると、どうやらEAP-MD5で認証しているようですね。
だからと言って何か進展する訳ではないですが、ちょっとずつ仕様が明らかになっていっています。
auひかりのホームゲートウェイを置換する その3 (2017/01/19) [ネットワーク機器]
とりあえず、一定時間毎の認証を除けばちゃんと繋がっているので、そちらについてまとめます。
※HGW＝ホームゲートウェイ（キャリアから提供される終端装置）
※ISP＝インターネットサービスプロバイダ（インターネット接続提供者）
■IPv4でDHCP取得する方法
DHCP要求の送信元MACアドレスもしくは、DHCP要求時のクライアントID（MACアドレスが埋め込まれる）をチェックしているようです。CISCOの場合、双方に対応するようカスタマイズできるので、下記でOKです。（インタフェース名は適宜読み替えて下さい）
なお、偽装するMACアドレスはHGWの管理画面に表示されるWAN側のMACアドレスになります。
■IPv6でDHCPv6取得する方法
こちらは少し悩みました。auひかりの場合、DHCPv6でprefix delegationを実装しています。prefix delegationとは、サブネット管理の委譲であり、簡単に言えば、IPアドレスを払い出して貰うのではなく、ネットワークアドレスを丸ごと払い出して貰う仕組みです。
もちろんCISCOはDHCPv6のpdに対応しており、そのコマンドもあります。CISCOルータがパケットを送出していることも確認していますが、ISP側から応答がありません。IPv4のDHCPのように何かしらのチェック機構が働いているのだと思いました。
ま、そんなときはパケットキャプチャです。するとIPv4 DHCPのクライアントIDに相当するDUIDというものがあり、それをDHCPv6要求パケットに埋め込んでいるようでした。HGWとCISCOとでは、その値が異なっていることまで確認したのですが、CISCOにはそれを変更する設定がありません。
ここで挫折かと思われましたが、CISCOマニュアルに下記のような記述を発見しました。
そう、確かに表示されるDUIDは、最も小さい番号のインターフェイスGi0/0のMACアドレスから算出した値になっているのです。ならばと下記を設定してみました。
この段階でshow ipv6 dhcpコマンドの結果は変わりません。失敗かと思ったのですが、show interfaceコマンドを確認すると、下記のように表示されたのです。
微妙な閃きがあり、上記コンフィグをwriteで保持したまま再起動してみました。おそるおそるshow ipv6 dhcpコマンドを発行してみると…
ちゃんと成功していれば、show ipv6 dhcp interfaceの結果にfe80:で始まらないグローバルIPアドレスが振られていることが確認できると思います。
※HGW＝ホームゲートウェイ（キャリアから提供される終端装置）
※ISP＝インターネットサービスプロバイダ（インターネット接続提供者）
■IPv4でDHCP取得する方法
DHCP要求の送信元MACアドレスもしくは、DHCP要求時のクライアントID（MACアドレスが埋め込まれる）をチェックしているようです。CISCOの場合、双方に対応するようカスタマイズできるので、下記でOKです。（インタフェース名は適宜読み替えて下さい）
なお、偽装するMACアドレスはHGWの管理画面に表示されるWAN側のMACアドレスになります。
interface GigabitEthernet0/4 mac-address aaaa.bbbb.cccc ip dhcp client client-id GigabitEthernet0/4 ip address dhcp
■IPv6でDHCPv6取得する方法
こちらは少し悩みました。auひかりの場合、DHCPv6でprefix delegationを実装しています。prefix delegationとは、サブネット管理の委譲であり、簡単に言えば、IPアドレスを払い出して貰うのではなく、ネットワークアドレスを丸ごと払い出して貰う仕組みです。
もちろんCISCOはDHCPv6のpdに対応しており、そのコマンドもあります。CISCOルータがパケットを送出していることも確認していますが、ISP側から応答がありません。IPv4のDHCPのように何かしらのチェック機構が働いているのだと思いました。
ま、そんなときはパケットキャプチャです。するとIPv4 DHCPのクライアントIDに相当するDUIDというものがあり、それをDHCPv6要求パケットに埋め込んでいるようでした。HGWとCISCOとでは、その値が異なっていることまで確認したのですが、CISCOにはそれを変更する設定がありません。
Router#show ipv6 dhcp This device's DHCPv6 unique identifier(DUID): 000300010123abc123abc
ここで挫折かと思われましたが、CISCOマニュアルに下記のような記述を発見しました。
各 DHCPv6 クライアントとサーバは、DHCP Unique Identifier（DUID; DHCP 固有識別子）によって識別されます。DUID は、クライアント識別子およびサーバ識別子オプションで伝送されます。DUID はすべての DHCP クライアントとサーバで一意であり、特定のクライアントまたはサーバに固定されます。DHCPv6 では、クライアントとサーバの両方の識別子にリンク層アドレスに基づく DUID を使用します。デバイスは、最も小さい番号のインターフェイスの MAC アドレスを使用して DUID を形成します
そう、確かに表示されるDUIDは、最も小さい番号のインターフェイスGi0/0のMACアドレスから算出した値になっているのです。ならばと下記を設定してみました。
interface GigabitEthernet0/0 mac-address aaaa.bbbb.cccc
この段階でshow ipv6 dhcpコマンドの結果は変わりません。失敗かと思ったのですが、show interfaceコマンドを確認すると、下記のように表示されたのです。
GigabitEthernet0/0 is up, line protocol is up Hardware is Gigabit Ethernet, address is aaaa.bbbb.cccc (bia 123abc.123abc.123abc)aaaa.bbbb.ccccは設定した偽装MACアドレスであり、123abc.123abc.123abcは装置が本来有している実MACアドレスです。私の想定とは表示場所が逆でした。aaaa.bbbb.ccccは上辺のなんちゃってMACアドレスなので、bia側に来ると思っていたのでが、この表示結果だとより深い階層にあると思われるハードウェアMACアドレスがaaaa.bbbb.ccccとなっているのです。
微妙な閃きがあり、上記コンフィグをwriteで保持したまま再起動してみました。おそるおそるshow ipv6 dhcpコマンドを発行してみると…
Router#show ipv6 dhcp This device's DHCPv6 unique identifier(DUID): 000300010aaaabbbbccccと、書き換えに成功してしまいました。auひかり側に改めて接続し直してみると、DHCPv6 pdが成功しました。
ちゃんと成功していれば、show ipv6 dhcp interfaceの結果にfe80:で始まらないグローバルIPアドレスが振られていることが確認できると思います。
auひかりのホームゲートウェイを置換する その2 (2017/01/18) [ネットワーク機器]
やっぱダメでした。残りの5%でやられました。
どうやら、下記条件に加え、
・WANインタフェースのMACアドレス認証をやっている
・IP電話を使う場合、さらに証明書認証をやっている
「一定時間（18～24時間？）毎に、EAP認証（おそらく証明書認証）が行われる」
という条件もあった模様。そんなの聞いてないですよ。
ケーブルを差し替えて一度認証を通してしまえば1日弱は安定し使えるのですが、都度差し替えるのは非常に面倒です。はい、太刀打ちできません。確かにそういう観点（キーワード）で調べれば情報がでてきますねぇ。皆さん挫折しているようですが。
L2スイッチを改造して無理矢理接続している強者もいるようですが、EAPOLフレームは基本的にLANスイッチ自身が吸収してしまうフレームのため、非常に扱いにくいことこの上ないのです。困った。
取り急ぎ報告まで。
どうやら、下記条件に加え、
・WANインタフェースのMACアドレス認証をやっている
・IP電話を使う場合、さらに証明書認証をやっている
「一定時間（18～24時間？）毎に、EAP認証（おそらく証明書認証）が行われる」
という条件もあった模様。そんなの聞いてないですよ。
ケーブルを差し替えて一度認証を通してしまえば1日弱は安定し使えるのですが、都度差し替えるのは非常に面倒です。はい、太刀打ちできません。確かにそういう観点（キーワード）で調べれば情報がでてきますねぇ。皆さん挫折しているようですが。
L2スイッチを改造して無理矢理接続している強者もいるようですが、EAPOLフレームは基本的にLANスイッチ自身が吸収してしまうフレームのため、非常に扱いにくいことこの上ないのです。困った。
取り急ぎ報告まで。
auひかりのホームゲートウェイを置換する その1 (2017/01/16) [ネットワーク機器]
"auひかり"は、もともと"TEPCOひかり"という名称で東京電力が提供していたISPサービスだったと記憶しています。100Mbps回線帯域占有というのがウリで、当時は私もYAMAHA RTX1100を使って接続してみたりしたものです。
その後、auひかり（ひかりone）がWAN 1Gbps（占有ではない）サービスを提供するようになり、WANインタフェースが100BASE-TXだったRTX1100ではスペック不足となり、auから提供されたホームゲートウェイを使用し今に至っています。
さてこの度、遊び道具としてCISCOルータを買ったので、今更ながらauひかりのホームゲートウェイを置き換えてみることにしました。インターネットにて、下記のような情報は事前情報として収集してありました。
・WANインタフェースのMACアドレス認証をやっている
・IP電話を使う場合、さらに証明書認証をやっている
MACアドレス詐称であればなんとかいけそうですが、証明書認証は手の出しようがないので、IP電話を使っている場合はそもそも置換ができません。あきらめましょう。
ただ、MACアドレス詐称レベルであればなんとかなりそう書きましたが、ちゃんと繋がる保証も何もなく、もちろんインターネット上にも情報がありません。他の皆さんは、無難にパススルー等のブリッジ接続でごまかしながら接続しているようです。
うまくいくかどうかの勝率は20%程度ですかね…
と言いつつ、全ての結果が出てからこのブログを書いているので、最初に答えを言ってしまうと、ほぼほぼ95%問題なく繋がることを確認しています。いやー、大変でした。
課題は大きく、3つですかね。
・DHCPでIPv4アドレスをゲットする問題
・DHCPv6で、PD（Prefix delegation）を行う問題
・その他、CISCOルータをブロードバンドルータとして使う問題
一番びっくりしたことは、自分のパソコンとFreeBSDサーバがCISCOのスイッチポートでダイレクト通信行うような構成に変えたろころ、Sambaのファイルコピーがほぼワイヤレート（最大110MB/秒）出るようになったことです。それまでは60MB/秒が限界で、てっきりFreeBSDサーバの性能不足かと思っていました。
auひかりのホームゲートウェイ側で頭打ちになっていたとは。
その後、auひかり（ひかりone）がWAN 1Gbps（占有ではない）サービスを提供するようになり、WANインタフェースが100BASE-TXだったRTX1100ではスペック不足となり、auから提供されたホームゲートウェイを使用し今に至っています。
さてこの度、遊び道具としてCISCOルータを買ったので、今更ながらauひかりのホームゲートウェイを置き換えてみることにしました。インターネットにて、下記のような情報は事前情報として収集してありました。
・WANインタフェースのMACアドレス認証をやっている
・IP電話を使う場合、さらに証明書認証をやっている
MACアドレス詐称であればなんとかいけそうですが、証明書認証は手の出しようがないので、IP電話を使っている場合はそもそも置換ができません。あきらめましょう。
ただ、MACアドレス詐称レベルであればなんとかなりそう書きましたが、ちゃんと繋がる保証も何もなく、もちろんインターネット上にも情報がありません。他の皆さんは、無難にパススルー等のブリッジ接続でごまかしながら接続しているようです。
うまくいくかどうかの勝率は20%程度ですかね…
と言いつつ、全ての結果が出てからこのブログを書いているので、最初に答えを言ってしまうと、ほぼほぼ95%問題なく繋がることを確認しています。いやー、大変でした。
課題は大きく、3つですかね。
・DHCPでIPv4アドレスをゲットする問題
・DHCPv6で、PD（Prefix delegation）を行う問題
・その他、CISCOルータをブロードバンドルータとして使う問題
一番びっくりしたことは、自分のパソコンとFreeBSDサーバがCISCOのスイッチポートでダイレクト通信行うような構成に変えたろころ、Sambaのファイルコピーがほぼワイヤレート（最大110MB/秒）出るようになったことです。それまでは60MB/秒が限界で、てっきりFreeBSDサーバの性能不足かと思っていました。
auひかりのホームゲートウェイ側で頭打ちになっていたとは。
UQWiMAXの使い勝手 (2015/01/29) [ネットワーク機器]
UQWiMAXを1～2ヶ月ほど使ってみました。なるほどなるほど良い感じです。
電波範囲としては、Y!mobile > UQWiMAXという原則がほぼほぼ成立するようですが、大きな問題になるほど困ったことはありません。やはり通信量を気にしなくても良いというのは精神衛生的にも良いですね。どこにいても気軽にGoogle Playのアップデートができます。
NAD11固有の問題ですが、省スペース薄型である分バッテリ容量も少なく、朝100%として朝夜の通勤・帰宅時に主に使用し、就寝時に残り30～50%です。ま、私の生活パターンで丸一日充電不要で耐えきるのでむしろこれは十分と言えるでしょう。それなりに激しく使用する人であれば、おそらく電池容量不足に陥ると思います。
明らかに体感差があったのは、会社へVPN接続する時です。このVPNは仕様非公開（独自実装？）のため、通信の実体が何かは分かりませんが、Y!mobileで接続まで3秒程度だったものが、UQWiMAXだと30秒ぐらい掛かるようになってしまいました。（ファイアウォール的なものは設定していないので、何が原因なのかは本当に不明） また、リモートデスクトップ系のアプリケーションを使うと、レスポンスが少しもっさりするようになってしまいました。
前者の30秒は最初に待たされるだけで、一度つながってしまえば気にしなくても良いのですが、後者のもっさりはあきらめています。おそらくY!mobileよりも電波の周波数成分が高周波数帯域のため、反射回数・反射波が多くなり、RTTが悪くなっているのではないかと思っています。
電波範囲としては、Y!mobile > UQWiMAXという原則がほぼほぼ成立するようですが、大きな問題になるほど困ったことはありません。やはり通信量を気にしなくても良いというのは精神衛生的にも良いですね。どこにいても気軽にGoogle Playのアップデートができます。
NAD11固有の問題ですが、省スペース薄型である分バッテリ容量も少なく、朝100%として朝夜の通勤・帰宅時に主に使用し、就寝時に残り30～50%です。ま、私の生活パターンで丸一日充電不要で耐えきるのでむしろこれは十分と言えるでしょう。それなりに激しく使用する人であれば、おそらく電池容量不足に陥ると思います。
明らかに体感差があったのは、会社へVPN接続する時です。このVPNは仕様非公開（独自実装？）のため、通信の実体が何かは分かりませんが、Y!mobileで接続まで3秒程度だったものが、UQWiMAXだと30秒ぐらい掛かるようになってしまいました。（ファイアウォール的なものは設定していないので、何が原因なのかは本当に不明） また、リモートデスクトップ系のアプリケーションを使うと、レスポンスが少しもっさりするようになってしまいました。
前者の30秒は最初に待たされるだけで、一度つながってしまえば気にしなくても良いのですが、後者のもっさりはあきらめています。おそらくY!mobileよりも電波の周波数成分が高周波数帯域のため、反射回数・反射波が多くなり、RTTが悪くなっているのではないかと思っています。
Y!mobile解約しました (2014/12/06) [ネットワーク機器]
Y!mobile解約しました。2年間使用した（今月が解約月）GL04Pです。Webの解約手続き方法によるとY!mobileショップに行けとありましたが、下記の有料電話番号のメニューから行けました。（オペレーター対応になります）
http://www.ymobile.jp/support/contact/ymobile/index.html
疑似解約となる0円プランを勧められたのはちょっとびっくりしました。契約情報は残るが永続的に0円になりますということで、要は加入者減を阻止するための形だけのプランでしょう。私は面倒でも書面による正式解約をしたいと伝えました。
そうしたら書面の郵送、返送日を経ると日割りの料金計算が面倒になるからと、「このお電話を以て解約処理完了とさせて頂きます」という結果に。スバラシイ！ 担当者はうじなんとかさんというお姉さんでしたが、対応は丁寧で良かったです。
今後は新規契約したUQWiMAX(NAD11)を使うことになります。
ちなみに今回解約した理由は、下記の通りです。
・GL04Pが使い始めてから2年契約しており、そろそろリプレイス時期であったが、kakaku.comのレビューを見る限り、現行ラインナップが散々たる有様だった（使いにくい、電波が入らないなど）
・端末割賦支払いが完了する2年が経ったので、月額料金が半額ぐらいになるのかと思っていたら、全く変わらないことが分かった（正確には、本来割賦込みで月額5500円ぐらい支払うものを、割賦分がまるまる1500円ほど割り引きされていただけ。だから2年経過しても月額は変わらない）
・帯域制限に関する約款が変わり、3日で366MBを超えただけで使い物にならなくなること（私はそんなに使わないけれど、万が一を考えると精神的に嫌だ）
・emobileがY!mobileになっちゃった
・ソフトバンクのiPhoneに対して、emobileのLTE回線を使わせるようになった（らしい）
なお、2014年12月時点のGL04Pの使用感を書いておきます。
○都内、関東近辺で使う限り、電波で困ったことはほとんどない
○地方（都市部）に行っても、電波で困った記憶はほとんどない
○建物内でも地下でもちゃんと使える
○それなりに速度も出る（繋がれば良いので、スループットはあまり気にしていなかったが）
○電池が結構持つ（連続使用で無ければ1日ぐらい平気）
○壊れたりしなかったので、頑丈なのかな？
○一部、地下鉄の駅と駅との間で電波が拾える
○SSL-VPNは使える（PPTPはダメだったような）
×でかい、重い。
×まれにフリーズする（電源入れ直すと直る）
×山手線（品川駅～東京間あたり）、電車の移動中はほとんど繋がらない（昔はそんなことなかったような記憶）
×ソフトバンクのiPhoneにLTE回線を開放したらしい
×そもそもソフトバンク
×端末がファーウェイで、何か個人情報が収集されていないかと不安
×WindowsにUSBケーブルで接続すると、（初回は）ドライバのインストールが必要で、かつ再起動を要求される
とまあ、そんな感じで。
http://www.ymobile.jp/support/contact/ymobile/index.html
疑似解約となる0円プランを勧められたのはちょっとびっくりしました。契約情報は残るが永続的に0円になりますということで、要は加入者減を阻止するための形だけのプランでしょう。私は面倒でも書面による正式解約をしたいと伝えました。
そうしたら書面の郵送、返送日を経ると日割りの料金計算が面倒になるからと、「このお電話を以て解約処理完了とさせて頂きます」という結果に。スバラシイ！ 担当者はうじなんとかさんというお姉さんでしたが、対応は丁寧で良かったです。
今後は新規契約したUQWiMAX(NAD11)を使うことになります。
ちなみに今回解約した理由は、下記の通りです。
・GL04Pが使い始めてから2年契約しており、そろそろリプレイス時期であったが、kakaku.comのレビューを見る限り、現行ラインナップが散々たる有様だった（使いにくい、電波が入らないなど）
・端末割賦支払いが完了する2年が経ったので、月額料金が半額ぐらいになるのかと思っていたら、全く変わらないことが分かった（正確には、本来割賦込みで月額5500円ぐらい支払うものを、割賦分がまるまる1500円ほど割り引きされていただけ。だから2年経過しても月額は変わらない）
・帯域制限に関する約款が変わり、3日で366MBを超えただけで使い物にならなくなること（私はそんなに使わないけれど、万が一を考えると精神的に嫌だ）
・emobileがY!mobileになっちゃった
・ソフトバンクのiPhoneに対して、emobileのLTE回線を使わせるようになった（らしい）
なお、2014年12月時点のGL04Pの使用感を書いておきます。
○都内、関東近辺で使う限り、電波で困ったことはほとんどない
○地方（都市部）に行っても、電波で困った記憶はほとんどない
○建物内でも地下でもちゃんと使える
○それなりに速度も出る（繋がれば良いので、スループットはあまり気にしていなかったが）
○電池が結構持つ（連続使用で無ければ1日ぐらい平気）
○壊れたりしなかったので、頑丈なのかな？
○一部、地下鉄の駅と駅との間で電波が拾える
○SSL-VPNは使える（PPTPはダメだったような）
×でかい、重い。
×まれにフリーズする（電源入れ直すと直る）
×山手線（品川駅～東京間あたり）、電車の移動中はほとんど繋がらない（昔はそんなことなかったような記憶）
×ソフトバンクのiPhoneにLTE回線を開放したらしい
×そもそもソフトバンク
×端末がファーウェイで、何か個人情報が収集されていないかと不安
×WindowsにUSBケーブルで接続すると、（初回は）ドライバのインストールが必要で、かつ再起動を要求される
とまあ、そんな感じで。
タグ：EMOBILE
