情報技術の四方山話

AI、IoT、ヤマハルータ、VPN、無線LAN、Linux、クラウド、仮想サーバと情報セキュリティのよもやま話

Wi-Fi環境改善のためヤマハWLX302を仮設置しました

2020-05-16 23:54:52 | 通信ネットワーク
今日は「Wi-Fi環境改善のためヤマハWLX302を仮設置しました」です。
お客様から「Wi-Fi環境がとても悪くて、、、、」とご相談を受けました。
現用のアクセスポイントは「5年ほど前の家庭用上級機」で、悪いものではありません。
しかしながら、インターネットを接続しているRTX810のDHCPでの割り当て表を見ると想定以上の接続があります。
職員さんの休息室もあるので、おそらくは同時接続の多い時代に合わなくなったのでしょう。
びっくりするくらい近隣のアクセスポイントが見えます。これも時代の変化ですね。

WLX302では、2.4G/5G帯併用のVAP/SSIDを組みました。
もう5G帯の時代なので、次の調整では2.4G帯を停波します。
経験の上でも5G帯の方が、見通しだと強力ですが、遮蔽に弱く遠くまで飛びません。
飛びすぎないことは、企業ネットではむしろ有利です。
コメント

ヤマハルータのIDS機能を監視し、月次報告書を作成しています

2020-05-09 21:45:56 | 通信ネットワーク
今回の話題は「ヤマハルータのIDS機能を監視し、月次報告書を作成しています」です。お客様のルータでIDS機能を使い、気になる通信状況を把握、より安全にするための方策を考えます。

実際には、なにもない方が良いのです。実害のないログが出ていました。
IDSにしろ、ファイヤウオールにせよ、ログを常時監視する必要があります。
その仕組みを提供し、ログを読み、状態を監視しています。

その結果を月次報告としてまとめて報告します。もちろん、緊急性のある事態は、即時報告と即時対応です。


コメント

PHSサービスの終了日が延長されています

2020-05-09 20:00:33 | 通信ネットワーク
今回の話題は「PHSサービスの終了日が延長されています」です。
Y!mobileが2020年4月17日に、PHSサービス終了日の延期が発表されています。
半年間の延長で、2011年1月31日までは使えますが、その後は全く使えなくなります。

PHSサービス
終了予定日:2020年7月31日
延期終了日:2021年1月31日

現在PHSサービスを提供しているのは旧WILLCOMを吸収したY!mobileのみです。
PHSは電波出力が弱く、医療機関の内線電話としても多くの利用がありました。

私の事務所では、社員の連絡用電話はPHSに050を結びつけたものを使っています。
楽天モバイル(旧Fusionコミュニケーションズ)が050を結びつけたPHSを提供しています。

一般回線の050と同じ料金で電話できるので、10年ほど前の導入当時は「格安携帯電話」でした。

弊社でも、PHS終了に伴い社内電話の4Gスマホへの切替を進めており、5月中に切替が完了します。
コメント

在宅VPNでL2TP/IPsecのときは自宅ルータのPPTPパススルー設定をお忘れなく

2020-04-27 05:55:10 | 通信ネットワーク
今日の話題は「在宅VPNでL2TP/IPsecのときは自宅ルータのPPTPパススルー設定をお忘れなく」です。
在宅勤務などで、L2TP/IPsecを使ったVPN接続を利用している方も多いと思います。

当方でも自社開発した「EasyRAS」という企業向けのリモートアクセスサービスを提供をしています。これは、企業ではRASを作りにくいことを改善するため、自社で開発して提供を始めたものです。昨今の事情で、在宅VPNとして多くの利用者様にご活用いただくようになりました。

「EasyRAS」の原型を最初にインストールしたのは2017年で、長期間にわたり問題なくお使いいただいています。その中で見えてきたのが「まれにつながらないことがある」ことです。

家庭用ルータの中には初期設定ではL2TP/IPsecを通さない機種があります。
これは、通らないことが悪いということではなく、セキュリティの考え方の違いです。なぜなら通すようにできるからです。

以下のメーカー製家庭用ルータはPPTPパススルー(VPNパススルー)を許可しないと、L2TP/IPsecが通りません。

1.I/Oデータの家庭用ルータ(最近の機種も)
2.Buffaloの家庭用ルータ(比較的古い機種で。最近の機種は可?)

「EasyRAS」はWindows, Android, macOS, iOSのOSの標準として備わっているL2TP/IPsecを使います。デバイス側には何もインストールする必要がないので、展開がたいへん楽です。
また、業界標準の接続方法なので、将来的にOSの標準機能から外れることがない限り使い続けることができます。当面は安心して導入できます。

在宅VPNのご活用にご興味のある方はこちらからお問い合わせください。
コメント

Bluetoothとは何?どこで使う?どの規格か良いの?

2019-08-13 17:17:51 | 通信ネットワーク
Bluetoothとは何?どこで使う?どの規格か良いの?


いつもアクセスありがとうございます。匠技術研究所の谷山 亮治です。
久々の投稿になります。今日はいつもお世話になっているBluetoothの話題です。

■Bluetoothとは
BluetoothとはPCやスマホと連携するデバイスをつなぐ無線接続規格です。例えば、急速に普及した無線イヤホン。マウスやキーボードのケーブルの置き換え、カーナビと連携してスピーカーホンを実現するなどで使います。

■どこで何に使うか
どの機器に、何がつながるかは、親機が備える機能の種類で決まります。例えば、Bluetoothイヤホンがスマホに接続できるかどうかは、スマートホン側の機能で決まります。

Bluetoothは様々な機器に搭載されています。Bluetoothは接続ケーブルの置き換えのイメージなので、あまり高速な通信を想定していません。数Mbps程度です。論理的には24Mbpsの伝送の規格があります。一般的には数百Mbpsと、今のインターネットの通信速度と比較すると、極めて低速です。

■どの規格が良いのか
Bluetoothイヤホン、ヘッドセットの普及で利用者が大きく拡大しています。新規購入や、買い替えを検討する際には、古い規格より新しい規格の方が省電力化と高音質化が進んでいます。

なるべくなら「BLE(Bluetooth Low Energy)」が実装された「Bluetooth 4」以降の機器を選択したほうが良いでしょう。私自身、モバイルPCの周辺機器は「Bluetooth 4」対応機器を選択しています。ただ、Bluetoothマウスなども、市場ではBluetooth 3対応機がほとんどです。

さらに「Bluetooth 5」が規格化されていいますが、まだPC周辺装置で対応機器を見たことがありません。もしご存じの方は、教えていただけると幸いです。
コメント

スマホとPC間をBluetoothテザリングしてインターネット接続する

2019-05-04 18:05:32 | 通信ネットワーク
スマホとPC間をBluetoothテザリングしてインターネット接続する


いつもアクセスありがとうございます。匠技術研究所の谷山 亮治です。
今日は「スマホとPC間をBluetoothテザリングしてインターネット接続する」についてです。

■スマホのテザリングはバッテリーが消耗する
スマホにWi-Fi経由でWindows PCをテザリング接続すると、スマホ側の電池の消耗が大きいと感じていました。
そのため、SIM付きのiPad miniを持っており、外出先でのPCのネット接続はバッテリーの大きなiPad miniのテザリングに任せています。
しかしながら、iPad miniを更新するにあたって「余分なSIMを減らそう」と思い、調べているとスマホのBluetoothテザリング機能を知りました。

■Bluetoothテザリングを試し始める
早速、これまで試していなかったBluetoothによるテザリングを試しています。
テザリングの方法は、スマホ側でPCのBluetoothのIDを表示できるようにそれぞれ設定し、スマホでPCのIDをクリックしてペアリングします。
スマホに表示されるPCのIDをクリックしてペアリングを指示したところで、PC側にペアリング確認の番号が表示されるので、確認ボタンをおします。
Bluetoothのペアリングの経験があれば難しさはありません。

いまのところBluetooth経由でのインターネット接続は「移動先としては十分な速度」です。
もちろん、ニュースサイトなど画像の多いページでは、表示が遅くなることを感じていますが、これまでもネット接続の高速性が必要な仕事はカフェなどでWi-Fiで行ってきました。ほんとうに負荷の高い仕事は、事務所のデスクトップPCをリモートデスクトップで呼び出すことができればできてしまいます。

Bluetoothテザリングは、Wi-Fiテザリングより遅い通信になりますが、各種情報によるとスマホの電池の持ちは良くなるはずです。

■お試し投稿
この記事は、スマホのBluetoothテザリング機能でWindows PCをインターネット接続して作成し、投稿しています。全く違和感はありません。
しばらく試してみて、調子が良ければ詳細を紹介します。

コメント

令和の時代の情報通信への取り組みについて

2019-05-02 23:59:30 | 通信ネットワーク

令和の時代の情報通信への取り組みについて


いつもアクセスありがとうございます。匠技術研究所の谷山 亮治です。
「令和の時代の情報通信への取り組みについて」です。


■目指すこと
IoT/クラウドネットワークと企業ネットワークをオープンソースを活用し実現します。

■取り組みについて
IoT分野は確かな通信網の提供を始めます。IoT対象機器をローカルな通信環境を経由して如何に効率よくクラウドとつなぐか。またクラウドからのフィードバックを如何にIoTの現場に行うのかを、研究開発していきます。また、IoT研究開発環境を提供し、お客様と一緒に研究開発に取り組んでいきます。

企業ネットワークは、汎用PCにノウハウを詰め込んだ形で、お届けします。使いたい機能を選んでいただければ、十分にテストした安定した実行環境をクラウドやハードウエアとして使えるようにします。また、そのノウハウの運用技術は技術研修として提供します。

ヤマハ通信機器と企業ネットワークは切り離すことができません。これまで通りヤマハ通信機器でできる部分はさらに使い込んで、現場の要求に基づいたネットワークシステムを構築していきます。そのノウハウも技術研修として提供します。

■背景

■■簡明で自律的なネットワーク運用時代の幕開け
通信事業者内部のコア側もそれに接続するユーザー側もネットワークの構築と運用の複雑性を回避するために、簡明なネットワークが基本になります。簡明にしたうえで、特にネットワークセキュリティ部分にAIを応用し、もっと自律的に正常性を維持する仕組みの普及が始まります。

■■本格的なIoT時代の到来
令和の時代の大きな特徴は、IoT通信が普及し、一般化することでしょう。IoT通信も様々な状況に応じ、様々な方法を併用することになります。IoTはハイブリッド通信網が必要ですし、当然です。はっきりしていることは、いわゆるスマホのモバイル通信網がバックボーンになることです。IoT端末が直接バックボーンと連携することもあるでしょうし、工場内ではローカルIoT通信をまとめて光回線でバックボーンに渡すこともありえます。

■■IoT通信の二分化
IoT通信は、リアルタイム性を強く求められる分野と、そうでもない分野に大別され、通信網の選択と、サーバ側の造りも、その特性に合わせて違うものになります。

5Gの登場で「遅延の少ない通信ができる」ことへの期待がありますが、網の遅延が少なくなっても、サーバ側も必要十分な応答性を備えなければ「低遅延」は実現しません。アプリケーションを含めたリアルタイムへの取り組みが必須になります。

サーバ側へのリアルタイム性への要求は、間違いなく非リアルタイムの分野でも応答性向上の影響を与えることになり、全般的な処理速度は向上していきます。

■■リアルタイムの高精細画像通信の到来
光回線の速度向上は、モバイル通信網を集約するためにも、高速化が要求されます。コンシューマ側では8K等の高精細画像配信が常態化することで、大容量のリアルタイム送信が当たり前になります。
もちろん、業務分野でも特に医療系での活用が本格化するでしょう。博物館などのコンテンツを保持している事業体も高精細画像の配信が本格化します。

■■汎用PCを活用したネットワークの到来
ネットワークの高速化は、通信事業者のコアネットワークの変化をもたらします。通信装置の汎用化が進み、コアのコア以外は、汎用ハードウエアに必要なインターフェイスを接続したネットワークに代わるでしょう。

ユーザー側もルーターは汎用機器上でルーターソフトを動かせば、十分な時代になります。通信事業者側のネットワークとは疎結合され、お互いの影響が小さくなるように設計されます。

■■既存ネットワークのリフォーム技術価値の向上
企業内ネットワークの設計は、既存ネットワークの調整が主体となります。いわゆる新築とは異なる、リフォームを、運用中のネットワークに影響なく実施できることが価値になります。既設のネットワークをひも解く技術力は、新築を計画する技術力とは異質のもので、どちらも必要です。

さらに、オープンな機器やクラウドサーバー、マルチベンダの通信機器を使って、必要な通信網を作り上げることが当然になるので、求められる知識範囲がとても広くなります。

コメント

モバイル投稿を試しています

2018-09-23 08:50:49 | 通信ネットワーク
こんにちは。匠技術研究所の谷山 亮治です。
今日は、電車の中から投稿します。と言いつつ、高校の文化祭の待ち時間での投稿です。

毎年、毎年、通信環境は驚くほど変化しています。この数年はオリンピックとIoTを合言葉に、通信基盤は、さらに大きく変わります。

一方、富士通が動画を1/1000 に圧縮して伝送する技術を発表しました。素晴らしい成果です。ソフト側でできることが、まだまだあることを示しています。

通信回線はその時々で有限な物理資源ですから、送るデータの方で効率化が実現すると、できることが増え、これまでは、電送量の都合でできないことが、できるようになります。IoTのエッジコンピューティングとは、まさにこのことを指しており、必要十分な電送量で通信を行う工夫をし、分散処理が必須なのです。API連携の考え方は電送量を意識したRESTに集約される方向でしょうね。

コメント

NTT西日本の「Bフレッツ」が2017年11月30日に提供終了へ

2017-10-29 11:35:14 | 通信ネットワーク
匠技術研究所

NTT西日本の「Bフレッツ」が2017年11月30日に提供終了へ

いつもアクセスありがとうございます。匠技術研究所の谷山 亮治です。
NTT西日本が提供する光回線サービス(FTTH)「Bフレッツ」が2017年11月30日で提供終了します。この日をもって完全にインターネットがつながらなくなります。

このサービスは2012年3月31日に申し込み受けつけが終了したものです。それ以降申し込みの回線は関係ありません。NTT西日本の光回線サービス提供開始後、早々に利用開始し、回線変更をせずに継続利用を続けている方が対象になります。

以下に、公式の詳細な案内があり、ユーザ側の光回線終端装置で回線種別を見分ける方法も案内されています。

NTT西日本 Bフレッツ 一部サービス終了の案内
コメント

ヤマハRTX810でIPv6接続:IPv6 PPPoEのアドレスを確認する

2016-05-24 09:08:31 | 通信ネットワーク
匠技術研究所
ヤマハRTX810でIPv6接続:IPv6 PPPoEのアドレスを確認する


いつもアクセスありがとうございます。匠技術研究所の谷山 亮治です。
IPv6を使ったネット接続の実際を紹介していきます。

今回はNTT東に繋いだIPv6 PPPoEの様子です。
なおこの事例作成にはプロバイダであるSANNET様の協力を頂いています。

■IPv6 PPPoEの状態
ヤマハRTX810でIPv6 PPPoEの接続中の状態です。一部IP情報など伏せ時にしています。
IPv4とは異なり、PPPoE接続情報の中にIPv6のアドレスは見えません。

> show status pp 1
PP[01]:
Description:
Current PPPoE session status is Connected.
Access Concentrator: e14yurgok-sseu000300
12 days 13 hours 49 minutes 11 seconds connection.
Received: 2010872 packets [2742174571 octet] Load: 0.0%
Transmitted: 465139 packets [54054897 octets] Load: 0.0%
PPP Cofigure Options
LCP Local: Magic-Number MRU, Remote: CHAP Magic-Number MRU
IPCP Local:, Remote: VJC(Max slot id=255 Comp slot id=0) Primary-DNS(***.***.***.***) Primary-WINS(***.***.***.***) Secondary-DNS(***.***.***.***) Secondary-
WINS(***.***.***.***)
PP IP Address Local: Unnumbered, Remote: ***.***.***.***
IPV6CP Local: Interface-ID, Remote: Interface-ID
PP Interface-ID Local: ffffffffff803f0a, Remote: ffffffffffd6db80
CCP: None
>


■IPv6 DHCPの状態
IPv6 PPPoEはDHCP6でプロバイダからルーターに情報が渡ります。
2fff:f:ffff:4000::/56でIPv6プレフィックスが渡されています。
このアドレス空間内は自分で好きなように使って良い空間です。
2の14乗というIPv4アドレスに比べて広大な自分空間を使うことができます。
以下のIPv6アドレスは改変しています。

> show status ipv6 dhcp

DHCPv6 status

LAN1 [server]
state: reply

PP[01] [client]
state: established
server:
address: ::
preference: 0
prefix: 2fff:f:ffff:4000::/56
duration: 14400
T1: 7200
T2: 11520
preferred lifetime: 14400
valid lifetime: 14400
DNS server[1]: 2fff:f:ffff::1
DNS server[2]: 2fff:f:ff::1

>

■IPv6 LANインターフェイスの状態
LAN1にのみグローバルIPv6が振られています。これはLAN1のIPv6設定によるものです。他のインターフェイスはグローバルIPv6の設定をしていないので、プライベートIPv6がデフォルト設定です。

> show ipv6 address
LAN1 scope-id 1 [up]
Received: 37420 packets 3130944 octets
Transmitted: 38447 packets 5476940 octets

global 2fff:f:ffff:4000::1/64
link-local fe80::2a0:deff:fe80:3f0a/64
link-local ff02::1/64
link-local ff02::2/64
link-local ff02::1:2/64
link-local ff02::1:ff00:1/64
link-local ff02::1:ff80:3f0a/64

LAN2 scope-id 2 [up]
Received: 49187 packets 7131709 octets
Transmitted: 30506 packets 3264620 octets

link-local fe80::2a0:deff:fe80:3f0b/64
link-local ff02::1/64
link-local ff02::2/64
link-local ff02::1:ff80:3f0b/64

PP[01] scope-id 23 [up]
Received: 32008 packets 4499168 octets
Transmitted: 0 packet 0 octet

link-local fe80::2a0:deff:fe80:3f0a/64
link-local ff02::1/64
link-local ff02::2/64

NULL scope-id 77 [up]
Received: 0 packet 0 octet
Transmitted: 0 packet 0 octet

link-local fe80::1/64
link-local ff02::1/64
link-local ff02::2/64

LOOPBACK1 scope-id 78 [up]
Received: 0 packet 0 octet
Transmitted: 0 packet 0 octet

link-local fe80::1/64
link-local ff02::1/64
link-local ff02::2/64

LOOPBACK2 scope-id 79 [up]
Received: 0 packet 0 octet
Transmitted: 0 packet 0 octet

link-local fe80::1/64
link-local ff02::1/64
link-local ff02::2/64

LOOPBACK3 scope-id 80 [up]
Received: 0 packet 0 octet
Transmitted: 0 packet 0 octet

link-local fe80::1/64
link-local ff02::1/64
link-local ff02::2/64

LOOPBACK4 scope-id 81 [up]
Received: 0 packet 0 octet
Transmitted: 0 packet 0 octet

link-local fe80::1/64
link-local ff02::1/64
link-local ff02::2/64

LOOPBACK5 scope-id 82 [up]
Received: 0 packet 0 octet
Transmitted: 0 packet 0 octet

link-local fe80::1/64
link-local ff02::1/64
link-local ff02::2/64

LOOPBACK6 scope-id 83 [up]
Received: 0 packet 0 octet
Transmitted: 0 packet 0 octet

link-local fe80::1/64
link-local ff02::1/64
link-local ff02::2/64

LOOPBACK7 scope-id 84 [up]
Received: 0 packet 0 octet
Transmitted: 0 packet 0 octet

link-local fe80::1/64
link-local ff02::1/64
link-local ff02::2/64

LOOPBACK8 scope-id 85 [up]
Received: 0 packet 0 octet
Transmitted: 0 packet 0 octet

link-local fe80::1/64
link-local ff02::1/64
link-local ff02::2/64

LOOPBACK9 scope-id 86 [up]
Received: 0 packet 0 octet
Transmitted: 0 packet 0 octet

link-local fe80::1/64
link-local ff02::1/64
link-local ff02::2/64

BRIDGE1 scope-id 87 [down]
Received: 0 packet 0 octet
Transmitted: 0 packet 0 octet

link-local ff02::1/64
link-local ff02::2/64

>

次回は、ルーティングの確認や経路の確認です。
コメント

ヤマハRTX810でIPv6接続:IPv6 IPoE/PPPoE接続方式の違い

2016-05-23 06:34:20 | 通信ネットワーク
匠技術研究所
ヤマハRTX810でIPv6接続:IPv6 IPoE/PPPoE接続方式の違い


いつもアクセスありがとうございます。匠技術研究所の谷山 亮治です。
何度かに分けて、IPv6を使ったネット接続を紹介します。

NTT東西のIPv6の接続方法は2つです。

1.PPPoE(トンネル)方式
2.IPoE(ネイティブ)方式

PPPoE方式はIPv4のプロバイダ接続で馴染みがあります。IPv4のPPPoEセッションに加えてIPv6用のPPPoEセッションを使い、IPv4とIPv6を同時に使う場合は、同時に2セッションが必要です。この方式に対応しているプロバイダは多くあります。

IPoE方式はNTT東西から振られるIPv6アドレスがインターネット接続可能なアドレスに変わるイメージです。NTT東西はひかり電話などのNGNサービスのためにIPv6を使っており、ひかり電話を接続するホームゲートウエイ(HGW)にはIPv6アドレスが振られます。この配下ではIPv6アドレスを取得できますが、NTT東西のプライベート網接続限定で、IPv6インターネットに接続することはできません。IPoE対応のプロバイダ契約をするとNTT東西のプライベートIPv6がグローバルなIPv6に変わります。この場合は、IPv4は従前どおりPPPoEで接続するか、IPv4 over IPv6でハイブリッド接続します。

まとめると、

PPPoE(IPv4)+PPPoE(IPv6)
PPPoE(IPv4)+IPoE(IPv6)
IPoE(IPv6,IPv4)

の3つの接続方法があります。

次回は、RTX810でIPv6網がどう見えるかを紹介します。
コメント

Linux/Raspberry Piの無線LAN動作確認コマンド-子機側編

2016-01-22 14:40:16 | 通信ネットワーク
匠技術研究所
Linux/Raspberry Piの無線LAN動作確認コマンド-子機側編


いつもアクセスありがとうございます。匠技術研究所の谷山 亮治です。
今回は「Linux/Raspberry Piの無線LAN動作確認コマンド-子機側編」です。

Linuxで無線LANを使う際の、無線LANアダプタ(子機側)の動作確認方法です。

1.ハード認識
2.無線LANアダプタの詳細情報
3.無線LAN子機のアクセスポイント(アンテナ)認識状況

以下、実機での操作ログです。

■無線LANアダプタの認識
二つ認識し、起動しています。
# lsusb
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 008: ID 1004:6124 LG Electronics, Inc.
Bus 001 Device 006: ID 0bda:8178 Realtek Semiconductor Corp. RTL8192CU 802.11n WLAN Adapter
Bus 001 Device 007: ID 0bda:8178 Realtek Semiconductor Corp. RTL8192CU 802.11n WLAN Adapter
#

# iwconfig
ppp0 no wireless extensions.

wlan0 unassociated Nickname:"<WIFI@REALTEK>"
Mode:Managed Frequency=2.412 GHz Access Point: Not-Associated
Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

lo no wireless extensions.

eth0 no wireless extensions.

wlan1 unassociated Nickname:"<WIFI@REALTEK>"
Mode:Managed Frequency=2.412 GHz Access Point: Not-Associated
Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

#

■無線LANをスキャンしてもAPが見つかりません
二つのアクセスポイントそれぞれに無線LAN子機を接続する予定です。たまたま二つのアクセスポイントが停止しています。
# iwlist wlan0 scan
wlan0 No scan results

# iwlist wlan1 scan
wlan1 No scan results

#

■良好な接続の場合
scanするとSSIDが表示され、アクセスポイントがあることが判ります。
複数のアクセスポイントがある場合は、それぞれの情報が表示されます。

$ lsusb
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 005: ID 1004:6124 LG Electronics, Inc.
Bus 001 Device 007: ID 0bda:8178 Realtek Semiconductor Corp. RTL8192CU 802.11n WLAN Adapter
$ iwconfig
ppp0 no wireless extensions.

wlan0 IEEE 802.11bg ESSID:"flashair01" Nickname:"<WIFI@REALTEK>"
Mode:Managed Frequency:2.462 GHz Access Point: B8:6B:23:59:FD:D0
Bit Rate:54 Mb/s Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off
Power Management:off
Link Quality=100/100 Signal level=100/100 Noise level=0/100
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

lo no wireless extensions.

eth0 no wireless extensions.

$ iwlist wlan0 scan
wlan0 Scan completed :
Cell 01 - Address: B8:6B:23:59:FD:D0
ESSID:"flashair01"
Protocol:IEEE 802.11bg
Mode:Master
Frequency:2.462 GHz (Channel 11)
Encryption key:on
Bit Rates:54 Mb/s
Extra:rsn_ie=30140100000fac040100000fac040100000fac020c00
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : CCMP
Pairwise Ciphers (1) : CCMP
Authentication Suites (1) : PSK
Quality=100/100 Signal level=100/100

$
コメント

Wi-Fi HaLow/802.11ahが公示-IoT用広域無線LAN規格

2016-01-06 07:46:16 | 通信ネットワーク
匠技術研究所
Wi-Fi HaLow/802.11ahが公示-IoT用広域無線LAN規格


あけましておめでとうございます。匠技術研究所の谷山 亮治です。
今回は「Wi-Fi HaLow/802.11ahが公示-IoT用広域無線LAN規格」の紹介です。

Wi-Fi Alliance® introduces low power, long range Wi-Fi HaLow™ (En)

■Wi-Fi HaLow/802.11ahについて
一つのAP(Access Point)で沢山のデバイスを収容するための無線LAN規格802.11ahの策定が進み、呼称を"Wi-Fi HaLow"としてWi-Fi Allianceが公示しました。
想定の利用範囲はIoTデバイスの収容と、モバイル端末の通信のオフロード等です。定期・常時接続型IoTデバイスは低消費電力で稼働し、APは数千のデバイスとつながる必要があります。この通信モデルは現在のパソコンやスマートデバイス(PC、スマートホン、タブレット)のモデルとは異なり、互換性もありません。

大きな特徴は以下のとおりです。国毎に詳細が異なります。
900Mhz band
1kmまでの伝送距離
150kbps以上の伝送速度
最大約8000デバイス/AP
IP通信が可能

■実現できること
IoTデバイスの通信経路を容易に確立できます。
これまでより低消費電力で通信を確立できます。

■例えば
一般家庭ではAP一台で屋外を含む家庭敷地内のデバイスと情報を交換することができます。
電気メーター、水道メーター、ガスメーター等を地域で集約して情報収集できます。
一般的な駅であれば、数ヶ所に設置することで構内全ての自販機や、センサー類と情報をやりとりできます。
長距離多数の集約ができるので、様々な動体デバイスの情報交換にも使うことができます。

■今後は
策定された規格にしたがって、各国の電波の割り当てが行われ、関連機器が登場します。
IoT政策は各国必須なので、一年程で様々な利用形態が見えて来ると思われます。
コメント

Linux/sedでコマンド・プロンプトのみ抜き出し

2015-10-18 12:16:47 | 通信ネットワーク
匠技術研究所
Linux/sedでコマンド・プロンプトのみ抜き出し


いつもアクセスありがとうございます。匠技術研究所の谷山 亮治です。
今回はLinux/sedでコマンド・プロンプトのみの抜き出しを紹介します。

■どこで使うか
expectでコマンド・プロンプトを待ち受けて次のコマンドの発行を実行します。
そのコマンド・プロンプトの抜き書きを試します。
機器ごとに違うコマンド・プロンプトの抜き出しを自動化したいので試しています。

■コマンド・プロンプトのみを抜き出す
echoで擬似的にコマンドラインを出力し、sedで編集して出力しています。

$ echo "Takumi1200> exit" | sed -n 's/>.*//p'
Takumi1200

sedではコマンドをプロンプトの終端を示す">"から行末までを消去しています。
とても短い処理になりました。
コメント

ZABBIXで観測-通信経路変更で応答時間が短縮した例

2015-08-19 23:59:23 | 通信ネットワーク
匠技術研究所
ZABBIXで観測-通信経路変更で応答時間が短縮した例


いつもアクセスありがとうございます。匠技術研究所の谷山 亮治です。
今回は「ZABBIXで観測-通信経路変更で応答時間が短縮した例」を紹介します。

ZABBIXでの観測を試していますが、特定拠点のVPN上のPing間隔が毎日夕方より、長くなることが観測できました。この現象が、回線またはプロバイダに依存しているのかどうかを知るために、一時的にVPNの経路を引き込み回線とプロバイダが異なる別経路に変更したところ、下記の通り、画期的にPing応答時間が短縮されました。



詳細は、追って紹介します。
コメント