pespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/35628?usp=email )
Change subject: gsup: Convert PDP-Type IE to PDP-Address IE
......................................................................
gsup: Convert PDP-Type IE to PDP-Address IE
The previous PDP-Type IE should have been a PDP-Address from the
start, since having only PDP-Type with no address is only a specific
case (dynamic addressing).
This becomes clear by looking at other similar protocols like:
* MAP: APN-Configuration IE has servedPartyIP-IP{v4,v6}-Address IEs
* Diameter S6b, 3GPP TS 29.272 7.3.35 APN-Configuration contains
Served-Party-IP-Address AVPs
* Diameter SWx, 3GPP TS 29.273 APN-Configuration.
* GTPv1C Ts 29.060 7.7.29 PDP Context containing PDP Address.
Since PDP-Type on its own really makes no sense, being it a special case
of PDP-Address, let's keep the IE by renaming it (keeping old name too
for API backward compat) and extend it to support lengths > 2 bytes.
Old implementation of libosmogsm gsup actually ignored lengths > 2
bytes, so we are safe acting against older implementations here, both
on the sending and receiving side on the wire.
While at it, fix the packetdiag representation, which was already wrong
before:
* Length is 1 byte, not 2 (this happened probably due to confusion
between TS 29.060 EUA and TS 24.008 PDP address, the former TLV being
2 bytes like all of GTP, and TS 24.008 being 1 byte).
* The bytes sharing several fields were swapped.
Change-Id: Ifb4e44b23d19ea049f03a3602c39f2471ff1bff4
Related: OS#6091
Related: libosmocore.git Change-Id I775ff9c3be165d9f30d6ab55d03f99b6104eadd6
---
M common/chapters/gsup.adoc
1 file changed, 56 insertions(+), 14 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-gsm-manuals refs/changes/28/35628/1
diff --git a/common/chapters/gsup.adoc b/common/chapters/gsup.adoc
index d9a87ca..eeada52 100644
--- a/common/chapters/gsup.adoc
+++ b/common/chapters/gsup.adoc
@@ -1105,7 +1105,7 @@
| |PDP Info IEI|<<gsup-iei>>|M|V|1
| |Length of PDP Info IE||M|V|1
|10|PDP Context ID|<<gsup-ie-pdpctxid>>|C|TLV|3
-|11|PDP Type|<<gsup-ie-pdptype>>|C|TLV|4
+|11|PDP Address|<<gsup-ie-pdpaddress>>|C|TLV|4-24
|12|Access Point Name|<<gsup-ie-apn>>|C|TLV|3-102
|13|Quality of Service|<<gsup-ie-qos>>|O|TLV|1-20
|14|PDP-Charging Characteristics|<<gsup-ie-charging>>|O|TLV|4
@@ -1113,11 +1113,14 @@
The conditional IE are mandantory unless mentioned otherwise.
-[[gsup-ie-pdptype]]
-==== PDP Type
+[[gsup-ie-pdpaddress]]
+==== PDP Address
-The PDP type value consists of 2 octets that are encoded like octet 4-5 of the
-End User Address (EUA) defined in 3GPP TS 29.060, 7.7.27.
+The value part is encoded like in the Packet data protocol address IE defined
+in 3GPP TS 24.008, Chapter 10.5.6.4.
+Hence this value also relates to End User Address (EUA) IE defined in 3GPP TS
+29.060, 7.7.27.
+The PDP type organization value must be set to 'IETF allocated address'.
[packetdiag]
----
@@ -1127,21 +1130,24 @@
0-6: PDP type IEI
7: Res
- 8-15: Length (2)
- 16-19: Spare
- 20-23: PDP type org
+ 8-15: Length
+ 16-19: PDP type org
+ 20-23: Spare
24-31: PDP type number
+ 32-191: Address (v4|v6|v4+v6)
}
----
-The spare bits are left undefined. While 29.060 defines them as '1 1 1 1', there
-are MAP traces where these bits are set to '0 0 0 0'. So the receiver shall
-ignore these bits.
+The spare bits are left undefined. While 3GPP TS 29.060 7.7.27 defines them as
+'1 1 1 1', there are MAP traces where these bits are set to '0 0 0 0'. So the
+receiver shall ignore these bits.
Examples:
-* IPv4: PDP type org: 1 (IETF), PDP type number: 0x21
-* IPv6: PDP type org: 1 (IETF), PDP type number: 0x57
+* IPv4: PDP type org: 1 (IETF), PDP type number: 0x21, 0 bytes address (dynamic addressing)
+* IPv4: PDP type org: 1 (IETF), PDP type number: 0x21, 4 bytes address
+* IPv6: PDP type org: 1 (IETF), PDP type number: 0x57, 16 bytes address
+* IPv6: PDP type org: 1 (IETF), PDP type number: 0x8D, 20 bytes address (v4+v6)
[[gsup-ie-pdpctxid]]
==== PDP Context ID
@@ -1296,7 +1302,7 @@
|0x09|HLR Number|<<gsup-ie-hlr>>
|0x0a|Message Class| <<gsup-ie-message-class>>
|0x10|PDP Context ID|<<gsup-ie-pdpctxid>>
-|0x11|PDP Type|<<gsup-ie-pdptype>>
+|0x11|PDP Address|<<gsup-ie-pdptaddress>>
|0x12|Access Point Name|<<gsup-ie-apn>>
|0x13|QoS|<<gsup-ie-qos>>
|0x14|PDP-Charging Characteristics|<<gsup-ie-charging>>
--
To view, visit https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/35628?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-gsm-manuals
Gerrit-Branch: master
Gerrit-Change-Id: Ifb4e44b23d19ea049f03a3602c39f2471ff1bff4
Gerrit-Change-Number: 35628
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: newchange
Hello Jenkins Builder,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/libosmocore/+/35624?usp=email
to look at the new patch set (#2).
The following approvals got outdated and were removed:
Verified+1 by Jenkins Builder
Change subject: gsup: Fail decoding if len of PDP Type IE is less than 2 bytes
......................................................................
gsup: Fail decoding if len of PDP Type IE is less than 2 bytes
As documented in gsup.adoc, this field is expected to be 2 bytes.
This is only a intermediate step to showcase the related test scenarios
submitting IE with len > 2. The logic will be changed in a follow-up
patch when changing the IE to also encode/decode the missing Address
part.
Change-Id: I0d024a9a4fb10beeff39ac33a9d2ed02f88f4580
---
M src/gsm/gsup.c
M tests/gsup/gsup_test.err
2 files changed, 19 insertions(+), 1 deletion(-)
git pull ssh://gerrit.osmocom.org:29418/libosmocore refs/changes/24/35624/2
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/35624?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: I0d024a9a4fb10beeff39ac33a9d2ed02f88f4580
Gerrit-Change-Number: 35624
Gerrit-PatchSet: 2
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-MessageType: newpatchset
Attention is currently required from: laforge, manawyrm, pespin, tnt.
jolly has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-e1d/+/34554?usp=email )
Change subject: Add option to automatically reset RIFO on underrun/overflow
......................................................................
Patch Set 5:
(3 comments)
File src/octoi/e1oip.c:
https://gerrit.osmocom.org/c/osmo-e1d/+/34554/comment/0535f333_57d548f7
PS4, Line 278: int32_t d = fn32+i - iline->e1t.rifo.next_out_fn;
> missing space between "fn32+i". […]
fixed the missing space
the wraparound is intended here (fn32 and netx_out_fn) are both 32 bits unsigned. the result is always the positive delay.
https://gerrit.osmocom.org/c/osmo-e1d/+/34554/comment/5f2d8b2d_c7a5a45a
PS4, Line 279: iline->e1t.delay += d;
> do you account for overflow/wrapround here?
the sum of delays (40000 measurements * maximum delay) is far below the range of 32 bits.
File src/octoi/frame_rifo.c:
https://gerrit.osmocom.org/c/osmo-e1d/+/34554/comment/aec8c2e8_9de892ad
PS4, Line 111: {
> wrong place for "{" char.
This is not part of my patch (see latest patchset).
--
To view, visit https://gerrit.osmocom.org/c/osmo-e1d/+/34554?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-e1d
Gerrit-Branch: master
Gerrit-Change-Id: Id7ccbfbdb288990c01f185dec79a1022a68b4748
Gerrit-Change-Number: 34554
Gerrit-PatchSet: 5
Gerrit-Owner: jolly <andreas(a)eversberg.eu>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: manawyrm <osmocom.account(a)tbspace.de>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: tnt <tnt(a)246tNt.com>
Gerrit-Attention: manawyrm <osmocom.account(a)tbspace.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: tnt <tnt(a)246tNt.com>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Fri, 19 Jan 2024 17:30:01 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: comment