Osmocom Libraries » libosmocore

I'm not the one who filed this issue, so I can only guess what lynxis might have meant. However, I don't understand why @arehbein would mean an invalid SNS-SIZE would only be able to have a wrong NSEI IE?

The SNS-SIZE IE has all kinds of IEs, some mandatory and some optional. Beyond NSEI there's RESET_FLAG, MAX_NR_NSVC, IPv4_EP_NR, IPV6_EP_NR, see Section 9.3.7 of TS 48.016.

A wrong NSEI is more like a general failure. There's a NSEI in most if not all NS messages, and unknown/invalid NSEI is something that we handle in some generic code looking up the NSEI. I would think particularly critical is missing IEs such as IPv4/IPv6 endpoint number. For example, neither of the two is always illegal. Only one of v4/v6 in a situation where we expect the other might be another situation (think of one side being v4-only while the other is v6-only).

laforge alright thank you. The NSEI is the only TLV of an SNS Size PDU, the others are TVs according to the spec. So I was wondering if there was anything particular to lookout for (and it didn't seem like it, as you said, the NSEI is pretty generic anyways).
Anyways then I'll just proceed testing all the IEs, maybe except the NSEI even since it's already tested somewhere else ;)

(at least) our use of "TLV" is more general. Basically it means all the
tag-identified elements usually located after a fixed header of a message.

After all, it's also the TLV parser which we use to parse the TV parts,
TL16V, T16L16V TvLV and many other types of encodings.

I finished some tools to make it easier for me to test and push to Gerrit and am getting the hang of the whole process I think...

About the current state (copy paste from my comment on the WIP commit for this on Gerrit):

This is a first test (the first one I could think of):
The SGSN receives an SNS Size containing the number of IP endpoints
So currently, the test fails.
But I just realized, that the expected cause I coded isn't right.

And I should still add some new tests (I came up with some new ideas now... before it wasn't clear to me, that semantically invalid TLVs were most likely asked for to be tested and I got hung up on trying to find cases for syntactically wrong TLVs (by now I think the only one I can come up with is a number of NS-VCs IE with a length of 1...)

So I'll now look into new testcases (and will probably abandon this one unless it actually still makes sense - I think it doesn't, I misunderstood some of the code) that check semantical validity according to the specs.

Nice. So this is a TLV parser test.

Due to TS 148 016 v16, section 8.1 ("General protocol error handling"):

Syntactical error: an IE is defined to be syntactically incorrect in a PDU if it contains at least one value defined
as "reserved" or "reserved for future use", or if its value part violates coding rules specified in the relevant
protocol specification, e.g. a too short IE (the length indicator shall be used to determine the boundary of the IE).
However, it is not a syntactical error that an IE specifies in its length indicator a greater length than defined in
the relevant protocol specification; and

this appears to me as rather protocol specific, and not generally applicable to TLVs. In the sense of being a TLV, any IE with length 1 containing a single octet as its payload would still be a valid as a general TLV, but it would constitute a protocol error according to TS 148 016 v16 if it is an NSEI TLV.

(The only thing that I don't yet understand is that section 8, as well as section 9 and 10 begin with

This sub-clause is not applicable to the Sub-Network Service protocol.

but from what I can tell, all those requirements are used for SNS messages and procedures as well (if that wasn't the case, then the spec would be missing general information about the SNS protocol...).)

Every SNS endpoint is either IPv4 or IPv6. I would guess our ttcn3 test only doing IPv4 tests atm.
I would implement 2 test cases here. One for IPv4 if SGSN listen on IPv6 and one for IPv6 when SGSN listen on IPv4. You can check which one should be execute and skip the other one.

This is what I tried here (except for not splitting it up in two testcases):

    /* Send IP4 endpoints when IP6 is configured and vice versa, in effect sending an unsupported type of NS-VC endpoints. */
    if (g_nsconfig.nsvc[0].provider.ip.address_family == AF_INET) {
        ts_base_SNS_SIZE_configured.pDU_SNS_Size.numberOfIP6_Endpoints :=
            {iEI := int2oct(enum2int(mp_ns_iei_num_ipv6_ep), 1), numberOfIP_Endpoints := int2oct(NUM_IP, 2)};
        cause := NS_CAUSE_INVALID_NR_OF_IPv6_ENDPOINTS;
    } else {
        ts_base_SNS_SIZE_configured.pDU_SNS_Size.numberOfIP4_Endpoints :=
            {iEI := int2oct(enum2int(mp_ns_iei_num_ipv4_ep), 1), numberOfIP_Endpoints := int2oct(NUM_IP, 2)};
        cause := NS_CAUSE_INVALID_NR_OF_IPv4_ENDPOINTS;
    }
    f_send_expect(IDX, ts_base_SNS_SIZE_configured, cause);

Maybe you can help me understand where my mistake is (I didn't get any errors).

E.g. your PCU has 2 NS binds. Your SGSN has also 2 NS binds (a bind is a ip/udp pair). So we need at least a num_nsvc of 4 to support this configuration.
The num_nsvc is a value to limit the resources on the BSS side. For us we don't care so much if it's 10 or 20. But there must be a limit. (I don't recall but I think it's an arbitrary number in our case).

Yes that's what I understood, but then the test shouldn't fail (?) If I try to send an SNS Size with 3 as the number of max. NS-VCs and the given bind config, I should get back a cause IE with cause code "Invalid number of NS-VCs" (TS 148 016 v16 6.2.4.1:)

If the maximum number of NS-VCs indicated in the SNS-SIZE PDU is less than the number of NS-VCs required for
full mesh connectivity between the peer NSEs, the SGSN shall send an SNS-SIZE-ACK PDU with a cause code
"Invalid number of NS-VCs"