This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Pablo, I've now submitted the 0001-abis_oml.patch (after removing some dead code) to wireshark, see https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5784 for details (I suggest you add yourself to Cc). On Sun, Mar 06, 2011 at 02:16:43PM +0100, Pablo Neira Ayuso wrote: > >> 18:14:15 Warn Dissector bug, protocol A-bis OML, in packet 13: > >> packet-gsm_abis_oml.c:940: failed assertion "DISSECTOR_ASSERT_NOT_REACHED" > >> > >> It seems that some TLVs that appear in the body of packets are unknown. > >> I'll debug which are the complaining tags and get back you. > > > > Did you enable the 'use ip.access nanoBTS' flag in the protocol preferences > > for the OML dissector? If you don't it will try to use the Siemens definitions > > on an ip.access protocol trace (which will break). > > Yes, the nanoBTS mode is enabled. > > I've been debugging this a bit. The problem seems to be related with > "Activate Software" and "Activate Software ACK" messages. They contain > an attribute whose tag is 0x42 which the dissector does not know how to > interpret. > > Any clue on this? I don't know yet, but I think it is not a blocker for submitting it. I really want to get it included. We can always fix those kind of minor bugs later. I think the next should be 0004-rsl_ipaccess.c, but maybe make it a (default: on) preference whether or not to enable ip.access support. It has the same C99 array initializer problems. -- - Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)