btw, I apologize for the noise around the osmo-msc patch review, it's a
challenge to keep all the eggs in the basket. For once I added python tests as
well as the various --enable- flags to 'make distcheck', then tried to get the
patches to pass the build check, and only now am really taking care of the all
the remaining code review. Every time I think it's settled, something else pops
up. Hope to be done with the current batch today.
~N
Review at https://gerrit.osmocom.org/3322
Rename osmo_pcap_{client_server} executables to osmo-pcap-{client,server}
This naming is more in line with what all the other osmocom programs are
doing (e.g. osmo-pcu, osmo-bts-sysmo, osmo-bsc, ...). We don't
generally use osmo_ anywhere else, so I suggest to change it for more
uniformity.
Change-Id: If1e3ce76f93266e0f01c801204769432b571fdb1
---
M src/Makefile.am
1 file changed, 1 insertion(+), 1 deletion(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-pcap refs/changes/22/3322/1
diff --git a/src/Makefile.am b/src/Makefile.am
index 0532acf..17ed4e3 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1,7 +1,7 @@
AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include -I$(top_builddir)/
AM_CFLAGS = -Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOVTY_CFLAGS) $(PCAP_CFLAGS) $(LIBGNUTLS_CFLAGS)
-bin_PROGRAMS = osmo_pcap_client osmo_pcap_server
+bin_PROGRAMS = osmo-pcap-client osmo-pcap-server
osmo_pcap_client_SOURCES = osmo_client_main.c osmo_common.c \
osmo_client_core.c osmo_client_vty.c \
--
To view, visit https://gerrit.osmocom.org/3322
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: If1e3ce76f93266e0f01c801204769432b571fdb1
Gerrit-PatchSet: 1
Gerrit-Project: osmo-pcap
Gerrit-Branch: master
Gerrit-Owner: Harald Welte <laforge(a)gnumonks.org>
Hi there! LaF0rge made me some suggestions for a better troubleshooting,
so here are the logs in .log format, since the previous email wasn't
readable.
I'm attaching the RSL+OML pcap file.
Please let me know if someone knows how to connect this nanobts =)
Cheers!
Hi!
Next to the announcement (http://osmocom.org/news/75) I've put together
some guide in the wiki as to how the Virtual Um interface can be used
with the osmo-bts-virtual, virtphy and mobile programs running all on
your local PC:
https://osmocom.org/projects/cellular-infrastructure/wiki/Virtual_Um
Feel free to try it out and/or improve the wiki page and/or let me know
if something is not sufficintly clear. I intentionally don't want to
repeat general information about configuring OsmoNITB or using
OsmocomBB. The above-mentioned page should only document those aspects
that are different from the classic setup with real hardware.
I'm now investigating some more of the bugs I'm starting to find with
using the VirtualUm interface from my related TTCN-3 testsuite, at this
time particularly https://osmocom.org/issues/2380
Will document that testsuite once it can actually run as expected.
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)
Hi all!
Some of you will have alrady noticed, over the last few days I reviewed,
cleaned up, submitted and merged the virtual Um interface support on
both the phone side (OsmocomBB) as well as on the BTS side (OsmoBTS).
Thanks to Sebastian Stumpf for working out most of the related code,
after my initial attempt on this got stalled more than 1.5 years ago.
This means that you can now run a complete circuit-switched GSM network
without posession of any real hardware or use of any radio waves. While
that takes away almost all the fun for some of us (I would typically
agree), it opens up possibilities, particularly in terms of testing.
If anyone wants to play with it, it's actually very easy:
* build osmo-bts and the rest of the network-side code (I don't think
osmo-bts-virtual is part of the nightly Osmocom packages yet, sorry)
* run osmo-bts-virtual with a config file (example included in osmo-bts.git)
* make sure you have matching unit_id, band, ... between BTS and
BSC/NITB, just like with real hardware
OsmoBTS will start to send downlink BCCH / CCCH frames to a multicast
IPv4 address (default: 239.193.23.1) to the usual GSMTAP port 4729. If
you don't have any specific multicast routing set up, this will be
visible with TTL=1 on the network device of your default route. You
should see the GSMTAP frames in wireshark.
On the OsmocomBB side, simply start the virt_phy binary. It replaces
your calypso based phoen and its firmware and offers the L1CTL socket to
the "layer23" programs like "mobile". Once virt_phy is running, you can
start "mobile" just like with real hardware. The phone will scan the
multicast frames for BCCH messages, build up a list of currently
received BTSs and then perform normal cell selection followed by
location update.
Everything from this point on is just normal. You cannot make voice
calls, but any signaling related transactions (LU, SMS, USSD, even call
signalling) should work. Voice is missing as there is no format
specified on how to transmit FR/EFR/HR/AMR frames over GSMTAP yet.
If somebody plays with this, I would really appreciate if they could
update the Osmocom wiki with a guide/howto on how to use such a setup.
My personal plans are to use this for verification/testing of those bits
that are difficult in a true end-to-end setup like osmo-gsm-tester.
That includes:
* simulation of massive amount of phones, more than one can easily set
up in a lab and connect to USB + RF cabling.
* verification of SYSTEM INFORMATION messages, particularly in response
to different config files, ensuring that all related bits are set
correctly at all times, even after making dynamic updates
* verification of the PAGING code, i.e. that paging load is correctly
reported, paging messages are structured correctly, ...
* exhausting all channels using simulated phones, verification of
IMM.ASS.REJECT being sent ins such cases
* verification of TA loop
* verification of uplink power control loop
* verification of radio link timeout
* testing of emergency calls, which is very critical with real phones as
there's always some possible leakage into real networks
* verification of correct CBCH messages
* verification of LAPDm contention resolution (two phones selecting same
RACH value and going both on same dedicated channel)
* verification of measurement reporting (Um vs. RSL)
* verification of downlink RF power ramping
This will of course take some time, but I'm already making good progress
implementing some SYSTEM INFORMATION test code.
In case somebody wants to join in on any of the above topics (or has
even more ideas on what kind of tests he would want to implement), feel
free to follow up so we can coordinate.
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)
Hi,
I'm using osmo-nitb in a testing environment and I've soon received a
request to enable SMS delivery reports.
After looking on the user manual, I couldn't find anything related to this.
I've also enabled debug logging and tried to grep for something like that
when sending a SMS between two handsets that have SMS delivery reports
enabled, without finding out anything. (SMS delivery reports tested and
worked on a public telephony system, for those two handsets)
Is there such an option available in osmo-nitb to enable delivery reports?
---
Thank you,
Stefan