Re: [Sigtran] M3UA: Message Length

["David Laight" <[e-mail]>]

I’ve NFI what you used to take that trace – Wireshark will only give me a hexdump.

Anyway the packet decodes as:

 

Pad, MAC addresses, ethertype

0000  00 00 00 01 00 06 00 1a  30 2b 4b c0 00 00 08 00

IP header

0010  45 02 00 ac 13 31 00 00  fe 84 3f ca 0a 3a 70 c8

0020  0a 3a e3 94

SCTP

      ports: 0f 53 0f 59

      tag:   49 33 5f c5

      cksum: 7f 3e b6 8d

0030  chunk type: 00

      flags:      03

      length:     00 8a

      TSN:        da 58 6c 93

      Stream id:  00 01

      Stream-seq: 00 08

      Payload-id: 00 00 00 03

 

M3UA data, length 0x7c

0040  01 00 01 01 00 00 00 7c

            02 00 00 08

                  00 00 00 02

0050        00 06 00 08

                  00 00 00 08

            02 10 00 62

                  00 00 0b ba

0060              00 00 13 8b 03 03 01 00  11 01 03 04 08 0c 45 04

0070              43 8b 13 07 04 43 ba 0b  07 39 00 00 00 00 00 00

0080              00 00 00 00 00 00 00 00  00 00 00 00 00 00 04 04

0090              04 04 04 04 04 04 04 04  04 04 04 04 04 04 04 04

00a0              04 04 04 04 04 04 04 04  04 04 04 04 04 04 04 04

00b0              04 04 04 10 04 40 00 00  00 00

 

Inter-chunk pad: 00 00

 

The problem is that the length of the M3UA message (0x7c)  is larger than the payload

part of the SCTP message (0x8a – 0x10 = 0x7a).

The RFC might let you send that if the M3UA length were 0x7a, but I know that

all implementations will not be able to receive such messages – so it is best not

to send them.

 

                David

 

 

From: santosh nayak [mailto:[e-mail]] 
Sent: 14 October 2013 05:47
To: David Laight
Subject: Re: [Sigtran] M3UA: Message Length

 

Hi,

 

Thanks for the response...

 

I am attaching the pcap... packet number 85

Could you explain what MUST is violated???

 

Thanks,

Santosh

 

 

On Thu, Oct 10, 2013 at 5:57 PM, David Laight <[e-mail]> wrote:

> From: [e-mail] [mailto:[e-mail]] On Behalf Of Michael Tuexen

> On Oct 10, 2013, at 11:40 AM, santosh nayak <[e-mail]> wrote:
>
> > Hi,
> >
> > We have a situation where message is being rejected at M3UA layer due to
> > buffer length is not equal to message length.
> >
> > What is the significance of Message Length and its importance with padding...
> >
> > in the current issue M3UA peer is sending the data buffer of size 122 bytes
> > to KSCTP. But message length parameter of M3UA common header contains a value
> > of 124 and KSCTP is doing the padding at its level of 2 bytes which is
> > observed from the wireshark traces.

Are you sure that pad isn't just from SCTP aligning it's chunks?


> > Now at DUT message droped with reason  (message length parameter is greater
> > than actual M3UA data buffer size)
> >
> > Is this expected??? Please comment on this...
>
> At least the behaviour of the sender is not expected, since the sender
> violates a MUST.

I'm not sure what the note in section 3.1.4 is trying to allow, but
I think the message you are describing is definitely illegal.

I believe that the overall length in the 'common' header should always
match that of the SCTP data chunk.
This allows M3UA data to be separated into messages when sent using (say)
TCP rather than SCTP.

I suspect the note allows an implementation to add the pad (following a
parameter) when it adds a new one, rather than when it adds a parameter
that isn't a multiple of 4 bytes.

In any case I'd change your sending end.

        David