Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-08T15:41:35ZOpen Source Mobile Communications
Redmine osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6396 (Feedback): add support for auth failu...https://osmocom.org/issues/63962024-03-08T15:41:35Zlynxis
<p>When a phone connects and the sim sequence numbers are out of sync, the authentication will fail<br />and the phone will additional supply Rand and Auts in the failure message.<br />Similar to the 3gpp rat.<br />The sgsn already has a test for this TC_attach_usim_resync.</p>
<p>To reproduce it with a real phone, you could decrease the sequence number in the hss. (AFAIR it is a sliding window, reducing the sequence number by 1 might not be enough).</p>
<pre>
UE - strongswan
<- Auth req
-> Auth failure (reason resync, auts, rand)
(HLR will update the sequence numbers)
<- Auth req
-> Auth succeed.
</pre> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6370 (In Progress): setup ims with kamailiohttps://osmocom.org/issues/63702024-02-20T19:53:27Zlynxis
<p>Setup kamailio as IMS to allow UEs to connect</p>
<p>PLMN: 901 / 70</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6366 (New): strongswan: test if gsup_client...https://osmocom.org/issues/63662024-02-17T01:05:48Zlynxis
<p>Can gsup requests pile up, when the gsup connection was dead when the sender tried to send a packet?</p>
<p>I've seen strongswan not always sending out requests after a reconnect situation.<br />As test case, let osmo-epdg crash or ignore a GSUP Send Auth Info Request.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6365 (New): strongswan: get the PDP type ou...https://osmocom.org/issues/63652024-02-17T00:03:41Zlynxis
<p>According to 33.402 / Section 8.2.2</p>
<blockquote>
<p>The UE sends the "Configuration Payload, Sec. associations, Traffic selectors, APN info" in the first IKE_Auth Request.</p>
</blockquote>
<p>Strongswan doesn't care. It only takes the APN and UE Identity from it. But nothing else.</p>
<p>1) Use a real phone to see the request and get the wireshark decode table<br />2) Find out when those information is available to collect it with the strongswan code (osmo-epdg plugin).<br />3) Send the correct type in SendAuthInfo and/or Location Update Request towards the osmo-epdg (erlang)</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6364 (In Progress): strongswan: gsup: remov...https://osmocom.org/issues/63642024-02-16T23:51:54Zlynxis
<p>Currently the strongswan only operates a single request via GSUP.<br />Remove this limitation and allow multiple requests in flight.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6363 (New): strongswan: Catch IKEv2 disconn...https://osmocom.org/issues/63632024-02-16T23:50:23Zlynxis
<p>When the IKEv2 SA got destroy we should<br />- inform osmo-epdg via GSUP (Msg: Purge MS Request)<br />- remove internal state</p>
<p>Use listener api ike_updown() + ike_rekey() to get notified about changes in the SA.<br />The python SWu-IKEv2 doesn't seem good enough to test this. Only ike_rekey() can be tested.</p>
<p>Reducing the timeout of the ike SA might help to provoke the code path.</p> OsmoDia2GSUP - Bug #6254 (In Progress): Reconnects of the ttcn3 aren't handledhttps://osmocom.org/issues/62542023-11-10T12:05:35Zlynxis
<p>When the mme drops the connection and tries to reconnect it doesn't work.<br />Same for ttcn3 tests</p> Cellular Network Infrastructure - Bug #6215 (New): Rebase open5gs pcrf_simple patches and submit ...https://osmocom.org/issues/62152023-10-09T10:31:09Zosmith
<p>Rebase the patches from this branch, that make mongodb optional and submit them upstream:<br /><a class="external" href="https://gitea.sysmocom.de/sysmocom/open5gs/src/branch/pcrf_simple">https://gitea.sysmocom.de/sysmocom/open5gs/src/branch/pcrf_simple</a></p> OsmoHNBGW - Bug #6158 (New): IMSI not shown in "show ue all"https://osmocom.org/issues/61582023-08-29T15:11:01Zsteviehs
<p>with OsmoHNBGW 1.4.1 (OsmoHNBGW)</p>
<pre>
show ue all
</pre>
<p>gives an empty IMSI:</p>
<pre>
UE IMSI "" context ID 27
</pre>
<p>according to <a class="user active" href="https://osmocom.org/users/1741">lynxis</a> this should not happen and I should file a bug with pcap attached.</p> OsmoDia2GSUP - Bug #6155 (Feedback): osmo_dia2gsup not setting Origin-State-Id Diameter AVP durin...https://osmocom.org/issues/61552023-08-28T17:20:03Zpespin
<p>The AVP is optional but it's nice to have in order to notify peers that the process was restarted.</p>
<p>See rfc6733.</p> OsmoHNBGW - Feature #6137 (New): ip.access Nano3Ghttps://osmocom.org/issues/61372023-08-16T06:54:15ZKira
<p>Hello,<br />I bought an ip.access nano3G S8 femtocell, but it turned out to be blocked (I can not connect via telnet, ssh and web interface). <br />Is there any way to unlock it? Or should I buy another cell for 3G?</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6091 (Feedback): osmo-epdg: Implement CEAI ...https://osmocom.org/issues/60912023-07-10T17:09:19Zlynxis
<p>Write all relevant parts to have a gsup server module which the strongswan can connect to it.</p> OsmoHLR - Bug #5889 (In Progress): subscriber data: send out correct PDP Infohttps://osmocom.org/issues/58892023-02-01T16:02:33Zlynxis
<p>The HLR is currently only sending out a single wildcard APN in the ISD.<br />A correct implementation would be:</p>
<p>- send out a APN with a specific value (which can't be the wildcard APN) with id 1. (default APN, every subscriber which is allowed to packet data must have a default APN)<br />- depending on the subscriber data, support multiple APNs including a wildcard APN.</p>
<p>Or as quick solution: send out the subscriber specific default APN and as second APN a wildcard.</p> OsmoSGSN - Bug #5880 (In Progress): User Manual sections 11.1.1-2 document non-existing (removed?...https://osmocom.org/issues/58802023-01-27T12:08:58Zfixeria
<p>This problem was reported by a user in the IRC:</p>
<pre>
18:55 < PJHarvy> i can't understand: in osmo sgsn manual we use:
18:55 < PJHarvy> encapsulation udp local-ip 127.0.0.1 1
18:55 < PJHarvy> encapsulation udp local-port 23000. but my version doesn't support this commands
</pre>
<p>The current <a class="external" href="https://downloads.osmocom.org/docs/latest/osmosgsn-usermanual.pdf">https://downloads.osmocom.org/docs/latest/osmosgsn-usermanual.pdf</a> indeed lists these commands, which do not exist.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #5861 (In Progress): extend charon with ...https://osmocom.org/issues/58612023-01-17T15:53:09Zlaforge
<p>right now there's a charon plugin for eap-aka. It uses a local CSV file for storage of K/OP values, and it assumes it can synchronously access that and use it to derive AUTN challenges. so basically it includes a mini-hss/hlr.</p>
<p>We need to modify/replace that with a system where we get an asynchronous request for authentication over some external interface (currently called CEAI in my diagram at <a class="wiki-page" href="https://osmocom.org/projects/osmo-epdg/wiki/EPDG_implementation_plan">EPDG_implementation_plan</a>), like a unix domain socket. Charon then needs to wait until whatever external application has obtained auth tuples, and proceed with EAP-AKA only once a tuple has been received.</p>
<p>This can be developed and tested independent of the actual ePDG by implementing a small stub program that for example reas key material from a local CSV file (again), or possibly even by asking osmo-hlr via GSUP (we do have all the related libraries in place for C and python, AFAIR). So the latter might actually be easier than the CSV approach, where again one needs to do key derviation etc.</p> Cellular Network Infrastructure - Feature #5771 (New): series of presentations about the invididu...https://osmocom.org/issues/57712022-11-14T19:25:57Zlaforge
<p>Most of the talks we ever gave on setting up and running the Osmocom CNI are ages old and hence relatively outdated.</p>
<p>Given the number of network elements and the relate complexity, I think we should consider doing a talk on each of them. The talk doesn't have to be of a particular length, so some network elements might have shorter or longer presentations.</p>
<p>Looking at the checklist below, we already have 14 items. Covering this in OsmoDevCall is not an option, it would take too long (14 months if no other topic would be covered in between). So it is going to be on a separate schedule.</p>
<p>I would consider each presentation should then be prominently linked from the redmine project page of each network element, next to the user manual.</p>
<p>We may of course still be publishing those via the OsmoDevCall "event" on media.ccc.de, so all videos are in one location.</p>
<p>I think every presentation should start with a quick picture at the overal diagram of netwokr elements, describe the surrounding elements and their interfaces to then look in detail at the specific element that ist he subject of the talk.</p>
It should cover
<ul>
<li>basic configuration to get it started / connected</li>
<li>VTY for state introspection ("ar alle connections up?", ...)</li>
<li>looking at logs / protocol traces</li>
<li>practical demo; looking at what happens in pcaps + logs for some basic transaction like LU, SMS, voice call.</li>
</ul> OsmoDia2GSUP - Feature #5758 (New): bring osmo_dia2gsup to production qualityhttps://osmocom.org/issues/57582022-11-09T21:44:36Zlaforge
<p>Bring the existing DIAMETER-to-GSUP converter osmo-gsup2dia from proof-of-concept to production quality (supporting all required messages and procedures for seamless 2G/4G mobility) in order to operate combined 2G/3G and 4G networks with a shared subscriber database (HLR/HSS)</p> OsmoDia2GSUP - Feature #5757 (Feedback): functional test suite for osmo_dia2gsuphttps://osmocom.org/issues/57572022-11-09T21:43:58Zlaforge
<p>The developed test coverage shall at least cover the successful (normal) and one failure (abnormal) case of each supported DIAMETER procedure. The converter shall pass all tests.</p> libosmocore - Bug #5716 (New): Replace dynamic (DEAD) NSE if we receive an NS_RESET from a confli...https://osmocom.org/issues/57162022-10-17T16:40:38Zdaniel
<p>If we allow dynamic ip.access-style NSEs then once created that NSE will exist forever. This can cause issues if one NSVC (identified by IP/port) is later reconfigured to use a different NSEI.</p>
<p>In that case BSS and SGSN will continuously disagree on the NSEI to use for the connection. This is desired in static configurations, but for dynamic NSEs if we receive an NS-RESET from the same IP/port with different NSEI/NSVCI we want to allow/use the new NSE.</p> OsmoDia2GSUP - Bug #5657 (Feedback): dia2gsup not (re-)connecting to HLR if osmo-hlr is downhttps://osmocom.org/issues/56572022-08-22T15:42:57Zdaniel
<p>It seems sometimes osmo_dia2gsup doesn't manage to connect to osmo-hlr:</p>
<pre>
root@sysmonitb:~# systemctl status osmo_dia2gsup
● osmo_dia2gsup.service - Osmocom DIAMETER to GSUP translator
Loaded: loaded (/lib/systemd/system/osmo_dia2gsup.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2022-08-22 14:57:42 UTC; 39min ago
Main PID: 254 (beam.smp)
Tasks: 23 (limit: 4642)
Memory: 55.7M
CPU: 4.710s
CGroup: /system.slice/osmo_dia2gsup.service
├─254 /usr/bin/osmo-dia2gsup -B -- -root /usr/lib/erlang -progname erl -- -home /var/lib/osmo_dia2gsup -- -boot no_dot_erlang -noshell -escript main osmo_dia2gsup -pz osm>
├─271 erl_child_setup 1024
├─454 inet_gethost 4
└─455 inet_gethost 4
Aug 22 14:57:42 sysmonitb systemd[1]: Starting Osmocom DIAMETER to GSUP translator...
Aug 22 14:57:42 sysmonitb systemd[1]: Started Osmocom DIAMETER to GSUP translator.
Aug 22 14:57:47 sysmonitb osmo-dia2gsup[254]: *DBG* ss7_routes got call flush_routes from <0.132.0>
Aug 22 14:57:47 sysmonitb osmo-dia2gsup[254]: *DBG* ss7_routes sent ok to <0.132.0>, new state {sr_state,ss7_routes}
Aug 22 14:57:48 sysmonitb osmo-dia2gsup[254]: 14:57:48.180 [info] Diameter HSS Application started on IP 127.0.0.8, sctp port 3868
Aug 22 14:57:48 sysmonitb osmo-dia2gsup[254]: 14:57:48.239 [info] Connecting to GSUP HLR on IP 127.0.0.1 port 4222
root@sysmonitb:~# systemctl status osmo-hlr
● osmo-hlr.service - Osmocom Home Location Register (OsmoHLR)
Loaded: loaded (/lib/systemd/system/osmo-hlr.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2022-08-22 15:02:28 UTC; 34min ago
Docs: https://osmocom.org/projects/osmo-hlr/wiki/OsmoHLR
Main PID: 532 (osmo-hlr)
Tasks: 1 (limit: 4642)
Memory: 5.1M
CPU: 176ms
CGroup: /system.slice/osmo-hlr.service
└─532 /usr/bin/osmo-hlr -c /etc/osmocom/osmo-hlr.cfg -l /var/lib/osmocom/hlr.db
Aug 22 15:02:28 sysmonitb systemd[1]: Started Osmocom Home Location Register (OsmoHLR).
Aug 22 15:02:29 sysmonitb osmo-hlr[532]: 20220822150229034 DMAIN NOTICE hlr starting (hlr.c:791)
Aug 22 15:02:29 sysmonitb osmo-hlr[532]: 20220822150229034 DDB NOTICE using database: /var/lib/osmocom/hlr.db (db.c:558)
Aug 22 15:02:29 sysmonitb osmo-hlr[532]: 20220822150229053 DDB NOTICE Missing database tables detected; Bootstrapping database '/var/lib/osmocom/hlr.db' (db.c:626)
Aug 22 15:02:29 sysmonitb osmo-hlr[532]: 20220822150229097 DDB NOTICE Database '/var/lib/osmocom/hlr.db' has HLR DB schema version 6 (db.c:636)
Aug 22 15:02:29 sysmonitb osmo-hlr[532]: 20220822150229102 DLGLOBAL NOTICE Available via telnet 127.0.0.1 4258 (telnet_interface.c:100)
Aug 22 15:02:29 sysmonitb osmo-hlr[532]: 20220822150229102 DLCTRL NOTICE CTRL at 127.0.0.1 4259 (control_if.c:1013)
</pre>
<p>You can see that the hlr has been started after dia2gsup was already running.</p>
<p>After restarting dia2gsup manually the connection succeeds:<br /><pre>
root@sysmonitb:~# systemctl restart osmo_dia2gsup
root@sysmonitb:~# systemctl status osmo_dia2gsup
● osmo_dia2gsup.service - Osmocom DIAMETER to GSUP translator
Loaded: loaded (/lib/systemd/system/osmo_dia2gsup.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2022-08-22 15:37:21 UTC; 3s ago
Process: 4301 ExecStartPre=/usr/bin/mkdir -p /var/lib/osmo_dia2gsup (code=exited, status=0/SUCCESS)
Main PID: 4302 (beam.smp)
Tasks: 23 (limit: 4642)
Memory: 36.1M
CPU: 4.608s
CGroup: /system.slice/osmo_dia2gsup.service
├─4302 /usr/bin/osmo-dia2gsup -B -- -root /usr/lib/erlang -progname erl -- -home /var/lib/osmo_dia2gsup -- -boot no_dot_erlang -noshell -escript main osmo_dia2gsup -pz os>
├─4309 erl_child_setup 1024
├─4330 inet_gethost 4
└─4331 inet_gethost 4
Aug 22 15:37:24 sysmonitb osmo-dia2gsup[4302]: "00:00:00:00:00:00",
Aug 22 15:37:24 sysmonitb osmo-dia2gsup[4302]: "00:00:00:00:00:00",
Aug 22 15:37:24 sysmonitb osmo-dia2gsup[4302]: "HSS-00-00-00-00-00-00",false}
Aug 22 15:37:24 sysmonitb osmo-dia2gsup[4302]: 15:37:24.947 [info] connected!
Aug 22 15:37:24 sysmonitb osmo-dia2gsup[4302]: Registering handler {process_id,<0.147.0>} for socket #Port<0.7> Stream {osmo,
Aug 22 15:37:24 sysmonitb osmo-dia2gsup[4302]: 5}
Aug 22 15:37:24 sysmonitb osmo-dia2gsup[4302]: Unblocking socket #Port<0.7>
Aug 22 15:37:24 sysmonitb osmo-dia2gsup[4302]: Unblocking socket #Port<0.7>:ok
Aug 22 15:37:24 sysmonitb osmo-dia2gsup[4302]: Stream 254, 17 bytes
Aug 22 15:37:24 sysmonitb osmo-dia2gsup[4302]: Socket #Port<0.7> Stream 254: ID_GET -> ID_RESP
Aug 22 15:37:50 sysmonitb osmo-dia2gsup[4302]: 15:37:50.392 [info] Peer up <0.146.0> - #diameter_caps{origin_host={"hss.localdomain","mme.localdomain"},origin_realm={"localdomain","lo>
</pre></p> Core testing infrastructure - Bug #5632 (In Progress): better test result summary / notificationshttps://osmocom.org/issues/56322022-07-26T09:32:19Zlaforge
<pre>
10:55 < fixeria> regarding the testsuite monitoring in Jenkins...
11:19 < fixeria> not sure if you guys still use RSS/Atom, but this is a convinient way to monitor test
results
11:20 < fixeria> https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/rssFailed
11:21 < fixeria> this one is specifically for ttcn3-bts-test, but you can also monitor all TTCN-3 stuff
11:21 < fixeria> https://jenkins.osmocom.org/jenkins/view/TTCN3/rssFailed
11:23 < LaF0rge> fixeria: i did a quick look, but this just gives you the high level overview of which job
failed, right?
11:24 < LaF0rge> fixeria: what we'd want is down on the junit-xml level of granularity where we can track
that sudenyl TC_foo_bar inside a jenkins job is failing
11:29 < LaF0rge> stuff like
https://jenkins.osmocom.org/jenkins/job/ttcn3-bts-test/lastCompletedBuild/testReport/api/xml
11:29 < fixeria> LaF0rge: it simply says: N more tests failing, N less
11:29 < LaF0rge> fixeria: that cumulative count can be misleading if some old failures are passing but some
new failures are added.
11:29 < LaF0rge> lynxis: ^^
11:30 < LaF0rge> I think those testReport/api/xml URLs should cointain what we need
11:30 < LaF0rge> it even has the errorStackTrace with the verbose error message [if there is one]
11:31 < LaF0rge> and it has 'age' and 'failedSince' fields
</pre> libosmocore - Feature #5507 (New): Optimize reset time after SGSN is restartedhttps://osmocom.org/issues/55072022-03-31T12:06:35Zpespin
<p>scenario:<br />osmo-pcu <-> osmo-gbproxy <-> osmo-sgsn, using ip-sns.</p>
<p>SGSN is restarted. Gbproxy keeps testing its peers using NS_ALIVE and expecting NS_ALIVE_ACK. The PCU side keeps working fine. The SGSN, since it was restarted, answers back with NS_STATUS cause="PDU not compatible with the protocol state (0x0a)" and PDU IE containing the NS_ALIVE.</p>
<p>When receveing this, the gbproxy basically ignores it, and keeps retrying the NS_ALIVE procedure on the gbproxy<->sgsn side for "timer tns-alive 3" "timer tns-alive-retries 10" times (3GPP TS 48.016 sec 7.4b). Meanwhile, PCU sees the connection as if it was up (because gbproxy is still interacting on that part of the conn).</p>
<p>Finally the 3sec*10 time iteration is over and NS_RESET+NS_RESET_ACK, NS_UNBLOCK+NS_UNBLOCK_ACK, BVC_RESET+BVC_RESET_ACK is done.<br />After that, we see both gbproxy<->sgsn sending NS_ACTIVE+NS_ACTIVE_ACK one each other correctly.</p>
<p>Now, the point here is that this reset procedure takes unnecessarily long (3*10 secs), which it could be done almost immediatelly, since the gbproxy can detect something is wrong with the SGSN when it receives the first NS_STATUS containing the NS_ALIVE.</p>
<p>The SGSN, upon receiving NS_STATUS with cause="PDU not compatible with the protocol state (0x0a)" and containing NS_ALIVE PDU, should trigger immediatelly the RESET procedure, instead of waiting for 3*10 secs.</p>
<p>This can probably implemented in the ns2 library in libosmocore?</p> SIMtrace 2 - Bug #5415 (New): cardem: watchdog triggers firmware resethttps://osmocom.org/issues/54152022-01-24T15:18:49Zlynxis
<p>While testing the cardem firmware on a owhw board with a script, the watchdog resets the board from time to time (2-4 times while doing 50 test runs).<br />When the watchdog triggers, the userspace application also exits because the USB transfer errors with a stall (bulk transfer).</p>
<p>bootloader version: 87f8de15 (based on ea9a91f5c)<br />app: 87f8de15 (based on ea9a91f5c)<br />I've pushed this version to lynxis/wip.</p>
<p>The test look like this pseudo c code<br /><pre>
for(i=0; i<50; i++) {
reset_modem();
for (j=0; j<5; j++) {
if (get_imsi() == 0)
break;
}
}
</pre></p> libosmocore - Bug #5277 (New): ns2: Allow SNS-CONFIG PDUs from unknown endpoints during config pr...https://osmocom.org/issues/52772021-10-22T14:28:37Zdaniel
<p>Currently the SNS code expects SNS-CONFIG to happen between the primary EPs configured in the VTY.</p>
<p>NS2 with the following configuration<br /><pre>
ns
bind udp sgsn
listen 10.0.0.2 2157
nse 1
ip-sns-remote 10.0.0.1 2157
ip-sns-bind sgsn
</pre><br />would only handle SNS-CONFIG PDUs from the SGSN that originate from 10.0.0.1:2157</p>
<p>However, 3GPP TS 48.016 Ch. 6.2.5 states:</p>
<blockquote>
<p>After completion on the BSS side of the Size procedure having indicated a reset, the BSS NSE shall send an SNS-CONFIG PDU to the same pre-configured SGSN IP endpoint used in the Size procedure.</p>
<p>NOTE: This does not imply that the SNS-CONFIG PDU has to be sent from the same IP endpoint used in the Size procedure</p>
</blockquote>
<p>This also seems to apply to the SNS-CONFIG PDU sent from the SGSN to the BSS because some SGSNs send the SNS-CONFIG PDU alreads from the EP that is specified in that same PDU.<br />So it seems we need to relax our requirements and accept SNS-CONFIG PDUs from any source address as long as there exists an NSE with the NSEI specified in that PDU (on the bind that received the message).</p> OsmoHNBGW - Bug #5230 (In Progress): hnbgw fails to connect to the sgsnhttps://osmocom.org/issues/52302021-09-07T16:08:36Zlynxis
<p>On the event gsm setup I've noticed that sometimes the packets doesn't flow between the daemons even all are up.<br />I would guess it's a stale connection or a wrong routing.</p>
<p>It's a full setup with osmo-bsc/msc/sgsn/hnbgw (+ the other non stp services).<br />I restart a daemon and the data doesn't flow even the daemon is reconnecting.</p>
<p>My current failure is with a nano3g <> hnbgw <> stp <> sgsn.<br />While the CS path to the msc works.</p>
<p>The UE is sending a GPRS-ATTACH-REQ which correlates to the following osmo-hnbgw failure message:</p>
<pre>
Sep 07 17:48:57 rc3-gsm osmo-hnbgw[9345]: 20210907174857511 DLSCCP ERROR Received unknown conn-id 1002 for primitive N-DATA.request (sccp_scoc.c:1758)
[...] for every Attach Request 1
</pre>
<p>I've noticed this bug from time to time while working with the event setup. I could image a bug in the sccp or stp.</p> libosmocore - Bug #5208 (Feedback): ns2: add testcase for SNS Size with invalid tlvhttps://osmocom.org/issues/52082021-08-06T16:52:55ZlynxisOsmoPCU - Bug #4845 (Feedback): only send content resolution if it's neededhttps://osmocom.org/issues/48452020-11-04T02:26:20Zlynxis
<p>The PCU is always sending the TLLI in the RLC/MAC even when the content resolution is over.<br />This would save some 32 bits per RLC/MAC</p> OsmoPCU - Bug #4844 (Feedback): do not resent DL assignment on RACHhttps://osmocom.org/issues/48442020-11-04T02:24:20Zlynxis
<p>When a MS wants to send data without a TBF present,<br />it sends a RACH, get's an immediate assign, moves over to the PDCH and receives a UL assignment.</p>
<p>However if the MS misses either the immediate assign or the UL assignment, the PCU tries to assign using the TLLI 0x0, which seems to be wrong.<br />The PCU uses TLLI 0x0, even it can't know the TLLI of the MS. It only knows it by the first UL data.</p>
<pre>
MS PCU
RACH ->
X- IMM assign (MS never receive IMM assign)
---- PCU have a UL timeout and doesn't know the TLLI
<- UL TBF Assignment TLLI for 0x0000000.
</pre> OsmoSGSN - Bug #4605 (New): GMM_ATTACH_REQ_FSM: Event E_AUTH_RESP_RECV_SUCCESS not permittedhttps://osmocom.org/issues/46052020-06-08T19:05:08Zlaforge
<p>I'm seeing quite a bit of these and don't think that's right.</p>
<pre>
<0002> gprs_gmm.c:647 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x56242275e5e0]{Init}: Event E_AUTH_RESP_RECV_SUCCESS not permitted
<0002> gprs_gmm.c:1354 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x56242275e5e0]{Init}: Event E_ATTACH_COMPLETE_RECV not permitted
<0002> gprs_gmm.c:647 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x5624227600a0]{Init}: Event E_AUTH_RESP_RECV_SUCCESS not permitted
<0002> gprs_gmm.c:1354 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x5624227600a0]{Init}: Event E_ATTACH_COMPLETE_RECV not permitted
<0002> gprs_gmm.c:647 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x562422762bc0]{Init}: Event E_AUTH_RESP_RECV_SUCCESS not permitted
<0002> gprs_gmm.c:1354 GMM_ATTACH_REQ_FSM(gb_gmm_req)[0x562422762bc0]{Init}: Event E_ATTACH_COMPLETE_RECV not permitted
</pre>
<p>any idas?</p> OsmoSGSN - Bug #2955 (New): No GMM ATTACH REJECT on GSUP UpdateLocation Errorhttps://osmocom.org/issues/29552018-02-17T08:30:59Zlaforge
<p>When the HLR responds with a UpdateLocation Error during AttachRequest processing, OsmoSGSN doesn't send the expected GMM ATTACH REJECT to the MS:</p>
<pre>
Sat Feb 17 09:28:05 2018 DLLC <0012> gprs_llc.c:526 LLC RX: unknown TLLI 0xd5390b4c, creating LLME on the fly
Sat Feb 17 09:28:05 2018 DLLC <0012> gprs_llc_parse.c:81 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x24bf94 CMD=UI DATA
Sat Feb 17 09:28:05 2018 DMM <0002> gprs_gmm.c:1271 MM(---/ffffffff) -> GMM ATTACH REQUEST MI(262420000000006) type="GPRS attach"
Sat Feb 17 09:28:05 2018 DMM <0002> gprs_sgsn.c:237 MM(/00000000) Allocated with GEA0 cipher.
Sat Feb 17 09:28:05 2018 DLGLOBAL <001d> rate_ctr.c:218 counter group 'sgsn:mmctx' already exists for index 0, instead using index 2. This is a software bug that needs fixing.
Sat Feb 17 09:28:05 2018 DMM <0002> gprs_gmm.c:556 MM(262420000000006/d724f6f6) <- GPRS IDENTITY REQUEST: mi_type=IMEI
Sat Feb 17 09:28:05 2018 DLLC <0012> gprs_llc_parse.c:81 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x612fca CMD=UI DATA
Sat Feb 17 09:28:05 2018 DMM <0002> gprs_gmm.c:1194 MM(262420000000006/d724f6f6) -> GMM IDENTITY RESPONSE: MI(IMEI)=499990000000006
Sat Feb 17 09:28:05 2018 DMM <0002> sgsn_auth.c:160 MM(262420000000006/d724f6f6) Requesting authorization
Sat Feb 17 09:28:05 2018 DMM <0002> sgsn_auth.c:185 MM(262420000000006/d724f6f6) Requesting authentication tuples
Sat Feb 17 09:28:05 2018 DMM <0002> gprs_subscriber.c:894 MM(262420000000006/d724f6f6) Requesting subscriber authentication info
Sat Feb 17 09:28:05 2018 DMM <0002> gprs_sgsn.c:726 MM(262420000000006/d724f6f6) Subscriber data update
Sat Feb 17 09:28:05 2018 DMM <0002> sgsn_auth.c:219 MM(262420000000006/d724f6f6) Updating authorization (unknown -> authenticate)
Sat Feb 17 09:28:05 2018 DMM <0002> sgsn_auth.c:248 MM(262420000000006/d724f6f6) Got authorization update: state unknown -> authenticate
Sat Feb 17 09:28:05 2018 DMM <0002> gprs_gmm.c:591 MM(262420000000006/d724f6f6) <- GPRS AUTH AND CIPHERING REQ (rand = ba fd 0b 20 23 9b 1b c5 be 69 09 8c 8e d2 c6 e8 )
Sat Feb 17 09:28:05 2018 DLLC <0012> gprs_llc_parse.c:81 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0xeb6e08 CMD=UI DATA
Sat Feb 17 09:28:05 2018 DMM <0002> gprs_gmm.c:731 MM(262420000000006/d724f6f6) -> GPRS AUTH AND CIPH RESPONSE
Sat Feb 17 09:28:05 2018 DMM <0002> gprs_gmm.c:778 MM(262420000000006/d724f6f6) checking auth: received GSM SRES = 4f 30 2f 17
Sat Feb 17 09:28:05 2018 DMM <0002> sgsn_auth.c:160 MM(262420000000006/d724f6f6) Requesting authorization
Sat Feb 17 09:28:05 2018 DMM <0002> sgsn_auth.c:196 MM(262420000000006/d724f6f6) Missing information, requesting subscriber data
Sat Feb 17 09:28:05 2018 DMM <0002> gprs_subscriber.c:869 MM(262420000000006/d724f6f6) Requesting subscriber data update
Sat Feb 17 09:28:05 2018 DGPRS <000f> gprs_subscriber.c:539 SUBSCR(262420000000006) GPRS update location failed, GMM cause = 'Network failure' (17)
Sat Feb 17 09:28:05 2018 DMM <0002> gprs_sgsn.c:726 MM(262420000000006/d724f6f6) Subscriber data update
Sat Feb 17 09:28:05 2018 DMM <0002> sgsn_auth.c:219 MM(262420000000006/d724f6f6) Updating authorization (authenticate -> authenticate)
Sat Feb 17 09:28:35 2018 DLINP <001f> input/ipa.c:67 connection closed with server
Sat Feb 17 09:28:45 2018 DLGSUP <0027> gsup_client.c:76 GSUP connecting to 127.0.0.1:4222
</pre>
<p>I've created <code>SGSN_Tests.TC_attach_gsup_lu_reject</code> for this.</p>