TCP connect handshake

Greetings,

I am implementing TCP connection functionality for my own embedded
system. I am trying to connect to a listening program on Linux and
capture network traffic with Ethereal network analyzer.
Note: Ethereal runs on the same Linux machine, to which I am trying to
connect to.

What I see is really strange.

Sequence of events is the following ("device" means my system):

device -> ARP request: who has the Linux machine's IP address
Linux -> ARP response: I have it
device -> SYN to the Linux'ex IP address
Linux -> SYN+ACK to device's IP address
device -> ACK to Linux'es IP address
Delay of 4.2 seconds
Linux -> SYN+ACK to device's IP address (packet identical to the
previous SYN+ACK)
device -> ACK to Linux'es IP address (analyzer says: TCP segment lost)
Linux -> ARP request: who has device's IP address
device -> ARP response: I have it
Linux -> SYN+ACK to device's IP address (packet identical to the
previous SYN+ACK)
device -> ACK to Linux'es IP address
....
and so on.

As strange as it sounds, it looks like Ethereal sees the ACK that my
system sends to SYN+ACK, but Linux'es TCP layer doesn't (???). Even
more strange, that was after Linux did see the first SYN that I sent.
Packets are formed correctly, and the checksum is correct.

I tried to connect to the same Linux machine from a Windows program
and captures the dump. It succeeded normally after SYN/SYN+ACK/ACK;
packets that Windows sent were identical to what I sent except for
different ISN, window size and obviously the checksum.

Did anybody encounter such a behavior with any system connecting to
Linux?.. Any idea what can go wrong?

I can send the pcap dump.

Thanks,
D

On Nov 24, 10:34 pm, stargazer3...@gmail.com wrote:
> Greetings,
>
> I am implementing TCP connection functionality for my own embedded
> system. I am trying to connect to a listening program on Linux and
> capture network traffic with Ethereal network analyzer.
> Note: Ethereal runs on the same Linux machine, to which I am trying to
> connect to.
>
> What I see is really strange.
>
> Sequence of events is the following ("device" means my system):
>
> device -> ARP request: who has the Linux machine's IP address
> Linux -> ARP response: I have it
> device -> SYN to the Linux'ex IP address
> Linux -> SYN+ACK to device's IP address
> device -> ACK to Linux'es IP address
> Delay of 4.2 seconds
> Linux -> SYN+ACK to device's IP address (packet identical to the
> previous SYN+ACK)
>
> [snip]
>
> As strange as it sounds, it looks like Ethereal sees the ACK that my
> system sends to SYN+ACK, but Linux'es TCP layer doesn't (???). Even
> more strange, that was after Linux did see the first SYN that I sent.
> Packets are formed correctly, and the checksum is correct.

Are you sending the correct Sequence and Acknowledgement numbers ?

Sequence number should be 1 higher than the Sequence number in your
device SYN packet.

Acknowledgement number should be 1 higher than the Sequence number in
the SYN+ACK packet from Linux.

> Did anybody encounter such a behavior with any system connecting to
> Linux?.. Any idea what can go wrong?
>
> I can send the pcap dump.

No experience with Linux and the dump would not help me since your
description is fairly accurate.
I could only have a guess - which is that the Linux system connection
to itself as an exception (if I got you right, both your device
and Linux use the same MAC [address]), and something does not work.
Apparently your first ACK does not reach the Linux host (or it has
the wrong TCP seq., as already suggested, which is another possible
scenario).
I suspect that not because I know how Linux does this - I don't - but
I know I have done it so myself for DPS and this would be one of the
places I would look into if I had here a similar issue (so far I
don't...
and hopefully I won't :-) ).
Another hint that this may be a "same host address" issue is the
ARP Linux sends out after having recently responded to your SYN
etc.

Dimiter

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------


On Nov 24, 11:34 pm, stargazer3...@gmail.com wrote:
> Greetings,
>
> I am implementing TCP connection functionality for my own embedded
> system. I am trying to connect to a listening program on Linux and
> capture network traffic with Ethereal network analyzer.
> Note: Ethereal runs on the same Linux machine, to which I am trying to
> connect to.
>
> What I see is really strange.
>
> Sequence of events is the following ("device" means my system):
>
> device -> ARP request: who has the Linux machine's IP address
> Linux -> ARP response: I have it
> device -> SYN to the Linux'ex IP address
> Linux -> SYN+ACK to device's IP address
> device -> ACK to Linux'es IP address
> Delay of 4.2 seconds
> Linux -> SYN+ACK to device's IP address (packet identical to the
> previous SYN+ACK)
> device -> ACK to Linux'es IP address (analyzer says: TCP segment lost)
> Linux -> ARP request: who has device's IP address
> device -> ARP response: I have it
> Linux -> SYN+ACK to device's IP address (packet identical to the
> previous SYN+ACK)
> device -> ACK to Linux'es IP address
> ...
> and so on.
>
> As strange as it sounds, it looks like Ethereal sees the ACK that my
> system sends to SYN+ACK, but Linux'es TCP layer doesn't (???). Even
> more strange, that was after Linux did see the first SYN that I sent.
> Packets are formed correctly, and the checksum is correct.
>
> I tried to connect to the same Linux machine from a Windows program
> and captures the dump. It succeeded normally after SYN/SYN+ACK/ACK;
> packets that Windows sent were identical to what I sent except for
> different ISN, window size and obviously the checksum.
>
> Did anybody encounter such a behavior with any system connecting to
> Linux?.. Any idea what can go wrong?
>
> I can send the pcap dump.
>
> Thanks,
> D

On Nov 25, 5:34 am, stargazer3...@gmail.com wrote:
> Greetings,
>
> I am implementing TCP connection functionality for my own embedded
> system. I am trying to connect to a listening program on Linux and
> capture network traffic with Ethereal network analyzer.
> Note: Ethereal runs on the same Linux machine, to which I am trying to
> connect to.
>
> What I see is really strange.
>
> Sequence of events is the following ("device" means my system):
>
> device -> ARP request: who has the Linux machine's IP address
> Linux -> ARP response: I have it
> device -> SYN to the Linux'ex IP address
> Linux -> SYN+ACK to device's IP address
> device -> ACK to Linux'es IP address
> Delay of 4.2 seconds
> Linux -> SYN+ACK to device's IP address (packet identical to the
> previous SYN+ACK)
> device -> ACK to Linux'es IP address (analyzer says: TCP segment lost)
> Linux -> ARP request: who has device's IP address
> device -> ARP response: I have it
> Linux -> SYN+ACK to device's IP address (packet identical to the
> previous SYN+ACK)
> device -> ACK to Linux'es IP address
> ...
> and so on.
>
> As strange as it sounds, it looks like Ethereal sees the ACK that my
> system sends to SYN+ACK, but Linux'es TCP layer doesn't (???). Even
> more strange, that was after Linux did see the first SYN that I sent.
> Packets are formed correctly, and the checksum is correct.
>
> I tried to connect to the same Linux machine from a Windows program
> and captures the dump. It succeeded normally after SYN/SYN+ACK/ACK;
> packets that Windows sent were identical to what I sent except for
> different ISN, window size and obviously the checksum.
>
> Did anybody encounter such a behavior with any system connecting to
> Linux?.. Any idea what can go wrong?
>
> I can send the pcap dump.
>
> Thanks,
> D

Ddi you try some network sniffer to analyze the packets.

ali

On Nov 24, 11:49 pm, Arlet <usene...@c-scape.nl> wrote:
> On Nov 24, 10:34 pm, stargazer3...@gmail.com wrote:
>
>
>
>
>
> > Greetings,
>
> > I am implementing TCP connection functionality for my own embedded
> > system. I am trying to connect to a listening program on Linux and
> > capture network traffic with Ethereal network analyzer.
> > Note: Ethereal runs on the same Linux machine, to which I am trying to
> > connect to.
>
> > What I see is really strange.
>
> > Sequence of events is the following ("device" means my system):
>
> > device -> ARP request: who has the Linux machine's IP address
> > Linux -> ARP response: I have it
> > device -> SYN to the Linux'ex IP address
> > Linux -> SYN+ACK to device's IP address
> > device -> ACK to Linux'es IP address
> > Delay of 4.2 seconds
> > Linux -> SYN+ACK to device's IP address (packet identical to the
> > previous SYN+ACK)
>
> > [snip]
>
> > As strange as it sounds, it looks like Ethereal sees the ACK that my
> > system sends to SYN+ACK, but Linux'es TCP layer doesn't (???). Even
> > more strange, that was after Linux did see the first SYN that I sent.
> > Packets are formed correctly, and the checksum is correct.
>
> Are you sending the correct Sequence and Acknowledgement numbers ?
>
> Sequence number should be 1 higher than the Sequence number in your
> device SYN packet.
>
> Acknowledgement number should be 1 higher than the Sequence number in
> the SYN+ACK packet from Linux.- Hide quoted text -
>
> - Show quoted text -

"Yes" - to both your questions.
I use low doulbe-word of CPU's time stamp counter for randomized ISN
that I send in SYN.
For ACK's sequence number I actually use acknowledgement number that I
got in SYN+ACK packet, which was exactly my ISN+1.
For ACK's acknowledgement number I use the ISN that I got in SYN+ACK
packet, +1.

Windows program succeeds to connect.

The only other visible difference between my connection process and
Windows'es is that I send ethernet packets padded to minimum of 64
bytes. But I guess that shouldn't be a problem (?) Especially, since
the SYN packet (also padded) was successfully received and answered.

Thanks,
D

On Nov 25, 12:11 am, Didi <d...@tgi-sci.com> wrote:
> > Did anybody encounter such a behavior with any system connecting to
> > Linux?.. Any idea what can go wrong?
>
> > I can send the pcap dump.
>
> No experience with Linux and the dump would not help me since your
> description is fairly accurate.
> I could only have a guess - which is that the Linux system connection
> to itself as an exception (if I got you right, both your device
> and Linux use the same MAC [address]), and something does not work.

No, "device" is in terms of TCP/IP terminology. For the matter of
correctness, it's a separate embedded computer with it's own MAC. It
is connected to Linux workstation with a hub. MAC address is
configurable, and is certainly different from the Linux station's MAC
address.

IP address for my device is embedded in the code. It is different from
Linux'es IP and belongs in the same network.

ARP packets look correct, both requests and replies.

BTW (if it at all matters), ping (ICMP) from Linux to my device works,
and UDP communication works too.

Thanks,
D

[...]
> > I can send the pcap dump.
>
> > Thanks,
> > D
>
> Ddi you try some network sniffer to analyze the packets.
>
> ali- Hide quoted text -
>
> - Show quoted text -

Yes, Ethereal.
In its comments to my ACK packet it finds correctly the (SYN+ACK)
packet, which I acknowledge.
I have dump captured if anybody wants to take a glance.

Thanks,
D

On Nov 25, 5:38 pm, Stargazer <stargazer3...@gmail.com> wrote:

> Yes, Ethereal.
> In its comments to my ACK packet it finds correctly the (SYN+ACK)
> packet, which I acknowledge.
> I have dump captured if anybody wants to take a glance.
>

Go ahead and post the captured dump somewhere.

On Nov 25, 7:47 pm, Arlet <usene...@c-scape.nl> wrote:
> On Nov 25, 5:38 pm, Stargazer <stargazer3...@gmail.com> wrote:
>
> > Yes, Ethereal.
> > In its comments to my ACK packet it finds correctly the (SYN+ACK)
> > packet, which I acknowledge.
> > I have dump captured if anybody wants to take a glance.
>
> Go ahead and post the captured dump somewhere.

I put the dump here: http://stargazer.3host.biz/tests/syn.zip
There are two dumps in ZIP: "syn.dump" is result of my device
connecting to Linux workstation and "syn2.dump" is result of Windows
program connecting to the same Linux workstation (the same IP and the
same port).
I will appreciate any productive idea :-)

Thanks,
D

On Nov 27, 12:58 am, Stargazer <stargazer3...@gmail.com> wrote:
> On Nov 25, 7:47 pm, Arlet <usene...@c-scape.nl> wrote:
>
> > On Nov 25, 5:38 pm, Stargazer <stargazer3...@gmail.com> wrote:
>
> > > Yes, Ethereal.
> > > In its comments to my ACK packet it finds correctly the (SYN+ACK)
> > > packet, which I acknowledge.
> > > I have dump captured if anybody wants to take a glance.
>
> > Go ahead and post the captured dump somewhere.
>
> I put the dump here:http://stargazer.3host.biz/tests/syn.zip
> There are two dumps in ZIP: "syn.dump" is result of my device
> connecting to Linux workstation and "syn2.dump" is result of Windows
> program connecting to the same Linux workstation (the same IP and the
> same port).
> I will appreciate any productive idea :-)
>
> Thanks,
> D

In syn.dump, packet #8 (your device's ACK), the destination MAC
address is mangled.