In hijacking mode (CAPIFLAG_HIGHJACKING), a PTY master/slave pair is created to
pass data back and forth between the application and mISDNcapid. However, there
is a small time window between creating the PTY slave and the application
opening the PTY slave. If a B3 data connection is established before the
application has opened the PTY slave, and B3 data is received and written to the
PTY master end, it is immediately read back by the B3 data receiver thread
(BCthread), which then sends the data back to the original sender, causing a
loopback. This e.g. happens when the application is the PPP daemon pppd which
has been configured to not send any data until it receives a valid LCP packet
("silent" option).
In order to fix this, an additional flag called tty_received remembers whether
the B3 data receiver thread has already read data from the PTY at least once.
Only if this is the case B3 data is written to the PTY master end, otherwise it
is discarded as there is no potential receiver at the PTY slave end yet. This
effectively avoids any loopback situations due to an unconnected PTY slave end.
Signed-off-by: Christoph Schulz <develop@kristov.de>
If early B3 is enabled we are currently opening channel B on appropriate
"Progress" IE.
If it turns out that this IE arrives in the same message that also sets
which B channel should be used the current code will fail to open
the B channel for early B3 as the current order is to first handle the IEs
then parse channel id.
Change this to first parse the B channel id then handle the IEs so in such
situation the B channel id will already be set at "Progress" IE handling
time.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Early B3 support is an useful functionality not only to listen to actual
exchange ringback tone but also to hear announcements like number changed,
line not provisioned, etc.
This commit adds partial early B3 support: mISDNcapid will try to open
B channel on "Call is not end-to-end ISDN; further call progress
information may be available in-band" and "In-band information or an
appropriate pattern is now available" progress indications, so CAPI
application will be able to connect to this B channel with CONNECT_B3_REQ
message.
Doing it this way needs only minimal changes to existing code - we just
need to make sure that B channel opening function ( lPLCILinkUp() )
doesn't try do it again when it is called for the second time.
Full early B3 support would need further decoupling NCCI management
from PLCI management so B channel could be opened on demand when CAPI
application issues CONNECT_B3_REQ.
While we are at it also make sure that lPLCILinkUp() function also
cleans up what it has already done when it exits early with an error.
Since this functionality is experimental it is not enabled by default -
a define needs to be uncommented at top of capi20/lplci.c to enable it.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
According to Q.931 (05/98) some of variable length information elements
may occur more than once in a message.
parseQ931() from mISDN layer3 library would store such second and next
occurrence of particular IE in an "extra" array of l3 struct.
This commit adds support for sending these repeated IEs to mISDNcapid
INFO_IND IE posting function ( lPLCIInfoIndIE() ) so they will be
available to CAPI applications.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
lPLCIInfoIndIE() in lplci.c returned early when mc->l3m was set and
continued execution when it was NULL, however from code further in this
function it is clear that opposite behavior was meant.
This caused CAPI applications to not receive INFO_IND with information
elements, as this function was no-op when called correctly.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
bch_worker() on {DL,PH}_DATA_IND returns what write() call has returned.
This function returns number of bytes written, however bch_worker() caller
main_worker() treats any non-zero return value of bch_worker() as signal
to disconnect the call.
This all meant that call terminated on first received chunk of data.
Fix it by normalizing a positive return value of write() in bch_worker()
to zero.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Signed-off-by: Karsten Keil <keil@b1-systems.de>
MT_CONNECT case in do_control_worker() was missing final break so on this
message code in next (identical) case of MT_CONNECT_ACKNOWLEDGE was
executed, too.
In "send and receive voice" mode this resulted in
"bchannel_senddata: next_skb exist ERROR (skb->len=64 next_skb->len=64)"
error and immediate call disconnection due to TX data being submitted
twice.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Signed-off-by: Karsten Keil <keil@b1-systems.de>
When CAPI application asks for B3 disconnection the NCCI state machine
sends disconnect request further down the stack and then goes into N_4
state waiting for disconnection confirmation.
If B channel was in direct layer 1 mode the disconnect request will be
sent as PH_DEACTIVATE_REQ which will go all the way down to an individual
mISDN chip driver.
It looks like all current chip drivers reply to such requests by sending
only PH_DEACTIVATE_IND message, however the state machine in N_4 state
only reacts to PH_DEACTIVATE_CNF message (translated into
EV_DL_RELEASE_CONF).
This means that such call will get stuck until remote side disconnects it.
Fix this by reacting to PH_DEACTIVATE_IND message also in N_4 state,
just like it is done in N_ACT state.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
CAPI specs say that CONNECT_B3_RESP message uses Reject parameter for
deciding what happens to incoming connection, however mISDNcapid code
used Info instead.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
According to Q.931 (05/98) on user-originated calls that did not select
a particular B channel in a SETUP message the selected B channel is sent
in a first message returned by the network in a response to
the SETUP message.
This Recommendation explicitly mentions SETUP ACKNOWLEDGE or
CALL PROCEEDING as examples of such response messages, however mISDNcapid
code ignored channel indication in CALL PROCEEDING messages.
This resulted in a no channel selected error on outgoing calls
on exchanges that reply with CALL PROCEEDING to SETUP.
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Under some conditions it could be happen that on a freeing capi object
a other thread still get a reference and then it use the already freed object.
To avoid this, we do 2 things, we only take a refernce if get_obj() succeed, it
do not longer succeed if the object is already cleaned. We also force scheduling
after releaseing the lock before really freeing the object - so the waiting thread
will not get a new reference.
layer3/q931.c: In function 'mi_encode_hlc':
layer3/q931.c:360:3: error: statement with no effect [-Werror=unused-value]
ie[1] | 0x80;
^
Thanks to Tobias Powalowski pointing to this issue
.
When layer 1 is down, an incomming message will now activate the
correct interface. This is required to pass a message when layer 1
is down, like PTMP interfaces.
CAPI 2.0 spec defines the CIP value indicated by CONNECT_IND
als highest matched bit position, not the higest CIP value
calculated from bearer + HLC info.
This bug caused that if a application did not request listening
for some of the higher bit values a not requested CIP was sent, so the
call was ignored.
Signed-off-by: Karsten Keil <keil@b1-systems.de>
Implement a method to disable temporary messages from applications to
synchronize the delivery of a incoming call. It is important, that
all listening application get informed before the first answer was handled.
Signed-off-by: Karsten Keil <keil@b1-systems.de>
if a call was not taken by an application and multiple applications
are listening, it could happen that the PLCI was deleted before we
did sent the CONNECT_IND to all applications.
Signed-off-by: Karsten Keil <keil@b1-systems.de>
Christoph Schulz