criu
criu copied to clipboard
checkpoint-restore
Support SCTP protocol
@xemul Hi, xemul Although SCTP module in kernel is not easy to be supported by criu, we think about some method to walk around. We tried usrSCTP (https://github.com/sctplab/usrsctp), which implement SCTP in user space. However, since usrSCTP use raw socket as: socket(AF_INET, SOCK_RAW, IPPROTO_SCTP), criu think it could not be dumped. I wonder whether it's possible to support this type of socket in do_dump_one_inet_fd() as:
- make it pass the check in can_dump_ipproto() and can_dump_inet_sk()
- dump settings with dump_ip_opts() + dump_socket_opts()
- just shutdown it following IPPROTO_UDP: sk_encode_shutdown()
Please advize, thanks!
@zgtian , yes, raw sockets would be much easier to support, from the first glance you've described everything correctly. Don't hesitate to submit a patch and ask for any explanations from now on :)
@xemul , we have modified some code on dump/restore. Yes, it seems work now without error, however, the restored client would send illegal packets to server. Please help to check the modification, please always take into consideration that we are newbie for socket/netlink/criu and we do a lot of dirty work to clear errors... :)
Two things bother me -- you don't save/restore socket opts for your sockets (you commented out these calls) and you don't save/restore raw-socket options. This may cause misbehavior.
@xemul ,thansk actually these commented code may cause error, i have no idea how to treat these errors currently. According to you, what is necessary to be saved and restored for SOCK_RAW of AF_INET? The same as SOCK_STREAM/SOCK_DGRAM or not? I notice you save and restore a lot of opts for AF_PACKET.
Well, first of all you should save all the opts that are currently saved by CRIU. If any of them fails, this should be analyzed option-by-option.
Next, looking at kernel's function do_ip_setsockopt() I can see a_lot of configuration for AF_INET socket. We don't save all of it currently, since for TCP socket they seem to be not-relevant. But for raw mode it can be crucial.
Here's the list of what I've found: IP_PKTINFO: IP_RECVTTL: IP_RECVOPTS: IP_RECVTOS: IP_RETOPTS: IP_TOS: IP_TTL: IP_HDRINCL: IP_MTU_DISCOVER: IP_RECVERR: IP_ROUTER_ALERT: IP_FREEBIND: IP_PASSSEC: IP_TRANSPARENT: IP_MINTTL: IP_NODEFRAG: IP_BIND_ADDRESS_NO_PORT: IP_UNICAST_IF: IP_MULTICAST_TTL: IP_MULTICAST_ALL: IP_MULTICAST_LOOP: IP_RECVORIGDSTADDR: IP_CHECKSUM: IP_RECVFRAGSIZE: IP_OPTIONS: IP_PKTINFO: IP_RECVTTL: IP_RECVTOS: IP_RECVOPTS: IP_RETOPTS: IP_PASSSEC: IP_RECVORIGDSTADDR: IP_CHECKSUM: IP_RECVFRAGSIZE: IP_TOS: IP_TTL: IP_HDRINCL: IP_NODEFRAG: IP_BIND_ADDRESS_NO_PORT: IP_MTU_DISCOVER: IP_RECVERR: IP_MULTICAST_TTL: IP_MULTICAST_LOOP: IP_UNICAST_IF: IP_MULTICAST_IF: IP_ADD_MEMBERSHIP: IP_DROP_MEMBERSHIP: IP_MSFILTER: IP_BLOCK_SOURCE: IP_UNBLOCK_SOURCE: IP_ADD_SOURCE_MEMBERSHIP: IP_DROP_SOURCE_MEMBERSHIP: MCAST_JOIN_GROUP: MCAST_LEAVE_GROUP: MCAST_JOIN_SOURCE_GROUP: MCAST_LEAVE_SOURCE_GROUP: MCAST_BLOCK_SOURCE: MCAST_UNBLOCK_SOURCE: MCAST_MSFILTER: IP_MULTICAST_ALL: IP_ROUTER_ALERT: IP_FREEBIND: IP_IPSEC_POLICY: IP_XFRM_POLICY: IP_TRANSPARENT: IP_MINTTL:
Hi, @xemul
We are working on this functionality right now, we were able to successfully dump and restore an SCTP socket in the listening state, now I want to add support for the established state using TCP_REPAIR like mechanism (SCTP_REPAIR), This why we need some help in that direction (for example which kernel files need to be updated ??)
Thank you in advance.
@Oussalvatore , that's good news! For any help that you'd need -- feel free to write either here or to criu@ ml or to me directly.
As far as the kernel is concerned -- please, grab the net-next tree (https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git) and make the patches over it. Then you'll need to negotiate them on the netdev@ mailing list.
Thank you @xemul , it would be very helpful if you can share the patch file of TCP connection repair with me :).
@Oussalvatore https://github.com/torvalds/linux/commit/ee9952831cfd0bbe834f4a26489d7dce74582e37
thank you @avagin, we have successfully dumped the SCTP connection and we are working on the restore now
Hi @xemul and @avagin , I'm facing some problems and I would be grateful if you can help me. Actually I'm trying to restore the dumped process and CRIU indicates that the process has been successfully restored but it's not the case, also I can observe the restoration of the SCTP socket in /proc/net/sctp/assocs file. Here is the dump and restore logs. Thank you dump.log restore.log
I'm having a similar problem (trying to dump SCTP sockets), but even in the latest CRIU release it still seems like a feature that's missing. Any progress on this, or any plans to support this in the future, if at all?
Hi @xemul and @avagin , I'm facing some problems and I would be grateful if you can help me. Actually I'm trying to restore the dumped process and CRIU indicates that the process has been successfully restored but it's not the case, also I can observe the restoration of the SCTP socket in /proc/net/sctp/assocs file. Here is the dump and restore logs. Thank you dump.log restore.log
Hello @Oussalvatore We are currently working on an application that requires SCTP protocol support for CRIU. I would like to know whether you are successful in the addition of SCTP support. Could you please share the sctp support module added and we shall work on it from the place where you encounter issues. Thank you.
Regards, Priya.
A friendly reminder that this issue had no activity for 30 days.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
A friendly reminder that this issue had no activity for 30 days.
A friendly reminder that this issue had no activity for 30 days.
Hello! Do we have any updates for supporting SCTP maintenance? @ShunmugaPriyaR I saw there is a repository that you guys working with, is there any progress? Thank you :)
