潛下去是為了浮出來

Asus P5KPL-E

原板子上面有插一條

Transcend TS256ML Q64V8P 2GB DDR2 800 DIMM 6-6-6

因需求，最近再加一條

Transcend TS256ML Q64V8U 2GB DDR2 800 DIMM 5-5-5

運作一陣子，

就會死當，

把Q64V8U拔起來，

就又一切正常，

之前用副廠JetRam也是一樣，

真的很想把這板子給丟了，快被G31氣死，

問華碩技術客服，

表示Transcend 2GB不在這板子的支援清單，

所以不能保證其相容性及穩定性

哇.....我要去面壁了

彷彿買東西沒看手冊，

耍帥就認為一定OK...

結果剉賽

…

UNC存取問題 ??

之前遇到Windows 2008 R2 Standard利用UNC的方式存取Windows 2003 Enterprice，

很頻繁的連線存取檔案，約每五分鐘會存取一次，

在一段時間後，

就突然會連不到，

Net View一台也看不到，

Net Use也無法用，

重開機又會正常幾天，

感到很納悶，

把Win 2008 改成Win 2003，

就正常，

在想會不會是smb 1.0 和 smb 2.0溝通上有什麼問題嗎??

Win 2003只支援 smb 1.0，是這因素嗎??

困惑

…

四個零

學網路的人都知四個零的意義，

有時常在想，我可以給多少零呢

才能任遊這個世界呢

能否一個零也沒有，

也能同我一起呢，

哈..哈...看來我真的挺愛做白日夢....

無論如何都得去創造啊，笨蛋

沒人愛Zero的

平凡的小確幸

一個人走在街上，

看著路上行人匆匆

我彷彿時空是停住的，

很懷疑這是我的城市嗎

轉進巷弄，看著一棵盛開的山櫻花，

才肯定了幸福的存在

寂靜的深夜

總會放著廣播，聽著音樂，

但反而哀傷了起來，

原來悲傷的音樂，無法使我無敵

真是不堪一擊

還好

我的夏天要來了

能再度感受

夏天的風

哈..哈..哈.....

這應是我熱愛的算式吧...

TIME_WAIT 狀態

根據TCP協議，主動發起關閉的一方，會進入TIME_WAIT狀態，持續2*MSL(Max Segment Lifetime)，預設為240秒，在這個 post 中簡潔的介紹了為什麼需要這個狀態。

值得一說的是，對於基於TCP的HTTP協議，關閉TCP連接的是Server端，這樣，Server端會進入TIME_WAIT狀態，可想而知，對於訪問量大的Web Server，會存在大量的TIME_WAIT狀態，假如server一秒鐘接收1000個請求，那麼就會積壓240*1000=240,000個TIME_WAIT的記錄，維護這些狀態給Server帶來負擔。當然現代操作系統都會用快速的查找算法來管理這些TIME_WAIT，所以對於新的TCP連接請求，判斷是否hit中一個TIME_WAIT不會太費時間，但是有這麼多狀態要維護總是不好。

HTTP協議1.1版規定default行為是Keep-Alive，

也就是會重用TCP連接傳輸多個request/response，一個主要原因就是發現了這個問題。

還有一個方法減緩TIME_WAIT壓力就是把系統的2*MSL時間減少，

因為240秒的時間實在是太長了點，對於Windows，修改注冊表，

在HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\Tcpip\Parameters上添加一個DWORD類型的值TcpTimedWaitDelay，一般認為不要少於60，不然可能會有麻煩。

對於大型的服務，一台server搞不定，需要一個LB(Load Balancer)把流量分配到若干後端服務器上，如果這個LB是以NAT方式工作的話，可能會帶來問題。

假如所有從LB到後端Server的IP包的source address都是一樣的(LB的對內地址），那麼LB到後端Server的TCP連接會受限制，

因為頻繁的TCP連接建立和關閉，會在Server上留下 TIME_WAIT狀態，而且這些狀態對應的remote address都是LB的，LB的source port撐死也就60000多個 (2^16=65536,1~1023是保留端口，還有一些其他端口預設也不會用），每個LB上的端口一旦進入Server的TIME_WAIT黑名單，就有240秒不能再用來建立和Server的連接，

這樣LB和Server最多也就能支持300個左右的連接。

如果沒有LB，不會有這個問題，因為這樣server看到的remote address是internet上廣闊無垠的集合，對每個address，60000多個port實在是夠用了。

一開始我覺得用上LB會很大程度上限制TCP的連接數，

但是實驗表明沒這回事，LB後面的一台Windows Server 2003每秒處理請求數照樣達到了600個，難道TIME_WAIT狀態沒起作用？

用Net Monitor和netstat觀察后發現，Server和LB的XXXX端口之間的連接進入TIME_WAIT狀態后，再來一個LB的XXXX端口的SYN包，Server照樣接收處理了，而不是想像的那樣被drop掉了。

翻書，從書堆里面找出覆滿塵土的大學時代買的《UNIX Network Programming, Volume 1, Second Edition: Networking APIs: Sockets and XTI》，中間提到一句，對於BSD-derived實現，只要SYN的sequence number比上一次關閉時的最大sequence number還要大，那麼 TIME_WAIT 狀態一樣接受這個SYN，難不成Windows也算BSD-derived? 有了這點線索和關鍵字(BSD)，找到這個post，在NT4.0的時候，還是和BSD-derived不一樣的，不過Windows Server 2003已經是NT5.2了，也許有點差別了。

做個試驗，用Socket API編一個Client端，每次都Bind到本地一個端口比如2345，重複的建立TCP連接往一個Server發送Keep-Alive=false的HTTP請求，Windows的實現讓sequence number不斷的增長，所以雖然Server對於Client 的2345端口連接保持TIME_WAIT狀態，但是總是能夠接受新的請求，不會拒絕。

那如果SYN的Sequence Number變小會怎麼樣呢？同樣用Socket API，不過這次用Raw IP，發送一個小sequence number的SYN包過去，Net Monitor里面看到，這個SYN被Server接收後如泥牛如海，一點反應沒有，被drop掉了。

按照書上的說法，BSD-derived和Windows Server 2003的做法有安全隱憂，不過至少這樣，至少不會出現TIME_WAIT阻止TCP請求的問題，當然，客戶端要配合，保證不同TCP連接的sequence number要上漲不要下降。

翻譯引用自 : http://mocheng.wordpress.com/2007/07/30/time_wait%E7%8A%B6%E6%80%81/

Timeout waiting for PADO packets

Timeout waiting for PADO packets
這篇寫的很詳細....
如果數據機沒問題...
那就是
數據機回應不及.....
中斷再撥時...
需要給它幾秒...

就像人生有時...也要停一下...

~~

SugarCRM 安裝Extension_Manager

環境

php-5.2.17

mysql-5.1.58

httpd-2.2.3

SugarCE-6.2.3

由於需要用到Enhanced Search的功能,

所以要裝Extension_Manager，

在6.2.3上裝時，

出現Could not connect to the Dispage Resource Center

如果按這解，是解不開的，

因為我很肯定，網路是正常的，

當時以為是版本有問題，

因為我裝SugarCE 5.5.0是很正常的，

一度以為只能裝這三版本，

在裝6.4.0時，還搞了一烏龍，

雖然沒秀出結束及Next按鍵，但其實已安裝好了，
直接去登入即可(按F5就會陷入迷陣中)，

回歸正題，

答案就是權限，而且不限那三版本，

在給安裝目錄的Owner及cache,custom,data,module 給予的權限，

一定要對，權限對，

就會如下圖安裝，但沒跑完整個訊息，

其實已安裝完成了，沒有Complete，也沒關係，

只要登出再登入，

就會出現login dispage的畫面(要先到dispage申請一帳號)，

就可安裝Extension Manager

也就可順利安裝Enhanced Search，

就是那麼簡單，

我卻是搞了老半天...
上次CSS事件，看來沒學到經驗...
每次都中權限這一招

STOP: 0X0000007B again

User 的 Notebook Asus F9E，不停重開機，
於是...
停用系統失敗時自動重新啟動，看訊息如下，
STOP: 0X0000007B (0XBA4D3524,0XC0000034,0X00000000,0X00000000)
想說....我怎老是遇到7B的問題，
雖有一點不同，
RAM和HDD 檢查沒問題，
就直接還原了，
啊.............還是一樣，
就搜了一下，
XP出現藍色死亡畫面....stop:0x0000007B....怎麼辦?!

我和這位大大遇到的狀況，幾乎一模一樣，

進BIOS，改一下，

Advanced/IDE Configuration/SATA Operation Mode 預設Enhanced，改成Compatible

果真，

開進去了........

我...太快還原了....唉
之前的經驗完全忘了，竟沒去檢查Bios的設定，

看來心已在過年了...

offline nt password 好用

offline nt password 好用...
一直以為只能破xp,vista 的密碼,
沒想到...
Win 7..也可以....

為何老是要用到呢.....業務歸還Notebook時....
我老是不在位置上

~~

STOP: 0x0000007b (xxxxxxxx,0xc0000032,0x00000000,0x00000000)

昨天幫一台老舊機器P4P800-VM換Ram，因為其不穩定，會出現0x0000007f，

覺得是Ram造成的，

沒想到，換完Ram，就出現藍底白字....

STOP: 0x0000007b

換回原本的Ram也一樣，
一整個一頭霧水........不就換個Ram，這.......................會不會太扯了，

試了許多步驟，

最後是按照Microsoft 技術支援找到答案，

因為PC中的硬碟，是使用動態磁碟，

覺得很有可能，步驟如下，

移除無法開機電腦中、包含系統磁碟分割的硬碟，將該硬碟安裝到第二部電腦，然後再啟動第二部電腦。
在第二部電腦上，依序按一下 [開始]、[執行]，在 [開啟] 方塊中輸入 regedt32，然後按一下 [確定]。
在「登錄編輯程式」中，按一下 [HKEY_LOCAL_MACHINE]，然後在 [登錄] 功能表上，按一下 [載入 Hive]。
找出並按一下包含第一部電腦作業系統 Hive 的系統檔案。
注意這個系統檔案位在 Drive:\Winnt\System32\Config 資料夾中，其中 Drive 是指第一部電腦中硬碟的磁碟機代號。(這邊是選Config中的System這個檔案)
按一下 [開啟]，在 [機碼名稱] 方塊中輸入 Temp，然後按一下 [確定]。
按兩下 [HKEY_LOCAL_MACHINE]，再按兩下 [Temp]。
按兩下 [ControlSet00n]，其中 n 是指此控制集的編號。
按兩下 [Service]，再按兩下 [dmio]，然後按一下 [Boot Info]。
用滑鼠右鍵按一下 [Primary Disk Group] 登錄機碼，然後按一下 [刪除]。
為 HKEY_LOCAL_MACHINE\Temp

子機碼中所顯示的每個 ControlSet00n 執行個體，重複執行步驟 7 至 9。
按一下 [Temp]，然後按一下 [登錄] 功能表上的 [解除 Hive 載入]，然後按一下 [是]。
結束「登錄編輯程式」。
關閉第二部電腦，再移除來自第一部電腦的硬碟。
將該硬碟重新安裝至第一部電腦，接著啟動第一部電腦。

Windows 2000 僅允許使用一個動態磁碟群組。當您將一部電腦上的動態磁碟，移到已經包含有動態磁碟的第二部電腦時，該磁碟的主要磁碟群組識別碼已經改變，而且該磁碟會合併到第二部電腦動態磁碟資料庫中。然而，此時該磁碟作業系統登錄內所儲存的主要磁碟群組識別碼並沒有改變。所以當您將該硬碟重新裝回第一部電腦時，就會產生新的主要磁碟群組識別碼與登錄中所儲存主要磁碟群組識別碼不相符的情況，進而造成這個錯誤。

沒錯，可正常開機登入，不會藍屏了，

其實到現在，我也不明白，為何換個Ram，就這樣.....
因為其它硬體完全沒變，

唯一想到，就是之前換Ram後，開機登入很慢，有把它直接關了再開，

難道這樣就挫賽...........

Mrtg 圖流量超過100M時，要用SNMPv2 來繪圖

超過100M時，Mrtg圖會異常，會整個突然往下掉，

SNMPv1

cfgmaker --global 'WorkDir: /var/www/html/mrtg' --global 'Options[_]: bits,growright' --output /etc/mrtg/mrtg.cfg public@1.2.3.4

這時要用SNMPv2

多加 --snmp-options=:::::2

SNMPv2

cfgmaker --snmp-options=:::::2 --global 'WorkDir: /var/www/html/mrtg' --global 'Options[_]: bits,growright' --output /etc/mrtg/mrtg.cfg public@1.2.3.4

而mrtg.cfg 中的target則會變成如下

Target[1.2.3.4_1]: 1:public@1.2.3.4:::::2

Cacti not running after php upgrade

CentOS 5.5
httpd 2.2.3
mysql 5.0.77
php 5.1.6
都為CentOS預設安裝，
Cacti 0.8.7h 安裝使用都沒問題，
就再把php升級到 php 5.2.17 就剉賽了...
出現如下， FATAL: Cannot connect to MySQL server on 'localhost'. Please make sure you have specified a valid MySQL database name in 'include/config.php'
我的Cacti 就被我玩壞了，
檢查config.php 並沒有錯，真的很無解...
東檢西檢，還是想不通..
最近怎麼老是碰到很無解的事..

隔天,火大...
把Mysql Remove掉, 再重裝,不行.....
變成500 internal server error
再把php 全移掉，
裝回 php 5.1.6 ..這當然Cacti就恢復了，
再把php 升級，
這次按照這位大大所寫升到 php 5.2.17
一切正常了，
好想放鞭炮啊...
當然SugarCRM也沒問題，
因為SugarCRM本來就要在PHP 5.2.0之後才能正常運作

~~

一年

今天莫名的難過....
原來上天也在提醒我...
一年了...
我什麼都沒變...
妳的選擇是對的.....

...

Ftp 傳檔會卡彈

話說某台主機，要開Ftp 服務，

所以用 iptables 對應 2121 port來對應這台主機的21 Port

iptables -t nat -A PREROUTING -p tcp -i ppp0 --dport 2121 -j DNAT --to-destination 192.168.1.123:21

然後Data Port 指定 2122

怪事就發生了.....

在主機(1.2.3.4)傳部分檔案時到NAT(2.3.4.5)後的一台Ftp Server，

會卡住，甚至突然連不到，

但從其它遠端主機(試過三個點)，都可正常連線傳檔，

真的有一種鬼打牆的感覺，

改過不同Port，也一樣，

讓Ftp server 和 iptables mapping的port 一致，也一樣，

iptables 加上以下這段，也一樣

iptables -A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:1536 -j TCPMSS –clamp-mss-to-pmtu

修改MTU 的值，也一樣

實在想不通，其它台都不會這樣，只有1.2.3.4會這樣，

最後清linux arp cache，好像有點用喔

又可開始傳了，

但會不會又突中斷呢????????

果然在剩551bytes又卡住了...

真的很不解...

用Tcpdump的記錄

不太對的結束

10:46:28.736435 IP 1.2.3.4.50587 > 2.3.4.5.HINET-IP.hinet.net.2122: . 2766512:2767964(1452) ack 1 win 260

10:46:28.736545 IP 1.2.3.4.50587 > 2.3.4.5.HINET-IP.hinet.net.2122: P 2767964:2768896(932) ack 1 win 260

10:46:28.737296 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.50587: . ack 2762156 win 65535

10:46:28.737320 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.50587: . ack 2765060 win 65535

10:46:28.737342 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.50587: . ack 2767964 win 65535

10:46:28.815986 IP 1.2.3.4.50587 > 2.3.4.5.HINET-IP.hinet.net.2122: P 2768896:2769447(551) ack 1 win 260

10:46:28.860889 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.50587: . ack 2768896 win 64603

10:46:28.939158 IP 1.2.3.4.50587 > 2.3.4.5.HINET-IP.hinet.net.2122: F 2769447:2769447(0) ack 1 win 260

10:46:28.939297 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.50587: . ack 2768896 win 64603 <nop,nop,sack 1 {2769447:2769448}>

10:46:29.250230 IP 1.2.3.4.50587 > 2.3.4.5.HINET-IP.hinet.net.2122: FP 2768896:2769447(551) ack 1 win 260

10:46:29.858240 IP 1.2.3.4.50587 > 2.3.4.5.HINET-IP.hinet.net.2122: FP 2768896:2769447(551) ack 1 win 260

10:46:31.059439 IP 1.2.3.4.50587 > 2.3.4.5.HINET-IP.hinet.net.2122: FP 2768896:2769447(551) ack 1 win 260

10:46:33.462147 IP 1.2.3.4.50587 > 2.3.4.5.HINET-IP.hinet.net.2122: FP 2768896:2769447(551) ack 1 win 260

10:46:38.266560 IP 1.2.3.4.50587 > 2.3.4.5.HINET-IP.hinet.net.2122: FP 2768896:2769447(551) ack 1 win 260

10:46:47.875998 IP 1.2.3.4.50587 > 2.3.4.5.HINET-IP.hinet.net.2122: R 2769448:2769448(0) ack 1 win 0

10:46:47.876140 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.50587: . ack 2768896 win 64603 <nop,nop,sack 1 {2769447:2769448}>

很巧.......檔案都剩 551 bytes，就卡住

17:45:35.147219 IP 1.2.3.4.51458 > 2.3.4.5.HINET-IP.hinet.net.2122: . 798980:800432(1452) ack 1 win 260

17:45:35.147473 IP 1.2.3.4.51458 > 2.3.4.5.HINET-IP.hinet.net.2122: . 800432:801884(1452) ack 1 win 260

17:45:35.147516 IP 1.2.3.4.51458 > 2.3.4.5.HINET-IP.hinet.net.2122: P 801884:802435(551) ack 1 win 260

17:45:35.147732 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.51458: . ack 800432 win 65535

17:45:35.205000 IP 1.2.3.4.51458 > 2.3.4.5.HINET-IP.hinet.net.2122: F 802435:802435(0) ack 1 win 260

17:45:35.205146 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.51458: . ack 801884 win 65535 <nop,nop,sack 1 {802435:802436}>

17:45:35.588111 IP 1.2.3.4.51458 > 2.3.4.5.HINET-IP.hinet.net.2122: FP 801884:802435(551) ack 1 win 260

17:45:36.196605 IP 1.2.3.4.51458 > 2.3.4.5.HINET-IP.hinet.net.2122: FP 801884:802435(551) ack 1 win 260

17:45:37.397616 IP 1.2.3.4.51458 > 2.3.4.5.HINET-IP.hinet.net.2122: FP 801884:802435(551) ack 1 win 260

17:45:39.816028 IP 1.2.3.4.51458 > 2.3.4.5.HINET-IP.hinet.net.2122: FP 801884:802435(551) ack 1 win 260

17:45:44.623436 IP 1.2.3.4.51458 > 2.3.4.5.HINET-IP.hinet.net.2122: FP 801884:802435(551) ack 1 win 260

17:45:45.217163 IP 192.168.65.112.2122 > 1.2.3.4.51451: F 2694783966:2694783966(0) ack 11686513 win 65535

17:45:54.229889 IP 1.2.3.4.51458 > 2.3.4.5.HINET-IP.hinet.net.2122: R 802436:802436(0) ack 1 win 0

17:45:54.230053 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.51458: . ack 801884 win 65535 <nop,nop,sack 1 {802435:802436}>

17:46:15.294639 IP 192.168.65.112.2122 > 1.2.3.4.51451: F 0:0(0) ack 1 win 65535

第二種異常的情形(似乎在交握後就卡住了)

14:38:40.410298 IP 1.2.3.4.59798 > 2.3.4.5.HINET-IP.hinet.net.2122: S 405981170:405981170(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>

14:38:40.410419 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.59798: S 3427131497:3427131497(0) ack 405981171 win 16384 <mss 1452,nop,wscale 0,nop,nop,sackOK>

14:38:40.488246 IP 1.2.3.4.59798 > 2.3.4.5.HINET-IP.hinet.net.2122: . ack 1 win 260

14:38:40.569975 IP 1.2.3.4.59798 > 2.3.4.5.HINET-IP.hinet.net.2122: R 1:23(22) ack 1 win 260

為何要發RST，真不明白

14:38:41.760530 IP 1.2.3.4.59800 > 2.3.4.5.HINET-IP.hinet.net.2122: S 321932119:321932119(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>

14:38:41.760722 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.59800: S 1062905933:1062905933(0) ack 321932120 win 16384 <mss 1452,nop,wscale 0,nop,nop,sackOK>

14:38:41.838006 IP 1.2.3.4.59800 > 2.3.4.5.HINET-IP.hinet.net.2122: . ack 1 win 260

14:38:41.918221 IP 1.2.3.4.59800 > 2.3.4.5.HINET-IP.hinet.net.2122: R 1:23(22) ack 1 win 260

14:38:43.121001 IP 1.2.3.4.59802 > 2.3.4.5.HINET-IP.hinet.net.2122: S 1507780913:1507780913(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>

正常的開始(Data Port)

15:07:45.974673 IP 1.2.3.4.60640 > 2.3.4.5.HINET-IP.hinet.net.2122: S 1826863521:1826863521(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>

15:07:45.974874 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.60640: S 2262885533:2262885533(0) ack 1826863522 win 16384 <mss 1452,nop,wscale 0,nop,nop,sackOK>

15:07:46.070670 IP 1.2.3.4.60640 > 2.3.4.5.HINET-IP.hinet.net.2122: . ack 1 win 260

15:07:46.169251 IP 1.2.3.4.60640 > 2.3.4.5.HINET-IP.hinet.net.2122: . 1:1453(1452) ack 1 win 260

15:07:46.169498 IP 1.2.3.4.60640 > 2.3.4.5.HINET-IP.hinet.net.2122: . 1453:2905(1452) ack 1 win 260

15:07:46.170015 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.60640: . ack 2905 win 65535

15:07:46.267141 IP 1.2.3.4.60640 > 2.3.4.5.HINET-IP.hinet.net.2122: . 2905:4357(1452) ack 1 win 260

15:07:46.267509 IP 1.2.3.4.60640 > 2.3.4.5.HINET-IP.hinet.net.2122: . 4357:5809(1452) ack 1 win 260

15:07:46.267748 IP 1.2.3.4.60640 > 2.3.4.5.HINET-IP.hinet.net.2122: . 5809:7261(1452) ack 1 win 260

15:07:46.268000 IP 1.2.3.4.60640 > 2.3.4.5.HINET-IP.hinet.net.2122: P 7261:8713(1452) ack 1 win 260

15:07:46.268042 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.60640: . ack 5809 win 65535

15:07:46.268524 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.60640: . ack 8713 win 65535

15:07:46.366657 IP 1.2.3.4.60640 > 2.3.4.5.HINET-IP.hinet.net.2122: . 8713:10165(1452) ack 1 win 260

15:07:46.366899 IP 1.2.3.4.60640 > 2.3.4.5.HINET-IP.hinet.net.2122: . 10165:11617(1452) ack 1 win 260

15:07:46.367144 IP 1.2.3.4.60640 > 2.3.4.5.HINET-IP.hinet.net.2122: . 11617:13069(1452) ack 1 win 260

15:07:46.367265 IP 1.2.3.4.60640 > 2.3.4.5.HINET-IP.hinet.net.2122: . 13069:14521(1452) ack 1 win 260

15:07:46.367420 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.60640: . ack 11617 win 65535

15:07:46.367486 IP 1.2.3.4.60640 > 2.3.4.5.HINET-IP.hinet.net.2122: . 14521:15973(1452) ack 1 win 260

15:07:46.367788 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.60640: . ack 14521 win 65535

15:07:46.367895 IP 1.2.3.4.60640 > 2.3.4.5.HINET-IP.hinet.net.2122: P 15973:17425(1452) ack 1 win 260

15:07:46.368141 IP 1.2.3.4.60640 > 2.3.4.5.HINET-IP.hinet.net.2122: . 17425:18877(1452) ack 1 win 260

15:07:46.368262 IP 1.2.3.4.60640 > 2.3.4.5.HINET-IP.hinet.net.2122: . 18877:20329(1452) ack 1 win 260

15:07:46.368408 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.60640: . ack 17425 win 65535

15:07:46.368777 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.60640: . ack 20329 win 65535

15:07:46.464389 IP 1.2.3.4.60640 > 2.3.4.5.HINET-IP.hinet.net.2122: . 20329:21781(1452) ack 1 win 260

15:07:46.464681 IP 1.2.3.4.60640 > 2.3.4.5.HINET-IP.hinet.net.2122: . 21781:23233(1452) ack 1 win 260

正常的結束(Datat Port)

17:30:19.056592 IP 1.2.3.4.50695 > 2.3.4.5.HINET-IP.hinet.net.2122: . 3272705:3274157(1452) ack 1 win 16698

17:30:19.057060 IP 1.2.3.4.50695 > 2.3.4.5.HINET-IP.hinet.net.2122: . 3274157:3275609(1452) ack 1 win 16698

17:30:19.057102 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.50695: . ack 3274157 win 65535

17:30:19.057159 IP 1.2.3.4.50695 > 2.3.4.5.HINET-IP.hinet.net.2122: P 3275609:3276801(1192) ack 1 win 16698

17:30:19.057280 IP 1.2.3.4.50695 > 2.3.4.5.HINET-IP.hinet.net.2122: P 3276801:3277659(858) ack 1 win 16698

17:30:19.057674 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.50695: . ack 3276801 win 65535

17:30:19.135571 IP 1.2.3.4.50695 > 2.3.4.5.HINET-IP.hinet.net.2122: F 3277659:3277659(0) ack 1 win 16698

17:30:19.135721 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.50695: . ack 3277660 win 64677

17:30:19.135971 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.50695: F 1:1(0) ack 3277660 win 64677

17:30:19.214566 IP 1.2.3.4.50695 > 2.3.4.5.HINET-IP.hinet.net.2122: . ack 2 win 16698

17:30:19.486572 IP 1.2.3.4.50696 > 2.3.4.5.HINET-IP.hinet.net.2122: S 497897029:497897029(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>

17:30:19.486764 IP 2.3.4.5.HINET-IP.hinet.net.2122 > 1.2.3.4.50696: S 20995647:20995647(0) ack 497897030 win 16384 <mss 1452,nop,wscale 0,nop,nop,sackOK>

17:30:19.554628 IP 1.2.3.4.50696 > 2.3.4.5.HINET-IP.hinet.net.2122: . ack 1 win 16698

TCP與UDP

控制旗標的解釋

http://www.pcnet.idv.tw/pcnet/network/network_ip_tcp.htm

訂閱：文章 (Atom)