osmocom-net-gprs

osmocom-net-gprs@lists.osmocom.org

6 participants
480 discussions

by None

* With multiple TBF assignment the tbf_by_tlli will return a list =A0 anyway. * For the multiple RACH cases we could it probably handle it more =A0 nicely. E.g. avoid this: <0005> bts.cpp:1035 Got RACH from TLLI=3D0xcf7611f6 while TBF(TFI=3D0= TLLI=3D0xcf7611f6 DIR=3DDL) still exists. Killing pending DL TBF <0002> bts.cpp:359 Got IMM.ASS confirm, but TLLI=3Dcf7611f6 does not = exit -- - Holger Freyther <<a href=3D"mailto:hfreyther@sysmocom.de">hfreyther@sy= smocom.de</a>> =A0 =A0 =A0 <a href=3D"http://www.sysmocom.de/" target=3D= "_blank">http://www.sysmocom.de/</a> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte </blockquote></div> </div> --20cf301d42625eb38c04ea05cbef--

3 years, 5 months

None

by None

* With multiple TBF assignment the tbf_by_tlli will return a list anyway. * For the multiple RACH cases we could it probably handle it more nicely. E.g. avoid this: <0005> bts.cpp:1035 Got RACH from TLLI=0xcf7611f6 while TBF(TFI=0 TLLI=0xcf7611f6 DIR=DL) still exists. Killing pending DL TBF <0002> bts.cpp:359 Got IMM.ASS confirm, but TLLI=cf7611f6 does not exit -- - Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

3 years, 5 months

None

by None

if we should use more C++ features (I am not talking STL, operator overloading)? Any opinions? holger PS: I think we should find a more nice solution to extern "C".. I spent various minutes trying to figure out which parts of the pcu have C linkage and which C++.. For things from libosmocore it is obvious.. but then we have the vty_info... -- - Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

3 years, 5 months

None

by None

bug fixes. Ideally I'd love to see Andreas developing them on top of the current 'master' and submitting them to the mailing list as soon as he push them. This way Ivan (and everyone else) would be able to review them and merge as soon as possible. I hate the situation when fixes are stored in a private branch and are not merged into mainline. On Mon, Nov 26, 2012 at 5:02 PM, Ivan Kluchnikov <Ivan.Kluchnikov(a)fairwaves.ru> wrote: > Hi, all! > > I absolutely agree with Harald and I am ready to use described life-cycle > model for osmo-pcu. > Before that time I merged branch 'jolly', when the differences between > master and jolly become critical. > I didn't coordinate merges with Andreas and jolly branch wasn't rebased > before merges. I think, it was my mistake. > Now I am ready to merge jolly branch at any time, when Andreas indicates > that his branch is ready for merge. > > > 2012/11/25 Harald Welte <laforge(a)gnumonks.org> >> >> Dear all, >> >> it is a pity to see that since many weeks there has been no progress on >> merging any of Andreas' work. I think everyone involved is to be >> blamed to some extent. Andreas because the provided branches are not >> kept clean, Ivan probably for lack of time, and me for not paying more >> attention and helping this process along. >> >> The general life-cycle in any project, including osmo-pcu, should be as >> follows: >> >> * contributor starts on some improvements, creates private branch >> * master advances meanwhile >> * contributor rebases (not merges!) his changes on top of more recent >> master >> * contributor indicates that his branch is ready for merge >> * maintainer merges (some of?) the commits of the contributor branch >> * contributor re-bases remaining commits on new master >> * contributor requests merge of remaing patches >> ... >> >> If I open 'gitk' on any of the branches (master / jolly / jolly_dsp) I >> get grey hair (to say the least). One would normally expect: >> >> 1) 'jolly' to be based on some (maybe not current) master >> >> 2) 'jolly_dsp' to be based on 'jolly' >> >> Neither of the two is the case. I've tried to >> * rebase jolly on top of master >> as well as >> * rebase jolly_dsp on top of jolly >> >> and both are impossible due to the series of merges and the unclear >> ancestry / relationship of the branches. Or, just for fun, try 'git >> diff origin/jolly..origin/jolly_dsp. It shows you anything else but >> what one would expect >> >> Andreas: Please take some time to clean up the mess. Your 'jolly' >> branch should contain a series of clean per-feature commit's on top of >> current master, and 'jolly_dsp' should be a set of few patches on top of >> 'jolly'. >> >> This way there is always a clean queue of changesets that Ivan can merge >> (or cherry-pick). I can understand that if I was in Ivan's place, I >> would not really know where to even start merging some of those >> contributions. >> >> Thanks for everyone's attention. Please take some time to get this >> resolved. Let me know if you have some questions. There are plenty of >> people with lots of git experience around (Holger, Pablo, myself) who >> can help if something is unclear. >> >> Regards, >> Harald >> >> -- >> - Harald Welte <laforge(a)gnumonks.org> >> http://laforge.gnumonks.org/ >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >> "Privacy in residential applications is a desirable marketing option." >> (ETSI EN 300 175-7 Ch. >> A6) >> > > > > -- > Regards, > Ivan Kluchnikov. > http://fairwaves.ru > --=20 Regards, Alexander Chemeris. CEO, Fairwaves LLC / =D0=9E=D0=9E=D0=9E =D0=A3=D0=BC=D0=A0=D0=B0=D0=B4=D0= =B8=D0=BE http://fairwaves.ru

3 years, 5 months

Osmocom CNI release 202111

by Pau Espin Pedrol

Dear all, I am pleased to announce new tagged releases for Osmocom Cellular Network Infrastructure components. Find more information about the release here [1]. Osmocom "Latest" repositories in OBS [2] should already contain packages for the new versions. OpenEmbedded related meta-layers such as meta-telephony usual stable/testing branch "201705" [3] have also been updated to build recipes for new versions. Regards, Pau [1] https://osmocom.org/news/152 [2] https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds [3] https://git.osmocom.org/meta-telephony/log/?h=201705 -- - Pau Espin Pedrol <pespin(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 * Geschaeftsfuehrer / Managing Director: Harald Welte

3 years, 6 months

TTCN-3 tests for MME

by Mirko Kovacevic

Hi, Osmonians, I don't know where to write for MME TTCN-3, so I chose to write to it closet relative - SGSN. I was trying to do slight modification to TTCN-3 code, modifing S1AP_Templates.ttcn. I embedded enodeb name for all tests with new protoc-IE = id-eNBname : ################################## template (value) S1AP_PDU ts_S1AP_SetupReq(template (value) Global_ENB_ID p_global_ENB_ID, template (value) SupportedTAs p_supportedTAs, template (value) PagingDRX p_pagingDRXs) := { initiatingMessage := { procedureCode := id_S1Setup, criticality := reject, value_ := { S1SetupRequest := { protocolIEs := { { id := S1AP_Constants.id_Global_ENB_ID, criticality := ignore, value_ := { Global_ENB_ID := p_global_ENB_ID } }, { id := S1AP_Constants.id_SupportedTAs, criticality := reject, value_ := {SupportedTAs := p_supportedTAs} }, { id := S1AP_Constants.id_eNBname,//id-eNBname criticality := ignore, value_ := {ENBname := "OsmoEnodeb"} } /* HACK: work around nextepc bug , { id := S1AP_Constants.id_pagingDRX, criticality := ignore, value_ := {PagingDRX := p_pagingDRXs} } */ } } } } } ######################## Code compiles, but PDU is not encoded well. I attached Wireshark preview. Can you help me with this issue ? -- Puno pozdrava, Mirko Kovacevic

3 years, 7 months

Osmocom redmine upgrade / Let me know if something broke

by Harald Welte

Dear Osmocom community, today we finally upgraded our redmine installation from the unmaintained 3.4.x to the latest 4.2.3. The upgrade had been overdue for years, but today we (actually, Kevin) finally managed to find out how to make the openid_provider plugin to work with modern rails 5.x. In any case, I'm just informing you in case there is some unexpected fallout. I've verified that at least the following appears working: * logging into redmine * openid authentication from gerrit.osmocom.org (also after logout/relogin) * graphviz rendering * mscgen rendering There could however still be unexpected problems, particularly in features such as * e-mail notifications from redmine * updating redmine issues via e-mail * git integration ("Closes: OS#xxxx") If you run into any troubles, pleas report to https://osmocom.org/projects/osmocom-servers or if that also fails, feel free to send e-mails. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

3 years, 7 months

[PATCH net-next] gtp: use skb_dst_update_pmtu_no_confirm() instead of direct call

by Gyeongun Kang

skb_dst_update_pmtu_no_confirm() is a just wrapper function of ->update_pmtu(). So, it doesn't change logic Signed-off-by: Gyeongun Kang <kyeongun15(a)gmail.com> --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 30e0a10595a1..24e5c54d06c1 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -539,7 +539,7 @@ static int gtp_build_skb_ip4(struct sk_buff *skb, struct net_device *dev, mtu = dst_mtu(&rt->dst); } - rt->dst.ops->update_pmtu(&rt->dst, NULL, skb, mtu, false); + skb_dst_update_pmtu_no_confirm(skb, mtu); if (!skb_is_gso(skb) && (iph->frag_off & htons(IP_DF)) && mtu < ntohs(iph->tot_len)) { -- 2.25.1

3 years, 8 months

RFC PATCHES - Merge gtp driver with https://github.com/free5gc/gtp5g

by Richard Haines

Harald, As requested I've copied this to the osmocom-net-gprs(a)lists.osmocom.org list. I'm not sure if any of you are interested in this (or even if it's useful as the "gtp5g" module is still 'work in progress'), however if you are interested any comments ??. I've attached a tarball (gtp-patches.tar.xz) with all the patches and here are some notes: 1) This has been built and tested on Fedora 34 using linux-5.14-rc4 kernel. 2) The first two kernel patches reinstall the current gtp driver into manageable modules. You can build the kernel with just these patches and should still be able to use libgtpnl, osmo-ggsn etc. as no code changes. 3) The remaining three kernel patches install the services from https://github.com/free5gc/gtp5g to DRV_VERSION "1.0.3a", also update core services (where possible) to use common functions e.g. gtp_dev_xmit(). It is possible to implement more common functions, but that can be done if the patch series is of any use !!! 4) There are three possible Kconfig configuration options: GTP_PDP only - GTP_PDR only - GTP_PDP and GTP_PDR 5) If GTP_PDP and GTP_PDR build selected, the basic tests using osmo-ggsn or openggsn work using tests in [1] and the tests from libgtp5gnl [2] (./run.sh SimpleUPTest & ULCLTest1) will also run - provided the following tarball patch has been applied to update [2]: 0001-libgtp5gnl-Update-to-match-new-linux-gtp.h-entries.patch 6) Be aware that apps/libs should now define their role specifically (i.e. GTP_ROLE_SGSN, GTP_ROLE_RAN) and not default thinking that '0' will always be GTP_ROLE_GGSN or GTP_ROLE_UPF. Both libgtp*nl versions do this. 7) I've only limited test options so cannot guarantee all will work !! 8) The kernel and tests have been built using Fedora 34. When building the kernel with Fedora the gtp5g side will hang when testing. This happens whether I build/load as described in the https://github.com/free5gc/gtp5g README i.e. untouched by me, or with my patches. To solve this issue I've commented out some code in pdr.c pdr_context_free() with a comment: /* FIXME - Stop crash when kernel built on Fedora 34 */ I'll try and fix this at some stage. 9) The original gtp5g driver 'struct net_device_ops' used: .ndo_get_stats64 = ip_tunnel_get_stats64, However this is deprecated so set to: .ndo_get_stats64 = dev_get_tstats64, 10) Running checkpatch on the kernel patches will show plenty of warning and check messages, however all 'errors' are fixed. 11) I've patches that add the LSM/SELinux services, however have not included these as I guess still nfi. [1] https://osmocom.org/projects/linux-kernel-gtp-u/wiki/Basic_Testing [2] https://github.com/free5gc/libgtp5gnl Richard Haines (5): gtp: Delete current gtp driver gtp: Split gtp driver into modules gtp: Add support for PDR services - Part 1 gtp: Add support for PDR services - Part 2 gtp: Add support for PDR services - Part 3 drivers/net/Kconfig | 17 +- drivers/net/Makefile | 2 +- drivers/net/gtp.c | 1462 ---------------------------- drivers/net/gtp/Kconfig | 45 + drivers/net/gtp/Makefile | 8 + drivers/net/gtp/dev_core.c | 103 ++ drivers/net/gtp/encap.c | 406 ++++++++ drivers/net/gtp/far.c | 596 ++++++++++++ drivers/net/gtp/gtp_core.c | 243 +++++ drivers/net/gtp/include/dev_core.h | 59 ++ drivers/net/gtp/include/encap.h | 27 + drivers/net/gtp/include/far.h | 64 ++ drivers/net/gtp/include/gtp_core.h | 105 ++ drivers/net/gtp/include/nl_core.h | 18 + drivers/net/gtp/include/pdp.h | 53 + drivers/net/gtp/include/pdp_ipv4.h | 31 + drivers/net/gtp/include/pdr.h | 96 ++ drivers/net/gtp/include/pdr_ipv4.h | 49 + drivers/net/gtp/include/proc_dbg.h | 85 ++ drivers/net/gtp/include/qer.h | 49 + drivers/net/gtp/nl_core.c | 444 +++++++++ drivers/net/gtp/pdp.c | 578 +++++++++++ drivers/net/gtp/pdp_ipv4.c | 166 ++++ drivers/net/gtp/pdr.c | 1272 ++++++++++++++++++++++++ drivers/net/gtp/pdr_ipv4.c | 330 +++++++ drivers/net/gtp/proc_dbg.c | 384 ++++++++ drivers/net/gtp/qer.c | 463 +++++++++ include/net/gtp.h | 105 +- include/uapi/linux/gtp.h | 200 +++- include/uapi/linux/if_link.h | 5 + 30 files changed, 5981 insertions(+), 1484 deletions(-) delete mode 100644 drivers/net/gtp.c create mode 100644 drivers/net/gtp/Kconfig create mode 100644 drivers/net/gtp/Makefile create mode 100644 drivers/net/gtp/dev_core.c create mode 100644 drivers/net/gtp/encap.c create mode 100644 drivers/net/gtp/far.c create mode 100644 drivers/net/gtp/gtp_core.c create mode 100644 drivers/net/gtp/include/dev_core.h create mode 100644 drivers/net/gtp/include/encap.h create mode 100644 drivers/net/gtp/include/far.h create mode 100644 drivers/net/gtp/include/gtp_core.h create mode 100644 drivers/net/gtp/include/nl_core.h create mode 100644 drivers/net/gtp/include/pdp.h create mode 100644 drivers/net/gtp/include/pdp_ipv4.h create mode 100644 drivers/net/gtp/include/pdr.h create mode 100644 drivers/net/gtp/include/pdr_ipv4.h create mode 100644 drivers/net/gtp/include/proc_dbg.h create mode 100644 drivers/net/gtp/include/qer.h create mode 100644 drivers/net/gtp/nl_core.c create mode 100644 drivers/net/gtp/pdp.c create mode 100644 drivers/net/gtp/pdp_ipv4.c create mode 100644 drivers/net/gtp/pdr.c create mode 100644 drivers/net/gtp/pdr_ipv4.c create mode 100644 drivers/net/gtp/proc_dbg.c create mode 100644 drivers/net/gtp/qer.c -- 2.31.1

3 years, 10 months

[PATCH net-next] gtp: Fix a typo

by Zheng Yongjun

Suppport ==> Support Signed-off-by: Zheng Yongjun <zhengyongjun3(a)huawei.com> --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 39c00f050fbd..1c9023d47e00 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -436,7 +436,7 @@ static inline void gtp1_push_header(struct sk_buff *skb, struct pdp_ctx *pctx) gtp1->length = htons(payload_len); gtp1->tid = htonl(pctx->u.v1.o_tei); - /* TODO: Suppport for extension header, sequence number and N-PDU. + /* TODO: Support for extension header, sequence number and N-PDU. * Update the length field if any of them is available. */ } -- 2.25.1

4 years

← Newer
1
...
6
7
8
9
10
11
12
...
48
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs