Hi,
I am a bit lost with the review of the current osmo-pcu patchset. Going through
the patches I have difficulties to see the red thread and what is better after
we integrate the changes.
I guess the goal is to add the allocation of multiple uplink timeslots but from
my point of view this is buried in a lot of subjective sideway development. My
wish would be:
For multiple slot UL allocation:
Make the most direct patchset to implement this feature. I understand that to
avoid code duplication some methods can be re-used but instead of having 10
patches that change int->bool, change signatures of functions, maybe make it
minimal to see how it works first?
After it works send a cover mail that explains what and why you took the
approach, what the _speed_ improvement for browsing is or when it is being
used. What you see the danger in terms of common ts and allocation.
For the clean-ups:
I don't say we shouldn't do them but we should do them in a way they don't
take much time to review and still provide a net gain to the contributor.
A "cosmetic" patch that breaks the build is very suspicious and forces a
reviewer to look extra carefully into these "clean-ups".
int->bool:
I think int->bool and 1->true adds little value for an application but if
it is important then please do it by semantic patching so they can be easily
reviewed.
bts->trx:
I think there is little value to change a function signature from getting
a BTS to a TRX when the implementation starts to do:
- bts->list
+ trx->bts->list
"API" documentation:
Comments can be helpful and it is good to explain on a high level what a
function will do and what the side-effects will be. But in an application
I think writing:
\param[in,out] bts Pointer to BTS struct
adds not enough value. First it is wrong as the type is not "BTS" but it
is the "C" gprs_rlcmac_bts. And second doxygen will perfectly tell you the
type of of the parameter anyway.
Documenting that -1 of a parameter has a specific semantic can have some
advantage but the risk of code/doc not agreeing is there as well.
libosmocore:
We do have a desire for reuse but everytime you make osmo-pcu depend on a
unreleased version of libosmocore rebuilding osmo-pcu get's more difficult
and the compile error is not obvious. It is not clear where the macro is
coming from. So please keep this in mind and try to find a balance.
thank you for your consideration
holger
Hi all,
we have recently merged a profound change to the inner workings of the VTY
configuration. We've hit some fallout due to that, hence I would like to let
you know that you might hit the same.
The VTY parsing of config files is now strict about indenting.
A child node *must* be indented below the parent node,
and indenting must be consistent.
For more details on the reason why and a definition of 'consistent', see the
commit log of
https://git.osmocom.org/libosmocore/commit/?id=4a31ffa2f0097d96201f80305a04…
So, if you are in the near future faced with config files being rejected that
worked perfectly before, it is most probably because your indenting was wrong
all the time, and only now did we start checking it.
If the cause is hard to figure out, a good aid is the telnet VTY, where you may
either 'show running-config' or traverse the nodes manually to query which
command exists on which level. If your current config is broken, you may be
able to start the program with an empty or stripped down config file to make
its telnet available.
The above is about reading config files, but we have also dropped the implicit
'exit' to parent level on the telnet VTY console. This caused fallout where
nodes by plain omission lack the 'exit' command: one is unable to leave such a
node once it is entered. That is a fault in the program's VTY setup that was
not found before, because the VTY would often just find the parent node's exit
command instead. I have a patch to avoid all of these everywhere, by
installing the exit and end commands automatically for every VTY node that gets
created; it is not merged yet: https://gerrit.osmocom.org/3998
------ Config Fallout Example ------
For example, we hit a breakage with this osmo-bts-trx.cfg:
phy 0
instance 0
osmotrx rx-gain 25
osmotrx tx-attenuation oml
osmotrx ip local 10.23.42.1
osmotrx ip remote 10.23.42.2
Before, this worked perfectly. Now it says the command 'osmotrx rx-gain' does
not exist. The reason is that 'osmotrx rx-gain' is a child node of 'instance
0'. The first fix looked like this:
phy 0
instance 0
osmotrx rx-gain 25
osmotrx tx-attenuation oml
osmotrx ip local 10.23.42.1
osmotrx ip remote 10.23.42.2
But alas, this time it said the command 'osmotrx ip local' does not exist. I
suspected bugs in the new parsing, but indeed, 'osmotrx ip' is actually a
direct child of the 'phy 0' level. Before, the VTY would implicitly step out of
a child level if it found a matching command one parent above. That is
confusing in other situations (see above commit log), hence we now require
indenting to clarify the structure. This is the correct one:
phy 0
instance 0
osmotrx rx-gain 25
osmotrx tx-attenuation oml
osmotrx ip local 10.23.42.1
osmotrx ip remote 10.23.42.2
Or rephrased:
phy 0
osmotrx ip local 10.23.42.1
osmotrx ip remote 10.23.42.2
instance 0
osmotrx rx-gain 25
osmotrx tx-attenuation oml
To query the structure via telnet, I did:
$ ./osmo-bts/src/osmo-bts-trx/osmo-bts-trx -c osmo-bts/doc/examples/trx/osmo-bts.cfg
$ telnet localhost 4241
OsmoBTS> enable
OsmoBTS# configure terminal
OsmoBTS(config)# phy 0
OsmoBTS(phy)# list
[...]
osmotrx ip HOST
osmotrx ip (local|remote) A.B.C.D
[...]
OsmoBTS(phy)# inst
OsmoBTS(phy)# instance 0
OsmoBTS(phy-inst)# list
[...]
osmotrx rx-gain <0-50>
osmotrx tx-attenuation <0-50>
osmotrx tx-attenuation oml
[...]
------ No Exit Example ------
The same osmo-trx VTY nodes also show the exit failure:
$ telnet localhost 4241
OsmoBTS> enable
OsmoBTS# configure terminal
OsmoBTS(config)# phy 0
OsmoBTS(phy)# exit
% Unknown command.
OsmoBTS(phy)# instance 0
OsmoBTS(phy-inst)# exit
% Unknown command.
On the phy level, we would previously find the parent's 'exit' command, but in
the 'instance' level, 'exit' has never been available. Above patch should fix
all of these.
~N
--
- 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
Hi all!
Just in case anyone here is intrerested, I'd like to point out that
a recent patch series for IPv6 (and other feature) support of the Linux
kernel GTP-U code has been posted to the linux-netdev list and is under
review/discussion there:
https://www.spinics.net/lists/netdev/msg455286.html
Please follow-up with any review comments there. Thanks!
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hello,
I was trying to clone git repository from http://git.osmocom.org/libgtpnl/but got an error :
remote: An error occurred while reading CGI reply (no response received)fatal: unable to access 'http://git.osmocom.org/libgtpnl/': The requested URL returned error: 502
I can't open http://git.osmocom.org/libgtpnl/ in browser either. It said 'An error occurred while reading CGI reply (no response received)'.
Is my url to git repository wrong ?
Thanks,
WangSS
Hi,
I want to ask two questions.
I dont know if you remember, but I have been trying to backport GTP to 3.18
kernel. I fixed all the errors, it works. However there is one issue that
I'm not sure how to implement it correctly.
--->There is one private flag called IFF_NO_QUEUE and it has no
implemetation in 3.18 kernel, I just set it to an unused bit in the private
flag field. I would like to get your opinion on this.
*include/linux/netdevice.h ->(*@IFF_NO_QUEUE: device can run without qdisc
attached*)
The other thing I would like to ask is that I cannot reach the git
repository for libgtpnl. Could you please check it?
Thanks,
Fırat
Hello,
I compiled osmo-ggsn and was trying to run it as per the instructions
present on https://osmocom.org/projects/openggsn/wiki/Kernel_GTP
But when I try to start osmo-ggsn *using -g or --gtp-linux*, it says
invalid option.
Please let me know how to start it using gtp kernel.
I have modprobed gtp.ko successfully.
[root@localhost osmo-ggsn]# lsmod |grep gtp
gtp 28672 0
ip6_udp_tunnel 16384 1 gtp
udp_tunnel 16384 1 gtp
[root@localhost examples]# osmo-ggsn --gtp-linux -c osmo-ggsn.cfg -d
*osmo-ggsn: unrecognized option '--gtp-linux'*
<0002> ggsn.c:159 APN(internet): Starting
<0002> ggsn.c:162 APN(internet): Opening TUN device tun4
<0002> ggsn.c:167 APN(internet): Opened TUN device tun4
<0002> ggsn.c:178 APN(internet): Setting tun IP address 176.16.222.0/24
<0002> ggsn.c:224 APN(internet): Creating IPv4 pool 176.16.222.0/24
<0002> ggsn.c:245 APN(internet): Successfully started
<0002> ggsn.c:159 APN(inet6): Starting
<0002> ggsn.c:162 APN(inet6): Opening TUN device tun6
<0002> ggsn.c:167 APN(inet6): Opened TUN device tun6
<0002> ggsn.c:190 APN(inet6): Setting tun IPv6 address 2001:780:44:2000::/56
<0002> ggsn.c:236 APN(inet6): Creating IPv6 pool 2001:780:44:2000::/56
<0002> ggsn.c:245 APN(inet6): Successfully started
<0002> ggsn.c:159 APN(inet46): Starting
<0002> ggsn.c:162 APN(inet46): Opening TUN device tun46
<0002> ggsn.c:167 APN(inet46): Opened TUN device tun46
<0002> ggsn.c:178 APN(inet46): Setting tun IP address 176.16.46.0/24
<0002> ggsn.c:190 APN(inet46): Setting tun IPv6 address
2001:780:44:2100::/56
<0002> ggsn.c:224 APN(inet46): Creating IPv4 pool 176.16.46.0/24
<0002> ggsn.c:236 APN(inet46): Creating IPv6 pool 2001:780:44:2100::/56
<0002> ggsn.c:245 APN(inet46): Successfully started
<0002> ggsn.c:687 GGSN(ggsn0): Starting GGSN
<000d> gtp.c:705 GTP: gtp_newgsn() started at 192.168.11.128
<0002> ggsn.c:724 GGSN(ggsn0): Successfully started
<0005> telnet_interface.c:102 telnet at 127.0.0.1 4260
<000c> control_if.c:788 CTRL at 127.0.0.1 4257
Also, I tried executing gtp-tunnel list but it gives empty output.
[root@localhost tools]# ./gtp-tunnel list
[root@localhost tools]#
Please help.
Thanks,
Ravi
<https://osmocom.org/projects/openggsn/wiki/Kernel_GTP>
Hi all,
12 years after OpenGGSN was seemingly abandoned by its original creators,
and 7 years after Osmocom adopted it, it is time for a significant change:
OpenGGSN is becoming a first-class Osmocom citizen called OsmoGGSN.
We had already taken some baby-steps in the past by introduction of a
CTRL interface as well as the use of libosmocore logging. However, my
recent patches introducing a VTY interface and changing the
configuration file format from the 'gengetopt' style to libosmovty based
change the look+feel of the program significantly that it is a good
point to rename.
After all, if command-line arguments and config file syntax are
changing, documentation will also need to change and it becomes
confusing to users to understand that depending on the version the
documentation is correct or incorrect.
So from today on,
* osmo-ggsn is available from http://git.osmocom.org/osmo-ggsn/
* osmocom:nightly packages will build both openggsn + osmo-ggsn
* osmocom:nitb-split:nightly packages will only build osmo-ggsn
* redmine still at http://osmocom.org/projects/openggsn due to
permanent redmine project naming...
The introduction of the VTY interface comes with many new possibilities,
such as
* multiple GGSN instances bound to different GTP IP addresses
* multiple APNs within each GGSN, each with different Address Pools and
tun-devices
* sophisticated logging configuration (syslog, file, stdout, telnet)
What's still missing:
* re-integrate kernel GTP-U support
* create OsmoGGSN user manual in osmo-gsm-manuals.git
* migrate TTCN-3 test execution on jenkins to osmo-ggsn
* perl/python script to convert old config file to new config file
format (any volunteers?)
Roadmap:
* IPv6 transport plane support (outer IP layer surrounding GTP/UDP)
* improved logging (ensure context is always included)
* libgtp: migration of kernel GTP-U support into libgtp (not just ggsn)
* libgtp: make PDP context hash table part of the 'gsn' structure
* once all expected ABI/API changes are done, rename libgtp to
libosmo-gtp
In terms of maintenance, I don't want to continue to maintain OpenGGSN
for much longer. We'll keep it around for some time and merge important
security and/or bug fixes, but I won't accept new feature patches into
OpenGGSN.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hello,
I am a newbie in this area so please pardon me if these are dumb or
covered questions!
I am looking for a GTP stack that implements GTP-C version 2. Is this
supported in open grps or is there a plan for that? If not, what stack
(preferably open source) is recommended?
Thanks,
Tom
Hi.
With the ongoing split of OpenBSC into per-project repository, I wonder if we could
do the same to OpenGGSN and split libgtp into separate repository?
Rationale:
* would simplify docs for newcomers (it's not obvious that openggsn have to be built
ahead of OsmoSGSN because of libgtp)
* simplify release process (we can release libgtp independently of OpenGGSN, makes it
easier to automate too)
While at it and considering recent IPv6 support (and related config changes) it might
be also good idea to rename it to OsmoGGSN (and libosmo-gtp?) to clearly mark the
breaking point.
What do you think?
--
Max Suraev <msuraev(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
