Packet_vlad's profile - activity

It's hard to tell without seeing an actual PCAP, but usually getting stuck on constant (not slowly increasing) Bytes In

It's hard to tell without seeing an actual PCAP, but usually getting stuck on constant (not slowly increasing) Bytes In

Can't see the screenshot..

If packet's Sequence Number and Next Sequence Number are equal that means the packet contains no data (TCP segment lengt

If packet's Sequence Number and Next Sequence Number are equal that means the packet contains no data (TCP segment lengt

Also you may read TCP/IP Illustrated vol.1 by Stevens, this book is must have for protocol understanding. TCP part of it

Try to use host stealmylogin.com as capture filter. It'll resolve the name and filter by corresponding IP. BUT the sit

Try to use host stealmylogin.com as capture filter. It'll resolve the name and filter by corresponding IP. BUT the sit

Try to use host stealmylogin.com as capture filter. It'll resolve the name and filter by corresponding IP. BUT the sit

Try ether host 34-E6-D7-55-24-23 || 34-E6-D7-55-24-34

Try ether host 34-E6-D7-55-24-23 || 34-E6-D7-55-24-34

Sake, no, I don't. I just captured Chrome traffic from home to random website, client side, on a notebook itself (PCAP

Sake, no, I don't. I just captured Chrome traffic from home to random website, client side, on a notebook itself (PCAP

Sake, no, I don't. I just captured Chrome traffic from home to random website, client side, on a notebook itself (PCAP

Sake, no, I don't. I just captured Chrome traffic from home to random website, client side, on a notebook itself (PCAP

Sake, no, I don't. I just captured Chrome traffic from home to random website, client side, on a notebook itself (PCAP

My guess is: we observe "simultaneous close" case which means both client and server decided to close a connection at th

My guess is: we observe "simultaneous close" case which means both client and server decided to close a connection at th

My guess is: we observe "simultaneous close" case which means both client and server decided to close a connection at th

My guess is: we observe "simultaneous close" case which means both client and server decided to close a connection at th

My guess is: we observe "simultaneous close" case which means both client and server decided to close a connection at th

My guess is: we observe "simultaneous close" case which means both client and server decided to close a connection at th

Sake: this is very good assumption. Check also Win size in RSTs - it is different (0 and 14336). I cannot understand on

Sake: this is very good assumption. Check also Win size in RSTs - it is different (0 and 14336). I cannot understand on

Sake: this is very good assumption. Check also Win size in RSTs - it is different (0 and 14336). I cannot understand on

Sake: this is very good assumption. Check also Win size in RSTs - it is different (0 and 14336). I cannot understand on

Sake: this is very good assumption. Check also Win size in RSTs - it is different (0 and 14336). I cannot understand on

Sake: this is very good assumption. Check also Win size in RSTs - it is different (0 and 14336). I cannot understand on

Sake: this is very good assumption. Check also Win size in RSTs - it is different (0 and 14336). I cannot understand on

@EricSnijders As for packet #2267: this is an ACK emitted by server for [FIN,ACK] packet #2265. It has ACK# 5733 (FIN h

@EricSnijders As for packet #2267: this is an ACK emitted by server for [FIN,ACK] packet #2265. It has ACK# 5733 (FIN h

@EricSnijders As for packet #2267: this is an ACK emitted by server for [FIN,ACK] packet #2265. It has ACK# 5733 (FIN h

@EricSnijders As for packet #2267: this is an ACK emitted by server for [FIN,ACK] packet #2265 from. It has ACK# 5733 (

@EricSnijders As for packet #2267: this is an ACK emitted by server for [FIN,ACK] packet #2265 from. It has ACK# 5733 (

@EricSnijders Ah, ok, thanks for clarification!

RST must have ACK set if it's intended to close an established TCP session. The second endpoint will check this ACK # f

The only thing weird in this case is that 172.24.9.13 does not wait for the ACK to be received, but sends a RST s

(!) Please remove and re-do captures filtering out SMB (TCP port 445) because you've exposed seemingly sensitive SMB tra

(!) Please remove and re-do captures filtering out SMB port 445 because you've exposed seemingly sensitive SMB traffic i

(!) Please remove and re-do captures filtering out SMB port 445 because you've exposed seemingly sensitive SMB traffic i

(!) Please remove and re-do captures filtering out SMB because you've exposed seemingly sensitive SMB traffic in there c

(!) Please remove and re-do captures filtering out SMB because you've exposed seemingly sensitive SMB traffic in there c