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/.
Suraev suraev at alumni.ntnu.no20.11.2015 11:12, Harald Welte пишет:
> logging level sm debug
I don't see this one but
logging level lgtp debug
and
logging level gprs debug
did the trick, thanks!
> If you're not getting a pdp context activate, then you phone is not
> activating a pdp context. Without pdp context, no user data.
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 MS is not activating a pdp context. Befoer that you will not see
> any data. Check your apn configuration.
I should have guessed - the lack of gprs indicator on the phone means it did not
actually attempt to use it.
Now, it works, although just one way for some reason.
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.
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).
However, none of the phone's requests receive reply. On the other hand if I try to
ping phone directly from the host than I got reply just fine, counters got updated in
sgsn, messages are visible in wireshark etc.
So it seems like the osmocom side of things is doing fine and the remaining issue is
somewhere on the host. I would blame iptables but I've checked that no blocking rules
installed and all policies defaults to accept for both regular and nat tables.
Anyway, will keep digging, thanks for help!
cheers,
Max.