Hi List!
As there isn't so much about GPRS on here, I though I might write something about experiments over the last couple of weeks with data inside and outside of the lab.
I've installed up to date versions of osmo-bts and osmo-pcu on sysmobts 2050 hardware and it's working great! Dynamic channels are really nice, with half rate TCH and AMR working perfectly. Thanks for all that work!
The question for this experiment was if it was going to be feasible to actually do anything with several hundred data hungry spying devices.... I mean mobile phones on the network.
For the traffic control, I setup a local blacklisting or whitelisting dns server. I've tried both. Blacklisting the worst culprits would be nice, but in practice I think I'll have to go for whitelisting only the intended permitted services. I configured pcodns1 in the ggsn to point to this DNS server, AND I setup a port 53 redirect to catch quite a lot of traffic from android that likes to just talk directly to 8.8.8.8 anyway.
In the wild, some dns request analysis reveals the worst culprits (this is a very basic analysis) appear to be all the google update stuff, play store etc, facebook iCloud, (all to be expected) , and certain CDNs. Some research shows that these CDN companys specialize in delivery of advertising content inside apps such as mobile platform games. Such is the sad state of affairs on today's internet. Fortunately, we have iptables and ip sets and we have AS blocks assigned to certain bandwidth hungry corporations :-)
So turns out it seems quite feasible to supply service for text messages with certain popular IM services to many phones. Short voice clips worked quite well in the lab tests, although support for media such as pictures and videos was not so great. I have yet to successfully send an image (sourced via device camera within the app) over a "secret" chat with Telegram messenger.
As this is not a very low level report, rather intended as some light reading :) I also have a question in a similar light vein.
I'm still getting to grips with the log messages available in the pcu , the sgsn and not so much the ggsn, and I'm observing and learning the sequence of events, so at some point I should be able to present a better report about this with some relevant traces and better analysis.
For now, In the lab tests I am constantly monitoring the RF uplink; I observe that a phone will attach and then go quiet. A foreground running app may report that it is "connecting" or some such, and the little arrows may be flashing to show that apparently we are transmitting data, but there is nothing on the uplink. My guess here is the OS has sent something and the baseband is saying yes yes doing it.. but the baseband at the same time is waiting for something from the network (and not getting it)?
This situation can persist for some time.. several minutes. I have observed that if I initiate any data transfer from the network side then the uplink is established. By the same token, If I transfer a file from the network (http download or some such), the same applies. The link stays active and the IM chat session is very responsive alongside the file transfer. Shortly after the file transfer completes, the uplink is quiet again and the latency in the IM session becomes a problem.
From a UX point of view.. Let me put it this way.. I can
start an IM chat, send a message.. but then we get to this quiet uplink sitation and the messages stop sending.. so from the user's point of view it's frustrating. the phone looks like it's transmitting.. until there are timeouts and disconnections and the app may show some indication to the user that it is having trouble connecting to the network.
However if I run something on the network side like a script that sends one ping to the phone every ten seconds, this keeps the connection 'alive' and the IM session is much more satisfactory for the user.
I should note I believe I observe this also on commercial networks in some places like certain Berlin U-bahn stations where you can still find (only) GPRS data coverage. Also, a more scientific report is needed, but I seem to observe some phones behaving "better" than others, as in being a little more active on the uplink. Maybe it is related to power saving configuration?
The not very low level and scientific question here is: Is this kind of thing tunable with gprs parameters? Any tips on which ones to play with? ( Quite happy to wait until I can send a more useful report too! )
Thanks!
Keith.
(BTW, for GPRS we use osmocom-net-gprs@lists.osmocom.org but admittedly, almost all osmocom communication is taking place on openbsc@)
On Mon, Oct 30, 2017 at 12:12:03PM -0600, Keith wrote:
I've installed up to date versions of osmo-bts and osmo-pcu on sysmobts 2050 hardware and it's working great! Dynamic channels are really nice, with half rate TCH and AMR working perfectly. Thanks for all that work!
Good to hear that!
I configured pcodns1 in the ggsn to point to this DNS server, AND I setup a port 53 redirect to catch quite a lot of traffic from android that likes to just talk directly to 8.8.8.8 anyway.
Interesting, this sounds like it would make for a good wiki page on osmocom.org.
games. Such is the sad state of affairs on today's internet. Fortunately, we have iptables and ip sets and we have AS blocks assigned to certain bandwidth hungry corporations :-)
So instead of compromising net neutrality by giving the rich more bandwidth, you do it by cutting the big ones out instead ;)
I have observed that if I initiate any data transfer from the network side then the uplink is established. By the same token, If I transfer a file from the network (http download or some such), the same applies. The link stays active and the IM chat session is very responsive alongside the file transfer. Shortly after the file transfer completes, the uplink is quiet again and the latency in the IM session becomes a problem.
It might be related to a basic problem we still have with data services: we don't cache anything. If a PDP context is still being established, we drop data transfers to the floor, instead of storing them and sending them through when the context is established. I'm personally not familiar with the details there, but that's my current understanding.
So a first ping would get lost, a second one within a timeframe that still has the PDP context open will go through.
I think the idea there is that generally, higher level data communication should attempt to resend, but in practice that often doesn't seem to work that well.
Not sure how to configure the PDP context timeout, or whether we even can.
Theoretically, if you had on your phone a regular ping running in the background ... it's ugly, but yea.
Caching those first packets is quite complex, especially for SGSNs sitting on a small device like a sysmoBTS with limited memory. I guess something could be tried there, by limiting resources used for caching in intelligent ways...
Someone would need to fund that, or go ahead and try.
~N
On 03/11/2017 12:59, Neels Hofmeyr wrote:
So instead of compromising net neutrality by giving the rich more bandwidth, you do it by cutting the big ones out instead ;)
Hi Neels!
Net Neutrality is a non-thing. It doesn't exist. Never has, never will. Therefore it cannot be compromised. While many net-freedom activists and net celebs have created a lot of blah blah blah and patted themselves on the back in recent years over this, the de-facto reality remains that the network infrastructure has never been free or anything that even resembles any definition of "free". Ask anybody who has had their small server DDOS'd off the network for political reasons, or any other reason.
Today's internet belongs to the corporations and everyday more to those that control the physical infra, and those that have CDNs and POPs in every provider's datacentre. You simply cannot compete with that.
The internet is pure capitalist, if you have money to buy access, you can have access and bandwidth to supply services, if not, then f**k you. Take a look at the price to the average consumer of anything more than a 256K or even 128K uplink in Mexico. The whole concept of "net neutrality" is toxic.
Everytime we say or write the phrase, somewhere in the world, a baby penguin dies. My apologies to the list for drifting dangerously off topic. It (probably) won't happen again.
;-)
k/
On Wed, Nov 08, 2017 at 09:58:46AM -0500, Keith wrote:
The whole concept of "net neutrality" is toxic.
Everytime we say or write the phrase, somewhere in the world, a baby penguin dies. My apologies to the list for drifting dangerously off topic. It (probably) won't happen again.
Ah oh, you were actually posting on list, lol :) Reading up to now I assumed it was a private mail :D
I accept your word on it not being a thing, but I'll keep net-neutrality as a utopian ideal phrase along with world peace and halting human made climate change. I hope creatures dying isn't causal to writing these phrases...
I did like the Rap News issue on it: http://www.youtube.com/watch?v=k-xSP_T0VqU but surely the "sacred principle of stacking money" has been in it all the time.
</off-topic>
~N
-
Keith -
Neels Hofmeyr