Dear Osmocom Community,
I have noticed that the wiki page for OpenBSC GPRS at https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_GPRS has not been updated for four years, and since then, there have been significant updates to the software. As a result, the information on the GPRS/EDGE Setup page may be outdated, and I am struggling to configure GPRS on my system.
I have attached my configuration files below for your review.
ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 link/ether ec:8e:b5:41:cb:90 brd ff:ff:ff:ff:ff:ff 3: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether b8:8a:60:4f:59:02 brd ff:ff:ff:ff:ff:ff inet 192.168.1.109/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp1s0 valid_lft 7152sec preferred_lft 7152sec inet6 fe80::649b:2ab5:6dd3:8779/64 scope link noprefixroute valid_lft forever preferred_lft forever
Dear Osmocom Community,
I have noticed that the wiki page for OpenBSC GPRS at https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_GPRS has not been updated for four years, and since then, there have been significant updates to the software. As a result, the information on the GPRS/EDGE Setup page may be outdated, and I am struggling to configure GPRS on my system.
I have attached my configuration files below for your review.
ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 link/ether ec:8e:b5:41:cb:90 brd ff:ff:ff:ff:ff:ff 3: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether b8:8a:60:4f:59:02 brd ff:ff:ff:ff:ff:ff inet 192.168.1.109/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp1s0 valid_lft 7152sec preferred_lft 7152sec inet6 fe80::649b:2ab5:6dd3:8779/64 scope link noprefixroute valid_lft forever preferred_lft forever
Regards
Tahmid
Hi Ahnaf,
the structure of osmocom have changed since the manual has been written. The manual is written for the long outdated osmo-nitb (a combined BSC,MSC).
I have noticed that the wiki page for OpenBSC GPRS at https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_GPRS has not been updated for four years, and since then, there have been significant updates to the software. As a result, the information on the GPRS/EDGE Setup page may be outdated, and I am struggling to configure GPRS on my system.
I have attached my configuration files below for your review.
I would recommend to take a look into the https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In... But you already have configuration files for bsc, msc, sgsn, ggsn.
I would also recommend you to add an IP for every core network component and ran. Because it helps debugging to have the IPs seperate. For a local network (everything runs on the same host) I would do:
* 127.0.0.10 bts + pcu * 127.0.0.11 bsc + bsc-mgw (yes running mgw twice)j * 127.0.0.12 msc + osmo-sip-connector + msc-mgw * 127.0.0.13 sgsn * 127.0.0.14 ggsn * 127.0.0.15 sip-server (e.g. asterix, ...) * 127.0.0.16 hlr You will need to change vty and ctrl interface ips as well.
Back to your current network. Are you running osmo-stp? osmo-stp is required for the new network.
Ok. but what is not working? Please add more information!
- Can your MS/UE connect to the network? - CS: location update works? - PS: routing area update works? - Does your phones gets an IP? (PDP Context) - Does `tcpdump -i tun4 -vn` shows any traffic?
Do you have a pcap trace? (Best to upload it to a website and only send the link on this mailinglist)
Your tun.network file looks wrong. The device should be named tun4 and the IP range is also wrong. Personally I wouldn't use systemd-networkd for this. At least I would expect routing issues. Also I wonder why there isn't a tun4 device.
Even if there is a tun4 device, you might missing the routing and depending on your setup, NAT/masquerading. I think you would need to run `ip route add 172.16.222.0/24 dev tun4` and `iptables -t nat -A POSTROUTING -j MASQUERADE -s 172.16.222.0/24 -o wlp1s0`
Best, lynxis
Hi Lynxis,
Thank you for your response and suggestions. Regarding my current network setup, I am using a b200 device to connect my Android phone to the osmobts network. I am able to establish roaming connections successfully, and I can make and receive calls as well as send and receive SMS. However, I am encountering an issue with the network connection for data services. I am not able to connect to the E (EDGE) or G (GPRS) networks. Despite being in a coverage area, my phone does not receive an IP address for data services. It seems that the GPRS/EDGE setup is not functioning properly. I have checked the configuration files and made the necessary adjustments based on your recommendations. I have also reviewed the tun.network file and corrected the device name to "tun4". However, I am still experiencing difficulties.
To provide more information, here are some specific questions:
Can my mobile phone successfully connect to the network for voice calls and SMS? Yes, I can make and receive voice calls and send/receive SMS without any issues. Is the Circuit-Switched (CS) functionality, such as location update, working properly? Yes, the CS functionality, including location update, is working as expected. Is the Packet-Switched (PS) functionality, such as routing area update, working properly? No, the PS functionality, including routing area update, is not working. I am unable to establish a network connection for data services. Is my phone receiving an IP address for data services (PDP Context)? No, my phone is not receiving an IP address for data services. Have I checked for network traffic using tcpdump -i tun4 -vn? Yes, I have checked for network traffic using the mentioned command, and I have got this: tcpdump: listening on tun4, link-type EN10MB (Ethernet), snapshot length 262144 bytes
Unfortunately, I do not have a pcap trace available at the moment. If necessary, I can provide additional information or logs to assist with troubleshooting. Thank you for your continued support.
Log:
- osmo-hlr https://docs.google.com/document/d/1TIj80mQmVUCgFyDyW58E0GdT2ebzkRmlwXuM1xCilZQ/edit?usp=sharing - osmo-msc https://docs.google.com/document/d/1sByzVEQ-sk7InhWPyaI3LIo5Ws7UuL_99gds1ZDLBCM/edit?usp=sharing - osmo-bsc https://docs.google.com/document/d/1mFRtjnOfecCFZSmAaA22GA_EM28rB59dIjftM_UXmPc/edit?usp=sharing - osmo-sgsn https://docs.google.com/document/d/1r3VfTNPlb-9XWU8FWfALh5kRr9502WgrSMuYXkqHrE0/edit?usp=sharing - osmo-ggsn https://docs.google.com/document/d/13aAEeM22w5gutpmSRmLoIGq1eE8COJF4rrQ4-NF49zY/edit?usp=sharing - osmo-pcu https://docs.google.com/document/d/1YZXZqG4vefV5kSviKLbgopmUBCTSSPzzKBxeJt28vLY/edit?usp=sharing - osmo-stp https://docs.google.com/document/d/1ePZ-CAlqjxs1mv4BYaNsUIBxeW3UWDZKqB-edpYu_oU/edit?usp=sharing - osmo-bts-trx https://docs.google.com/document/d/1jWDZvGJzqCPiGEiHw2Itu80bM3LePrsaVQ5koPkfGN8/edit?usp=sharing - osmo-trx-uhd https://docs.google.com/document/d/1vliUJ6nzt3f9o4VGlyY3ZvqNDyj-go96ZM3hDqtBw3w/edit?usp=sharing
Best regards, Tahmid
On Sat, 20 May 2023 at 16:42, Alexander 'lynxis' Couzens lynxis@fe80.eu wrote:
Hi Ahnaf,
the structure of osmocom have changed since the manual has been written. The manual is written for the long outdated osmo-nitb (a combined BSC,MSC).
I have noticed that the wiki page for OpenBSC GPRS at https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_GPRS
has
not been updated for four years, and since then, there have been significant updates to the software. As a result, the information on the GPRS/EDGE Setup page may be outdated, and I am struggling to configure
GPRS
on my system.
I have attached my configuration files below for your review.
I would recommend to take a look into the https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In... But you already have configuration files for bsc, msc, sgsn, ggsn.
I would also recommend you to add an IP for every core network component and ran. Because it helps debugging to have the IPs seperate. For a local network (everything runs on the same host) I would do:
- 127.0.0.10 bts + pcu
- 127.0.0.11 bsc + bsc-mgw (yes running mgw twice)j
- 127.0.0.12 msc + osmo-sip-connector + msc-mgw
- 127.0.0.13 sgsn
- 127.0.0.14 ggsn
- 127.0.0.15 sip-server (e.g. asterix, ...)
- 127.0.0.16 hlr
You will need to change vty and ctrl interface ips as well.
Back to your current network. Are you running osmo-stp? osmo-stp is required for the new network.
Ok. but what is not working? Please add more information!
- Can your MS/UE connect to the network?
- CS: location update works?
- PS: routing area update works?
- Does your phones gets an IP? (PDP Context)
- Does `tcpdump -i tun4 -vn` shows any traffic?
Do you have a pcap trace? (Best to upload it to a website and only send the link on this mailinglist)
Your tun.network file looks wrong. The device should be named tun4 and the IP range is also wrong. Personally I wouldn't use systemd-networkd for this. At least I would expect routing issues. Also I wonder why there isn't a tun4 device.
Even if there is a tun4 device, you might missing the routing and depending on your setup, NAT/masquerading. I think you would need to run `ip route add 172.16.222.0/24 dev tun4` and `iptables -t nat -A POSTROUTING -j MASQUERADE -s 172.16.222.0/24 -o wlp1s0`
Best, lynxis
Hi Tahmid,
- osmo-bsc
https://docs.google.com/document/d/1mFRtjnOfecCFZSmAaA22GA_EM28rB59dIjftM_UXmPc/edit?usp=sharing
- osmo-sgsn
https://docs.google.com/document/d/1r3VfTNPlb-9XWU8FWfALh5kRr9502WgrSMuYXkqHrE0/edit?usp=sharing
your pcu can't connect to the sgsn. You tell your pcu to connect to 127.0.0.9:23001 The bsc is configuring the pcu via the bts. (bsc -> bts -> pcu) bsc-config: [...] gprs nsvc 0 remote ip 127.0.0.9 gprs nsvc 0 remote udp port 23001 gprs nsvc 0 local udp port 23002 gprs nsvc 0 nsvci 1800 [...]
But in your sgsn configuration you set the listen ip/port to 127.0.0.20:23000 [...] ns bind udp local listen 127.0.0.20 23000 accept-ipaccess [...]
Please change your bsc configuration to 127.0.0.20 and the remote udp port to 23000
gprs nsvc 0 remote ip 127.0.0.20 gprs nsvc 0 remote udp port 23000
Also your ggsn configuration has: ip dns 0 127.0.0.1
This will tell the phone to ask itself for dns queries. Please replace it with a valid dns server (e.g. 1.1.1.1)
Best, lynxis
On Sat, 20 May 2023 at 16:42, Alexander 'lynxis' Couzens lynxis@fe80.eu wrote:
Hi Ahnaf,
the structure of osmocom have changed since the manual has been written. The manual is written for the long outdated osmo-nitb (a combined BSC,MSC).
I have noticed that the wiki page for OpenBSC GPRS at https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_GPRS
has
not been updated for four years, and since then, there have been significant updates to the software. As a result, the information on the GPRS/EDGE Setup page may be outdated, and I am struggling to configure
GPRS
on my system.
I have attached my configuration files below for your review.
I would recommend to take a look into the https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In... But you already have configuration files for bsc, msc, sgsn, ggsn.
I would also recommend you to add an IP for every core network component and ran. Because it helps debugging to have the IPs seperate. For a local network (everything runs on the same host) I would do:
- 127.0.0.10 bts + pcu
- 127.0.0.11 bsc + bsc-mgw (yes running mgw twice)j
- 127.0.0.12 msc + osmo-sip-connector + msc-mgw
- 127.0.0.13 sgsn
- 127.0.0.14 ggsn
- 127.0.0.15 sip-server (e.g. asterix, ...)
- 127.0.0.16 hlr
You will need to change vty and ctrl interface ips as well.
Back to your current network. Are you running osmo-stp? osmo-stp is required for the new network.
Ok. but what is not working? Please add more information!
- Can your MS/UE connect to the network?
- CS: location update works?
- PS: routing area update works?
- Does your phones gets an IP? (PDP Context)
- Does `tcpdump -i tun4 -vn` shows any traffic?
Do you have a pcap trace? (Best to upload it to a website and only send the link on this mailinglist)
Your tun.network file looks wrong. The device should be named tun4 and the IP range is also wrong. Personally I wouldn't use systemd-networkd for this. At least I would expect routing issues. Also I wonder why there isn't a tun4 device.
Even if there is a tun4 device, you might missing the routing and depending on your setup, NAT/masquerading. I think you would need to run `ip route add 172.16.222.0/24 dev tun4` and `iptables -t nat -A POSTROUTING -j MASQUERADE -s 172.16.222.0/24 -o wlp1s0`
Best, lynxis
Hi Lynxis,
This time I am getting this following log.
osmo-pcu
<0009> tbf_dl_fsm.c:372 TBF(DL:TFI-0-0-0:STATE-ASSIGN:GPRS:IMSI-901550000123457:TLLI-0xd586ae05) releasing due to PACCH assignment timeout. <0002> pdch.cpp:348 PDCH(bts=0,trx=0,ts=4) PACKET CONTROL ACK with unknown FN=248629 TLLI=0xd586ae05 (TRX 0 TS 4) <0002> pdch.cpp:353 PDCH(bts=0,trx=0,ts=4) PACKET CONTROL ACK with unknown TBF corresponds to MS with IMSI 901550000123457, TA 0, uTBF (TFI=0, state=None), dTBF (TFI=0, state=ASSIGN) <0009> tbf_dl_fsm.c:372 TBF(DL:TFI-0-0-0:STATE-ASSIGN:GPRS:IMSI-901550000123457:TLLI-0xd586ae05) releasing due to PACCH assignment timeout. <0009> llc.c:326 MS(IMSI-901550000123457:TLLI-0xd586ae05:TA-0:MSCLS-12-12:UL:DL) Discarding LLC PDU because lifetime limit reached, count=5 new_queue_size=0 <0023> gprs_bssgp_bss.c:236 BSSGP (BVCI=1800) Tx LLC-DISCARDED TLLI=0xd586ae05, FRAMES=5, OCTETS=40 <0002> pdch_ul_controller.c:324 PDCH(bts=0,trx=0,ts=4) Timeout for registered POLL (FN=252689, reason=DL_ACK): TBF(DL:TFI-0-0-0:STATE-FLOW:GPRS:IMSI-901550000123457:TLLI-0xd586ae05) <0008> tbf.cpp:466 TBF(DL:TFI-0-0-0:STATE-FLOW:GPRS:IMSI-901550000123457:TLLI-0xd586ae05) poll timeout for FN=252689, TS=4 (curr FN 252689) <0008> tbf.cpp:543 TBF(DL:TFI-0-0-0:STATE-FLOW:GPRS:IMSI-901550000123457:TLLI-0xd586ae05) Timeout for polling PACKET DOWNLINK ACK: |Assignment was on PACCH|No downlink ACK received yet|
osmo-sgsn
20230521195557390 DMM INFO MM(901550000123457/d586ae05) -> ACTIVATE PDP CONTEXT REQ: SAPI=3 NSAPI=5 (gprs_sm.c:468) 20230521195557390 DMM INFO MM(901550000123457/d586ae05) Found GGSN 0 for APN 'internet' (requested 'internet') (mmctx.c:578) 20230521195557390 DGPRS NOTICE PDP(901550000123457/0) Create PDP Context (sgsn_libgtp.c:181) 20230521195557391 DGPRS INFO PDP(901550000123457/0) Received CREATE PDP CTX CONF, cause=128(Request accepted) (sgsn_libgtp.c:399) 20230521195557391 DSNDCP INFO SNSM-ACTIVATE.ind (lle=0x5651b2543258 TLLI=d586ae05, SAPI=3, NSAPI=5) (gprs_sndcp.c:526) 20230521195557391 DGPRS INFO PDP(901550000123457/0) <- ACTIVATE PDP CONTEXT ACK (gprs_sm.c:190) 20230521195557391 DLNSDATA INFO NSE(01800)-NSVC(01800) Tx NS-UNITDATA (gprs_ns2_message.c:426) 20230521195557391 DLLC NOTICE Sending XID type NULL (8 bytes) request to MS... (gprs_llc.c:364) 20230521195557391 DLNSDATA INFO NSE(01800)-NSVC(01800) Tx NS-UNITDATA (gprs_ns2_message.c:426) 20230521195557451 DLNSDATA INFO NSE(01800)-NSVC(01800) Rx NS-UNITDATA (gprs_ns2.c:1311) 20230521195557451 DLNSDATA INFO NSE(01800)-NSVC(01800) Rx NS-UNITDATA (gprs_ns2_vc_fsm.c:686) 20230521195557451 DMM INFO MM(901550000123457/d586ae05) -> ACTIVATE PDP CONTEXT REQ: SAPI=3 NSAPI=6 (gprs_sm.c:468) 20230521195557451 DMM INFO MM(901550000123457/d586ae05) Found GGSN 0 for APN 'internet' (requested 'internet') (mmctx.c:578) 20230521195557451 DGPRS NOTICE PDP(901550000123457/0) Create PDP Context (sgsn_libgtp.c:181) 20230521195557451 DGPRS INFO PDP(901550000123457/1) Received CREATE PDP CTX CONF, cause=220(Unknown PDP address or PDP type) (sgsn_libgtp.c:399) 20230521195557451 DMM NOTICE MM(901550000123457/d586ae05) <- ACTIVATE PDP CONTEXT REJ: Unknown PDP address or PDP type (gprs_sm.c:235) 20230521195557451 DLNSDATA INFO NSE(01800)-NSVC(01800) Tx NS-UNITDATA (gprs_ns2_message.c:426) 20230521195557931 DLNSDATA INFO NSE(01800)-NSVC(01800) Rx NS-UNITDATA (gprs_ns2.c:1311) 20230521195557931 DLNSDATA INFO NSE(01800)-NSVC(01800) Rx NS-UNITDATA (gprs_ns2_vc_fsm.c:686) 20230521195557931 DLLC NOTICE Received XID confirmation from MS. (gprs_llc.c:329) 20230521195557931 DLLC NOTICE Ignoring XID-Field: XID: type N201_I, data_len=2, data=05df (gprs_llc.c:202) 20230521195557931 DLLC NOTICE Ignoring XID-Field: XID: type N201_U, data_len=2, data=01f4 (gprs_llc.c:202) 20230521195557931 DLLC NOTICE Ignoring XID-Field: XID: type VERSION, data_len=1, data=00 (gprs_llc.c:202)
osmo-ggsn
20230521195334823 DTUN DEBUG TUN(apn0): APN(internet) Rx DL data packet for IP address outside pool of managed addresses: 224.0.0.251 <- 192.168.1.109 (ggsn.c:629) 20230521195334823 DTUN DEBUG TUN(apn0): APN(internet) Rx DL data packet for IP address outside pool of managed addresses: 224.0.0.251 <- 192.168.1.109 (ggsn.c:629) 20230521195334834 DTUN DEBUG TUN(apn0): APN(internet) Rx DL data packet for IP address outside pool of managed addresses: 224.0.0.22 <- 0.0.0.0 (ggsn.c:629) 20230521195335054 DTUN DEBUG TUN(apn0): APN(internet) Rx DL data packet for IP address outside pool of managed addresses: 224.0.0.22 <- 0.0.0.0 (ggsn.c:629) 20230521195335823 DTUN DEBUG TUN(apn0): APN(internet) Rx DL data packet for IP address outside pool of managed addresses: 224.0.0.251 <- 192.168.1.109 (ggsn.c:629) 20230521195335823 DTUN DEBUG TUN(apn0): APN(internet) Rx DL data packet for IP address outside pool of managed addresses: 224.0.0.251 <- 192.168.1.109 (ggsn.c:629) 20230521195337831 DTUN DEBUG TUN(apn0): APN(internet) Rx DL data packet for IP address outside pool of managed addresses: 224.0.0.251 <- 192.168.1.109 (ggsn.c:629) 20230521195337831 DTUN DEBUG TUN(apn0): APN(internet) Rx DL data packet for IP address outside pool of managed addresses: 224.0.0.251 <- 192.168.1.109 (ggsn.c:629) 20230521195505388 DLGTP DEBUG Registering seq=8212 in restransmit resp queue (gtp.c:503) 20230521195505388 DGGSN INFO PDP(901550000123457:5): Deleting PDP context (ggsn.c:354) 20230521195505388 DGGSN INFO SGSN(127.0.0.9): Deleting SGSN (sgsn.c:21) 20230521195505388 DLGTP DEBUG Begin pdp_tiddel tid = 5754321000055109 (pdp.c:296) 20230521195505388 DLGTP DEBUG End pdp_tiddel: PDP found (pdp.c:303) 20230521195521006 DLGTP DEBUG Retransmit resp queue seq 8212 expired, removing from queue (gsn.c:291) 20230521195556748 DLGTP DEBUG Begin pdp_tidget tid = 5754321000055109 (pdp.c:322) 20230521195556748 DLGTP DEBUG Begin pdp_tidget. Not found (pdp.c:330) 20230521195556748 DLGTP DEBUG Begin pdp_tidset tid = 5754321000055109 (pdp.c:277) 20230521195556748 DLGTP DEBUG End pdp_tidset (pdp.c:286) 20230521195556748 DGGSN DEBUG PDP(901550000123457:5): Processing create PDP context request for APN 'internet' (ggsn.c:446) 20230521195556748 DGGSN ERROR PDP(901550000123457:5): APN doesn't support requested EUA / AF type (ggsn.c:582) 20230521195556749 DLGTP DEBUG Registering seq=8213 in restransmit resp queue (gtp.c:503) 20230521195556749 DGGSN INFO PDP(901550000123457:5): Deleting PDP context (ggsn.c:354) 20230521195556749 DGGSN NOTICE PDP(901550000123457:5): Deleting PDP context: without private structure! (ggsn.c:367) 20230521195556749 DLGTP DEBUG Begin pdp_tiddel tid = 5754321000055109 (pdp.c:296) 20230521195556749 DLGTP DEBUG End pdp_tiddel: PDP found (pdp.c:303) 20230521195556749 DGGSN NOTICE GGSN(ggsn0): Received Recovery IE for unknown SGSN (no PDP contexts active) (ggsn.c:806) 20230521195557391 DLGTP DEBUG Begin pdp_tidget tid = 5754321000055109 (pdp.c:322) 20230521195557391 DLGTP DEBUG Begin pdp_tidget. Not found (pdp.c:330) 20230521195557391 DLGTP DEBUG Begin pdp_tidset tid = 5754321000055109 (pdp.c:277) 20230521195557391 DLGTP DEBUG End pdp_tidset (pdp.c:286) 20230521195557391 DGGSN DEBUG PDP(901550000123457:5): Processing create PDP context request for APN 'internet' (ggsn.c:446) 20230521195557391 DGGSN INFO SGSN(127.0.0.9): Discovered (sgsn.c:83) 20230521195557391 DGGSN DEBUG PDP(901550000123457:5): PCO Protocol 0x8021 (pco.c:205) 20230521195557391 DGGSN DEBUG PDP(901550000123457:5): PCO Protocol 0x000d (pco.c:205) 20230521195557391 DGGSN DEBUG PDP(901550000123457:5): PCO Protocol 0x000a (pco.c:205) 20230521195557391 DGGSN INFO PDP(901550000123457:5): Unknown/Unimplemented PCO Protocol 0x000a: (pco.c:220) 20230521195557391 DGGSN DEBUG PDP(901550000123457:5): PCO Protocol 0x0005 (pco.c:205) 20230521195557391 DGGSN INFO PDP(901550000123457:5): Unknown/Unimplemented PCO Protocol 0x0005: (pco.c:220) 20230521195557391 DGGSN DEBUG PDP(901550000123457:5): PCO Protocol 0x0010 (pco.c:205) 20230521195557391 DGGSN INFO PDP(901550000123457:5): Unknown/Unimplemented PCO Protocol 0x0010: (pco.c:220) 20230521195557391 DGGSN INFO PDP(901550000123457:5): Successful PDP Context Creation: APN=internet(internet), TEIC=1, IPv4=127.0.42.13, IPv6=none (ggsn.c:569) 20230521195557391 DLGTP DEBUG Registering seq=8214 in restransmit resp queue (gtp.c:503) 20230521195557451 DLGTP DEBUG Begin pdp_tidget tid = 6754321000055109 (pdp.c:322) 20230521195557451 DLGTP DEBUG Begin pdp_tidget. Not found (pdp.c:330) 20230521195557451 DLGTP DEBUG Begin pdp_tidset tid = 6754321000055109 (pdp.c:277) 20230521195557451 DLGTP DEBUG End pdp_tidset (pdp.c:286) 20230521195557451 DGGSN DEBUG PDP(901550000123457:6): Processing create PDP context request for APN 'internet' (ggsn.c:446) 20230521195557451 DGGSN ERROR PDP(901550000123457:6): APN doesn't support requested EUA / AF type (ggsn.c:582) 20230521195557451 DLGTP DEBUG Registering seq=8215 in restransmit resp queue (gtp.c:503) 20230521195557451 DGGSN INFO PDP(901550000123457:6): Deleting PDP context (ggsn.c:354) 20230521195557451 DGGSN ERROR PDP(901550000123457:6): Cannot find/free IP Pool member (ggsn.c:362) 20230521195557451 DGGSN NOTICE PDP(901550000123457:6): Deleting PDP context: without private structure! (ggsn.c:367) 20230521195557451 DLGTP DEBUG Begin pdp_tiddel tid = 6754321000055109 (pdp.c:296) 20230521195557451 DLGTP DEBUG End pdp_tiddel: PDP found (pdp.c:303) 20230521195612002 DLGTP DEBUG Retransmit resp queue seq 8213 expired, removing from queue (gsn.c:291) 20230521195613002 DLGTP DEBUG Retransmit resp queue seq 8214 expired, removing from queue (gsn.c:291) 20230521195613002 DLGTP DEBUG Retransmit resp queue seq 8215 expired, removing from queue (gsn.c:291)
osmo-bts-trx
<0000> rsl.c:1389 (bts=0,trx=0,ts=2,ss=0) not sending CHAN ACT ACK <0000> rsl.c:1389 (bts=0,trx=0,ts=3,ss=0) not sending CHAN ACT ACK <0000> rsl.c:1389 (bts=0,trx=0,ts=4,ss=0) not sending CHAN ACT ACK <0000> rsl.c:1389 (bts=0,trx=0,ts=7,ss=0) not sending CHAN ACT ACK <0000> rsl.c:1389 (bts=0,trx=0,ts=5,ss=0) not sending CHAN ACT ACK <0000> rsl.c:1389 (bts=0,trx=0,ts=6,ss=0) not sending CHAN ACT ACK
I have set apn as internet in my android device. And, I didn't configure any auth policy in osmo-hlr. Sims are registering through IMSI. [image: image.png]
Best regards, Tahmid
On Sun, 21 May 2023 at 15:29, Alexander 'lynxis' Couzens lynxis@fe80.eu wrote:
Hi Tahmid,
- osmo-bsc
<
https://docs.google.com/document/d/1mFRtjnOfecCFZSmAaA22GA_EM28rB59dIjftM_UX...
- osmo-sgsn
<
https://docs.google.com/document/d/1r3VfTNPlb-9XWU8FWfALh5kRr9502WgrSMuYXkqH...
your pcu can't connect to the sgsn. You tell your pcu to connect to 127.0.0.9:23001 The bsc is configuring the pcu via the bts. (bsc -> bts -> pcu) bsc-config: [...] gprs nsvc 0 remote ip 127.0.0.9 gprs nsvc 0 remote udp port 23001 gprs nsvc 0 local udp port 23002 gprs nsvc 0 nsvci 1800 [...]
But in your sgsn configuration you set the listen ip/port to 127.0.0.20:23000 [...] ns bind udp local listen 127.0.0.20 23000 accept-ipaccess [...]
Please change your bsc configuration to 127.0.0.20 and the remote udp port to 23000
gprs nsvc 0 remote ip 127.0.0.20 gprs nsvc 0 remote udp port 23000
Also your ggsn configuration has: ip dns 0 127.0.0.1
This will tell the phone to ask itself for dns queries. Please replace it with a valid dns server (e.g. 1.1.1.1)
Best, lynxis
On Sat, 20 May 2023 at 16:42, Alexander 'lynxis' Couzens <lynxis@fe80.eu
wrote:
Hi Ahnaf,
the structure of osmocom have changed since the manual has been
written.
The manual is written for the long outdated osmo-nitb (a combined
BSC,MSC).
I have noticed that the wiki page for OpenBSC GPRS at
https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_GPRS
has
not been updated for four years, and since then, there have been significant updates to the software. As a result, the information on
the
GPRS/EDGE Setup page may be outdated, and I am struggling to
configure
GPRS
on my system.
I have attached my configuration files below for your review.
I would recommend to take a look into the
https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In...
But you already have configuration files for bsc, msc, sgsn, ggsn.
I would also recommend you to add an IP for every core network
component
and ran. Because it helps debugging to have the IPs seperate. For a local network (everything runs on the same host) I would do:
- 127.0.0.10 bts + pcu
- 127.0.0.11 bsc + bsc-mgw (yes running mgw twice)j
- 127.0.0.12 msc + osmo-sip-connector + msc-mgw
- 127.0.0.13 sgsn
- 127.0.0.14 ggsn
- 127.0.0.15 sip-server (e.g. asterix, ...)
- 127.0.0.16 hlr
You will need to change vty and ctrl interface ips as well.
Back to your current network. Are you running osmo-stp? osmo-stp is required for the new network.
Ok. but what is not working? Please add more information!
- Can your MS/UE connect to the network?
- CS: location update works?
- PS: routing area update works?
- Does your phones gets an IP? (PDP Context)
- Does `tcpdump -i tun4 -vn` shows any traffic?
Do you have a pcap trace? (Best to upload it to a website and only send the link on this mailinglist)
Your tun.network file looks wrong. The device should be named tun4 and
the
IP range is also wrong. Personally I wouldn't use systemd-networkd for this. At least I would expect routing issues. Also I wonder why there isn't a tun4 device.
Even if there is a tun4 device, you might missing the routing and depending on your setup, NAT/masquerading. I think you would need to run `ip route add 172.16.222.0/24 dev tun4` and `iptables -t nat -A POSTROUTING -j MASQUERADE -s 172.16.222.0/24
-o
wlp1s0`
Best, lynxis
Hi,
On 5/21/23 16:17, Ahnaf Tahmid wrote:
20230521195557391 DGGSN INFO PDP(901550000123457:5): Successful PDP Context Creation: APN=internet(internet), TEIC=1, IPv4=127.0.42.13, IPv6=none (ggsn.c:569)
The problem is most probably that osmo-ggsn is assigning to the MS an Ip address from the 12.0.42.0-255 range, which is iirC of local host scope.
Try changing the address pool in the APN config in osmo-ggsn.cfg to provide a local area network range, such as 192.168.40.100-200. Also update accordingly the IP address set on the related tun device.
-
Ahnaf Tahmid -
Alexander 'lynxis' Couzens -
Pau Espin Pedrol