manual testing of osmo-pcu
these are manual testruns with osmo-pcu and osmo-bts-sysmo from -nightly and the cni running on debian on an apu.
attached are the configs for the sysmobts (osmo-pcu and osmo-bts-sysmo) as well as the remaining cni (on debian9 from -nightly)
the pcap files are generated by dumping the complete interface on the bsc. in addition to that the gsmtap for -bts and -pcu sends its debug there.
the pcap file(s) are single runs: getting the phone from airplane mode - register - do a network request - airplane mode.
#8 Updated by keith over 1 year ago
I think this is a great idea, as much as it is time consuming and well... manual.
However, I think that better than testing "browsing" on mobile browser with a result set of [works|does not work], it would be better to place an extremely restrictive firewall on the ggsn and intercept and answer NXDOMAIN for all DNS requests but a select few you will use for testing and then do something a little more controlled, like a simple ping test, opening a local LAN "web page" or connecting an XMPP client to a local server or some such.
My reasoning behind this is that most phones are probably going to saturate the capacity of the link as soon as they get an IP address with call home requests, cloud service logins, weather, app update checks and whatever.
I'm almost loathe to mention it, but to go beyond ping tests and test something a little more real world, telegram messenger gives a pretty good visual feedback of the status of the connection, and is a reasonably "easy" way to create MS or Network side traffic to initiate TBFs. Telegram has a small set of known IPs that you can allow in order for service to work quickly.