Hi,
Tcpdump reveals zeros instead of sequence numbers in the header when the SB70 sends a TCP packet. This causes a problem when establishing a connection with Apache2 on Linux. The SB70 will successfully establish a connection with netcat on Linux without sequence numbers however. Here is the text of that tcpdump. The first of eight lines is the session between the SB70 and the LAMP server, the next eight lines is the session between a browser and the same LAMP server. Notice the "S 0:0(0)" in the first SB70 packet to the server.
17:59:31.361340 IP 192.168.1.100.5209 > 192.168.1.102.http: S 0:0(0) win 0 <mss 1460,nop,nop,nop,eol>
17:59:31.361497 IP 192.168.1.102.http > 192.168.1.100.5209: S 3806710012:3806710012(0) ack 1 win 5840 <mss 1460>
17:59:31.361946 IP 192.168.1.100.5209 > 192.168.1.102.http: . ack 1 win 4644
17:59:31.403657 IP 192.168.1.100.5209 > 192.168.1.102.http: P 1:24(23) ack 1 win 4644
17:59:31.403832 IP 192.168.1.102.http > 192.168.1.100.5209: . ack 24 win 5840
17:59:31.490515 IP 192.168.1.100.5209 > 192.168.1.102.http: F 24:24(0) ack 1 win 4644
17:59:31.490780 IP 192.168.1.102.http > 192.168.1.100.5209: F 1:1(0) ack 25 win 5840
17:59:31.491258 IP 192.168.1.100.5209 > 192.168.1.102.http: . ack 2 win 4643
17:59:41.545240 IP 192.168.1.104.3528 > 192.168.1.102.http: S 816002305:816002305(0) win 16384 <mss 1460,nop,nop,sackOK>
17:59:41.545416 IP 192.168.1.102.http > 192.168.1.104.3528: S 3804493063:3804493063(0) ack 816002306 win 5840 <mss 1460,nop,nop,sackOK>
17:59:41.545571 IP 192.168.1.104.3528 > 192.168.1.102.http: . ack 1 win 17520
17:59:41.546074 IP 192.168.1.104.3528 > 192.168.1.102.http: P 1:396(395) ack 1 win 17520
17:59:41.546205 IP 192.168.1.102.http > 192.168.1.104.3528: . ack 396 win 6432
17:59:41.548352 IP 192.168.1.102.http > 192.168.1.104.3528: P 1:268(267) ack 396 win 6432
17:59:41.756062 IP 192.168.1.104.3528 > 192.168.1.102.http: . ack 268 win 17253
Is there something I've missed seeing in the API that causes this behavior in the SB70?
I'm looking to set the SB70 to produce these sequence numbers.
Thanks for your consideration,
Paul
SB70 puts zeros in TCP SYN packet for sequence numbers
Re: SB70 puts zeros in TCP SYN packet for sequence numbers
Hi,
This is more information on the last post about zeros in the TCP SYN packet. I'm running the TCP Client code given in the examples.
Paul
This is more information on the last post about zeros in the TCP SYN packet. I'm running the TCP Client code given in the examples.
Paul
Re: SB70 puts zeros in TCP SYN packet for sequence numbers
Are you sure that your dump code is not "Adjusting the sequence numbers"
Ethereal aka wireshak will adjust the sequence numbers so the connection sequence starts at zero even
though the actual numbers stored in the packet are not zero. There is an otion in wireshark to turn this off.
On connect the first syn packet will have zeros for the ACK sequence number as we have not seen anything from the
other side yet to setup sequence numbers, but the outgoing sequence will be set to
GetFirstSeq()
this counts on seconds to try and be somewhat random.
If you connect inthe first second after boot the first connection could be zero.
(Zero is a prefectly valid sequence number)
The code for getfirst seq is:
GetFirstSeq()
{
static WORD ww;
return ( Secs << 16 ) | ( ww++ );
}
Ethereal aka wireshak will adjust the sequence numbers so the connection sequence starts at zero even
though the actual numbers stored in the packet are not zero. There is an otion in wireshark to turn this off.
On connect the first syn packet will have zeros for the ACK sequence number as we have not seen anything from the
other side yet to setup sequence numbers, but the outgoing sequence will be set to
GetFirstSeq()
this counts on seconds to try and be somewhat random.
If you connect inthe first second after boot the first connection could be zero.
(Zero is a prefectly valid sequence number)
The code for getfirst seq is:
GetFirstSeq()
{
static WORD ww;
return ( Secs << 16 ) | ( ww++ );
}