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>