(BTW, for GPRS we use osmocom-net-gprs(a)lists.osmocom.org but admittedly, almost
all osmocom communication is taking place on openbsc@)
On Mon, Oct 30, 2017 at 12:12:03PM -0600, Keith wrote:
> I've installed up to date versions of osmo-bts and osmo-pcu
> on sysmobts 2050 hardware and it's working great!
> Dynamic channels are really nice, with half rate TCH and AMR
> working perfectly. Thanks for all that work!
Good to hear that!
> I configured pcodns1 in the ggsn to point to this DNS
> server, AND I setup a port 53 redirect to catch quite a lot
> of traffic from android that likes to just talk directly to
> 8.8.8.8 anyway.
Interesting, this sounds like it would make for a good wiki page on
osmocom.org.
> games. Such is the sad state of affairs on today's internet.
> Fortunately, we have iptables and ip sets and we have AS
> blocks assigned to certain bandwidth hungry corporations :-)
So instead of compromising net neutrality by giving the rich more bandwidth,
you do it by cutting the big ones out instead ;)
> I have observed that if I initiate any data transfer from
> the network side then the uplink is established. By the same
> token, If I transfer a file from the network (http download
> or some such), the same applies. The link stays active and
> the IM chat session is very responsive alongside the file
> transfer. Shortly after the file transfer completes, the
> uplink is quiet again and the latency in the IM session
> becomes a problem.
It might be related to a basic problem we still have with data services: we
don't cache anything. If a PDP context is still being established, we drop data
transfers to the floor, instead of storing them and sending them through when
the context is established. I'm personally not familiar with the details there,
but that's my current understanding.
So a first ping would get lost, a second one within a timeframe that still has
the PDP context open will go through.
I think the idea there is that generally, higher level data communication
should attempt to resend, but in practice that often doesn't seem to work that
well.
Not sure how to configure the PDP context timeout, or whether we even can.
Theoretically, if you had on your phone a regular ping running in the
background ... it's ugly, but yea.
Caching those first packets is quite complex, especially for SGSNs sitting on a
small device like a sysmoBTS with limited memory. I guess something could be
tried there, by limiting resources used for caching in intelligent ways...
Someone would need to fund that, or go ahead and try.
~N
Dear Osmocom community,
I would like to point out that at sysmocom, we're currently (again)
hiring [1]. If you happen to have an interest in open source cellular
communications and are fluent in C language development, we would
love to hear from you.
sysmocom probably doesn't need any introduction here, but just in case:
The company was founded by Holger Freyther and Harald Welte, two of the
leading OpenBSC and Osmocom developers from the very early days of the
project. Today we are responsible for by far the largest number of commits
to the Osmocom GSM/3G infrastructure related git repositories.
Among our current priorities are automatic testing for the GPRS PCU,
generalization of the OsmoMGW media gateway, support for load-based hand-over,
inter-BSC hand-over as well as various improvements on the lower layers
of the GPRS protocol stack.
We're very dedicated to the cause in furthering the capabilities of
open source cellular infrastructure from 2G to 4G. We believe in
working upstream, no open core or dual licensing.
If you have an interest working with an enthusiastic, strong technical
and dedicated team of Osmocom hackers, please don't hesitate to let me know,
best by e-mail to jobs(a)sysmocom.de
Thanks,
Harald
p.s.: I hope this kind of message is not disturbing to anyone. I think
it is important to the Osmocom project to have more paid people working
on the stack, so it is justified. The positions we are seeking to fill
will work [almost exclusively] on Osmocom, so it's not a random job ad
but in the very interest of Osmocom, and hence on-topic for this list.
[1] https://www.sysmocom.de/jobs/
--
- Harald Welte <hwelte(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
Dear Osmocom community,
since the NITB-split has completed, and we have integrated 3G fully
into master, and also merged nitb-split and nitb packages in one
feed, the next step on the agenda was to create packages/feeds that
are more stable than "nightly".
After a long day of "release engineering" work and related fixes,
starting from today, Osmocom not only has the "osmocom:nightly" feed
tracking the "master of the day" of all repositories.
We now also have a "osmocom:latest" feed for various Debian and Ubuntu
GNU/Linux distributions which contains packages for the last tagged
version of each source code repository.
The setup is fairly similar to that of the "osmocom:nightly" packages
and is described at
https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds
I've also removed all known references to Nightly_Builds on the wiki and
replaced it with a reference to the new Binary_Packages page explaining
the differences between Nightly_Builds and Latest_Builds:
https://osmocom.org/projects/cellular-infrastructure/wiki/Binary_Packages
As you can see at
https://build.opensuse.org/project/monitor/network:osmocom:latest
almost all the packages are building already. I intend to fix the
remaining three (osmo-bsc, osmo-msc and osmo-pcu) shortly.
--
- Harald Welte <hwelte(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
Dear all,
during manual review, I found some pretty obvious bugs and inconsistencies
in the gtpie_encaps() and gtpie_encaps2() functions of libgtp.
Interestingly, it seems those functions have been around since the very fist
commit in 2002. However, no code in openggsn, osmo-ggsn, osmo-sgsn or even
gtphub seems to be using them.
Does anyone know of any users of those functions? Rather than keeping them
updated manually without any test cases and users, I would say there's a strong
argument to remove them from the code base.
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)
[cross-post to many lists, please follow-up-to openbsc(a)lists.osmocom.org]
Dear all,
time is flying, and I would like to start early with discussions and planning
about OsmoCon and OsmoDevCon in 2018. It helps to start early.
Side note: We have some pending issues about the events from last year at
http://osmocom.org/projects/osmo-dev-con/issues - I've incorporated them
in the text below.
== OsmoDevCon ==
For OsmoDevCon, I think it's easy: We keep it as-is. Same procedure as
every year, which means:
* same venue, same catering options
* same concept of 'anyone contributing to Osmocom can apply for
registration until all seats are taken'
* same idea of inviting some few speaker[s] doing other FOSS mobile
communications work to join us
The parts that we need to change, IMHO:
* don't reduce from 4 to 3 days like last year. Have full 4 days again
* sort topics per day / half-day, i.e. have "GSM/UMTS Cellular
Infrastructure" days for BTS/BSC/NITB/MSC/HLR/SGSN/GGSN & Co,
but then have other days for other projects. This would enable people
not interested in the [continued evolvement] of the cellular projects
be able to skip those days, or to simply meet in an adjacent room for
parallel hacking sessions/discussions
* try to be a bit more structured with the schedule in general. The
existing approach works for people who attend all the event all day
long, but not so well for people with other plans / limited time
Any further change requests or topics to discuss?
Please note that Pablo Neira has offered to kindly host an OsmoDevCon in
Seville (Spain). I've attended a number of netfilter workshops he
organized there, and he's doing a great job! However, given the large
number of attendees from Berlin (and Germany in general), I think this
would make things more complicated, and more expensive for most
attendees. If you disagree with that assessment: I'm open for having
the discussion, I just thought it's more practical/economic to do it in
Berlin.
=== 10 year Anniversary Party ===
Given that 2018 marks the 10 year anniversary of Dieter and me hacking
with the Siemens BS-11 in 2008, I think the 2018 incarnation deserves
some special celebration of some form. I have no concrete idea yet, but
for sure we should so something, and it should be at/around
OsmoDevCon. And for sure we should have a BS-11 around :)
== OsmoCon ==
The public OsmoCon was welcomed and was a success. However,
let's start this discussion with a review of last years event.
=== Registration ===
* Registrations came in way too late. Two weeks ahead of the event, we were
considering to cancel it. And then within the last few days, we had
to turn people down due to limited seating capacity
* To make planning more reliable, we see on other option but to
significantly raise the registration fee combined with an equally
significant discount for early booking
=== Duration ===
* Many people requested multiple days rather than just one, in order to
make more out of (long distance) travels. This is obvious, but as we
had no idea how many people would attend at all (or if we have to
cancel due to lack of attendance), planning multiple days in the first
incarnation would have been high risk and a multitude of work
* I would suggest to expand to two or even three days this week,
possibly one days with tutorials and the other day with tech talks
* Slightly less crammed schedule due to multiple days
=== Venue ===
We recognize this yearso venue was not the best option, due to
* Bad ventilation in the basemenet
* Difficult to find
* No space next to the conference room where people can meet / hang out
in parallel to talks (not everyone attends every talk)
I still like the "understatement" of the venue. I'd prefer any hostel /
non-profit / hackerspace / university over luxurious hotels any time.
Going to an expensive venue means more or less automatically more
expensive ticket fees, which again is more likely to exclude pure
community members without a commercial activity related to Osmocom.
So any future venue would ideally:
* be able to hold slightly more people than this year
* have a second room or large lobby in which people can meet for
extended coffee breaks in parallel to some talks, as needed
* be slightly easier to find (and we have to put up some signs outside
and in the lobby)
* have better WiFi and/or wired connectivity
=== Programme / Format ===
* less crammed over multiple days
* some more "interactive" formats were requested, for users to provide
feedback to developers
* there was some discussion about topics / speakers in redmine last
year, but not too much participation [until it was too late].
* I'd suggest a more formal CfP process with a submission deadline that
allows us to publish a preliminary schedule long ahead of the event
=== Video Recordings ===
I think they were a big success, and it was a very big surprise that the
CCC Video Operations Center was volunteering to help such a small and
niche-interest event like OsmoCon. We should make sure that we can
repeat this for 2018.
== Dates / Frequency ==
Having OsmoCon and OsmoDevCon back to back becomes somewhat long, if
OsmoCon is 2-3 days and OsmoDevCon is 4 days. Basically we're looking at
a full week for those of you who would like to attend both events. But
then, I think the number of people attending both events is actually not
all that big. Without checking the details, I think not more than half
of the OsmoDevCon attendees were attending OsmoCon. I would expect that
tendency to remain or even increase.
I still think it's good to keep them back-to-back.
In terms of frequency, I would actually suggest we move to a 6-month
cycle rather than a 12-month cycle. There's a lot of development going
on at all time. I understand that not everyone is able to attend two
events just on Osmocom, especially if it's a spare time / hobby type
activity. That's ok, I think there's no problem with attending either
of the two only, and catching up by video recordings and/or mail on the
other.
The qeustion is: Should that second event be developer-oriented or
user-oriented? Or again both? Any comments here?
Ok, that was a somewhat lengthy e-mail. Please make sure to provide any
feedback you may have as early as possible, to increase the chances of
your feedback being reflected in the planning.
Happy hacking,
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)
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
