Hi all,
I have an ip.access NanoBTS 139U (Part No 139U V 139U V351800). I believe it is operating on the 1800 MHz although admittedly that's a guess from the part number. I've not found a definitive way of confirming the supported band via Telnet or otherwise.
I can see the BTS attempting to connect to the BSC, but after the "Set Radio Carrier Attributes" request from the BSC, the BTS sends a NACK and the OML link is dropped.
<0004> abis_nm.c:984 OC=RADIO-CARRIER(02) INST=(00,00,ff): SET RADIO ATTRIBUTE NACK CAUSE=Message cannot be performed <0004> osmo_bsc_main.c:226 Got SET RADIO ATTRIBUTE NACK going to drop the OML links.
I've grabbed some debug info, note that in the PCAP the packets are wrapped in TZSP as I used a Mikrotik to stream them to Wireshark.
Log from BSC - https://s3.eu-west-2.amazonaws.com/cdn.marrold.co.uk/files/osmocom/osmobsc_l...
PCAP - https://s3.eu-west-2.amazonaws.com/cdn.marrold.co.uk/files/osmocom/NanoBTS.p...
It's worth noting that ipaccess-config tool also has an issue parsing the frequency which may well be related:
ipaccess-config -G 10.0.130.101 ipaccess-config (C) 2009-2010 by Harald Welte and others This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY
Trying to connect to ip.access BTS 10.0.130.101... OML link established using TRX 0 getting Attributes (3): 88 91 86 rc"" 0 <0004> abis_nm.c:652 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): Get Attributes Response: Primary OML IP is 10.0.130.111:0 <0004> abis_nm.c:658 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): Get Attributes Response: Unit ID is 1800/0/0 <0004> bts.c:497 (bts=0) Unsupported frequency band. <0007> abis_nm.c:725 (bts=0) BTS config invalid, dropping BTS! <0007> bts_ipaccess_nanobts.c:624 (bts=0) Deferring Drop of OML link. <0007> input/ipaccess.c:431 Bad signalling message, sign_link returned error: Invalid argument. <0007> bts_ipaccess_nanobts.c:557 (bts=0) Dropping OML link: Deferred link drop
Thanks in advance Matthew / marrold
I can see the BTS attempting to connect to the BSC, but after the "Set Radio Carrier Attributes" request from the BSC, the BTS sends a NACK and the OML link is dropped.
I think this might be misleading. This post https://www.mail-archive.com/openbsc@lists.osmocom.org/msg10239.html inspired me to use an SDR to check for BTS activity and sure enough it does briefly transmit and then stop. The Telnet log shows "TRX is not responding - reinitialising the unit..." and it looks like the BTS reboots shortly after. I swapped out the 1800MHz BTS for an 850MHz version and had the same behaviour. To rule out a PoE problem I swapped out the genuine ip.access injector for another known good PoE source but the issue remained.
I did see the photos on the Wiki ofa NanoBTS with bad caps. Is that a known issue? Visually the capacitors look fine in both units. Unfortunately the 1800MHz model has some quite serious corrosion inside and looks like some compartments have been flooded with sea water or something caustic. The PCB is in reasonable condition but some vias are damaged - it might be beyond repair.
Unless anyone has some inspiration I don't think it's worth digging too deeply into the Osmocom side as it's likely hardware issues.
Thanks Matthew / marrold
Hi Matthew,
On Wed, Nov 16, 2022 at 12:42:48AM +0000, Matthew H wrote:
I think this might be misleading. This post https://www.mail-archive.com/openbsc@lists.osmocom.org/msg10239.html inspired me to use an SDR to check for BTS activity and sure enough it does briefly transmit and then stop.
so 1800 MHz is confirmed then?
The Telnet log shows "TRX is not responding - reinitialising the unit..." and it looks like the BTS reboots shortly after.
it might still be some "unexpected" parameters in our OML which trigger this kind of malfunction in the BTS stack.
I did see the photos on the Wiki ofa NanoBTS with bad caps. Is that a known issue?
Not that I've heard of so far.
Visually the capacitors look fine in both units. Unfortunately the 1800MHz model has some quite serious corrosion inside and looks like some compartments have been flooded with sea water or something caustic.
ugh. ok.
Unless anyone has some inspiration I don't think it's worth digging too deeply into the Osmocom side as it's likely hardware issues.
probably, given your description.
Hi Matthew,
On Mon, Nov 14, 2022 at 09:03:23PM +0000, Matthew H wrote:
I have an ip.access NanoBTS 139U (Part No 139U V 139U V351800). I believe it is operating on the 1800 MHz although admittedly that's a guess from the part number. I've not found a definitive way of confirming the supported band via Telnet or otherwise.
It's ages since I worked with those, so I don't recall. One strategy might be to look for RF filters in the RF frontend on the circuit board _if_ those carried readable part numbers.
I can see the BTS attempting to connect to the BSC, but after the "Set Radio Carrier Attributes" request from the BSC, the BTS sends a NACK and the OML link is dropped.
<0004> abis_nm.c:984 OC=RADIO-CARRIER(02) INST=(00,00,ff): SETRADIO ATTRIBUTE NACK CAUSE=Message cannot be performed <0004> osmo_bsc_main.c:226 Got SET RADIO ATTRIBUTE NACK going to drop the OML links.
I've grabbed some debug info,
you mentioned 'telnet' in the other mail. Are you referring to ipaccess-telnet in that case, i.e. the debug output of the nanoBTS itself?
It's worth noting that ipaccess-config tool also has an issue parsing the frequency which may well be related: [...]
it would be interesting to see a pcap of that.
-
Harald Welte -
Matthew H