-
Notifications
You must be signed in to change notification settings - Fork 279
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't communicate with kernel SCTP stack program. #603
Comments
You can not run the kernel stack and the userland stack at the same time using SCTP/IP. The packet containing the Either use two different hosts (and no kernel stack on the host running the program with the userland stack) or use UDP encapsulation, but I think the Linux kernel does not support this yet. |
Why does the
./echo_server
./client 192.168.131.1 7780 In the meantime, I ran tshark both on NIC whose IP address is 192.168.131.1 and on NIC whose IP address is 192.168.131.2 to monitor network traffic. I got below records:
It confused me that 192.168.32.1 is just a virtual NIC and there was no route between it and 192.168.131.2. Why did |
When you have a kernel stack, packets get delivered to that stack. Since the kernel stack does not have states for associations handled in userland, it considers them as out of the blue and replies with a packet containing an ABORT chunk.
Two issues:
|
|
If you are using Linux, |
Yes, I've just run this command: lsmod | grep sctp I got below output: sctp 279238 2
libcrc32c 12644 4 xfs,sctp,nf_nat,nf_conntrack So disabling kernel SCTP stack means removing the sctp module? rmmod: ERROR: Module sctp is in use I've checked that my kernel client and server weren't running at the time. |
I've not much experience with Linux, but I think you can't unload the |
Thanks, I've looked up some references and found that to remove the |
Why don't we just use the destination address of the INIT packet to fill the source address of the INIT_ACK packet? I've looked through the code and found that the INIT_ACK packet's source address is filled using the INIT packet's destination address only in the loopback scope. But in other cases, usrsctp will re-choose a source address for the INIT_ACK packet. I don't know why this is better. if (stc.loopback_scope) {
over_addr = (union sctp_sockstore *)dst;
} else {
over_addr = NULL;
} I've changed to directly assign dst to over_addr like below: over_addr = (union sctp_sockstore *)dst; I remade it all and tested it again. Now COOKIE_ECHO packet can be sent and COOKIE ACK can be sent too. But the problem was that there was no data sent between the two. I saw consecutive COOKIE_ECHO packets wat sent. It seems that the client didn't recognize the COOKIE_ACK packet and kept sending COOKIE_ECHO until max try. What might the root cause be? I guess my modification is incomplete. Does this have something to do with the state cookie? Thanks! |
The FreeBSD kernel stack uses the IP layer to determine the source address (based on the routing table). The userland stack has not this functionality. Regarding the COOKIE-ACK: Can you enable the debug output and get an idea why it is not accepted. Which IP addresses are used for the handshake? |
I've written a simple sctp client using interface provided by linux, part of my code is like below:
It confused me when I run echo_server provided by usrsctp and this simple sctp client. The connection failed, and it told me:
Can't connect to 127.0.0.1, port 7780, errno: 111, Connection refused
Then I tried to capture the packets to see what happened. I started Wireshark to capture packets on loopback NIC, then I got these records:
Why did this happen? I've also written a simple server using Linux socket. And I've verified that my server and client could communicate with each other normally. They can complete INIT->INIT_ACK->COOKIE_ECHO->COOKIE_ACK process.
The text was updated successfully, but these errors were encountered: