Arpchat - ARPだけで同じネットワーク上の友だちにメッセージを送るチャットアプリ
(github.com/kognise)- arpchat は、コンピューターが同じネットワーク上の別のコンピューターの MAC アドレスを見つけるために使う ARP を利用して作られたチャットアプリのツール
- クライアント分離ネットワークで友だちとチャットしたいという利用状況が動機として示されたプロジェクト
- ARP 上に単純な汎用転送プロトコルを実装しており、数万文字の長さのメッセージを送ることができ、多少の 圧縮 も使用
- 接続および退出通知とともに、オンラインユーザー一覧を更新するための presence discovery と heartbeat システムを備える
- インストール用バイナリは releases page から入手可能
- Windows では npcap が必要な場合があり、インストール時に
Install Npcap in WinPcap API-compatible Modeの選択が必要 - Linux では
sudo setcap CAP_NET_RAW+ep /path/to/arpchatでネットワーク権限の付与が必要な場合あり
- Windows では npcap が必要な場合があり、インストール時に
- ターミナルでバイナリを実行し、送信したメッセージが自分の画面に表示されれば正常動作していると判断可能
- ビルドは最新の unstable Rust でテストされており、Windows ビルドには WinPcap Developer's Pack と、
LIB環境変数をWpdPack/Lib/x64/フォルダーに設定する手順が必要
1件のコメント
Hacker News のコメント
これを作った本人です。今日 HN に載った別のものも作ったのですが（https://news.ycombinator.com/item?id=37062422）、ArpChat も一緒に上がっているのを見てかなり不思議な気分です。たぶん誰かが私のプロフィールを見たのでしょう。
本当に楽しいプロジェクトで、ネットワーキングをたくさん学びました。
少し前に完全オフライン環境で実際に使ってみる機会もあり、面白かったです。ただ、その後大きなバグを見つけ、そのバグがものすごい遅延を引き起こしていました。修正はしましたが、まだ新しいビルド成果物を上げられていないので、実環境でテストするつもりならソースから自分でビルドしたほうがよいです。遊びでユーザー名の色とメッセージ時刻も追加しました。近いうちに新しいリリースを上げると約束します。
興味があれば、約1年前に ArpChat の仕組みについて書いた記事もあります: https://kognise.dev/writing/arp
これからもコードで遊び続けてほしいです。justine tunney が https://justine.lol/ape.html のような仕事で見せたものにも少し似ています。ごく少数の人だけがきちんと理解している領域、たとえばコンパイラのバイナリ形式の細部を深掘りしたうえで、「すべてのバイナリ形式を1つのメタ形式につなぎ合わせて、実際に全部で実行できるようにできないか？」みたいな狂った問いを投げかけ、実際に動くものを作り上げる感じです。
# sudo getcap ./arpchat./arpchat cap_net_raw=ep“error getting channel, might be missing permissions” と出ます。
追記: このエラーは
setcapの設定ではなく arpchat から出ているものです。まさにこういうものを求めていました。データリンク層で遊ぶなんて。
Address Resolution Protocol（ARP）が何かを知らない人向けにかなり大ざっぱに言うと、MAC アドレス（Ethernet が使うもの）と IP アドレス（インターネットが使うもの）をつなぐミッシングリンクです。
routeで見られる IP ルーティングテーブルが、次にパケットを送る IP アドレスを決めると、arpで見られる ARP キャッシュが、その IP に対応する MAC アドレスを決定します。通常はルーターのローカル IP アドレスです。最近では ARP の存在を知っているだけでも、少し非専門的な秘教知識のように扱われがちで、IPv6 側の兄弟である Neighbor Discovery Protocol はさらにそうです。現代のクラウドベースのデプロイでは頻繁に直接触らないとしても、その存在を知っていると、ネットワークスタック全体を俯瞰する視野がずっと完全になります。
arpingは、同じネットワークセグメント上の機器が起動しているものの ICMP ping に応答しないかを確認するときに非常に便利です。tcpdumpや Wireshark のダンプを見れば、いずれ必ず遭遇します。ただ、ソフトウェアエンジニアはクラウドと従来型ネットワークがかなり違うため、アプリケーションより先に自宅ネットワークをデバッグするときに触れることになるかもしれません。ARP が任意のペイロードを載せられる点を悪用するのは面白いですが、ネットワーキング入門の観点から言い直すと、作者が頼っている核心は、スイッチが
ff:ff:ff:ff:ff:ff宛てのパケットをブロードキャストドメイン全体にフラッディングするという単純な事実です。スーパーユーザー権限や raw パケット権限がなくても、L3 ブロードキャストアドレスにパケットを送れば通常 L2 でフラッディングされるため、似たようなメッセージ伝播を作れます。つまりブロードキャストアドレスに ping を打つのは面白いということです。
ARP を使うことに特別な利点はありません。また、最近のスイッチの多くは ARP パケットを監視する機能を持っているため、偽の ARP トラフィックを大量に流すと実際に悪影響が出る可能性があります。それでも面白い取り組みで、自分が学んでいた頃に作っていたいたずらを思い出します。個人的にはこの目的には ICMP を悪用しただろうと思いますし、今後の開発方向になるかもしれません。楽しいプロジェクトに拍手を送ります。
ARP、DNS、HTTP、TLS は、一方では私たちが思い浮かべるまさにそのプロトコルですが、同時にすべて数字にすぎません。ARP も HTTP と同じ数字の空間にアクセスしています。UDP だけが 11 ビットバイトを使うわけでもなく、DNS だけが使える特別な CPU 命令があるわけでもありません。結局は全部数字です。最後には、望む数字を線に押し込むことができ、世界の残りはその数字を受け取ってそれぞれの仕事をするだけです。
今日では動作すべきではありませんが、当時は無邪気な TCP/IP 実装、つまりそのかなり多くが喜んで参加していました。
ほとんどのOSに標準搭載されているプロトコルを悪用するのが好き。別途クライアントソフトウェアをインストールせずに済むクロスプラットフォームのGUI/CLIメッセージングシステムが見つからなかったので、Finder.app/Explorer.exe/Gnome/KDEでメッセージを見られる、ばかげた偽の Samba共有 を作ったことがある
ローカルネットワークでnetcatを呼ぶのもうまくいかず、ブロードキャストするにはOSごとのフラグの違いもあった。ファイルブラウザでSamba共有のメッセージを見てクリックし、ファイル名を修正して3行の「掲示板」を更新する方式だった
https://github.com/jedahan/samba-haiku/blob/master/index.js
これも元々はWi-Fi SSIDを使ってcaptive portal俳句を作っていたものを再実装したもの
https://github.com/jedahan/haiku-wifi
思った以上に面白いかもしれない。主要ベンダーのハードウェアで VLAN を使ってネットワークを分離していたのだが、ほとんどの場合VLANは機能している一方で、ARPトラフィックが漏れていることに気づいた
マシンはすべてのトラフィックをルーター経由で送る必要があったのに、時々、本来見えてはいけないARP応答を見て、別のマシンへ直接到達できると判断していた。その結果、ARPキャッシュエントリが期限切れになるまでトラフィックを送れず、厄介だった。ベンダーは大きすぎて気にせず、バグ修正にも関心を示さなかった
特定の状況では、このチャットアプリがVLANを突破できる可能性がある
妻と子どもたち、そして自分はほとんど家で仕事や勉強をしていて、それぞれ別の部屋にいることが多い。必要なときに互いにメッセージをやり取りするために BeeBEEP を使っている。サーバー不要で、LinuxクライアントとWindowsクライアントの両方があるのが決め手だった
かなりうまく動くが、ノートPCがスリープから復帰したあと、LAN上の他の人を再び見えるようにするには、たまに再起動が必要になる。それと、トレイアイコンから特定の人へ直接メッセージウィンドウを開けない点が、ほぼ唯一の不満。面白い猫画像をコピーして貼り付けることもできるし、ファイル転送など自分が使っていない機能もある。有料広告ではなく、ただ長々と語っただけ
https://www.beebeep.net/
高校のとき
net sendでこれをやって叱られたそこでシステム管理者のユーザー名をスプーフィングし（Win9xでは難しくなかった）、厳しい警告メッセージを送った。突然メッセージがすべて止まったところを見ると、かなり驚いたらしい
writeがよろしくと言っているhttps://en.wikipedia.org/wiki/Write_(Unix)
net sendはドメインに接続されている必要があったと記憶しているので、ARPは使っていなかったと思うとてもクール。ただしTCP/IPはOSIモデルに従っていないので、OSIの微妙な区分をそのまま適用するのは難しい
ARPは実務上、Stevens基準のTCP/IPモデルにおける 2.5層 と定義できると見なせるので、2.5と呼ぶのが最も妥当に思える。そしてARPフレームはルーティングされないので、明らかにL3ではない
IPv4 NATが事実上の標準だった時代、今もそうではあるがIPv6とCGNATもある最近とは違って、NATChat というものを作ったことがある
基本的にグローバルIPv4アドレスを基準にチャットルームを作り、同じネットワークの誰とでもチャットできるようにした。オフィスで他の人たちと使うにはなかなか良かった。オフィスというものも当時は存在していたし
C++で書かれた似たものもある: https://github.com/gbonacini/arpchatcpp