Project

General

Profile

Actions

Bug #6383

closed

pysim shell: edit_decoded EF.ePDGId is missing the epdg address

Added by lynxis about 1 month ago. Updated about 1 month ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
03/01/2024
Due date:
% Done:

0%

Spec Reference:

Description

I'm trying to edit the EF.ePDGId:

select ADF.USIM
select EF.ePDGId
edit_binary_decoded
# before edit, because file is "empty" 
change to
{
    "e_pdg_id": {
        "type_of_ePDG_address": 255,
        "ePDG_address": null
    }
}

{
    "e_pdg_id": {
        "type_of_ePDG_address": 0,
        "ePDG_address": "epdg.osmocom.org" 
    }
}

Results into 800100.
The domain is completely missing.

Actions #1

Updated by fixeria about 1 month ago

lynxis can you try the following?

{
    "e_pdg_id": {
        "type_of_ePDG_address": "FQDN", // <<---
        "ePDG_address": "epdg.osmocom.org" 
    }
}

I think I also faced this limitation of trying to pass a value instead of an enum string.

Actions #2

Updated by fixeria about 1 month ago

Correction (edited): "FQDN" instead of "IPv4", of course.

Actions #3

Updated by fixeria about 1 month ago

With this patch (not a fix, just a proposal / RFC):

https://gerrit.osmocom.org/c/pysim/+/36140 [RFC] ePDGId: allow passing both string and int type values

you should be able to encode the FQDN either way: by passing "FQDN" or 0.

Actions #4

Updated by laforge about 1 month ago

  • Assignee set to laforge
Actions #5

Updated by laforge about 1 month ago

  • Status changed from New to Rejected

fixeria wrote in #note-3:

With this patch (not a fix, just a proposal / RFC): https://gerrit.osmocom.org/c/pysim/+/36140 you should be able to encode the FQDN either way: by passing "FQDN" or 0.

I really don't think this is the way to go. I think it's not worth the massive extra effort, both in modifying the code as well as generating test cases for it. Our promise is that whatever we generate during decode can be re-encoded. It's big enough a challenge to support that. Adding multiple different input formats just makes things a hell more complex, particularly as you can not simpyl do a decode -> reencode test, as the decode would always give you the string values.

I think the proper solution to this problem is to have good JSON examples as part of our user manual. Those could be auto-generated from test case input data that we [should] have for each file, anyway. See #6316

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)