laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-hnbgw/+/26795 )
Change subject: mgw_fsm: add MGW support to osmo-hnbgw ......................................................................
Patch Set 9:
(2 comments)
https://gerrit.osmocom.org/c/osmo-hnbgw/+/26795/7/src/osmo-hnbgw/hnbgw_cn.c File src/osmo-hnbgw/hnbgw_cn.c:
https://gerrit.osmocom.org/c/osmo-hnbgw/+/26795/7/src/osmo-hnbgw/hnbgw_cn.c@... PS7, Line 362: switch (((uint8_t *)msgb_l2(oph->msg))[1]) { why such a hack here and peek into the raw msgb without the use of the decoder? Why not simply decode the message first (at least the first level of decode into a RANAP_RANAP_PDU_t) and then check the procedure code?
If you want to go for this low-level-hackish approach, you need to be able to prove that there is no flexibility within the encoding rules that would permit a message to have e.g. a multi-byte RAB assignment type. I know that BER leaves a lot of flexibility to the sender, and you can format any integer any number of bytes wide, so the same value has any number of different encodings. APER is probably stricter, but have you studied the encoding rules?
https://gerrit.osmocom.org/c/osmo-hnbgw/+/26795/7/src/osmo-hnbgw/hnbgw_rua.c File src/osmo-hnbgw/hnbgw_rua.c:
https://gerrit.osmocom.org/c/osmo-hnbgw/+/26795/7/src/osmo-hnbgw/hnbgw_rua.c... PS7, Line 273: case RANAP_ProcedureCode_id_RAB_Assignment: likewise the same here.