This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Neels Hofmeyr nhofmeyr at sysmocom.deOn Sun, Nov 22, 2015 at 05:20:18PM +0100, Suraev wrote:
> Doh! As far as I recall sgsn/ggsn ignores apn (btw, there's nothing while searching
> for "apn" in wiki) but I forgot that phone still got to have something set as apn
> ("internet" works fine) in order to start actually using gprs.
The APN may be used to find the proper GGSN to establish a PDP context
with (APN and parts of the IMSI are used to compose a "*.gprs" name, which
is then resolved using DNS to find the GGSN's IP address). If your SGSN is
configured to send things to a specific GGSN, the APN does in fact not
have an impact. So it depends on your SGSN's configuration.
> I can see activated pdp context in sgsn vty:
>
> OsmoSGSN# show pdp-context all
> PDP Context IMSI: 901708776992222, SAPI: 3, NSAPI: 5
> APN: internet
> PDP Address: IPv4 192.168.0.2
> SGSN PDP Context Statistics:
> User Data Messages ( In): 16 (0/s 0/m 16/h 0/d)
> User Data Messages (Out): 0 (0/s 0/m 0/h 0/d)
> User Data Bytes ( In): 1032 (0/s 0/m 1032/h 0/d)
> User Data Bytes (Out): 0 (0/s 0/m 0/h 0/d)
>
> Also I see the dns requests in tcpdump over tun0 interface.
>
> The problem is the above 0 Out - nothing has been sent to the mobile.
I was at first unsure because an SGSN receives and sends both to/from
mobile as well as to/from GGSN. But looking at the code, it seems that
your interpretation is correct.
> The masquerading on the host seems to work fine at first glance:
> ping -S 192.168.0.3 8.8.8.8
> gets expected response (here 192.168.0.3 is the address from the space assigned to
> phones).
Could you explain the -S? In my host system's man page, -S is documented
as:
-S sndbuf
Set socket sndbuf. If not specified, it is selected to
buffer not more than one packet.
and busybox's ping doesn't document any -S option ... ? So to me it seems
your ping command sets a send buffer of 192 packets (ignoring ".168.0.3")
and pings google's nameserver.
I'm still new on the subject, just hoping to be helpful... I've recently
done GTP and PDP context related stuff, so a few shots in the dark:
In wireshark, you could examine which GSN addresses the SGSN is telling
the GGSN to use ("GPRS Tunneling Protocol" / "GSN address"). There's two,
the first is for the Ctrl plane, the second for User. The GGSN will reply
to the PDP context creation and then switch to those GSN addresses for
subsequent messages. If those are wrong/not reachable from the GGSN side,
that may cause lost replies?
Have you enabled forwarding on the host running the GGSN? I'm using these
commands to be able to locally test with a "fake" GGSN on my laptop:
sudo -s
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
~Neels
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151123/5c08134c/attachment.bin>