Otherwise the library won't build with gcc-11.2
In file included from misc/mbuffer.c:21:
misc/mbuffer.c: In function ‘alloc_mbuffer’:
../include/mISDN/mbuffer.h:160:14: error: array subscript ‘struct mbuffer[0]’ is partly outside array bounds of ‘struct mqueue[1]’ [-Werror=array-bounds]
160 | next = prev->next;
| ~~~~~^~~~~~~~~~~~
The library fails to compile with gcc-11.2 as 'extern' is missing from
forward declaration of global variables.
/usr/bin/ld: faxl3.o:mISDNuser/capi20/alaw.h:7: multiple definition of `alaw2lin'; daemon.o:mISDNuser/capi20/alaw.h:7: first defined here
/usr/bin/ld: faxl3.o:mISDNuser/capi20/alaw.h:6: multiple definition of `slin2alaw'; daemon.o:mISDNuser/capi20/alaw.h:6: first defined here
/usr/bin/ld: faxl3.o:mISDNuser/capi20/alaw.h:5: multiple definition of `lin2alaw'; daemon.o:mISDNuser/capi20/alaw.h:5: first defined here
/usr/bin/ld: alaw.o:mISDNuser/capi20/alaw.h:5: multiple definition of `lin2alaw'; daemon.o:mISDNuser/capi20/alaw.h:5: first defined here
/usr/bin/ld: alaw.o:mISDNuser/capi20/alaw.h:6: multiple definition of `slin2alaw'; daemon.o:mISDNuser/capi20/alaw.h:6: first defined here
/usr/bin/ld: alaw.o:mISDNuser/capi20/alaw.h:7: multiple definition of `alaw2lin'; daemon.o:mISDNuser/capi20/alaw.h:7: first defined here
not only is it a signed/unsigned error, but on some architectures the
sizes of those two types are not identical, leading to a buffer overflow
on the stack. gcc-11.2 is complaining about it:
bridge.c: In function ‘ph_control’:
bridge.c:159:9: error: array subscript 2 is outside array bounds of ‘unsigned char[16]’ [-Werror=array-bounds]
159 | *d++ = c2;
| ^~~~
bridge.c:150:23: note: while referencing ‘data’
150 | unsigned char data[MISDN_HEADER_LEN+sizeof(int)+sizeof(int)];
| ^~~~
The loop within BCthread() continuously emits a warning like the following one
BCthread(24062):Bchannel1 timeout (release not pending) thread=24062
every 500 ms as long as no data is received over the B-channel. This is very
irritating and noisy and fills up the log file without a good reason. This
commit lets the warning be shown only if the timeout occurs while a release
operation is pending (and this is worth a warning because such a timeout does
not occur under normal circumstances).
Signed-off-by: Christoph Schulz <develop@kristov.de>
GCC reports problems like this:
gcc -DHAVE_CONFIG_H -I. -I../include -I../include -Wall -Werror -I./include -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -MT layer3/q931.lo -MD -MP -MF layer3/.deps/q931.Tpo -c layer3/q931.c -fPIC -DPIC -o layer3/.libs/q931.o
In file included from /usr/include/string.h:494,
from layer3/q931.c:22:
In function ‘strncpy’,
inlined from ‘mi_encode_redirecting_nr’ at layer3/q931.c:531:3:
/usr/include/bits/string_fortified.h:106:10: error: ‘__builtin_strncpy’ forming offset [25, 31] is out of the bounds [0, 24] of object ‘ie’ with type ‘unsigned char[24]’ [-Werror=array-bounds]
return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Thanks to Tobias Powalowski for reporting this
This commit fixes issue #9 on github.
There is a very limited list of functions one is allowed to call from a
signal handler (see "man 7 signal"). This list does not include
va_{start,end} required by iprint. Therefore, this commit moves calls to
dump_* from the dumpHandler and the iprint from termHandler to
main_control.
For dumping, this required two new constants MICD_CTRL_DUMP_{1,2}
Note: calling send_master_control from a signal handler is only safe with
argument len==0, because otherwise malloc(), memcpy() and free() would be
called which are VERY unsafe.
Create a signal handler just like the termHandler, that sends a new flag
(MICD_CTRL_REOPEN_LOG) to the master control queue. Once main control
encounters that flag, it flushes and closes the debug log file and
re-opens it.
Here exist two differnt content versions of octet 5b in bearer capabilities
but only alternatively depending on the L1 protocol, so we only need one octet 5b here.
If using a tty for sending/receiving B3 data, the mc buffer for data sent is
not freed by ncciDataConf() because this is done only by AnswerDataB3Req()
which is not called when using a tty. Fix this by explicitly freeing the mc
buffer when a tty is used.
Signed-off-by: Christoph Schulz <develop@kristov.de>
Until now, B3ReleaseLink() did not care about BType_tty B3 links. This commit
makes them behave like BType_Direct links.
Signed-off-by: Christoph Schulz <develop@kristov.de>
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>
The function lPLCIDisconnectInd() is called by plci_cc_disconnect_ind() when a
EV_L3_DISCONNECT_IND event is being handled. If the B3 link has already gone,
lPLCIDisconnectInd() returns -ENODEV, which prevents plci_cc_disconnect_ind()
from calling lPLCILinkDown() and therefore from cleaning up properly. This
commit makes lPLCIDisconnectInd() returns zero (i.e. success) in such a
situation.
Signed-off-by: Christoph Schulz <develop@kristov.de>
Always sends PH_ACTIVATE_REQ and not DL_ESTABLISH_REQ down the mISDN stack when
opening a B-channel, as DL_ESTABLISH_REQ is only understood by layer-2, and
B-channel management is done at layer-1.
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>
Harald Welte
Karsten Keil