Cellular Network Infrastructure » Radio Access Network » OsmoBTS

Hello pespin,

two points I'd like to have some feedback on:

1. Which component/config combinations do I need to start in order to reproduce this scenario? (Any commands to trigger the queue buildup?)

Here are the commands I ran and some output:

osmocom-bb/src/target/trx_toolkit$ ./fake_trx.py -R 127.0.0.1

osmo-bsc$ ./src/osmo-bsc/osmo-bsc -c doc/examples/osmo-bsc/osmo-bsc-4trx.cfg

<0022> ../../src/m3ua.c:508 XUA_AS(as-clnt-A-0-m3ua)[0x612000010d20]{AS_DOWN}: Event AS-TRANSFER.req not permitted

osmo-pcu$ ./src/osmo-pcu -c ./doc/examples/osmo-pcu.cfg

<0001> osmobts_sock.c:238 osmo-bts PCU socket /tmp/pcu_bts has been connected
<0001> pcu_l1_if.cpp:1119 Received message for new BTS0
<0001> pcu_l1_if.cpp:732 BTS not available

osmo-bts$ ./src/osmo-bts-trx/osmo-bts-trx -c ./doc/examples/trx/osmo-bts-trx.cfg

<0012> ../../src/input/ipaccess.c:1098 enabling ipaccess BTS mode, OML connecting to 192.168.122.1:3002
<000b> trx_if.c:1266 phy0.0: Opening TRXC/TRXD connections
<0009> pcu_sock.c:1191 PCU socket connected to external PCU
<0001> oml.c:90 OC=GPRS-CELL INST=(00,ff,ff): Sending PCU version report to BSC: 1.2.0.1-d8ce
<0001> oml.c:90 OC=GPRS-CELL INST=(00,ff,ff): Sending PCU version report to BSC: 1.2.0.1-d8ce
<0001> oml.c:90 OC=GPRS-CELL INST=(00,ff,ff): Sending PCU version report to BSC: 1.2.0.1-d8ce
...

Seems like the BTS doesn't advertise itself as available for whatever reason. I'm not sure what's going on/if that means anything for this testcase etc., would appreciate some help with setting up the case referred to in the issue description, plus the approximate amount of time (i.e. magnitude) it took to build up that RAM usage.

2. Current approach

I thought I'd ask before coding away in this case... especially since I haven't yet been able to reproduce the error and am currently going on what I've read in the code/here.

This is what I'm thinking of doing (more of a rough sketch with possible errors than a solution):

• make member upqueue of struct pcu_sock_state a struct osmo_wqueue, set the maximum size of the queue/make it configurable
• set the read/write callbacks for the wqueue (the logic for that probably already exists and I'll just have to put it in a callback function... it'll probably be a function quite similar to pcu_sock_send())
• adapt queueing/dequeueing in the code to reflect that change in data type and by adapting the fd setup in the PCU socket code of the BTS
• if enqueuing fails with -ENOSPC, close the PCU socket

Please tell me if that is the right kind of approach or if I should be doing something else.

Hi pespin,

these are the configs. Took a short look and yes, it says gprs mode none.

Can you refer me to a working example of the components needed for this test configured with gprs enabled (and then what to do for the allocations to build up?)

Thank you

I have just uploaded two patches (one with the fix, the other with the config stuff separate):

Main fix:
https://gerrit.osmocom.org/c/osmo-bts/+/31533

Config/vty:
https://gerrit.osmocom.org/c/osmo-bts/+/31534

The memleak on PCU pause via gdb was gone, didn't observe any other memory building up either on open-bts-trx in the described case.

dexter can you probably give a try to this to see if the queueing is working fine? I believe you are the only one with an RBS setup right now? The patch is merged, so it's probablyu only about a quick test with osmo-bsc master.