Created an attachment (id=131) [details]
version of tcp-tester than shows the tcp hang problem.

Created an attachment (id=134) [details]
new test case updated to the latest API

I evaluated your test case, and I seem not to get any hang at all:
raj@raj-desktop:~/Desktop/ns-3 Files/bug174$ ./tcp-tester 2 44489
TalkerApp::ConfSend(0x8069338,02-06-0a:01:00:02:20:00,2) Client
TalkerApp::ConfRecv(0x80696e0,02-06-00:00:00:00:20:00,44489) Server
TalkerApp::StartApplication() Client
TalkerApp::StartApplicationSend() Client
writing buffer (SHello) Client
TalkerApp::StartApplication() Server
TalkerApp::StartApplicationRecv() Server
TalkerApp::ConnectionRequested(): Server
TalkerApp::ConnectionSucceeded(): Client
TalkerApp::ConnectionCreated(): Server
Received    2 bytes from 10.1.0.1 [02-06-0a:01:00:01:01:c0]    1:S           S(
    2)
writing buffer (RBackAtYou) Server
Received  536 bytes from 10.1.0.2 [02-06-0a:01:00:02:20:00]   10:RBackAtYou  R(
  536)
Received  536 bytes from 10.1.0.2 [02-06-0a:01:00:02:20:00]  536:R{536}      R(
 1072)
Received  536 bytes from 10.1.0.2 [02-06-0a:01:00:02:20:00]  536:R{536}      R(
 1608)
...
Received  536 bytes from 10.1.0.2 [02-06-0a:01:00:02:20:00]  536:R{536}      R(
40200)
Received  536 bytes from 10.1.0.2 [02-06-0a:01:00:02:20:00]  536:R{536}      R(
40736)
Received  536 bytes from 10.1.0.2 [02-06-0a:01:00:02:20:00]  536:R{536}      R(
41272)
Received  536 bytes from 10.1.0.2 [02-06-0a:01:00:02:20:00]  536:R{536}      R(
41808)
Received  536 bytes from 10.1.0.2 [02-06-0a:01:00:02:20:00]  536:R{536}      R(
42344)
Received  536 bytes from 10.1.0.2 [02-06-0a:01:00:02:20:00]  536:R{536}      R(
42880)
Received  536 bytes from 10.1.0.2 [02-06-0a:01:00:02:20:00]  536:R{536}      R(
43416)
Received  536 bytes from 10.1.0.2 [02-06-0a:01:00:02:20:00]  536:R{536}      R(
43952)
Received  536 bytes from 10.1.0.2 [02-06-0a:01:00:02:20:00]  536:R{536}      R(
44488)
Received    1 bytes from 10.1.0.2 [02-06-0a:01:00:02:20:00]    1:R           R(
44489)

And it exits normally at that point.  I had to SLIGHTLY modify the code you
posted to make it compile under a few helper API changes, and I removed the
GetUid API of your tag class, as it appears this is incompatible with the
newest ns-3-dev and didn't appear to be used in this test case.  I've attached
my updated version.

Can you confirm that you are still having the same hanging issue?

Issue appears to be resolved.  David Evensky reports off tracker that:
> It appears to be fixed. [snip]
> [I] beat on it pretty hard (moved 10K bytes in forward direction and
10M bytes in the backward direction) and it worked great.

Marking the bug as fixed.

Created an attachment (id=145) [details]
simple two way tcp test program using what I guess is the current API.

I can't tell where the bug is in my code or ns-3-dev, the docs for Socket seems
to have disappeared from doxygen generated web pages. I think I'm using the API
correctly using the force (aka looking at the source), but I'm not sure. I
would like to see some sort of bi-direction test added to ns-3 distro so that
this sort of functionality gets tested.

This program should send bytes both ways, but it doesn't it only send bytes the
forward direction.

Output:

evensky@waltz$ ./tcp-tester 600 700
TalkerApp::ConfSend(0x62d780,02-06-0a:01:00:02:20:00,600) Client
TalkerApp::ConfRecv(0x62de10,02-06-00:00:00:00:20:00,700) Server
TalkerApp::StartApplication() Client
TalkerApp::StartApplicationSend() Client
TalkerApp::SendPacket(Hello,S,600) Client
TalkerApp::StartApplication() Server
TalkerApp::StartApplicationRecv() Server
TalkerApp::ConnectionRequested(0x632cd0,02-06-0a:01:00:01:01:c0): Server
TalkerApp::ConnectionSucceeded(0x6312c0): Client
TalkerApp::ConnectionCreated(0x6333e0,02-06-0a:01:00:01:01:c0): Server
TalkerApp::HandleRead(0x6333e0): Server
TalkerApp::SendPacket(BackAtYou,R,700) Server
 536 bytes from 10.1.0.1 [02-06-0a:01:00:01:01:c0]  Payload
(size=536)|ns3::SocketRxAddressTag [0-536] address=00-00-00
TalkerApp::HandleRead(0x6333e0): Server
  64 bytes from 10.1.0.1 [02-06-0a:01:00:01:01:c0]  Payload
(size=64)|ns3::SocketRxAddressTag [0-64] address=00-00-00

What does the 02-06 part of the mac addr mean? What is the address tag in the
packet used for?

Thanks,
\dae

(In reply to comment #4)
> Created an attachment (id=145) [edit] [details]
> simple two way tcp test program using what I guess is the current API.
> 
> I can't tell where the bug is in my code or ns-3-dev, the docs for Socket seems
> to have disappeared from doxygen generated web pages. I think I'm using the API

yes, a lot of docs seem to have disapeared from the output. We need another bug
to track that issue.

> correctly using the force (aka looking at the source), but I'm not sure. I
> would like to see some sort of bi-direction test added to ns-3 distro so that
> this sort of functionality gets tested.

would you mind provide one ?

> 
> This program should send bytes both ways, but it doesn't it only send bytes the
> forward direction.
> 
> Output:
> 
> evensky@waltz$ ./tcp-tester 600 700
> TalkerApp::ConfSend(0x62d780,02-06-0a:01:00:02:20:00,600) Client
> TalkerApp::ConfRecv(0x62de10,02-06-00:00:00:00:20:00,700) Server
> TalkerApp::StartApplication() Client
> TalkerApp::StartApplicationSend() Client
> TalkerApp::SendPacket(Hello,S,600) Client
> TalkerApp::StartApplication() Server
> TalkerApp::StartApplicationRecv() Server
> TalkerApp::ConnectionRequested(0x632cd0,02-06-0a:01:00:01:01:c0): Server
> TalkerApp::ConnectionSucceeded(0x6312c0): Client
> TalkerApp::ConnectionCreated(0x6333e0,02-06-0a:01:00:01:01:c0): Server
> TalkerApp::HandleRead(0x6333e0): Server
> TalkerApp::SendPacket(BackAtYou,R,700) Server
>  536 bytes from 10.1.0.1 [02-06-0a:01:00:01:01:c0]  Payload
> (size=536)|ns3::SocketRxAddressTag [0-536] address=00-00-00
> TalkerApp::HandleRead(0x6333e0): Server
>   64 bytes from 10.1.0.1 [02-06-0a:01:00:01:01:c0]  Payload
> (size=64)|ns3::SocketRxAddressTag [0-64] address=00-00-00
> 
> What does the 02-06 part of the mac addr mean? What is the address tag in the
> packet used for?

the 02-06 part identifies the type (02: Mac48 on your system) and the length
(06 bytes). The address tag is used to provide the to address to the Send
(Ptr<Packet> p) function.

[my email reply didn't seem to make it to bugzilla, so.... ]

Should I create a seperate bug report for the missing docs?

I'll be happy to modify this program, once its working, to be used as a test
case.

Thanks,
\dae

(In reply to comment #6)

> Should I create a seperate bug report for the missing docs?

see bug 202.

Fixed in ns-3-dev 3229:ec45f705b9ca

Looks like the cutover to finite buffers caused some casualties...

It seems to work now. Thanks. I'm thinking about adding some tag stuff in so
that when tags are preserved there will be a good test case.

Also, any suggestions on what I should change/fix to turn this into an official
ns-3 regression test? (e.g. coding standards, output requirements, etc.)

Thanks again,
\dae

(In reply to comment #9)
> It seems to work now. Thanks. I'm thinking about adding some tag stuff in so
> that when tags are preserved there will be a good test case.
> 
> Also, any suggestions on what I should change/fix to turn this into an official
> ns-3 regression test? (e.g. coding standards, output requirements, etc.)

we don't have any formal requirements but here are a few thinks I consider to
be nice:
  - does not generate large output traces
  - runs as fast as possible (can ideally be run not too slowly under valgrind)

Then, the way you integrate your script is by adding a second python script to
the regression/tests/ directory and the reference traces to
regression/ns-3-dev-traces/

Created an attachment (id=150) [details]
same program as before only now with more tags and a header.

For some reason the Header that I add in MarkPacket doesn't seem to make it
across the TCP socket. Also, in MarkPacket (on the Tx side), the Packet::Print
doesn't print the tag.

(In reply to comment #11)
> Created an attachment (id=150) [edit] [details]
> same program as before only now with more tags and a header.
> 
> For some reason the Header that I add in MarkPacket doesn't seem to make it
> across the TCP socket. Also, in MarkPacket (on the Tx side), the Packet::Print

It does make it and, if you remove it with RemoveHeader, you will find it. What
does not make it is the metadata so Packet::Print cannot print the content of
the packet but the content should be right if you call Packet::RemoveHeader.

> doesn't print the tag.

Packet::Print does not print tags. Packet::PrintTags prints the tags.

Although I agreed that you add this report to this old bug, I think that it
would be better in the future to file new bugs :)