This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
wangpalm palm.wang at hotmail.comThanks very much for your advice. I've done the pcap IP-catching, printed out flow-control information of openbsc, excluded the RF problem, and checked the layer3 singals with TEMS tools. Nothing abnormal was found.(Or maybe there was something, but I have not noticed). It just seems suddenly nothing is flowing in and out nanobts for a while. After all of that, I replaced the nanobts (software version: 168d502, aquired with ipaccess-find) with another nanobts (software version: 168a302). The data rate problem never appeared. However, I ran into another problem occasionally, which has not occurred before. After printing following logs, nanoBTS auto-restarts/reconnects with OpenBSC, and thus causes network interruption. ----- Logs ----Failure Event Report Type=processing failure Severity=warning level failure Probable cause= 03 00 01 Additional Text=24410:WARN:BH_TRX_ROUTER_TR:igki_nucleus.c#256:Memory pool=2 full, execution delayed. Count 1 Failure Event Report Type=processing failure Severity=warning level failure Probable cause= 03 00 01 Additional Text=24411:WARN:BH_TRX_ROUTER_TR:igki_nucleus.c#256:Memory pool=2 full, execution delayed. Count 2 Failure Event Report Type=processing failure Severity=warning level failure Probable cause= 03 00 01 Additional Text=24412:WARN:BH_TRX_ROUTER_TR:igki_nucleus.c#256:Memory pool=2 full, execution delayed. Count 3 Failure Event Report Type=processing failure Severity=warning level failure Probable cause= 03 00 01 Additional Text=24413:WARN:BH_TRX_ROUTER_TR:igki_nucleus.c#256:Memory pool=2 full, execution delayed. Count 4 ---------- At this point, I'm wondering if openbsc has some compatible problems with nanoBTS sw?Has any body run into this, and what's your sw version of nanoBTS? > Date: Thu, 5 Nov 2015 10:13:53 +0100 > From: laforge at gnumonks.org > You are running a complex setup (a GSM/EGPRS network), and there can be > many reasons. > > * Have you excluded RF interference? In order to do that, you could > connect your EGPRS capable MS over coaxial cable, duplexer and > attenuators directly without any antenna to the BTS. This way you > exclude any RF side interference. you also exclude the possibility > that any other phones not part of your test setup are meanwhile > attempting to register or use services of the network > > Next point is to obtain protocol traces (pcap) with synchronized > time-stamps on > * the MS side (the IP you get out of your MS) > * the Gb side betwene BTS and SGSN > * the IP side of the GGSN > > Recording those pcap files and looking at what happens where in the > timeline can be very useful. > > * Have you studied the protocol traces on the Gb level? Looking at them > it should be easy to determine if flow control was an issue at the > time you experience low througput. > > * Have you studied the IP level protocol traces on MS side or on the > GGSN side? What does a TCP sequence number / RTT analysis give you > for those traces? When are packets lost? > > * you could use OsmocomBB + bust_ind + gprsdecode to obtain > air-interface protocol traces to further analyze that interface. > > * finally, the nanoBTS telnet debug interface might be of help to > provide you some insight into what is happening in the (closed source) > PCU at the time you experience problems. > > -- > - Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151120/d86a1e03/attachment.htm>