Hi Marco，
Thanks for your detail explanation.
1. I just saw the function ip4_sctp_compute_checksum(). The comment /*
Initialize checksum with ip header. */ seems that you include the IP header to
calculate the checksum. And also in this function, you call
ip_incremental_checksum(), so it seems that the algorithm not like crc32c.
2. Maybe I was wrong. But I didn't find any structure to save the cookie in the
sctp_state_cookie_param_t. In the function sctp_handle_init_ack(), you save it
like this:
case SCTP_STATE_COOKIE_TYPE:
{
sctp_state_cookie_param_t *state_cookie_param =
(sctp_state_cookie_param_t *) opt_params_hdr;
clib_memcpy (&(sctp_conn->cookie_param), state_cookie_param,
sizeof (sctp_state_cookie_param_t));
break;
}
And then in the function sctp_prepare_cookie_echo_chunk(), just copy it like
this:
clib_memcpy (&(cookie_echo_chunk->cookie), &sctp_conn->cookie_param,
sizeof (sctp_state_cookie_param_t));
Maybe I miss something, but indeed in the COOKIE_ECHO chunk from the standard,
it's only COOKIE, not optional state cookie parameter, i.e. there is no
Parameter type and Parameter length in the COOKIE_ECHO chunk.
Best regards
刘道林 (Daolin Liu)
T&W大连市共进科技有限公司
DALIAN GONGJIN TECHNOLOGY CO.,LTD
中国大连市高新园区软件园路1A-4-24层
Floor 24th, 1A-4 Software Park Road, Hi-tech Zone, Dalian, Liaoning, China
直线(TEL)：(86-411)39996705 分机(EXT)：76824
手机(Mobile)：(86)13704090959
-----邮件原件-----
发件人: Marco Varlese [mailto:mvarl...@suse.de]
发送时间: 2018年11月23日 20:39
收件人: Liu Daolin (刘道林); vpp-dev@lists.fd.io
主题: Re: 答复: 答复: 答复: [vpp-dev] about sctp
On Fri, 2018-11-23 at 09:14 +0000, Liu Daolin (刘道林) wrote:
> Hi Marco，
>
> 1. If you indeed use crc32c, it's ok. But from my view, it should not include
> ip header.
And it does not!
>
> 2. the definition is below:
>
> #define SHA1_OUTPUT_LENGTH 20
> /*
> * 0 1 2 3
> * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * | Parameter Type | Parameter Length |
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> * \ \
> * / Parameter Value /
> * \ \
> * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> */
> typedef struct
> {
> sctp_opt_params_hdr_t param_hdr;
>
> unsigned char mac[SHA1_OUTPUT_LENGTH]; /* RFC 2104 */
> u64 creation_time;
> u32 cookie_lifespan;
>
> } sctp_state_cookie_param_t;
>
> The macro definition SHA1_OUTPUT_LENGTH 20 seems not enough.
In your earlier email you mentioned COOKIE LENGTH which is _NOT_ what you're
referring to now. The SHA1_OUTPUT_LENGTH has nothing to do with the COOKIE
LENGTH but the length of the hash calculated via a SHA1 algorithm!
Indeed the macro is called SHA1_OUTPUT_LENGTH which it's pretty self
explanatory.
I have no clue why you believe it is "not enough", maybe you were thinking about
the COOKIE LENGTH? I have no idea...
As you can see from the code there is a reference to an RFC (2104): if you spent
2 minutes looking that up you would see that it states (section 2, page 2, line
6): "16 bytes for MD5 hash output and 20 bytes for SHA-1 hash output".
Further, the RFC 2104 is referenced by the SCTP (RFC 4960) at section 5.1.3
where the topic State Cookie is discerned.
Having said all that, I won't go into any deeper details about the RFC/protocol
over the ML; you can read that up.
If you identify anything wrong with the implementation (which doesn't match the
RFC) please send a patch via gerrit with RFC references.
>
>
>
>
> Best regards
> 刘道林 (Daolin Liu)
> T&W大连市共进科技有限公司
> DALIAN GONGJIN TECHNOLOGY CO.,LTD
> 中国大连市高新园区软件园路1A-4-24层
> Floor 24th, 1A-4 Software Park Road, Hi-tech Zone, Dalian, Liaoning, China
> 直线(TEL)：(86-411)39996705 分机(EXT)：76824
> 手机(Mobile)：(86)13704090959
>
>
> -----邮件原件-----
> 发件人: Marco Varlese [mailto:mvarl...@suse.de]
> 发送时间: 2018年11月23日 17:07
> 收件人: Liu Daolin (刘道林); vpp-dev@lists.fd.io
> 主题: Re: 答复: 答复: [vpp-dev] about sctp
>
>
> On Fri, 2018-11-23 at 00:57 +0000, Liu Daolin (刘道林) wrote:
> > Hi Macro,
> >
> > OK, I will try it when I have time.
> Well, as you wish.
>
> > I'm reading the sctp source code and found some issues. The most critical
> > one
> > is the checksum. The sctp checksum should not include the ip header, just
> > only
> > sctp data, and also it should use crc32c, not the current code shown.
> I am not sure what you refer to with "code shown".
> However the crc calculated is indeed the one you mention and it's using SSE4
> instructions which are exactly using the polynomial depicted by RFC 4960.
>
> > Another important issue is the max cookie length is 20 from the macro
> > definition. Actually it should not be a fixed value (usually more than 200).
> So I cannot find a definition for the actual length of the cookie.
> It would help if you could point to the actual filename / definition when
> reporting issues.
>
> >
> > Best regards
> > 刘道林 (Daolin Liu)
> > T&W大连市共进科技有限公司
> > DALIAN GONGJIN TECHNOLOGY CO.,LTD
> > 中国大连市高新园区软件园路1A-4-24层
> > Floor 24th, 1A-4 Software Park Road, Hi-tech Zone, Dalian, Liaoning, China
> > 直线(TEL)：(86-411)39996705 分机(EXT)：76824
> > 手机(Mobile)：(86)13704090959
> >
> > 发件人: Marco Varlese [mailto:mvarl...@suse.de]
> > 发送时间: 2018年11月22日 20:52
> > 收件人: Liu Daolin (刘道林); vpp-dev@lists.fd.io
> > 主题: Re: 答复: [vpp-dev] about sctp
> >
> > Dear Liu,
> >
> > The reason why I asked you to take a look at the "test_sctp.py" is to see
> > how
> > things are setup and execute the exact steps in the CLI. You'll see things
> > work.
> >
> > You cannot remove the MTU code because that's used to initialize the PMTU
> > and
> > calculate initially the MSS to be sent to the other peer.
> >
> >
> > Cheers,
> > Marco
> >
> > On Wed, 2018-11-21 at 01:50 +0000, Liu Daolin (刘道林) wrote:
> > > Hi Marco,
> > >
> > > Thanks for your reply.
> > >
> > > Actually I'm trying to read the sctp code recently to want to know how it
> > > works. My requirement is very simply. I need to run sctp server based on
> > > vpp
> > > on one VM, and run sctp client without vpp (I have this now) on the other
> > > VM. As my below email, there will be aborted (core dumped), and I found
> > > the
> > > place yesterday, but I don’t know the root reason. You can see below
> > > picture:
> > >
> > >
> > >
> > > The sw_if_index is -1, so crashed when get mtu. Maybe I miss something?
> > > When
> > > I run actually is CLI command from echo_server.c. As you mentioned, if I
> > > run
> > > test_sctp.py, it will work fine? My requirement is only C language as it
> > > will merged some other code, so I don’t like to run it with python.
> > >
> > > Yesterday, I also try to remove this mtu code, and the crash was
> > > disappeared
> > > although the sw_if_index is still -1, and then I start sctp client on the
> > > other VM to send INIT, but the server with vpp seemed be dead (no crash
> > > but
> > > cannot enter any command, seemed dead loop).
> > >
> > > Anyway, I think it's better to try CLI "test echo server" in your side and
> > > find and fix all issues visually.
> > >
> > >
> > >
> > >
> > >
> > > Best regards
> > > 刘道林 (Daolin Liu)
> > > T&W大连市共进科技有限公司
> > > DALIAN GONGJIN TECHNOLOGY CO.,LTD
> > > 中国大连市高新园区软件园路1A-4-24层
> > > Floor 24th, 1A-4 Software Park Road, Hi-tech Zone, Dalian, Liaoning, China
> > > 直线(TEL)：(86-411)39996705 分机(EXT)：76824
> > > 手机(Mobile)：(86)13704090959
> > >
> > > -----邮件原件-----
> > > 发件人: Marco Varlese [mailto:mvarl...@suse.de]
> > > 发送时间: 2018年11月21日 1:06
> > > 收件人: Liu Daolin (刘道林); vpp-dev@lists.fd.io
> > > 主题: Re: [vpp-dev] about sctp
> > >
> > > Hi,
> > >
> > > On Tue, 2018-11-20 at 02:50 +0000, Liu Daolin (刘道林) wrote:
> > > > Hi,
> > > >
> > > > I encountered below Aborted (core dumped) issue:
> > > >
> > > >
> > > >
> > > > When I run "test echo server uri", it's ok for tcp, but crashed
> > > immediately
> > > > for sctp.
> > > >
> > > > Please try this in your side and give me advice. I use 18.10. Thanks!
> > > Can you please try to run "make test TEST=test_sctp"?
> > > >
> > > > Best regards
> > > > 刘道林 (Daolin Liu)
> > > > T&W大连市共进科技有限公司
> > > > DALIAN GONGJIN TECHNOLOGY CO.,LTD
> > > > 中国大连市高新园区软件园路1A-4-24层
> > > > Floor 24th, 1A-4 Software Park Road, Hi-tech Zone, Dalian, Liaoning,
> > > > China
> > > > 直线(TEL)：(86-411)39996705 分机(EXT)：76824
> > > > 手机(Mobile)：(86)13704090959
> > > >
> > > > 发件人: Liu Daolin (刘道林)
> > > > 发送时间: 2018年11月19日 19:23
> > > > 收件人: 'vpp-dev@lists.fd.io'
> > > > 主题: about sctp
> > > >
> > > > Hi,
> > > >
> > > > I'd like to know some information about sctp.
> > > >
> > > > Is this fully functional? Or just partly?
> > > There are missing pieces to the SCTP implementations.
> > >
> > > > Actually, I want to try simply with CLI to verify sctp basic functions
> > > now.
> > > > But it seems that there is no CLI, and the binary APIs are also
> > > > imperfect.
> > > What do you actually mean by imperfect? Any input (e.g. patch submission)
> > > would
> > > be greatly appreciated!
> > > > Do you have any plan in the next release? Including the sample test.
> > > I am planning to create some JIRA ticket(s) so that people can see what's
> > > missing and contribute if they like. Would you be interested?
> > >
> > > > Best regards
> > > > 刘道林 (Daolin Liu)
> > > > T&W大连市共进科技有限公司
> > > > DALIAN GONGJIN TECHNOLOGY CO.,LTD
> > > > 中国大连市高新园区软件园路1A-4-24层
> > > > Floor 24th, 1A-4 Software Park Road, Hi-tech Zone, Dalian, Liaoning,
> > > > China
> > > > 直线(TEL)：(86-411)39996705 分机(EXT)：76824
> > > > 手机(Mobile)：(86)13704090959
> > > >
> > > >
> > > 本电子邮件（包括任何的附件）为本公司保密文件。本文件仅仅可为以上指定的收件人或公司使用，如果阁下非电子邮件所指定之收件人，那么阁下对该邮件部分或全部
> > > 的泄
> > > 漏、
> > > 阅览、复印、变更、散布或对邮件内容的使用都是被严格禁止的。如果阁下接收了该错误传送的电子邮件，敬请阁下通过回复该邮件的方式立即通知寄件人，同时删除你
> > > 所接
> > > 收到
> > > > 的文本。 This e-mail may contain confidential and/or privileged information.
> > > If
> > > > you are not the intended recipient (or have received this e-mail in
> > > > error)
> > > > please notify the sender immediately and destroy this e-mail. Any
> > > unauthorized
> > > > copying, disclosure or distribution of the material in this e-mail is
> > > strictly
> > > > forbidden.
> > > > -=-=-=-=-=-=-=-=-=-=-=-
> > > > Links: You receive all messages sent to this group.
> > > >
> > > > View/Reply Online (#11334): https://lists.fd.io/g/vpp-dev/message/11334
> > > > Mute This Topic: https://lists.fd.io/mt/28240674/675056
> > > > Group Owner: vpp-dev+ow...@lists.fd.io
> > > > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [mvarl...@suse.de]
> > > > -=-=-=-=-=-=-=-=-=-=-=-
> > > 本电子邮件（包括任何的附件）为本公司保密文件。本文件仅仅可为以上指定的收件人或公司使用，如果阁下非电子邮件所指定之收件人，那么阁下对该邮件部分或全部
> > > 的泄
> > > 漏、阅览、复印、变更、散布或对邮件内容的使用都是被严格禁止的。如果阁下接收了该错误传送的电子邮件，敬请阁下通过回复该邮件的方式立即通知寄件人，同时删
> > > 除你
> > > 所接收到的文本。 This e-mail may contain confidential and/or privileged
> > > information.
> > > If you are not the intended recipient (or have received this e-mail in
> > > error) please notify the sender immediately and destroy this e-mail. Any
> > > unauthorized copying, disclosure or distribution of the material in this
> > > e-
> > > mail is strictly forbidden.
> > > -=-=-=-=-=-=-=-=-=-=-=-
> > > Links: You receive all messages sent to this group.
> > >
> > > View/Reply Online (#11357):
> > > https://lists.fd.io/g/vpp-dev/message/11357
> > >
> > >
> > > Mute This Topic:
> > > https://lists.fd.io/mt/28280869/675056
> > >
> > >
> > > Group Owner:
> > > vpp-dev+ow...@lists.fd.io
> > >
> > >
> > > Unsubscribe:
> > > https://lists.fd.io/g/vpp-dev/unsub
> > >
> > > [
> > > mvarl...@suse.de
> > >
> > > ]
> > > -=-=-=-=-=-=-=-=-=-=-=-
> >
> > 本电子邮件（包括任何的附件）为本公司保密文件。本文件仅仅可为以上指定的收件人或公司使用，如果阁下非电子邮件所指定之收件人，那么阁下对该邮件部分或全部的泄
> > 漏、
> > 阅览、复印、变更、散布或对邮件内容的使用都是被严格禁止的。如果阁下接收了该错误传送的电子邮件，敬请阁下通过回复该邮件的方式立即通知寄件人，同时删除你所接
> > 收到
> > 的文本。 This e-mail may contain confidential and/or privileged information. If
> > you are not the intended recipient (or have received this e-mail in error)
> > please notify the sender immediately and destroy this e-mail. Any
> > unauthorized
> > copying, disclosure or distribution of the material in this e-mail is
> > strictly
> > forbidden.
> 本电子邮件（包括任何的附件）为本公司保密文件。本文件仅仅可为以上指定的收件人或公司使用，如果阁下非电子邮件所指定之收件人，那么阁下对该邮件部分或全部的泄漏、
> 阅览、复印、变更、散布或对邮件内容的使用都是被严格禁止的。如果阁下接收了该错误传送的电子邮件，敬请阁下通过回复该邮件的方式立即通知寄件人，同时删除你所接收到
> 的文本。 This e-mail may contain confidential and/or privileged information. If
> you are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any unauthorized
> copying, disclosure or distribution of the material in this e-mail is strictly
> forbidden.
本电子邮件（包括任何的附件）为本公司保密文件。本文件仅仅可为以上指定的收件人或公司使用，如果阁下非电子邮件所指定之收件人，那么阁下对该邮件部分或全部的泄漏、阅览、复印、变更、散布或对邮件内容的使用都是被严格禁止的。如果阁下接收了该错误传送的电子邮件，敬请阁下通过回复该邮件的方式立即通知寄件人，同时删除你所接收到的文本。
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this e-mail is strictly
forbidden.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11407): https://lists.fd.io/g/vpp-dev/message/11407
Mute This Topic: https://lists.fd.io/mt/28320162/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
