タグ付けされた質問 「networking」

モノのインターネットデバイスのネットワークとその管理、管理、およびセキュリティに関する質問。このタグはネットワーキング自体に関する一般的な質問を対象としているため、これらのタグではなく、より具体的なタグを使用することを検討してください。

4
Tor wifiルーターを使用すると、IoTの安全性が向上しますか?
Tor wifiルーターを使用すると、IoTは攻撃などからより安全になりますか? これらのルーターはTorクライアントを提供し、すべてのインターネットトラフィックをVPN経由でトンネルします。サーバーはIPアドレスを識別できないため、これによりインターネットアクセスが匿名化されます。VPNを使用すると、サードパーティのWi-Fiホットスポットを使用して接続している場合でも、インターネットの公共部分でトラフィックを傍受するのが困難になります。ノードとルーターのパスは標準の802.11暗号化を使用し、ルーターとパブリックの部分はVPN内にカプセル化されます。

3
メッシュネットワークがIoTネットワークに頻繁に使用されるのはなぜですか?
私が調査した多くの一般的なIoT通信プロトコルは、メッシュトポロジ(たとえばZigBee、Thread、Z-Wave)を採用しています。これは、すべてのデバイスが1つのルーター/ハブに接続するWi-Fiの通常のスタートポロジとはかなり対照的です。 EETimesは次のことも述べています。 メッシュネットワーキングは、多数のネットワークデバイスを相互接続するための理想的な設計ソリューションとして浮上しています。 EETimesは、信頼性の向上(例えば、自己修復伝送)がメッシュネットワークの主な利点の1つであることを示唆していますが、これは、メッシュネットワークのセットアップの複雑さの追加と比較すると、小さな利点のようです。 約10〜20のネットワークデバイスを含み、エンドツーエンドで短距離に広がるホームIoTネットワークの場合、メッシュネットワークが通常のスタートポロジよりも適しているのはなぜですか?追加された複雑さは、私が信じているほど重要ではありませんか?

2
ブロックチェーンがIoTで使用されるアプリケーションはありますか?
これら2つのテクノロジーの登場以来、ブロックチェーンやその他の形式の暗号通貨がより頻繁に使用されるようになる可能性は近い将来にあります。 この記事によると: ブロックチェーンの分散型で自律的で信頼できない機能は、産業用IoTソリューションの基本要素になる理想的なコンポーネントになります。エンタープライズIoTテクノロジーがブロックチェーンテクノロジーの早期採用者の1つに急速に成長したことは驚くに値しません。 さらに、記事の最後に、Filamentという名前の会社がBitCoin支払いを使用して、さまざまな地域で特定のアプリケーションのセンサーを有効にしています。 現在、ブロックチェーン+ IoTを覗くことができるオープンソースアプリケーションはありますか?

1
IoTネットワークの一般的なネットワークトポロジは何ですか?
たとえば、ポートフォワーディングに関する質問など、IoTネットワークの詳細について質問する質問がいくつかあります。汎用のIoTシステムの典型的なベースラインアーキテクチャとは何であると考えられるかについて質問することは有用だと思います。 私たちは、センサ側でのネットワークの話をいくつかの質問がある場合は、メッシュネットワークはこの質問のためになど、適切な、私はあまりこれらに興味がある-彼らは短距離無線接続として一般化することができます。詳細がネットワークトポロジ全体に直接影響する場合を除いて、ノード間のローカルネットワークの詳細にも特に興味はありません。 私は完全な説明を求めているのではなく、現在の基準を捉えているだけです。今日一般的に使用されている一般的なネットワークトポロジはどれですか。また、少なくとも次の機能をカバーする優れたスケーラブルなモデルを提供します。 ローカルのネットワーク制御 リモートアクセス 複数の場所にあるセンサーノード データ集約(機械学習など) データの共有(信頼できる隣人など) 停止に対する回復力(WANを通常考える) 私はここで発明を探しているのではなく、特定のコーナーケースに深く入っている答えを探しています。また、セキュリティを除外したいと思います。ただし、トポロジのいずれかの側面が優れたセキュリティに不可欠である場合を除きます(これは非常に明白であり、上記の機能リストに属していないと想定しています)。

1
Weightless-Wで使用するテレビの「ホワイトスペース」周波数を決定するにはどうすればよいですか?
無重量Wは、「テレビのホワイトスペーススペクトルで動作する低電力ワイドエリア(LPWAN)スターネットワークアーキテクチャ」としての地位を高め、この送信方法にはいくつかの好ましい特性があることを示唆しているようです。 端末レベルでは、データパケットサイズが10バイトで上限がなく、オーバーヘッドが非常に低く、50バイトパケットのオーバーヘッドが20%未満のリンクバジェットに応じて、1kbit / s〜10Mbit / sのデータレートが可能です。[...] 非常に広い範囲の変調方式と拡散係数により、屋内端末への5 kmのカバレッジを可能にするネットワーク設計に柔軟性が提供されます。 上のどの無重力標準ページ、それも述べて: ネットワークが配備される場所でTVホワイトスペーススペクトルが利用可能であり、広範な機能セットが必要な場合は、Weightless-Wを使用します 問題は、ホワイトスペーススペクトルが利用可能かどうかを判断することです。Weightless-WでIoTを使用するために空白が開いている場所を確認するにはどうすればよいですか?これを決定するために使用できるツールまたはマップはありますか?また、他のIoTネットワークがホワイトスペース周波数の一部を占めているかどうか、およびそれらが干渉する可能性を考慮する必要がありますか? それが答えに役立つ場合は、イギリスのTVの空白を特定することに特に焦点を当てることができますが、もっと一般的な解決策も読むのは興味深いでしょう。

1
DLNAインフラストラクチャをデバッグする方法は?
私は家にいるとんでもない状況に困っています。 私は持っています: マランツNR1504 AVレシーバー。PowerLanおよびイーサネット経由でルーター/モデムに接続されています。 WiFiを介して同じルーターに接続されたSamsung SmartTV。 BubbleUPnPを備え、WiFi経由で同じルーターに接続されたAndroidスマートフォン。 イーサネット経由で同じルーターに直接接続されたSynology DS414。 Synologyには、MP3とFLACの音楽ファイルのコレクションが含まれています。このコレクションにはテレビ、レシーバー、BubbleUPnPからアクセスできました。レシーバーから直接再生したり、HDMIから返されたサウンドを使用してテレビで再生したり、スマートフォンを使用してミュージカルコレクションにアクセスしてレシーバーでサウンドを再生したりできます。 SynologyはMedia Serverを使用して音楽ファイルを提供します。 要約すると、状況は次のとおりです。 BubbpleUPnPはSynologyの音楽コレクションを見ることができ、レシーバーを見ることができます。 受信者はSynologyの音楽コレクションを見ることができ、BubbleUPnPを見ることができます。 TVはSynologyでミュージカルコレクションを見ることができます。 しばらくの間、すべてがうまくいきました。私はいつもすべての機能を使用したわけではないので、いつ問題が発生したのか正確にはわかりません。ただし、現在の状況は次のとおりです。 BubbleUPnPはSynologyをまったく認識しません。それはまだ受信機を見ています。 レシーバーはSynologyをまったく認識しません。BubbleUPnPは表示されます。 TVはSynologyをすべてのメディアファイルで問題なく表示できます。 Synologyのメディアサーバーは、メディアサーバー> DMA互換性>デバイスリストにTV、BubbleUPnP、レシーバーを表示します。 そう: 2つのDLNAチャネルは問題なく機能します。TV—SynologyとBubbleUPnP—レシーバーです。 2つのDLNAチャネルが1つの方法で機能します。SynologyはBubbleUPnPとレシーバーを認識しますが、逆方向は認識しません。 そのような構成をデバッグするための「標準」または推奨されるアプローチはあるのでしょうか。複数のベンダーとデバイス、およびかなり複雑なネットワーク構成が含まれるため、どのテクニカルサポートに問い合わせればよいかさえわかりません。一方で、こういう問題を解決するには、ある程度の知識が必要だと思います。

2
インターネットに接続されていないWiFiデバイスの標準ですか?
たくさんのホームオートメーションをするつもりです。そのために、すべてのデバイスが接続されるプライベートな分離WiFiネットワークをホストします。デバイスは、単純なライト、RGB LEDストリップ(smd5050およびws2812b)、サーモスタット、ファン、ウィンドウオープナー、ウィンドウシェードコントローラー、および通常のコンセントになります。また、テレビを起動するためにリモコンをシミュレートするIRトランスミッター。そして、標準のリモート制御コンセントを切り替えることができるリモコンをシミュレートする433MHzトランスミッター。 今、これらのデバイスがWiFiネットワークに公開する必要があるインターフェイスの種類に標準があるかどうか疑問に思っています。 もちろん、すべてのデバイスに単純なhttpルートを与え、自分のインターフェースを理解するアプリケーションを作成することもできますが、すでに作成されたアプリケーションやプログラムを使用して標準を理解できるようにする標準を実装できればよいと思います。

1
AlexaはFauxmoとESP8266を識別できません
fauxmoを使用してESP8266を制御しようとしています。プログラムは正しくコンパイルされますが、Alexaアプリを実行してデバイスを検索すると、ESPが表示されません。 ESPは確実にホームネットワークに接続されており、プログラムは実行されています(シリアル出力を確認しました)。また、Nestサーモスタットなど、他のネットワークデバイスも表示されます。 なぜそれが表示されないかもしれないかのようなアイデアは、大歓迎です。 これが私のwemos d1 miniのコードです #include <Arduino.h> #include <ESP8266WiFi.h> #include "fauxmoESP.h" #define WIFI_SSID "..." #define WIFI_PASS "..." #define SERIAL_BAUDRATE 115200 fauxmoESP fauxmo; // ----------------------------------------------------------------------------- // Wifi // ----------------------------------------------------------------------------- void wifiSetup() { // Set WIFI module to STA mode WiFi.mode(WIFI_STA); // Connect Serial.printf("[WIFI] Connecting to %s ", WIFI_SSID); WiFi.begin(WIFI_SSID, WIFI_PASS); …

1
DHCPを介してIPを割り当てることによるプライベートサブネットの作成
必要に応じて、esp8266 wifiモジュールを使用しています。私がやろうとしていることは、モジュールをホームルーターに接続し、他のモジュールをこのモジュールに接続して2番目の層を形成させ、この2番目の層に他のモジュールを接続して3番目の層を形成し、ネットワークを拡張することです。ネットワークトポロジのように。ホームルーターに接続する最初のモジュールは、ホームルーターのIP範囲から独立した独自のプライベートIP範囲にし、さらにサブネット化します。だから私たちはから始めます: 最初のモジュールは10.0.0.0/8。それはIP 10.1.0.0を取ります DHCP経由で10.2.1.0/16、10.3.1.0/16 ... 10.254.0.0/16を提供します 10.2.1.0/16はさらに、10.2.2.1 / 24、10.2.3.0 / 24などをDHCP経由で10.2.254.0/24まで提供できます。 10.2.2.1/24は10.2.2.2/32から10.2.2.254/32 DHCPを提供できます すべてのモジュールは、独自のDHCPサーバーを実行します。 ここで問題は、モジュールが別のモジュールからIPアドレスを割り当てる要求を受け取ると、DHCPサーバーが応答することです。しかし問題は、DHCPが私が説明した方法でIPアドレスを割り当てることができず、隣接するip-blocksに対してのみ設定できるように見えることです。 例192.168.1.0から192.168.254.254は問題ありませんが、192.168.1.0から192.168.254.0が必要です DHCPサーバーに希望どおりにIPアドレスを割り当てる方法はありますか?

2
LoraWanゲートウェイの構成
Arduinoでプログラム可能なセンサーとDragino Loraシールドを使用してLoRaWanネットワークを構築しようとしています。 私はラズベリーパイなどのゲートウェイを作成するための多くのソリューションは、別のDragino LORAシールドまたはに接続されて発見したiC880Aクラウド内のサーバを行う、と私は受信データが送信されます。ゲートウェイのプログラミングについて非常に混乱しています。 ノードとサーバーに接続するように指示する必要がありますか?それともデータを自動的に受け取りますか? そして、ゲートウェイに接続するように、または直接ノードに接続するようにサーバーをプログラムしますか?
10 networking  lora 

3
XMPPには、IoTデバイスが短く頻繁にメッセージを送信するための大きなオーバーヘッドがありますか?
私はXMPPをIoTデバイスの潜在的な通信プロトコルとして読んでいましたが、1つのソースを読んだ後、各メッセージのオーバーヘッドを懸念している場合、それが本当に適切なプロトコルであるかどうかわかりません。 このソースは述べています: ただし、XMPPにはいくつかの問題があり、EMBEDDED IOT PROTOCOLSにはやや望ましくありません。XMPPはXMLベースのプロトコルであるため、HTTPよりも非常に詳細であり、データオーバーヘッドが大きくなります。IOT CONNECTED DEVICEからサーバーに1バイトのデータを送信するための単一の要求/応答交換は、0.5 kBを超えます。 効率的なXML Interchange(EXI)と呼ばれるXMLエンコーディングを使用してXMPPを圧縮するドラフト仕様があります。ただし、EXIを使用しても、同じ1バイトのデータはXMPPだけから数百バイトのプロトコルオーバーヘッドを取得します。EXIは、現在利用可能な他のオプションよりも処理がはるかに難しいフォーマットです。これらの固有の問題のため、組み込みIoTアプリケーションでXMPPを使用しないことをお勧めします。 ただし、XMPP はそれ自体がIoTアプリケーションに適していると宣伝しています(ただし、オーバーヘッドが低いとは具体的には言われていません)。そのため、このような大規模で一見冗長なプロトコルがIoTデバイスに推奨/昇格されるのは奇妙に思われます。 XMPPのオーバーヘッドは、ソースが少量のデータに対して示しているのと同じくらい大きいですか?たとえば、8バイトのメッセージを送信する場合、どのくらいのオーバーヘッドがありますか? また、(ソースで言及されているように)EXI圧縮が使用されている場合、オーバーヘッドはそれほど大きいですか?これにもいくつかの落とし穴がありますか?

1
メッセージの損失や重複を回避して、デバイス間でデータを同期するにはどうすればよいですか?
私は相互にデータを送信するデバイスのIoTネットワークを使用しており、データはデータベースに保存されています。 デバイスが10パケット/ APIリクエストを順番に送信している場合、宛先に到達するのがごく少数の場合があります。たとえば、パケット1、3、9は宛先に到達し、他のパケットは到達しない場合があります。 これらのパケットを追跡して、すべてが重複や漏洩なしに宛先に到達するようにするにはどうすればよいですか?実際のシナリオでは、1つのデバイスがパケットを失うだけでなく、何千ものデバイスが存在すると予想しています。


2
IoTデバイス設定を構成するためのプロトコル
MQTTは、エンドデバイスとホストサービス間でアプリケーションデータを交換する場合、IoTで広く使用されています。パブリッシュサブスクライブモデルを使用すると、ハンドシェイクやネゴシエーションなどが不要になります(少なくともMQTTプロトコルレイヤーの上)。それは主にデータを簡単に消費者に配布できるデータプロデューサーに向けられています。 ただし、エンドデバイスで設定を構成する中央サーバーに関しては、モデルが非常に適しているかどうかはわかりません。サーバーはコマンドをデバイスに送信して応答を待ちます(たとえば、特定の設定を読み取り、応答を待ちます)。これは、MQTTのパブリッシュ/サブスクライブモデルにはあま​​り適していません。 コマンドの送受信とリモートデバイスの構成を目的とした既存のプロトコルがあるかどうか疑問に思っていましたか?

3
ブロードバンドネットワーク経由で接続されたIoTセットアップでRaspberry Piを攻撃から保護する方法
セットアップ: ブロードバンド接続を介してインターネットに接続されているマスターノードとしてRaspberry Piを使用しています。raspberrypiは、いくつかのセンサーや他のマイクロコントローラーを接続します。Piはクラウドホスティングプロバイダーのサーバーに継続的に接続されます。 質問は次のとおりです。 権限のないユーザーがラズベリーPiにアクセスできないようにするにはどうすればよいですか? PiへのDDoS攻撃を防ぐにはどうすればよいですか? PiへのアクセスにDDNS(ダイナミックDNS)をどのように使用する必要がありますか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.