osmocom-net-gprs

osmocom-net-gprs@lists.osmocom.org

6 participants
480 discussions

Re: Dropping packet from invalid source address

by Holger Freyther

> On 06 Oct 2016, at 09:01, Peter Lithner <plithner(a)yahoo.com> wrote: > > Hello Holger, > > I can see packets now, after creating a PDP and running tcpdump on tun0. However, the ICMP requests I send are not GTP encapsulated as I would have expected, and I can only see the "downlink" data (the ping requests, and not the replies). The ping is successful though, so the replies are sent some way. Let's say tun1 is the SGSN emu device and you have a ICMP Request in it. The kernel will tell the sgsnemu process that new data is present and the sgsnemu will then wrap the data with GTP-u and send it to the GGSN. So you should be able to see the wrapped data on the loopback device. > And like I mentioned before, I can not force delays in packet delivery by temporarily pausing the GGSN with ctrl-z. > > What I did was, exactly what you proposed. I used your config, and you command lines (with the only exception that I created to virtual interfaces instead of using 127.0.0.1 and 127.0.0.2. I tried that as well though, and behaviour was the same. > > One thing that looks a bit odd, is that when I run tcpdump on tun0 (ggsn tun interface) and run ping, I can only see the "downlink" packets. That is to say, I only see the Ping requests and not the responses. The attachment shows this. > The setup once again: > Ubuntu 16.04.01 > ggsn installed with apt-get > ggsn.cfg: > root@ip-10-7-0-240:/home/ubuntu# cat ggsn.conf > listen 192.168.1.2 > logfile /tmp/foo > loglevel DEBUG > net 10.10.10.1/24 > pcodns1 8.8.8.8 > > ggsn command line: > ggsn -c ggsn.conf -f > > sgsnemu command line: > sgsnemu --listen 192.168.1.3 --remote 192.168.1.2 --apn internet --createif > > capture: > tcpdump -i tun0 -w tun0.pcap > ping: > ping -I tun1 10.10.10.1 > So if you trace on eth0 as well you should see ICMP Echo req and GTP+U ICMP echo req. As you trace on tun0 the GGSN has received GTP-u and wrote it into tun0. Now the kernel decides not to respond. E.g. maybe your cloud image has some kind of firewall, you could try to disable the rp_filter on tun0, etc.

8 years, 8 months

Re: Dropping packet from invalid source address

by Holger Freyther

> On 05 Oct 2016, at 18:01, Peter Lithner <plithner(a)yahoo.com> wrote: > >> Dear Peter, > Peter: Did you mean ggsn on 127.0.0.2 and client on 127.0.0.1? yes. > >> While sgsnemu is running a new interface will be created (e.g. tun1 due the --createif route). Can you check >which netmask is being set there? E.g. tun_addroute is called by the sgsnemu and it might capture more than >you wanted? And in that case filter on tcpdump -i tun1 as well. > > Peter: The thing is, that I do not see any tun1 interface (only the ton0 which is created when i start ggsn). This was what I meant in my original post. > > Anyway, I used your config, and in the log file I see this: > <0002> ggsn.c:283 Set file log level to DEBUG > <0002> ggsn.c:492 gtpclient: Initialising GTP tunnel > <000c> gtp.c:700 GTP: gtp_newgsn() started > <000c> gtp.c:661 State information file (/var/lib/ggsn/gsn_restart) not found. Creating new file. > <000c> gtp.c:682 fopen(path=/var/lib/ggsn/gsn_restart, mode=w) failed: Error = No such file or directory > <0002> ggsn.c:510 Creating tun interface > <0002> ggsn.c:516 Setting tun IP address > > I'm probably just missing some stupid/obvious thing in my setup... with tcpdumo you should really see this packet and what kind of message it is. I just tried the following in Debian 8.0 VM with the config I had posted: GGSN: sudo ./ggsn/ggsn -c ./../../ggsn.conf -f SGSN: sudo ./sgsnemu/sgsnemu -l 127.0.0.1 -r 127.0.0.2 -a "foo" --createif Using default DNS server Local IP address is: 127.0.0.1 (127.0.0.1) Remote IP address is: 127.0.0.2 (127.0.0.2) IMSI is: 240010123456789 (0xf987654321010042) Using NSAPI: 0 Using GTP version: 1 Using APN: foo Using selection mode: 1 Using MSISDN: 46702123456 Initialising GTP library <000c> gtp.c:701 GTP: gtp_newgsn() started Setting up interface Done initialising GTP library Sending off echo request Setting up PDP context #0 Waiting for response from ggsn........ Received echo response Received create PDP context response. IP address: 10.23.42.2 After network config: tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.23.42.1 P-t-P:10.23.42.1 Mask:255.255.255.0 UP POINTOPOINT RUNNING MTU:1500 Metric:1 RX packets:3 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:252 (252.0 B) TX bytes:0 (0.0 B) tun1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.23.42.2 P-t-P:10.23.42.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 B) TX bytes:252 (252.0 B) So tun0 has been allocated by the GGSN and tun1 by the SGSN ping -I tun1 10.23.42.1 PING 10.23.42.1 (10.23.42.1) from 10.23.42.2 tun1: 56(84) bytes of data. 64 bytes from 10.23.42.1: icmp_seq=1 ttl=64 time=0.223 ms 64 bytes from 10.23.42.1: icmp_seq=2 ttl=64 time=0.132 ms 64 bytes from 10.23.42.1: icmp_seq=3 ttl=64 time=0.134 ms 64 bytes from 10.23.42.1: icmp_seq=4 ttl=64 time=0.123 ms 64 bytes from 10.23.42.1: icmp_seq=5 ttl=64 time=8914 ms (I used CTRL+Z on the ggsn to see that there are actually delays). Can you try to repeat that? holger

8 years, 8 months

Dropping packet from invalid source address

by Peter Lithner

Hi I'm trying out openGGSN, currently running it on an Ubuntu 16.04 VM in Amazon. The reason I'm doing this is part of an evaluation I'm helping out with for a customer in the Telco-industry. I have been able to install, and run ggsn and sgsnemu to the point of sending the ECHO and creating the PDP-C (see attachment). However, I can't see that a network interface is created after the PDP-C has been accepted. According to the README on https://github.com/osmobuntu/openggsn that should happen: "After this it will attempt to establish a pdp context. If successful it will create a local interface and set up routing." Anyway, I have probably missed something in the setup. If you have any suggestions, that would be highly appreciated! What I did so far is: Install sudo apt-get update sudo apt-get install openggsn Create "virtual" interfaces (since I'm running everything on the same machine. Not sure if this is the right way to do it though) ifconfig eth0:0 192.168.1.2 netmask 255.255.255.0 up ifconfig eth0:1 192.168.1.3 netmask 255.255.255.0 up I also did the following steps, but I'm not sure exactly what they do... pardon my ignorance! 1. Add the following line to /etc/modules.conf: alias char-major-10-200 tun 2. depmod -a Start GGSN ggsn -c ggsn.conf --fg -l 192.168.1.2 --net 192.168.0.0/24 --dynip 192.168.0.0/24 After this I can see the new tun0 tun0: flags=81<UP,POINTOPOINT,RUNNING> mtu 1500 inet 192.168.0.1 netmask 255.255.255.0 destination 192.168.0.1 inet6 fe80::9ea3:6876:c4ce:fc96 prefixlen 64 scopeid 0x20<link> unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 7 bytes 448 (448.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 send ECHO (successfully) sgsnemu --listen 192.168.1.3 --remote 192.168.1.2 --dns 10.20.38.51 --timelimit 10 --contexts 0 Send ECHO + Create PDP-C sgsnemu --listen 192.168.1.3 --remote 192.168.1.2 --dns 10.20.38.51 --timelimit 10 --contexts 1 --apn internet --imsi 240011234567890 --msisdn 46702123456 --createif --defaultroute Which outputs the following: Using DNS server: 10.20.38.51 (10.20.38.51) Local IP address is: 192.168.1.3 (192.168.1.3) Remote IP address is: 192.168.1.2 (192.168.1.2) IMSI is: 240011234567890 (0xf098765432110042) Using NSAPI: 0 Using GTP version: 1 Using APN: internet Using selection mode: 1 Using MSISDN: 46702123456 Initialising GTP library <000c> gtp.c:700 GTP: gtp_newgsn() started After printing this line, sgsnemu stays very silent for 30-ish seconds, after which it prints (all in one go): Setting up interface Done initialising GTP library Sending off echo request Setting up PDP context #0 Waiting for response from ggsn........ Received echo response Received create PDP context response. IP address: 192.168.0.2 Dropping packet from invalid source address: 0.0.0.0 Dropping packet from invalid source address: 0.0.0.0 Dropping packet from invalid source address: 0.0.0.0 Dropping packet from invalid source address: 10.7.0.240 Dropping packet from invalid source address: 10.7.0.240 Dropping packet from invalid source address: 0.0.0.0 Dropping packet from invalid source address: 10.7.0.240 Dropping packet from invalid source address: 0.0.0.0 Dropping packet from invalid source address: 10.7.0.240 Dropping packet from invalid source address: 10.7.0.240 Dropping packet from invalid source address: 0.0.0.0 Dropping packet from invalid source address: 10.7.0.240 Dropping packet from invalid source address: 0.0.0.0 Dropping packet from invalid source address: 10.7.0.240 Disconnecting PDP context #0 Received delete PDP context response. Cause value: 128 Where 10.7.0.240 is the ip address of eth0 Once again, if you have any suggestions, I'm all ears! Thanks in advance! /peter

8 years, 8 months

[PATCH 0/2] OpenGGSN fixes for gsn_restart file path composition

by Neels Hofmeyr

Neels Hofmeyr (2): fix gsn_restart file buffer overflow and missing path sep gsn_restart file: set umask back to original after write failure gtp/gtp.c | 20 +++++++++----------- gtp/gtp.h | 1 - 2 files changed, 9 insertions(+), 12 deletions(-) -- 2.1.4

8 years, 8 months

sgsn segfault wegen sndcp / v42.bis commits?

by Neels Hofmeyr

I have a reproducable segfault in the SGSN, bisecting to below commit: (To bisect, I rearranged the commits, see branches neels/sndcp_bisect and neels/sndcp_bisect_bad in openbsc) ▶ git bisect bad 97991d56800fdc913e6fdf95cac68d598f66b498 is the first bad commit commit 97991d56800fdc913e6fdf95cac68d598f66b498 Author: Philipp <pmaier(a)sysmocom.de> Date: Fri Aug 26 17:00:21 2016 +0200 SNDCP: add RFC1144 header compression functionality - Add module to handle compression entities - Add module to control header compression - Introduce VTY commands for heade compression configuration - Add changes in sndcp and llc to integrate header compression Change-Id: Ia00260dc09978844c2865957b4d43000b78b5e43 :040000 040000 de76aa0ab5dc11ad81666f9f4c933544eedcd4f1 c199c47cd19b5a1a334020a598dba3e0be922fe5 M openbsc Reproduce: Have a 3G UE try to establish a PDP context. (basically just let it subscribe to the network with mobile data enabled.) Yes, this is on the sysmocom/iu branch. Note: the N-DATA.ind shows the correct hexdump and data length, but the backtrace shows that two lines below that a function is passed the values ctx=0x6cf9d0, data=0x0, len=140737316187968) at ranap_common_cn.c:310 So it looks like a stack corruption caused somewhere completely different. It's very reproducable though, even after rearranging things with other library states I always get the exact same place segfaulting: 20160927195152039 <001a> iu.c:755 N-DATA.ind(0, 60 00 00 1d 00 00 01 00 34 40 16 00 00 01 00 33 40 0f 60 28 dc 35 00 01 0a 09 01 0b 00 00 00 00 01 , len 33) 20160927195152039 <001a> iu.c:757 1msg 0x6d07a8 len 33 20160927195152039 <001a> iu.c:767 2msg 0x6d07a8 len 33 <RANAP_RAB-SetupOrModifiedList> <raB-SetupOrModifiedList-ies> <RANAP_IE> <id>51</id> <criticality><ignore/></criticality> <value>60 28 DC 35 00 01 0A 09 01 0B 00 00 00 00 01</value> </RANAP_IE> </raB-SetupOrModifiedList-ies> </RANAP_RAB-SetupOrModifiedList> 20160927195152039 <001a> iu.c:460 handle_co(dir=4, proc=0) 20160927195152039 <001a> iu.c:433 RAB Asignment Response:<RANAP_RAB-SetupOrModifiedItem> <rAB-ID> 00000101 </rAB-ID> <transportLayerAddress> 00110101000000000000000100001010000010010000000100001011 </transportLayerAddress> <iuTransportAssociation> <gTP-TEI>00 00 00 01</gTP-TEI> </iuTransportAssociation> </RANAP_RAB-SetupOrModifiedItem> Setup: (5/35 00 01 0a 09 01 0b )20160927195152039 <001a> sgsn_libgtp.c:483 Updating TEID on RNC side from 0x00000001 to 0x00000001 20160927195152039 <000f> gprs_gmm.c:2031 PDP(901990000000038/0) <- ACTIVATE PDP CONTEXT ACK 20160927195152039 <001a> iu.c:398 Transmitting L3 Message as RANAP DT (SUA link 0x6ce280 conn_id 0) <RANAP_IE> <id>16</id> <criticality><ignore/></criticality> <value> 31 8A 42 03 0E 23 62 1F 72 99 3F 3F 11 43 FF FF 00 00 00 00 2B 06 01 21 0A 17 2A 02 27 14 80 80 21 10 02 00 00 10 81 06 08 08 08 08 83 06 00 00 00 00 </value> </RANAP_IE> <RANAP_IE> <id>59</id> <criticality><ignore/></criticality> <value>00</value> </RANAP_IE> 20160927195152039 <001b> sua.c:591 Received SCCP User Primitive (N-DATArequest) 20160927195152039 <001b> sua.c:245 sua_link_send(01 00 08 08 00 00 00 60 00 06 00 08 00 00 00 00 01 05 00 08 00 00 03 e8 01 0b 00 46 00 14 00 3e 00 00 02 00 10 40 32 31 8a 42 03 0e 23 62 1f 72 99 3f 3f 11 43 ff ff 00 00 00 00 2b 06 01 21 0a 17 2a 02 27 14 80 80 21 10 02 00 00 10 81 06 08 08 08 08 83 06 00 00 00 00 00 3b 40 01 00 00 00 ) Program received signal SIGSEGV, Segmentation fault. sndcp_sn_xid_req (lle=0x340, nsapi=5 '\005') at gprs_sndcp.c:926 926 gprs_sndcp_comp_free(lle->llme->comp.proto); (gdb) bt #0 sndcp_sn_xid_req (lle=0x340, nsapi=5 '\005') at gprs_sndcp.c:926 #1 0x0000000000415681 in send_act_pdp_cont_acc (pctx=0x6d0290) at sgsn_libgtp.c:346 #2 0x0000000000416ba6 in sgsn_ranap_rab_ass_resp (ctx=0x340, setup_ies=0x0) at sgsn_libgtp.c:492 #3 0x0000000000422e28 in ranap_handle_co_rab_ass_resp (ies=<optimized out>, ies=<optimized out>, ctx=<optimized out>) at iu.c:445 #4 cn_ranap_handle_co (ctx=0x6cf9d0, message=0x0) at iu.c:510 #5 0x00007ffff5909f60 in ranap_cn_rx_co (cb=0x422890 <cn_ranap_handle_co>, ctx=0x6cf9d0, data=0x0, len=140737316187968) at ranap_common_cn.c:310 #6 0x0000000000423d1c in sccp_sap_up (oph=0x6d06a8, link=0x6ce280) at iu.c:768 #7 0x00007ffff5be6c7f in sua_rx_codt (xua=<optimized out>, link=<optimized out>) at sua.c:1164 #8 sua_rx_co (msg=<optimized out>, xua=<optimized out>, link=<optimized out>) at sua.c:1196 #9 sua_rx_msg (link=0x0, msg=0x5) at sua.c:1232 #10 0x00007ffff5be7042 in sua_srv_conn_cb (conn=0x6cf300) at sua.c:1360 #11 0x00007ffff4c4c881 in osmo_stream_srv_read (conn=0x6ce1b0) at stream.c:512 #12 osmo_stream_srv_cb (ofd=<optimized out>, what=1) at stream.c:563 #13 0x00007ffff79bab82 in osmo_fd_disp_fds (_eset=0x7fffffffe360, _wset=0x7fffffffe2e0, _rset=0x7fffffffe260) at select.c:149 #14 osmo_select_main (polling=0) at select.c:191 #15 0x0000000000404ee2 in main (argc=3, argv=0x0) at sgsn_main.c:448 (gdb) How do we do this? Revert Philipps commits for now? I need to go now, but next I'll take a short look whether I can reproduce with other hardware / spot a bug anywhere. No idea yet whether it only happens for 3G. ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

8 years, 8 months

RE: GTP-u Kernel module

by Ferrer Guasch Vicent

> On my side, I have no plans to add what you need, so patches are very > welcome. I can help providing indications on how to get things done if you > have time to work on this. So I would suggest you fire at one front at a time. > > I would start by adding the assymmetric tunnel ID allocation that you need, > which should not be too complicated to add. You have to extend the netlink > interface that we have on gtp to support this. > Thanks Pablo for the kind response, I will study the docs and the gtp module and try to propose some patches. Rgds, Vicent

8 years, 8 months

GTP-u Kernel module

by Ferrer Guasch Vicent

Hi! We are affiliated with Aalto University and conducting research in the area of mobile networks. We have been improving Amit Chawre's project NwEPC<https://sourceforge.net/projects/nwepc/>. I saw your implementation of the GTP-U kernel module and I started to check If I could integrate it to this project. I couldn't find any roadmap of the GTP-U in your website. Do you have any future plans for it? I am interested in the following points: - Creation, modification and removal of unidirectional tunnels, opposed to the creation of both tunnels without possibility of modification. In the real EPC nodes, the tunnels are never created at the same time. Also they can be removed due to the UE moving to Idle state (i.e. GTP downlink between the eNB and the S-GW). - Possibility to send End Marker and direct and indirect forwarding tunnels. - The S-GW receive from a GTP endpoint and sends it to a different one. What mechanisms do you have in mind to do this? - Support of multiple EPS bearers for the same UE. - Policy control, enforcement and statistics reporting (probably integrating it with netfilter). How can I contribute to this project. Should I work on the whole kernel tree? I have no experience with kernel module development. If you want I could work on some API modification proposals and designs. Kind Regards, Vicent Ferrer Guasch PhD candidate Networking Technology Department of Communications and Networking Aalto University

8 years, 8 months

OVS GTP-U patch

by Ashish Kurian

Dear Members, I have applied the GTP-U patch for OVS which was available online and it was applied successfully. But now I realised that a GTP-U kernel space implementation is available from you. I am not sure of the interplay of OVS and linux kernel. The patch for the OVS works in the kernel space and if I want to use the patched OVS with your linux kernel patch, should I do some modifications to the patch? Best Regards, Ashish Kurian

8 years, 8 months

High level summary of the performance activity done by Radisys using NuRAN 1.0 platform

by Aravind Sirsikar

Hi All, Below is the high level summary of the performance activity carried on NuRAN 1.0 board with Commercial UE and Dongle under lab conditions. * Single MS test 1. UL Test a. Performance test for long duration (24 hours) for EGPRS Uplink (MCS9) with stable data rate of 45.2kbps 2. DL Test b. Performance test for long duration (24 hours) for EGPRS downlink(MCS9) with stable throughput of 223kbps with all slots configured for single UE c. Performance test for all EGPRS MCS(MCS1-MCS9) with stable expected throughput d. Stress test for short duration with more than theoretical max data rate (MCS9) without any breakage in the system. e. Stress test for short duration with signaling load (MCS8) without any breakage in the system. f. Speed test through speedtest.net downlink - 210kbps uplink - 40kbps * Multi MS test 3. DL Test a. Performance test for long duration (24 hours) for EGPRS downlink (4 UEs - MCS9) with a combined cell throughput of 223kbps. Following are the links to the issues raised in Redmine and related patch information which is merged in master 1. https://osmocom.org/issues/1811 a. https://git.osmocom.org/osmo-pcu/commit/?id=22a901905c9749b03fceccda4d550f3… b. https://git.osmocom.org/osmo-pcu/commit/?id=3463bd4adc1598462560ed84da837d0… 2. https://osmocom.org/issues/1808 a. https://git.osmocom.org/osmo-pcu/commit/?id=e26ee01d56b4c4c2da6abc6b649cb76… b. https://git.osmocom.org/osmo-pcu/commit/?id=8e70bb5bb4751e3a7f33b95b2994bff… c. https://git.osmocom.org/osmo-pcu/commit/?id=0ee31cfa381282d0d724fb36c48bae2… 3. https://osmocom.org/issues/1806 a. https://git.osmocom.org/osmo-pcu/commit/?id=a35c911a91ea7b6d8b017fd103c0d86… b. https://git.osmocom.org/osmo-pcu/commit/?id=7c7a86c080edd9c92778c941bbe484f… 4. https://osmocom.org/issues/1805 a. https://git.osmocom.org/osmo-pcu/commit/?id=9f5f008aedc910ff0ce18bf3f92b9b7… b. https://git.osmocom.org/osmo-pcu/commit/?id=024152683646f1b68c85de74f783b81… 5. https://osmocom.org/issues/1792 a. https://git.osmocom.org/osmo-pcu/commit/?id=e26ee01d56b4c4c2da6abc6b649cb76… Below issue in Redmine is still pending to be submitted to master. 1. https://osmocom.org/issues/1789 Relevant PCU configuration used is present at https://git.osmocom.org/radisys/osmo-pcu/commit/?h=radisys/egprs_integratio… Thanks, Aravind Sirsikar

8 years, 9 months

[PATCH 1/3] Fix possible buffer overflow for gsn_restart file path

by Neels Hofmeyr

For strncat, to obtain n, one must not subtract the length of what is appended, but the length of what is already written from the buffer size. Verified with this little test program: #include <stdio.h> #include <string.h> int main() { char buf[20]; strncpy(buf, "123", 10); strncat(buf, "456789012345", 10 - strlen(buf)); printf("%s\n", buf); return 0; } It prints "1234567890". --- gtp/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gtp/gtp.c b/gtp/gtp.c index 12cb492..55a8ce4 100644 --- a/gtp/gtp.c +++ b/gtp/gtp.c @@ -650,7 +650,7 @@ static void log_restart(struct gsn_t *gsn) filename[NAMESIZE - 1] = 0; /* No null term. guarantee by strncpy */ strncpy(filename, gsn->statedir, NAMESIZE - 1); - strncat(filename, RESTART_FILE, NAMESIZE - 1 - sizeof(RESTART_FILE)); + strncat(filename, RESTART_FILE, NAMESIZE - 1 - strlen(filename)); i = umask(022); -- 2.1.4

8 years, 9 months

← Newer
1
...
27
28
29
30
31
32
33
...
48
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs