Hi Tom,
thanks for your investigation!
It turns out my basic setup of IP addresses was wrong.
When I started up the CN, error messages already appeared *without* any mobile device even involved. So I noticed that the main difference to the other BTS models is that for TRX, I also run osmo-bts on my host machine.
My configuration files instructed the programs to communicate over my eth0 IP address in the local network, 10.9.1.120. When I change all of these configs to 127.0.0.42 (an implicitly created loopback address), I no longer get the "NS RESET ACK Discarding unexpected..." errors. I haven't fully understood why this fixes it yet, but it seems the SGSN sent the NS RESET ACK to itself... :P
Nevertheless, thanks again, I highly appreciate your effort!
On Tue, Jun 28, 2016 at 05:50:36PM -0700, Tom Tsou wrote:
I'm using the latest PCU version 189742b6 with reverted commit "f1a7b8f tbf: Add state WAIT_ASSIGN". I did pass any build time arguments.
Yes, that's my default setup, too.
20160628170837632 DL1C <0006> scheduler.c:240 Prim for trx=0 ts=0 at fn=272652 is out of range, or channel already disabled. If this happens in conjunction with PCU, increase 'rts-advance' by 5. (current fn=272658)
It seems to me that it's related to an initial clock sync of sorts...
20160629171522824 DL1C <0006> scheduler_trx.c:1420 GSM clock skew: old fn=463983, new fn=463888 20160629171523170 DL1C <0006> scheduler_trx.c:1420 GSM clock skew: old fn=463963, new fn=463888 20160629171523817 DL1C <0006> scheduler.c:240 Prim for trx=0 ts=0 at fn=464004 is out of range, or channel already disabled. If this happens in conjunction with PCU, increase 'rts-advance' by 5. (current fn=464010)
Ignoring it for now.
~Neels