LOG IN

Completely understood TCP

by otsuka752

2019/06/05

絶妙にセッティングしてある俺の椅子を持ち出す奴にムカつく。適当に戻すんじゃねーよ。俺の椅子じゃねーよ。

Tcpreplay を久しぶりに仕事で使った。使い方、すっかり忘れてた。でも簡単楽ちん便利だ。そして、適当に edit して投げつけた SYN が対向に届いてるのは確認できるのに、SYN+ACK が返らないのは何でなんだっけ? たいてい UDP や ICMP で使うので勝手が分からん。

結局、scapy で。

こんにちは、有志の方です。

timestamp option を無効にした kernel でのパケットでも試したんだった。

server 側の tcpdump でパケット到着は確認できてる。でも、checksum error だったりするのか? 送信時に再計算してくれるはずだけど、要確認。

-C, --fixcsum

Force recalculation of IPv4/TCP/UDP header checksums.

Causes each IPv4/v6 packet to have their checksums recalculated and fixed. Automatically enabled for packets modified with --seed, --pnat, --endpoints or --fixlen.

ポート番号変えるだけだと再計算されないのか。そして、ポート番号とチェックサムは関係ないんだっけか?

IP は IP header だけ?

TCP は payload だけ?

忘れた...

--fixcsum チェックサム再計算したら期待通りに動作した。投げつけた SYN に SYN+ACK が返ってきた。

なるほど TIME_WAIT 面白い!!!

NAT(NAPT) は TIME_WAIT など TCP の状態遷移相当のステータスを持つんだろうか。session entry を作って消すだけだから、FIN あるいは 2つ目の FIN あるいはそれぞれの FIN に対する ACK が届いたかどうかや、ACK 後に session entry を消すまでの時間を管理するだけで、別の異なる概念なんだろうか。

session entry 持ってたとしても、その tupple が ESTABLISHED にはならないか。

netfilter conntrack 辺りで Linux での挙動は見えそう。じゃ、Linux でない実装を、外から見た挙動で推測するにはどうしたら良いですか?

Netfilter のこと調べてたら有用な gist にたどり着き、よく見たら @SatchanP のアカウントだった。

2019/06/06

面倒くさいから嫌だを示すための方法が面倒くさくなった点につきまして。こんなんだから裏技使う羽目に。何が大切かを分かってない作りだ。

2019/06/07

宣言しよう。約 10時間後にはこんな顔してる。

2階建てバスの 2階の先頭席からの青空

サイツヨの Web サーバを準備するんじゃなく、TCP_DEFER_ACCEPT さんで kernel に頑張ってもらえば行けるかも。 結構強い NAT 装置の session entry を埋める話。その次は TCP listener 導入で。

キーボード

UKキーボード使いづらくて US を!

1杯目

2杯目

ラーメン食べたい

幸せの黒バス

3杯目

OTHER SNAPS