今回は、LAN内で利用されているIPアドレスを調べる方法についてをまとめてみた。 環境によっては使用されているOSが複数ある場合がある(というか、その方が多い)ので、LinuxとWindowsで分けて記載する。 1.Linuxの場合 1-1.ping + arpで調べる 基本的なコマンドしかインストールされていない環境では、やはりpingとarpコマンドを組み合わせた方法が良く利用されるだろう。 以下のようにforコマンドと組み合わせて実行することで、IPアドレスとそれに対応するMACアドレスを取得することが出来る。 for a in `seq 1 254`; do ping -c 1 -w 0.5 対象セグメント(第３オクテットまで).$a > /dev/null && arp -a 対象セグメント(第３オクテットまで).$a | grep ether; done test@ubuntu
(*1) backlog(512)はtcp_max_syn_backlog(400)より大きいので、400を切り上げた512がsyn backlogのサイズになる。 syn backlogのサイズを大きくしようとするには、以下の点に注意する。 (a) net.ipv4.tcp_max_syn_backlogを大きくする (b) listen()で指定するbacklog値を大きくする(apacheならListenBackLogディレクティブで指定できる) (c) backlogの値自体はnet.core.somaxconnに切り詰められるため、net.core.somaxconnの方も大きくしておく。 syn backlogの最大サイズはbacklogサイズに基づいて決まるため、net.ipv4.tcp_max_syn_backlogを大きくするだけでなく、backlog自体が大きくなるよう
調査をするときに使うが、毎回忘れてしまうので自分用にメモ statファミリーまとめ dstat 美しい！ 目で見るならこれ。 最も役に立つ参考サイト：http://qiita.com/harukasan/items/b18e484662943d834901 vmstat メモリやCPUを見る時に使う。 iostat ディスクIOを見るときに使う。 netstat ネットワークの状態を見るときに使う。 カーネルチューニングとKVS設定 net.core.somaxconn TCPのmax connection数。 参考サイト：http://d.hatena.ne.jp/tetsuyai/20111220/1324466655 例えばmemcacheやRedis等のKVSを使うときは、memcachedのtcp_backlogや、Redisのmaxclientsの数値以上にあげたほうがいい。
概要 ↓ memcachedのtcp_backlogのデフォルト値は1024で、stats settingsにも1024と表示されているのですが、 stats settings ... STAT tcp_backlog 1024 ... END↓ net.core.somaxconnがデフォルト値のままだと128に切り詰められてしまい、 # cat /proc/sys/net/core/somaxconn 128負荷が高いサーバーでは接続要求を取りこぼしてしまうことがあるそうです。 このnet.core.somaxconn、MemcacheやMySQLなど、高負荷時に多くの接続要求を受け付けるサーバーではチューニングが必要なカーネルパラメータのようです。いったいどういう値なのか、調べてみました。 net.core.somaxconnとは TCPソケットはlisten()関数の第二引数 ba
curlでSSLでつないだときのSSLのヘッダを読みたいのですが、どのような方法があるでしょうか
When an application puts a socket into LISTEN state using the listen syscall, it needs to specify a backlog for that socket. The backlog is usually described as the limit for the queue of incoming connections. Because of the 3-way handshake used by TCP, an incoming connection goes through an intermediate state SYN RECEIVED before it reaches the ESTABLISHED state and can be returned by the accept s
最近 ParallelServer というライブラリを作ったのですが、その最中に奇妙な状態になってる TCP ポートを見つけたので、メモっておきます。 Ruby では TCP サーバーは次のような感じで作ることができます。お手軽ですね。 require 'socket' Socket.tcp_server_loop(12345) do |socket, client_addr| socket.puts "Your IP address: #{client_addr.ip_address}" name = socket.gets socket.puts "Hello, #{name}" socket.close end これは 12345 ポートでクライアントからの接続を待ち、接続されたらクライアントのIPアドレスとクライアントからの入力をクライアントに送信して切断するだけの簡単なプログラム
tcpdumpやwiresharkでTCP制御フラグを指定してパケットを収集する方法を忘れることが多いのでメモ。 SYNフラグが設定されたパケットの収集 "tcp[13] & 2 != 0" SYNフラグが設定されていないパケットの収集 "tcp[13] & 2 == 0" SYNフラグのみ設定されたパケットの収集 "tcp[13] & 255 == 2" ACKフラグが設定されたパケットの収集 "tcp[13] & 16 != 0" ACKフラグが設定されていないパケットの収集 "tcp[13] & 16 == 0" ACKフラグのみ設定されたパケットの収集 "tcp[13] & 255 == 16" ACKフラグとSYNフラグが設定されたパケットの収集 "tcp[13] & 18 == 18" ACKフラグとSYNフラグのみ設定されたパケットの収集 "tcp[13] & 255 ==
ネットワーク接続作業を行うと毎回のように何らかの問題が発生します。 pingは通るのに対向先のネットワーク機器にTCPコネクションが張れない、通信が突然切断された、そんな経験をしたことはありませんか？そういった事態に遭遇したとき、本記事がトラブルの元を突き止める手段のひとつとして参考になれば幸いです。 パケットキャプチャで原因を探る問題発生の状況として、サーバーへpingは通るけれどssh接続ができない状態を想定します。 このような場合、次のような原因が考えられます。 サーバーのポート22番が閉じている サーバーのFW機能で弾いている 経路上のFWで弾いている 原因を探るためパケットキャプチャしたところ、サーバーのIPアドレスからリセットパケットが送信されている事がわかりました。pingは問題なく通ります。 そこで問題です。 リセットパケットを送ったのは誰でしょうか？次のパケットキャプチャ
I'm currently maintaining some web server software and I need to perform a lot of I/O operations. The read(), write(), close() and shutdown() calls, when used on a socket, may sometimes raise an ENOTCONN error. What exactly does this error mean? What are the conditions that would trigger it? I can never seem to reproduce it locally but there are users who can. Right now I just ignore ENOTCONN when
#ihatedumbpeople 2016-09-30 [Fri] 12:43 Rant. So I went to this bank with about 10 ATM machines, and they're all filled with people, doing kernel hacking or something. But no, they're just struggling to draw cash. There's a huge line. I was at the bottom and enraged. "WTF ARE THEZE PEOPEL DOIN?!" The whole process took about 10 minutes. What kind of black magic takes you more than a minute to just
2016 年 6 月 14 日 (火) 筑波大学発ベンチャー ソフトイーサ株式会社 代表取締役 登 大遊 「OPEN IPv6 ダイナミック DNS for フレッツ・光ネクスト」サービスを公開 NTT 東日本のフレッツ回線間で VPN 機器や IoT 機器同士のフレッツ網内の高速・低遅延の直接通信を実現 ソフトイーサ株式会社は、本日、「OPEN IPv6 ダイナミック DNS for フレッツ・光ネクスト」サービス (https://i.open.ad.jp/) のベータ版を提供開始しました。 この無償のダイナミック DNS (DDNS) サービスを利用すると、NTT 東日本のすべてのエリアの 1,066 万本のすべてのフレッツ回線上で、インターネットから絶対に不正侵入されるおそれのない、大変高速かつ低遅延な VPN を、簡単に構築できます (注 1)。また、IoT 機器をフレッツ網に直
総務省は2020年までに全国すべての小・中・高校に無線LAN「Wi-Fi」を導入する方針だ。教科書の内容をタブレット端末などに収めた「デジタル教科書」の普及に向け、導入費用の半分を補助する。災害時には避難者に開放し、携帯電話の基地局が故障してもインターネットや電子メールを使えるようにする。現在、無線LANを利用できる小・中・高校の教室は24%にとどまる。総務省はまず今夏につくる17年度政府予算
Linux Kernel 2.6 Documentation: /usr/src/linux/Documentation/networking/bonding.txt networking/bonding.txt Linux bonding ドライバの設定方法 [プレインテキスト版] 原著作者: Thomas Davis <tadavis at lbl.gov> 翻訳者: Akira Yoshiyama <yosshy at debian dot or dot jp> バージョン: 2.6.25 翻訳日時: 2008/02/20 Linux Ethernet Bonding Driver HOWTO % Latest update: 12 November 2007 % 最終更新：2007年11月12日 %Initial release : Thomas Davis <tadavis at
The Rise of the Stupid Network was originally written during a single long weekend in May 1997 by David S. Isenberg while he was an employee of AT&T Labs Research. It was officially released onto the Internet by AT&T in June 1997. It was printed (without permission, with some bad editing, and with the last few hundred words truncated) by Computer Telephony in its August 1997 issue. If you want to
Stupid Network (“Rise of the Stupid Network1”) David S. Isenberg (isen@isen.com - www.isen.com) (m-sato@remus.dti.ne.jp) • • • • • 20 1000 1 • 20 2 • • Ethernet 1Copyright 1998 by ACM, originally appeared in ACM netWorker, Feb./March 1998 • 4 Stupid Network • • • Stupid Network : Sprint, MCI, GTE, SNET 70 1979 6 2 2000 11 1000 1 70 4 10,000 510-547-0000, 0001, 0002, 510-547-9999 10,000 10 1 ? SS7
電気通信事業法(昭和59年12月25日法律第86号)第2条第1号において「電気通信」は、以下のように定義されている。 この「符号、音響又は影像」という書きぶりは、有線電気通信法を引き継いだものだが、その意味するところは微妙に異なっている(cf.田中正人『解説電気通信事業法・放送法』オーム社、昭和60年4月)。立法当時、音声ではPARCORやLSP、白黒画像ではG3FAXなどの圧縮符号化が実用化されており、さらなる符号化技術が研究されていた。新たな符号化技術が現れれば、同じ音声や画像であっても、異なる符号に成りうるのは当然である。そこで「符号」から「音響」と「影像」を切り離す書きぶりを踏襲し、符号化された音声や画像ではなく、音声や画像そのものを「通信」するという書きぶりにしておいたわけである。 この書きぶりのおかげで、音声に関しては、CELPなどの圧縮符号化が次々に現れても、郵政省令(のちに
今年に入ってぐらいから各種方面で話題として登場することが増えているNTT IPv6閉域網フォールバック問題ですが、実は単なる技術的な問題というわけではなく、ある種政治的な「駆け引き」であるというのが私の感想です。 多くの方々にとっては「World IPv6 Launchが開催されて、それ以降はフレッツ光ユーザが困る」ぐらいのイメージだと思いますが、実はもう少し複雑です。 NTT IPv6閉域網フォールバック問題に対してどう対処するのかは、コンテンツ事業者、ISP、JAIPA、NTTによる一種の駆け引きとなりつつあります。 実は、この話題に関して結構多くの公開情報があるのですが、あまりそれらをまとめて語っている記事がなさそうなので書いてみました。 2011年のWorld IPv6 Dayの評価 今年の6月6日に行われる予定のWorld IPv6 Launchを巡る駆け引きを知るには、昨年行わ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く