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> 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> 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> OsmoBTS - Bug #5895 (New): LC15: Audio Quality Problem sometime after cf7a7fcebf625a14fd764355c3b...https://osmocom.org/issues/58952023-02-07T03:11:09Zkeith
<p>Writing this up now while it's a bit fresh...</p>
<p>I have spent the last 12 hours or so working with people on site to try to track down these problems:</p>
<p>Fierce complaints about audio quality (no audio, unintelligible, intermittent, chopped)</p>
<p>Observation of a lot of very variable Q in meas reps, especially on downlink (associated with bad audio) and more pronounced when the call B-leg was using another codec such as G.729 on the other side of the PBX, - in fact not transcoding at site and sending AMR to our data centre and trancoding there to PCMA/U for the upstream VoIP was giving better results most of the time.</p>
<p>However, today I discovered the extent of how bad this was on local MS to MS calls.</p>
<p>After exhausting everything I could think of, we went back to the timeline and there were some opinions that this started around a date last year which seemed to be around the time I changed this site away from osmo-nitb. Given I wasn't seeing any signalling problems, I had been looking for problems with maybe the MGW or something with RTP that would have changed. but I could find nothing.</p>
<p>Of course none of that was at fault, what happened was that along with the move to osmo-bsc, I built v1.4.0 of osmo-bts - I think not 1.5.0 because at the time 1.4.0 built against the libs I had on the BTS, anyway, going back to the binary I had built before from cf7a7fce "solves" the problem.</p>
<p>Given the current somewhat tense situation I don't envisage "test"-ing anything at this site for the time being so I can't exactly try to dissect between cf7a7fce and 1.4.0 not that it would be very easy to run each commit against a bunch of manual tests that annoy the local people, asking them to make calls to each other.</p>
<p>So what to do? Well note it at least. I don't have another lc15 to test on. <br />Maybe shout-out to the main devs who committed code that touched lc15 or common, (which seems to have to do with power control, interference measurements) to see if they have any ideas. My feeling is that something that was done is not happy on the LC15 PHY.</p>
<p>There's the chance that this was fixed since 1.4.0 or in another lib.</p>
<p><em>Trivia: cf7a7fce is the last commit that can do RSL/OML bring-up against osmo-nitb.. that's why that one.</em></p> OsmoHLR - Feature #5865 (New): Automate selection of LU Reject Causehttps://osmocom.org/issues/58652023-01-20T13:59:07Zkeith
<p>There is some suggestion in <a class="external" href="https://gerrit.osmocom.org/c/osmo-hlr/+/16808">https://gerrit.osmocom.org/c/osmo-hlr/+/16808</a> that osmo-hlr could use some criteria to decide what cause/reason to send to the GSUP client when rejecting a Location/Routing Update</p>
<p>Possibly, sending "IMSI Unknown in HLR" is wrong when the SIM is foreign to our network.</p>
<p>We could have a regex config option to let osmo-hlr know what is "our" SIM or not. Or maybe a GSUP client like osmo-msc can comunicate MNC-MCC info from the MSC network config over GSUP? I'm not familiar with GSUP.</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> 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> 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> 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> OsmoGGSN (former OpenGGSN) - Bug #5241 (Feedback): GTP: Malformed Packet pdp ctx response.https://osmocom.org/issues/52412021-09-29T20:09:33Zkeith
<p>I have some Alcatel 1066G feature phones.</p>
<p>I notice they do have a "browser" and they are Class 12 devices.</p>
<p>I don't see any IP traffic from them though, when using the browser.</p>
<p>Wireshark notes a "Malformed Packet" in the create pdp ctx response, however this only happens with GTP version 1.</p>
<p>(Wireshark can't parse the QoS IE, even though it is the same IE as the one in the pdp ctx request)</p>
<ul>
<li>These phones do have some strange behaviour - for example:</li>
<li>When choosing the "Network Account" (APN) to use for the browser, it doesn't always respect what you set, even after power cycle.</li>
<li>It doesn't always delete the PDP context on shutdown.</li>
<li>The APN profiles have an option for IP v4/v6/both, but it doesn't respect it and always asks for IPv4v6</li>
</ul>
<p>Maybe some of the above behaviour may be due to error from the network?<br />I don't care about getting data working on this device, but maybe it's pointing out a bug in libgtp to us?</p>
<p>THe main difference I can see in the pdp ctx requests/response with this and other phones is the length, with this alcatel QoS IE length is 11, with others it is 14.</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 #5179 (New): gprs_ns2: use refcounting for the NSEhttps://osmocom.org/issues/51792021-06-13T02:24:42Zlynxis
<p>A NSE could be freed by the application on multiple events.<br />However there are certain cases when multiple events are emitted which will result in a use-after-free when called in the wrong order.</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 #4604 (New): Lots of "Unusual event"https://osmocom.org/issues/46042020-06-08T19:00:32ZlaforgeOsmoSGSN - Bug #4601 (Feedback): gmm_fsm{Registered.SUSPENDED}: Event E_GMM_COMMON_PROC_INIT_REQ ...https://osmocom.org/issues/46012020-06-08T18:11:06Zlaforge
<p>When using OsmoSGSN (current nightly) in a setup with 3rd party 2G BSS and 3G RAN, we are running quite often into the following log error message:</p>
<pre>
<0002> gprs_gmm.c:1099 GMM(gmm_fsm)[0x558767ce3c50]{Registered.SUSPENDED}: Event E_GMM_COMMON_PROC_INIT_REQ not permitted
</pre>
<p>but also</p>
<pre>
<0002> gprs_gmm.c:1762 GMM(gmm_fsm)[0x558767ce3c50]{Registered.SUSPENDED}: Event E_GMM_COMMON_PROC_SUCCESS not permitted
</pre>
<p>any ideas?</p> OsmoSGSN - Bug #4600 (Feedback): gmm_fsm{CommonProcedureInitiated}: Event E_GMM_COMMON_PROC_INIT_...https://osmocom.org/issues/46002020-06-08T18:08:16Zlaforge
<p>When using OsmoSGSN (current nightly) in a setup with 3rd party 2G BSS and 3G RAN, we are running quite often into the following log error message:</p>
<pre>
<0002> gprs_gmm.c:1877 GMM(gmm_fsm)[0x558767ce3c50]{CommonProcedureInitiated}: Event E_GMM_COMMON_PROC_INIT_REQ not permitted
</pre>
<p>the bearer at the time of this message seems to be Iu (as far as I can tell so far).</p> OsmoSGSN - Bug #4599 (New): counter group sgsn:pdpctx already exists for index X, instead using Yhttps://osmocom.org/issues/45992020-06-08T18:05:33Zlaforge
<p>When using OsmoSGSN (current nightly) in a setup with 3rd party 2G BSS and 3G RAN, we are running quite often into the following error message:</p>
<pre>
<0020> rate_ctr.c:224 counter group 'sgsn:pdpctx' already exists for index 5, instead using index 8. This is a software bug that needs fixing.
</pre>
<p>I wonder how this happens. It basically means we want to allocate a PDP context for the same NSAPI where we already have a PDP context.</p>
<p>The only path that calls sgsn_pdp_ctx_alloc() is sgsn_create_pdp_ctx() via activate_ggsn() originating from do_act_pdp_req() and the latter actually chekcs if we already have a PDP context fro the NSAPI in sgsn_pdp_ctx_by_nsapi. weird.</p>
<p><a class="user active" href="https://osmocom.org/users/1741">lynxis</a> any ideas?</p> osmo-gbproxy - Feature #4520 (In Progress): gbproxy: Redundancy between NS-VCs (BSS Side)https://osmocom.org/issues/45202020-05-01T13:37:47Zlaforge
<p>Each osmo-gbproxy is interconnected via several E1 lines to the BSS.</p>
<p>The normal Gb interface load distribution functions must ensure that traffic is transparently passed only over those NS-VCs that are marked as UNBLOCKED, ALIVE.</p> Cellular Network Infrastructure - Bug #4141 (New): No osmux specific code in place during codec n...https://osmocom.org/issues/41412019-08-05T15:57:19Zpespin
<p>Current code in OsmoBSC and OsmoMSC doesn't take into account that Osmux is to be used when codec negotiation goes one. That means that supported codec list needs to be correctly configured manually in VTY in order to avoid selecting incorrect codecs (like non-AMR). Moreover if an MS doesn't support AMR, since we don't have transcoding yet, the call cannot take place.</p>
<p>Different scenarios need to be listed here and think about what we want to do in each case.</p> Cellular Network Infrastructure - Bug #3567 (New): coverity: move the secret token out of $HOME/o...https://osmocom.org/issues/35672018-09-18T15:34:10Zlynxis
<p>When the token has been moved, the jenkins Coverity job is independent from the static path $HOME/osmo-ci.</p> Cellular Network Infrastructure - Feature #3229 (New): build-system: jenkins.sh: Improve debian ...https://osmocom.org/issues/32292018-05-03T12:40:28Zpespin
<p>The idea is to add extra tests/checks to avoid breaking debian package building during nightly builds in OBS. Instead, let's catch it during gerrit patch submission time and don't allow merging it until it's fixed.</p>
<p>We should investigate several tools, like pbuilder, dpkg-build, etc. I recall lynxis also told me something about some kind of lint tool available for this purposes.</p> Cellular Network Infrastructure - Feature #3142 (New): Further simplification of "NITB like" setupshttps://osmocom.org/issues/31422018-04-05T20:09:38Zlaforge
<p>Running the post-NITB network is quite a lot more complex than the old code.</p>
<p>There are some ideas on how to make it simpler to run small, self-contained networks while removing some complexity</p>
<ul>
<li>I was also wondering if we should spend time on "MGW-less operation". In theory, you only need OsmoMGW if you have no IP-level routing between your Abis / A / core network [like any decent network operator for security reasons]. But then, if you run everything on one machine, and don't need/want transcoding, and have transparent routing between all components, we could do without the MGW.</li>
</ul>
<ul>
<li>stp-less operation should also be possible (but make configuration actually more complicated), as both the "ASP" (client) and "SG" (server) role are inside libosmo-sigtran, and hence the server could run inside the MSC without the need of an external stp (osmo-stp is just a thin wrapper with vty around libosmo-sigtran)</li>
</ul>
<p>Let's keep this as a reminder and create sub-tasks as ideas materialize more</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> OsmoMSC - Bug #2933 (New): change of trans->bearer_cap (e.g. via MNCC) will not trigger BSSMAP AS...https://osmocom.org/issues/29332018-02-12T11:36:39Zlaforge
<p>Whenever the trans->bearer_cap change (e.g.due to a CC MODIFY or MNCC MODIFY), the MSC must chck if the new bearer capabilities are different from the old bearer capabilities, and subsequently trigger a BSSMAP ASSIGNMENT towards the BSS.</p>
<p>Currently, the handling of bearer_cap will in only work if the related CC/MNCC message with <br />besrer_cap IE happens before the pint in time at which the MSC performs the BSSMAP ASSIGNMENT<br />procedure. Our logic still needs to change in a way that the CC/MNCC <br />code in gsm_04_08.c detects if trans->bearer_cap != new bearer_cap, and<br />in that case triggers a new follow-up BSSMAP ASSIGNMENT.</p> OsmoBSC - Feature #1946 (New): Add checks to the BSC VTY to prevent configurations known to not workhttps://osmocom.org/issues/19462017-02-08T23:41:53Zneelsnhofmeyr@sysmocom.de
<p>e.g. running TCH/F_TCH/H_PDCH timeslots on a nanobts doesn't work,<br />similarly, the BS11 should reject any codec except HRv1, FR and EFR (i.e. no AMR),<br />and so on.</p> Cellular Network Infrastructure - Bug #1612 (New): more configuration consistency checkinghttps://osmocom.org/issues/16122016-02-23T16:22:14Zlaforge
<p>Right now it is possible to configure various things that wouldn't work, like an ARFCN that is outside the band of the BTS, or even the TRX.</p>
<p>More consistency checks would make sense, together with reasonable error messages.</p> OsmoBTS - Feature #1576 (New): consider using hLayer2 as a pointer storagehttps://osmocom.org/issues/15762016-02-23T15:38:30Zlaforge
<p>This would speed up the l1if_hLayer_to_lchan lookup. Not sure if it's worth the extra risk.</p>