search

sctplab / sctp-refimpl

Automatically exported from code.google.com/p/sctp-refimpl
BSD 2-Clause "Simplified" License
8 stars 2 forks source link

Documentation of the client example program misses the local port number parameter #6

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Compile under windows
2. Run example echo_server and client

What is the expected output? What do you see instead?
Client is getting stuck on usrsctp_connect, no connection attempt appears to be 
sent and no error is returned from the call. 

What version of the product are you using? On what operating system?
Windows 7 64 bit

Please provide any additional information below.
compiled and tested on 2 different machines, the same problem occurs.

Original issue reported on code.google.com by twiste...@gmail.com on 11 Dec 2014 at 4:21

GoogleCodeExporter commented 9 years ago 
Tried again and left it for 20 minutes, came back to this on the client

usrsctp_connect: Unknown error
Local addresses: fe80::c1eb:5e8c:faa3:ce4f, 192.168.1.12.
usrsctp_getpaddrs: Unknown error

Original comment by twiste...@gmail.com on 11 Dec 2014 at 9:48

GoogleCodeExporter commented 9 years ago 
Where you running the server on one machine and the client on the other, or did 
you try to run both programs on the same machine? What are the command line 
parameters used to start the client and the server?

Original comment by t00FC...@googlemail.com on 12 Dec 2014 at 5:11

GoogleCodeExporter commented 9 years ago 
I ran the server and client on the same machine using the loopback device, I 
used the parameters in the manual.
discard_server.exe 11111 22222
client.exe 127.0.0.1 9 22222 11111

Original comment by twiste...@gmail.com on 12 Dec 2014 at 9:00

GoogleCodeExporter commented 9 years ago 
OK, I can reproduce the problem. I think it is not limited to Windows.

Original comment by t00FC...@googlemail.com on 12 Dec 2014 at 6:54

GoogleCodeExporter commented 9 years ago 
The problem is that the usage of the client program was changed in
https://code.google.com/p/sctp-refimpl/source/detail?r=8490
but the documentation wasn't updated. This has been fixed in
https://code.google.com/p/sctp-refimpl/source/detail?r=9085

On non-Windows systems you can use
client.exe 127.0.0.1 9 0 22222 11111

Please note that on Windows you can't use 127.0.0.1 as indicated in the 
documentation you must use one of your addresses. Since it seems that you have 
192.168.1.12 configured on your system please try
client.exe 192.168.1.12 9 0 22222 11111

Please let me know if this resolves the issue. At least it does it on my test 
system running Windows 7.

Original comment by t00FC...@googlemail.com on 13 Dec 2014 at 10:06

GoogleCodeExporter commented 9 years ago

Original comment by t00FC...@googlemail.com on 13 Dec 2014 at 10:08

GoogleCodeExporter commented 9 years ago 
Thanks but it's still not working for me, I've tried running the client and 
server on separate PC's and the same error is thrown. It just appears to hang 
for ages before throwing this

client 192.168.1.9 9 0 22222 11111
usrsctp_connect: Unknown error
Local addresses: fe80::2d84:ddee:1cfc:5f00, fe80::7879:b082:d179:23da, 
192.168.1.9.
usrsctp_getpaddrs: Unknown error

I've tried compiling without inet6 but same error.

Original comment by twiste...@gmail.com on 13 Dec 2014 at 12:51

GoogleCodeExporter commented 9 years ago 
Can you use wireshark to see whether the packets make it on the wire or not?
You might need to disable any kind of firewall on both machines. Please check
on the client side if you see outgoing packet containing INIT chunks, if you
receive them on the server side and if the server responds with packets 
containing
INIT-ACK chunks.

The sender is working fine and retransmits the packets. It takes 10 
retransmissions
to fail the association.

Disabling INET6 doesn't help... It might even be counter productive.

Best regards
Michael

Original comment by t00FC...@googlemail.com on 13 Dec 2014 at 1:35

GoogleCodeExporter commented 9 years ago 
So it looks like the server is receiving the INIT chunks but not replying.
The wireshark captures of the client and server are attached. It takes an age 
for it to reach 10 and timeout so I've just captured the first 6.

Original comment by twiste...@gmail.com on 13 Dec 2014 at 1:59

Attachments:

GoogleCodeExporter commented 9 years ago 
The client behaves as expected. The retransmissions of the INIT are after 3 
seconds, 6, 12, 24, 48, 60, 60, 60, 60, 60. This is as specified in RFC 4960. 
If you want to change it, you can use socket options to tweak the parameters. 
See  https://tools.ietf.org/html/rfc6458#section-8.1.1

The problem is on the server side. Do you have switched off *all* firewalls. 
Any external ones and also the windows built-in ones?

Original comment by t00FC...@googlemail.com on 13 Dec 2014 at 3:54