> I don't understand. This callback will be called with data you need to
write
> to the network. In case of MTP Level3 you will need to wrap that around
the
> msgb you got.
I means: is the interaction with mtp3 layer implemented (is sending sccp
data by mtp3 implemented by the library?)?
Also, what about the reception of data from mtp3 layer. is that implemented
in the sccp lib.
I am asking these questions because I see the code of mtp3 in the lib but no
significant call is present in the sccp part of the lib.
Thank you for your help.
On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote:
> [translated from german]
> is it certain that we switch a channel to PDCH only when
> gprs mode != none?
A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we
send a PDCH ACT message.
We send a PDCH ACT message
- during init (CHANNEL OML's state changed to enabled -> send PDCH ACT),
- and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH.
So the question is, when we receive a channel release ack, could that be
the PDCH release and we switch PDCH right back on by accident? No, because
we only receive a chan rel ack when the *TCH/F* is being released.
That is because the PDCH release is initiated "internally" from the PDCH
DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches
on, which existed before dyn PDCH:
if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) {
LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n",
gsm_lchan_name(lchan));
return 0;
}
In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but
not in the rsl_rx_dyn_pdch().
This is analogous to the ip.access way -- the ip.access nanobts replies to
a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel
release ack.
Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH
for clarity? (But we shouldn't actually send a release ack, to stay
compatible.)
Even though it works as-is, we should indeed add another flag check:
- We do check the flags that no ACT/DEACT is already pending;
- And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE;
- But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE.
This should never happen, but it would make sense to ensure that.
~Neels
I've raised this some years ago, then had gotten the response that our .ttcn
files should grow to any size, and we should fix the tooling instead or buy a
faster computer.
But I'm still having the annoyance when working with our ttcn that even
changing a tiny constant will trigger a longish recompilation. It looks like it
is dividing a .ttcn into parts, and keeps recompiling *all* of the parts.
(not always all of the parts, but usually it is clumsy about compiling more
than would be logically required from my POV.)
It looks like this:
+ make -j 5
Creating dependency file for HNBGW_Tests_part_6.cc
Creating dependency file for HNBGW_Tests_part_5.cc
Creating dependency file for HNBGW_Tests_part_4.cc
Creating dependency file for HNBGW_Tests_part_3.cc
Creating dependency file for HNBGW_Tests_part_2.cc
Creating dependency file for HNBGW_Tests_part_1.cc
Creating dependency file for HNBGW_Tests.cc
env CCACHE_SLOPPINESS=time_macros ccache g++ -c -DLINUX -DMAKEDEPEND_RUN -DUSE_SCTP -DLKSCTP_MULTIHOMING_ENABLED -DAS_USE_SSL -I/usr/include/titan -fPIC -o HNBGW_Tests.o HNBGW_Tests.cc
env CCACHE_SLOPPINESS=time_macros ccache g++ -c -DLINUX -DMAKEDEPEND_RUN -DUSE_SCTP -DLKSCTP_MULTIHOMING_ENABLED -DAS_USE_SSL -I/usr/include/titan -fPIC -o HNBGW_Tests_part_1.o HNBGW_Tests_part_1.cc
env CCACHE_SLOPPINESS=time_macros ccache g++ -c -DLINUX -DMAKEDEPEND_RUN -DUSE_SCTP -DLKSCTP_MULTIHOMING_ENABLED -DAS_USE_SSL -I/usr/include/titan -fPIC -o HNBGW_Tests_part_2.o HNBGW_Tests_part_2.cc
env CCACHE_SLOPPINESS=time_macros ccache g++ -c -DLINUX -DMAKEDEPEND_RUN -DUSE_SCTP -DLKSCTP_MULTIHOMING_ENABLED -DAS_USE_SSL -I/usr/include/titan -fPIC -o HNBGW_Tests_part_3.o HNBGW_Tests_part_3.cc
env CCACHE_SLOPPINESS=time_macros ccache g++ -c -DLINUX -DMAKEDEPEND_RUN -DUSE_SCTP -DLKSCTP_MULTIHOMING_ENABLED -DAS_USE_SSL -I/usr/include/titan -fPIC -o HNBGW_Tests_part_4.o HNBGW_Tests_part_4.cc
env CCACHE_SLOPPINESS=time_macros ccache g++ -c -DLINUX -DMAKEDEPEND_RUN -DUSE_SCTP -DLKSCTP_MULTIHOMING_ENABLED -DAS_USE_SSL -I/usr/include/titan -fPIC -o HNBGW_Tests_part_5.o HNBGW_Tests_part_5.cc
env CCACHE_SLOPPINESS=time_macros ccache g++ -c -DLINUX -DMAKEDEPEND_RUN -DUSE_SCTP -DLKSCTP_MULTIHOMING_ENABLED -DAS_USE_SSL -I/usr/include/titan -fPIC -o HNBGW_Tests_part_6.o HNBGW_Tests_part_6.cc
env CCACHE_SLOPPINESS=time_macros ccache g++ -shared -o HNBGW_Tests.so HNBGW_Tests.o
env CCACHE_SLOPPINESS=time_macros ccache g++ -shared -o HNBGW_Tests_part_3.so HNBGW_Tests_part_3.o
env CCACHE_SLOPPINESS=time_macros ccache g++ -shared -o HNBGW_Tests_part_4.so HNBGW_Tests_part_4.o
env CCACHE_SLOPPINESS=time_macros ccache g++ -shared -o HNBGW_Tests_part_2.so HNBGW_Tests_part_2.o
env CCACHE_SLOPPINESS=time_macros ccache g++ -shared -o HNBGW_Tests_part_1.so HNBGW_Tests_part_1.o
HNBGW_Tests_part_5.cc: In function ‘OCTETSTRING HNBGW__Tests::f__gen__one__compl__l3(const Compl3Type&, const MobileL3__CommonIE__Types::MobileIdentityLV_template&, const INTEGER&)’:
HNBGW_Tests_part_5.cc:2130:1: warning: control reaches end of non-void function [-Wreturn-type]
2130 | }
| ^
env CCACHE_SLOPPINESS=time_macros ccache g++ -shared -o HNBGW_Tests_part_5.so HNBGW_Tests_part_5.o
env CCACHE_SLOPPINESS=time_macros ccache g++ -shared -o HNBGW_Tests_part_6.so HNBGW_Tests_part_6.o
I want a fast dev cycle, and the ttcn dev cycle is slow: after a tiny edit,
the CPU spools up and the fan goes for a whole while, and I get bored and
irritated. When I'm on a train ttcn compilation drains the battery...
My local workaround was to create a second file, like BSC_Tests_2.ttcn, with
only my new test in it. Then compilation cycles are rapid.
But that requires modifying all sorts of s/private/friend and even only moving
the code is another annoyance. If I want to apply CR, I won't move it back and
forth, so usually I end up with two copies and get confused.
So my local workaround isn't working out very well.
Why am I writing this here? Because I would like to request that we start
subdividing our ttcn into smaller compilation units, not as my local workaround
but permanently in our upstream.
Please?
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> https://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Siemensstr. 26a
* 10551 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
