On 18.08.2018 21:37, Harald Welte wrote:

Hi Keith,

Hi Harald, thanks for taking the time to reply.

it would be useful if you could provide a PCAP file of the Gb interface and the GTP traffic for this, so we can look at the actual ip address allocation as it happens in the network.

Probably not worth spending time on this to open traces etc.. I looked at the trace and see what would be expected in the pdp context activation.

Please note that the PPP you speak is only between the modem and the ppp daemon, and there is no PPP over the radio interface. The IP address allocation happens via the PDP context activation on the signaling plane.

Yep, I see this, in the PDP Context Activation Ack, we have a Packet Data Protocol Address with the IPv4 Address then there's an PPP IP Control Protocol Configuration ACK with the Primary and Secondary DNS.

No mention of 192.168.100.101.

Maybe this is just what the ppp code in the pppd or in the kernel uses for the dstaddr of the p-t-p link if it is not getting this info elsewhere?

I found this page which shows the same thing https://ubuntuforums.org/showthread.php?t=670714

k/

Keith wrote:

No mention of 192.168.100.101.

Maybe this is just what the ppp code in the pppd or in the kernel uses for the dstaddr of the p-t-p link if it is not getting this info elsewhere?

Harald Welte replied:

No, I think it's what some component in your phone is inventing and returning to the ppp daemon on your Linux machine :)

My first thought in reaction to Keith's analysis was what Harald said, so I decided to test it experimentally. I don't have my own Osmocom network or any BTS of my own to test with, but I do have active service on several SIMs with the local GSM&UMTS commercial network operator in my neck of the woods (T-Mobile USA), and the available services include mobile Internet in addition to calls and SMS. My thought was to make a pppd connection from the same host (my Slackware laptop) to the same T-Mobile network through two different GSM+GPRS(+UMTS) modem implementations, and see if the P-t-P address reported in ifconfig changes or not.

The first tested implementation is Huawei E303, a 3G data modem in the USB stick form factor; it is Qualcomm-based to the best of my knowledge. Here is the ifconfig output:

ppp0 Link encap:Point-to-Point Protocol inet addr:21.227.117.124 P-t-P:10.64.64.64 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:33967 errors:0 dropped:0 overruns:0 frame:0 TX packets:29454 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:28077904 (26.7 Mb) TX bytes:2831375 (2.7 Mb)

The other tested implementation is my own FreeCalypso, or more specifically an FCDEV3B modem board running FreeCalypso Magnetite hybrid firmware, build date 2018-07-30T20:24:34Z. It is also using a different SIM, although on the same billing account with T-Mobile and with the same service configuration - I am too lazy to move the same SIM back and forth between the USB stick modem and my own board. Here is the ifconfig output:

ppp0 Link encap:Point-to-Point Protocol inet addr:22.255.27.2 P-t-P:10.64.64.64 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:285 errors:0 dropped:0 overruns:0 frame:0 TX packets:341 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:79139 (77.2 Kb) TX bytes:35368 (34.5 Kb)

The dynamically assigned IP address is different because I had to shut down pppd with one modem and start a new session with the other modem, but notice that the P-t-P address is the same fixed 10.64.64.64.

One very special feature of my FreeCalypso GSM+GPRS modem implementation is that it is compiled from source code that is freely published for anyone to study or tweak as they like, so if anyone is interested, you are more than welcome to study the PPP-to-GPRS translation code in this modem implementation and see what it does. Unfortunately, though, I don't have any spare cycles at the present time to do such a code study myself - I am not the original author of this code, I inherited it from TI, and while I strive to maintain it, I will only be able to devote significant time to this task if someone buys my modem hardware (the firmware is useless without the hardware) in a commercially significant quantity, which hasn't happened yet. In the absence of commercial customers for FreeCalypso modems, I can only spend very little time on firmware maintenance, just enough to verify that it works on a basic level, which it does - I am sending this post through the mobile Internet GPRS connection going through my FreeCalypso modem.

But I consider it rather unlikely that two independent and very different implementation of PPP-to-GPRS translation (or PPP-to-UMTS in the case of the 3G modem) have the same 10.64.64.64 IP address hard- coded in them, so in this case the P-t-P address is probably coming from T-Mobile's GGSN and not from the modem.

Many [modern] modems are doing some internal NAT so that the IP addresses on the host PC (pppd) side don't correspond to those on the modem-sgsn side.

While I don't have the time to study it and see for myself (see above), I highly doubt that the implementation which we (FreeCalypso) inherited from TI does such NAT.

M~

Hi Keith!

So, I decided to carry out a similar simple test, by putting my local operator SIM into the modem. I still got the 192.168.100.101 p-t-p address. Given that this happens on OpenWRT and Windows, although I didn't bother test windows with the local operator, I would have to assume that in my case, it's coming from the modem, as Harald suggests.

I wonder, is it possible for the GGSN to either provide or not provide the far end IP address? I wonder if the modems pass on the far end IP address provided by the GGSN if there is one, and make up their own placeholder otherwise? I suppose I won't know until I take the time to study the implementation code I got from TI, and I don't know when I may be able to find the time to do that...

I wish I could send you one of my FreeCalypso modem boards so you could test it against your Osmocom network - it would be the first- ever GPRS connection made between a free, fully understood modem implementation and a free, fully understood network - but I don't have any boards left: all V1 boards are sold out, and I need about 3000 USD to order the PCB fabrication of V2 boards.

Can we see diagnostic output on gprs negociation on the freecalypso side?

By default only L1 emits voluminous debug output, not any of the upper protocol stack layers, but you can send developer commands to the running fw over the second UART (the same one on which the debug output is, not the one that carries AT commands and PPP) to enable more verbose debug traces. However, you cannot enable "everything", as the trace output mechanism will be overwhelmed and you will be lost in the noise, instead you need to study the code first, get a good grip on its architecture, and then selectively enable the traces of interest to whatever you are investigating.

Does it give us an "insight" into what this TI baseband is doing?

"What this TI baseband is doing" - just to be sure that everyone understands the context, the hardware and the DSP black box only receive and transmit bursts, nothing more; everything above the physical layer is done by software running on the ARM7 processor, and we have the complete C source for that software, no blobs. It is a *different* version of TI's upper level protocol stack code than the one that was used by Openmoko - the latter had blobs with no corresponding source. I am using a newer version of TI's upper level protocol stack code that was originally supported by TI only on their LoCosto chipset, which is much less understood by the community than the good old Calypso - so I backported that code from LoCosto to Calypso, and then built my own Calypso-based board to run it on. Motorola C1xx phones that are used by OsmocomBB aren't good enough for this purpose: I really needed two UARTs (one for AT commands and PPP, the other for development and debug), whereas those Motorolas only have one usable UART.

People should also get over the incorrect notion that it is all TI's stuff and that I am merely pirating and remarketing it. The FC Magnetite repository alone (the one from which I make stable production builds) has more than 500 commits since the initial import, it took 349 commits in another repository to reconstruct the L1 code (watch my REcon Montreal 2017 video for the details), another 806 commits across several repositories to develop various supporting tooling, and all of that was *after* my initial attempt (freecalypso-sw) which I concluded was the wrong approach; that "rough first attempt" freecalypso-sw repository got 1034 commits at the time of its retirement. There is no practically available hardware on which one could run any of TI's original code versions without my changes, and the only hardware that *is* practically available (my development board, called FCDEV3B) requires FreeCalypso firmware to function usefully, not any of the historical pre-existing versions from TI or from other companies.

TI has not provided one bit of support for any of this software or for the silicon needed to run it since 2009, all development after that date (almost a decade) was done by me and not by them. I am not merely "hacking" this code, I am striving to maintain it, support it and continue further development of it no worse than TI did in their peak days. However, the code base is huge, and being just one person working on it in my spare time without commercial funding, I can only do so much - there are many parts of the code which I haven't studied yet because the code "just works" and I haven't had a need to delve into it yet - most of the GPRS code is in this category.

I was actually quite amazed that the GPRS code just worked out of the box when I backported the new TCS3/LoCosto version of G23M to the Calypso and made it compile in my Magnetite build environment. This new code version differs from the old one which TI officially supported on the Calypso: they added a new protocol stack component called UPM (User Plane Manager), and it appears to originate from TI's dual-mode GSM+UMTS (3G) protocol stack - but it also has a 2G-only mode when no UMTS protocol stack components are present, and this 2G-only UPM is a required component of the FreeCalypso hybrid (previously TI LoCosto) protocol stack for GPRS.

Osmocom has done a magnificent job of bringing to the world a FLOSS implementation of the network side of GSM, GPRS and UMTS, but there are no practically usable Osmocom offerings for the mobile side - every one of those awesome Osmocom 2G or 3G networks out there is still serving end user phones and modems that are 100% closed and proprietary. It is high time for the user equipment side to be freed too, and if Osmocom is not doing it, then someone else will. At the present time I am not aware of anyone else other than FreeCalypso offering any kind of practically usable cellular end user equipment that is anything other than an impenetrable binary blob that is also tivoized most of the time.

M~

P.S. I wish I could meet you all at OsmoCon in October, but it won't be possible even if someone volunteered to pay for my airfare: I would need to get a U.S. Travel Document (aka Re-entry Permit) in order to travel outside of USA+Canada+Mexico territory, and that process would certainly take longer than the two months or less between now and OsmoCon. However, if there is any other conference or gathering coming a little further out, and if someone would like me to come to that one and would cover my flight, please let me know and I will start the months-long application process to get my travel document, which will then be good for 2 y.

Hi Keith!

It's a problem for sure, even if such a (mobile side) device existed, users would likely in most cases just use it to connect to closed, proprietary, centralised, surrveillance based and advertising funded networks to give away their thoughts and minds and freedoms. What to do?

I don't see how it would be a problem if people use a FLOSS phone to connect to mainstream commercial GSM or UMTS networks. I don't see those networks as advertising-funded, they sure seem subscriber-funded to me (everyone pays a monthly bill to get a SIM with a phone number), and if you have the complete source code plus hardware schematics for your phone, then *you* control what your phone does and doesn't do, and it simply interacts with the operator's network in accordance with standard protocol specs.

If I use the cellular voice network of T-Mobile USA with my own phone (not issued and not approved by T-Mobile) for everyday mundane business like calling in to say that I am on my way in traffic when I'm running a little late for an appointment, I don't see how I am giving away my thoughts or my mind or my freedom - in my view, I am not.

OsmoCon next year?

If someone is interested enough in my mobile-side work to sponsor my travel costs, then sure, and in that case the prospective sponsor would need to tell me now so I can start the months-long application process for the travel document - it can't be done at the last minute. In the absence of such interest and sponsorship, I do hope to make it out to OsmoCon on my own dime eventually, but it won't be next year: it would have to be after my surgery, which means at least another 2-3 years. Leah Rowe of Libreboot just got hers done (vimuser.org/surgery), now it's time for mine, so that's where I am currently directing all of my spare money.

(Maybe rhizomatica should host it in Mexico, although that would mean a lot of carbon burning for most people to get there!)

If you do host something in Mexico (preferably somewhere close to the border like Tijuana), that should definitely be affordable for me to travel to on my own! I am just north of that border.

M~

Mychaela Falconia wrote:

The first tested implementation is Huawei E303, a 3G data modem in the USB stick form factor; it is Qualcomm-based to the best of my knowledge. Here is the ifconfig output:

ppp0 Link encap:Point-to-Point Protocol inet addr:21.227.117.124 P-t-P:10.64.64.64 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:33967 errors:0 dropped:0 overruns:0 frame:0 TX packets:29454 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:28077904 (26.7 Mb) TX bytes:2831375 (2.7 Mb)

The other tested implementation is my own FreeCalypso, or more specifically an FCDEV3B modem board running FreeCalypso Magnetite hybrid firmware, build date 2018-07-30T20:24:34Z. It is also using a different SIM, although on the same billing account with T-Mobile and with the same service configuration - I am too lazy to move the same SIM back and forth between the USB stick modem and my own board. Here is the ifconfig output:

ppp0 Link encap:Point-to-Point Protocol inet addr:22.255.27.2 P-t-P:10.64.64.64 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:285 errors:0 dropped:0 overruns:0 frame:0 TX packets:341 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:79139 (77.2 Kb) TX bytes:35368 (34.5 Kb)

The dynamically assigned IP address is different because I had to shut down pppd with one modem and start a new session with the other modem, but notice that the P-t-P address is the same fixed 10.64.64.64.

In this case the P-t-P IP address 10.64.64.64 is probably coming from the pppd on your linux machine.

If the remote P-t-P IP address cannot be determined via IPCP pppd is using fallback IP addresses.

The IP address pppd then uses is 0x0a404040 + a interface unit id. The interface unit id is "0" for ppp0, "1" for ppp1, ...

The resulting (fake) fallback P-t-P remote IP addresses are

ppp0 -> 10.64.64.64 ppp1 -> 10.64.64.65

For more details see: https://github.com/paulusmack/ppp/blob/5c765a67fd25f9d84e71ed61ace37c8c97f6b...

This ppp implementation aka "Paul's PPP Package" from https://ppp.samba.org/ is used by more or less all linux distributions these days.

best regards, Martin

Hi Keith,

On Thu, Aug 23, 2018 at 12:47:38PM +0200, Keith wrote:

To try to bring this back on topic for the list, I still have the question of whether the GGSN /could/ in fact provide the correct p-t-p address?

A GTP tunnel is *not* a point-to-point link, and hence it technically doesn't have a point-to-point address. This is a mismatch between IETF/PPP and 3GPP architecture.

The point is that a GGSN is not seen as a router, but merely a tunnel entry point, transporting user packet data such as IP.

The actual GGSN implementation may be implemented as a router, but that's then an implementation detail and nothing in the 3GPP design.

So I think it would be illogical if the GGSN would advertise a point-to-point address, if it isn't a point-to-point link :)