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/132
[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
In case anyone has been annoyed by this before:
wireshark so far always showed _only_ the BSSGP decode in the Information column
of a Gb interface pcap file, even if that BSSGP was contained in the "erroneous
message" IE of a NS-STATUS message.
This made it particularly difficult to spot NS-STATUS, and without custom
coloring rules or search filters, a protocol trace would just look fine - except
that in reality it isn't.
I've now found out what's the proper method to resolve this and submitted
a patch to wireshark, which was merged very quickly:
https://gitlab.com/wireshark/wireshark/-/merge_requests/2081
After this change, the Information column in the packet list will show
NS-STATUS with the human-redaable cause value for the reject, rather than
displaying BSSGP as if nothing odd happened.
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)
Hi, osmocom team members
We have run OsmoGGSN project using the attached config file in this email
and the following command:
osmo-ggsn
As you can see in the config file, we have set IP 127.0.0.2 for GGSN.
After executing the above command, a tunnel named tun4 is created.
To communicate with SGSN, we use the SGSN emulator in OsmoGGSN as follow:
sgsnemu -l 127.0.0.1 -r 127.0.0.2
After executing the above command, we see that 2 packets are sent from SGSN
to GGSN. These packets are "Echo request" and "Create PDP context request"
and GGSN responses to SGSN with the packets "Echo response" and "Create PDP
context response".
To test tun4, we send a GTP <DNS> packet containing an arbitrary query to
GGSN and we see that this GTP <DNS> packet is received in Loopback (lo)
interface and also, the DNS packet is received in tun4 interface. But there
is no DNS response to our query neither in tun4 interface nor lo interface.
A screenshot of the lo interface and tun4 interface in the wireshark is
attached in this email (right is lo and left is tun4).
How can we receive DNS responses to our DNS query? (Does tun4 require
routing or something else?)
--
*When there is much light, The shadow is deep...*
Hi Osmocom team
We have a basic question about libgtpnl (Linux Kernel GTP-U).
We receive a lot of GTP <DNS> packets which are sent from MS to our HNB and
from HNB to our SGSN (a screenshot is attached in this email). As you can
see in the one of these packets in the attached image, our MS IP is
10.250.0.114 and our SGSN IP is 172.60.3.154. Also, our TEID is 100 which
is set in RAB-Assignment Request sending from SGSN to HNB. In order to put
these GTP packets in our GTP tunnel, we use libgtpnl and the two following
commands:
gtp-link add gtp1
gtp-tunnel add gtp1 v1 100 1 10.250.0.114 172.60.3.154
But when we monitor the gtp1 interface in the wireshark, there is no packet
on this interface. Could you please help us to know the reason for this
problem?
(It is worth mentioning that after receiving these GTP <DNS> packets from
MS to SGSN and using netstat, we see that Recv-Q (bytes in UDP port 2152
which are ready to read) is increased to a value more than 0)
Best regards
--
*When there is much light, The shadow is deep...*
