奈良にHDDレコーダーやテレビなどいろいろな家電があり、録画したものを東京でみたいと思ったとき、実装をどうしようか悩んでおり、解決方法が無いか模索していた。その中で、DTCP-IPを流す方法。しかし、技術仕様に7msの壁があり、想定内であったものの、やはり通らず。
東阪には、L2の網が引かれており、その上にVLANが流れてる。基本的にはバックボーンセグメントとしてOSPFによる経路交換を行うVLANをベースに運用していますが、汎用性を持たせるため、L2網の上にVLANを流せるような設計にしています。
841M導入時にはまったネタを参考に。
話を戻して、DTCP-IPはL2でないといけないので、専用のVLANを東阪に敷設してのばしましたが、RTTの問題で、結局NG。proxy arp + L2 Bridge でごまかそうかとおもって、しらべていたところ、「日本のちゃんとしたメーカ製レコーダは、共有鍵生成プロセス中に時間測定してるはずなので難しいと思います。」といったコメントをとある人からいただいた。うーむ、難しいなぁ。あきらめて、ひとまず、HDMI Extender over IP を使用してみることに。
東阪のL2ネットワークを構成しているルータの制約で、300Mbpsが上限。スペック通りにでないね、ってメーカーに言ったらそんなことは無いはず。とだが、検証方法含めフィードバックしたら、やはり出ないねと。後継機種があるので、そっちを試してください!といわれ、ハンドキャリーで評価機の貸し出し。負荷試験したら、東阪では、800Mbpsを簡単に超えれたが、今のところ買い換える予定は無し。壊れたら後継機種買いますね。HDMI Extender のスペックをいろいろと調べていると、80Mbpsやら、100Mbpsといった帯域幅を要求するとあるので、これなら、HDMI Extender over IP でも、3本は通る計算。ということで、いろいろと調査した結果、要件に合いそうなものを適当に2機種購入。
どちらも調べてみると、怪しい表記ではあったモノの、どちらもover Ethernetに対応している様子。スイッチをかましてもいけるとのこと。
ただ、373側はHDCP対応、891はIR対応だが、HDCP対応とは記載が無い。同一メーカーのようだが、Amazonでいろいろと調べてみると、あちこちにOEMを出しており、891には、HDCP対応という記載は無かった。ちなみに、どちらもCECには未対応の為、テレビからHDMIデバイスを操作することは出来ないので、IR対応の891も併せて購入している。
まずは届いたので開墾の儀。
パッケージおよび、373(左)、891(右)
外観パッケージは同じのようだ。見た目の区別は付かず、サイズも同じ。
開封してみると、Amazonの商品紹介と同じく、そのまま。
LAN側インターフェース
HDMI側およびACアダプタインターフェース
上から
裏面から
ACアダプタは5V 1Aのもの。うまく使えば、USBから供給可能なので、宅内に、HUBやオーディオの同軸→光の変換、HDMIセレクター、Amazon FireTVなどそういったデバイスが多い場合は、 Anker PowerPort 6 Lite (30W 6ポート USB急速充電器)といった、各ポート1A供給できる6ポート程度のUSB充電器などを用意すればよいだろう。今となっては、QCやUSB Type-Cなどが始まり、古くなったUSB給電アダプタを余らしているところも多いだろうから、そういうのを転用しても良さそう。その際は、 USB-DC電源供給ケーブル センタープラス 1m (Φ5.5/2.1mm 標準DCプラグ)といったモノを準備すればよいだろう。※ サイズは、Φ5.5/2.1mm 標準DCプラグ だと思いますが、はかっておりませんので注意してください。
ということで、届いたので、電源を入れて、動作確認。
作業用のスイッチとして、我が家では
Panasonic Switch-M8eG や、
BUFFALO BS-G2108URといったスイッチを大量に採用しており、予備機も潤沢にあるので、今回は、一般家庭を想定し、BUFFALO BS-G2108URを使用してみた。
HDMI Extenderの紹介には、帯域幅80Mとか100Mといった表記しかなく、また、製造メーカーも不明であり、詳細を調べることが出来なかった。
まず、LEDを見ていただきたいのだが、オレンジ色でLinkUpしている。すなわち、100Mで上がっているということだ。多くても上限で100Mbpsの能力しか無いということ、L2遠伸をしても、実効帯域300Mbpsあるので、影響は受けないということになる。
さて、環境がそろったところで、次の組み合わせ試験を行った。
- 373(Tx) - 373(Rx)
- 373(Tx) - 891(Rx)
- 891(Tx) - 891(Rx)
- 891(Tx) - 373(Rx)
- 891(Tx) - 373(Rx) and 891(Rx)
いずれの組み合わせもOK。ついでに、空きポートにPCをつないだところ、そちらにもパケットが来ており、他のポートと同様に点滅することから、フラッディングしている様子。
これは、想定範囲内で、
Amazonのレビューに次のようなコメント
1つのLANハブから各部屋に有線LANを通していて、そこに接続をすると全てのハブがビージー状態になってしまいます。(使ってないところまでピカピカと点滅する)←うまく説明できない
すなわち、ブロードキャストに投げるような粗悪な実装か、マルチキャストをしているのではないかと、容易に想像が付く。今回、IGMP未対応のスイッチを使用しているので、フラッディングしているように見えるが、正常。実際にパケットをみてみると、次のようなメッセージ。
15:45:05.858549 00:0b:78:00:60:01 > 01:00:5e:02:02:02, ethertype IPv4 (0x0800), length 1066: (tos 0x40, ttl 128, id 9006, offset 0, flags [none], proto UDP (17), length 1052) 192.168.168.55.2068 > 226.2.2.2.2068: [no cksum] UDP, length 1024 15:45:05.858667 00:0b:78:00:60:01 > 01:00:5e:02:02:02, ethertype IPv4 (0x0800), length 1066: (tos 0x40, ttl 128, id 9006, offset 0, flags [none], proto UDP (17), length 1052) 192.168.168.55.2068 > 226.2.2.2.2068: [no cksum] UDP, length 1024 15:45:05.858784 00:0b:78:00:60:01 > 01:00:5e:02:02:02, ethertype IPv4 (0x0800), length 1066: (tos 0x40, ttl 128, id 9006, offset 0, flags [none], proto UDP (17), length 1052) 192.168.168.55.2068 > 226.2.2.2.2068: [no cksum] UDP, length 1024 15:45:05.858901 00:0b:78:00:60:01 > 01:00:5e:02:02:02, ethertype IPv4 (0x0800), length 1066: (tos 0x40, ttl 128, id 9006, offset 0, flags [none], proto UDP (17), length 1052) 192.168.168.55.2068 > 226.2.2.2.2068: [no cksum] UDP, length 1024 15:45:05.858902 00:0b:78:00:60:01 > 01:00:5e:02:02:02, ethertype IPv4 (0x0800), length 1066: (tos 0x40, ttl 128, id 9006, offset 0, flags [none], prot 15:45:05.859019 00:0b:78:00:60:01 > 01:00:5e:02:02:02, ethertype IPv4 (0x0800), length 1066: (tos 0x40, ttl 128, id 9006, offset 0, flags [none], proto UDP (17), length 1052) 192.168.168.55.2068 > 226.2.2.2.2068: [no cksum] UDP, length 1024IP Multicast については、英語の WikiPedia:Multicast addressがてっとり早く詳しいが、226.2.2.2 は RFC5771によると、
225.0.0.0 - 231.255.255.255 (7 /8s) RESERVEDとなっている。宛先mac address 01:00:5e は、RFC1112で定義されたアドレス。
01-00-5E-00-00-00 - 01-00-5E-7F-FF-FF 0x0800 IPv4 Multicast (RFC 1112), insert the low 23 Bits of the multicast IPv4 Address into the Ethernet Address (RFC 7042 2.1.1.)
上記の背景からIP Muticast を使用していると断言出来る。
さて、ではスループットについてしらべてみよう。IGMP未対応のスイッチのため、フラッディングしてくるので、同じトラフィックがPCでも見ることが出来る。
すなわち、プロミスキャス・モードに切り替え、テスト用端末のインターフェースで受信したトラフィック量をモニタしてみた。
$ ifstat -b -i eth1 eth1 Kbps in Kbps out 64244.03 0.00 53804.32 0.00 49787.48 0.00 49209.97 0.00 50719.70 0.00 63823.11 0.00 69301.00 0.00 68460.17 0.00 64678.62 0.00 58649.50 0.00 52736.90 0.00 47499.17 0.00 51966.95 0.00 58729.38 0.00 67817.21 0.00 68894.07 0.00 68828.96 0.00 $
上記から、映像を送信している場合は、最大でも、70Mbps程度使用していることになる。300Mbpsの有効帯域があると言うことは、4本のHDMIが通ると言ってもよい。4chですよ、4ch。すごいね。
尚、真っ黒の画面を送信した場合は、10Mbps程度、HDMI入力をOFFにした場合は、ほとんどパケットの送信は無かった。電源が入っている限り、トラフィックを出すと言った仕様では無いこと、映像によって、帯域は可変で、10Mbps〜70Mbps程度の幅があることがわかった。
参考として、HDMI の Source に使用した機器は、 パナソニック プライベート・ビエラ UN-15T5のチューナーに接続、測定した。
さてさて、これだけでは、本記事としては面白くないということ、端末にIPアドレスが付与されているということで、scanなどを行ってみた。
# nmap -sP 192.168.168.0/24 Starting Nmap 7.60 ( https://nmap.org ) at 2018-08-18 15:50 JST Nmap scan report for 192.168.168.55 Host is up (0.0046s latency). MAC Address: 00:0B:78:00:60:01 (Taifatech) Nmap scan report for 192.168.168.56 Host is up (0.0088s latency). MAC Address: 00:0B:78:00:60:02 (Taifatech) Nmap scan report for 192.168.168.148 Host is up (0.0058s latency). MAC Address: 00:0B:78:00:60:A4 (Taifatech) Nmap scan report for 192.168.168.1 Host is up. #
基本的にはTxとRxの出荷のMacAddressは連番になっているようで、891については、.55(Tx), .56(Rx)となっていたが、373は、.55(Tx)、.148(Rx)となっていたので、Tx側モジュールをそのまま使うには、IPアドレスが重複する可能性がある。ちなみに、同時にTxを2つつないだ場合の挙動は未確認。後ほどテストをしてみます。
mac addressからして、Taifatech となっており、oui.txt によると、下記の通り。
000B78 (base 16) TAIFATECH INC. 8F-1 No.289, Sec.2 Guangfu Rd. Hsinchu 300 TW
台湾の会社で、調べても、 Taifatech Inc. Announces PC2HDTV Full HD Interactive Solution that Goes Beyond Wireless Displayという記事ぐらいしかヒットせず、他は、oui の情報程度。リリースには、「@taifatech.com」というドメイン表記はあり、whois をしてみたところ、失効した形跡は無いが別物のように見える。情報がなさすぎる。ということで、nmapによる追試験を行ってみると、次のような結果に。
- 891 Tx
sh-3.2# nmap -P0 -p1-65535 192.168.168.55 Starting Nmap 7.70 ( https://nmap.org ) at 2018-08-18 22:22 JST Nmap scan report for 192.168.168.55 Host is up (0.0045s latency). Not shown: 65362 closed ports, 172 filtered ports PORT STATE SERVICE 80/tcp open http MAC Address: 00:0B:78:00:60:01 (Taifatech) Nmap done: 1 IP address (1 host up) scanned in 74.85 seconds sh-3.2#
- 891 Rx
sh-3.2# nmap -P0 -p1-65535 192.168.168.56 Starting Nmap 7.70 ( https://nmap.org ) at 2018-08-18 22:27 JST Nmap scan report for 192.168.168.56 Host is up (0.0055s latency). Not shown: 65376 closed ports, 158 filtered ports PORT STATE SERVICE 80/tcp open http MAC Address: 00:0B:78:00:60:02 (Taifatech) Nmap done: 1 IP address (1 host up) scanned in 90.87 seconds sh-3.2#
どちらもHTTPがあいている様子。というこことは、ブラウザでアクセスするに限るということ。
ここでファームウェアの更新も、IPアドレスの変更も出来るようで、また、Uart Bpsとあることから、内部におそらく、シリアルコンソールがあると思われる。そのため、ここで触ると、何か楽しいことがあるかもしれない。尚、Tx/Rxおよび、モデルによっても全く同じWebUIであったため、891 Txのみのスクリーンショットとしている。
なお、HTTPを手で叩いてみたところ、httpd の finger print など何も返さなかったので、さらに追試験してみると、次のような結果に。
sh-3.2# nmap -p 80 -O 192.168.168.56 Starting Nmap 7.70 ( https://nmap.org ) at 2018-08-18 22:42 JST Nmap scan report for 192.168.168.56 Host is up (0.00074s latency). PORT STATE SERVICE 80/tcp open http MAC Address: F0:0C:0C:00:00:80 (Unknown) Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Device type: proxy server Running: Blue Coat embedded OS CPE: cpe:/h:bluecoat:packetshaper OS details: Blue Coat PacketShaper appliance Network Distance: 1 hop OS detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 3.08 seconds sh-3.2#
明らかに、このOSは間違っているだろう。尚、HDMI Extender の起動は数秒で終わっているため、組み込みLinuxとも違うのか。謎である。
さらに調べていたところ、HDMI Extender は IP Multicast なので、vlc などで拾うことが出来ないか実験、調査していたところ、下記のような情報が。
- REVERSE ENGINEERING LENKENG HDMI OVER IP EXTENDER
- NEW VERSION OF LENKENG HDMI OVER IP EXTENDER LKV373A (UPDATE 20. OCT 2017)
- GitHub - bp2008/HdmiExtender
考えることは同じだ。環境を作れば、パケットを拾い、PCでキャプチャすることも可能のようだ。
ローカルの試験は完了したので、L2遠伸で遠くの拠点に映像を伝送しようかとおもうが、チューナーは一カ所においてあるため、NHK対策にちょうどよい。NHKは放送の受信機を設置した場所に取り立てにくるとのことなので、こういった映像だけ伝送する場合は対象外だ。NHK対策に、実家にチューナー、拠点にモニタ+HDMI Extenderによる映像の伝送などを試してみるとよいかもしれない。
さらに最近は、インターネット回線に対して、頭の悪いキチガイ集団は、課金をしようとしているようだが、専用線を調達して一カ所から集中のゲートウェイを作れば、インターネットとしての契約は1つで済むので、この問題も解決出来るだろう。
キチガイ対策に検討を祈る。