argv is a pointer to an array of character strings, not a pointer to a single
character string. Some compilers do not like incorrect arguments for
main().
Based on patch for older configure script by Giuseppe Sacco <eppesuig@debian.org>.
gcc 14 require our tests to have a valid return type for the main
function, to have all functions declared before they are used (thus
having the right header file included) and to have arguments passed to
functions requiring them. Updated our configure script to do all of
this.
Patrice Fournier [Fri, 21 Jun 2024 21:54:32 +0000 (17:54 -0400)]
Copied TIFF tables from Libtiff 4.5.0
From Lee's work:
| commit fc167c4b11dc46f588c02258d86818888b58428e
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Thu Jan 5 21:44:57 2023 +0000
|
| As of libtiff-4.5.0 that library no longer exports TIFFFaxBlackCodes,
| TIFFFaxBlackTable, TIFFFaxMainTable, TIFFFaxWhiteCodes,
| TIFFFaxWhiteTable, and _TIFFFax3fillruns.
|
| This, then, makes them inaccessible to us in HylaFAX.
|
| libtiff development advised that those functions and tables simply be
| copied from libtiff directly into HylaFAX source code.
|
| That's what this does.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+/trunk@2695 5505949e-d877-4686-9e03-c53b7a51b376
Patrice Fournier [Mon, 27 Nov 2023 18:34:42 +0000 (13:34 -0500)]
Cope with ECM data received in V.34 Class 1.0 phase D signaling
From Lee's work:
| commit fc5a0fbc0029cd4526aadea731e244cf2b4138af
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Mon Apr 3 15:52:26 2023 +0000
|
| cope with Class 1.0 V.34-Fax scenarios where we receive ECM data
| frames when we were expecting Phase D signaling
|
| There are instances, possibly only with the Si2435, where after the
| modem indicates a switch to the control channel it can subsequently
| deliver Phase C ECM data frames without first indicating the primary
| channel. This is odd, and may just mean that the control channel
| indication was in error or something. V.34-Fax is just a stream of
| DLE-encoded HDLC frames, anyway, and whether the modem indicated the
| control channel or the primary channel to us it's all really the same
| thing.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+/trunk@2706 5505949e-d877-4686-9e03-c53b7a51b376
| commit 8e6f55893173bf6d52e0d44868c0e22bb96c783a
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Wed Apr 5 05:23:55 2023 +0000
|
| Further to r2706, the other Phase C data frame is RCP, so we need to
| also handle that appropriately.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+/trunk@2707 5505949e-d877-4686-9e03-c53b7a51b376
and:
| commit c2e8cf78cfb2d055fcb77636f67600eeff8ac1ab
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Wed Apr 5 05:27:29 2023 +0000
|
| Here's the rest of the changes missed by the previous commit.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+/trunk@2708 5505949e-d877-4686-9e03-c53b7a51b376
Patrice Fournier [Mon, 27 Nov 2023 18:11:44 +0000 (13:11 -0500)]
Do not flush the buffer following CONNECT after AT+FRM=n
From Lee's work:
| commit 900c3fe36e17a83d319caea8ea8d5d97ba203133
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Tue Dec 25 22:51:02 2012 +0000
|
| Do not flush the buffer following CONNECT after AT+FRM=n as it risks
| losing data.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+@2250 5505949e-d877-4686-9e03-c53b7a51b376
Patrice Fournier [Mon, 27 Nov 2023 17:21:37 +0000 (12:21 -0500)]
Cope with V.21 HDLC carrier loss following +FRH:3 better
From Lee's work:
| commit 1df7b3cfc4c15289aca919d97e0ee2700eb4da5e
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Fri Jan 22 18:20:05 2016 +0000
|
| Some modems (spandsp v0.0.6 is one) will signal +FRH:3 incorrectly.
|
| This probably happens because it can be difficult to distinguish
| between carriers quickly.
|
| The tested scenario only happens with V.17 long-train (TCF), so this
| patch only addresses the situation for TCF/training. It does
| not address the situation for following CRC/CTR exchange in which the
| carrier is changed.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+/trunk@2396 5505949e-d877-4686-9e03-c53b7a51b376
and:
| commit 911bcf000b3bdff72018883671f5236dca338ff9
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Wed Jan 27 00:08:22 2016 +0000
|
| This applies the same fixes to Phase C +FRH:3, CONNECT, NO CARRIER
| as was done for TCF in r2396.
|
| The codework looks messy, but it really just is mostly adding a
| do-while loop around a large block of code.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+/trunk@2400 5505949e-d877-4686-9e03-c53b7a51b376
Patrice Fournier [Mon, 20 Nov 2023 19:55:37 +0000 (14:55 -0500)]
Update SiLabs configuration for more peculiarities
From Lee's work:
| commit 522f94c60eb92d331807af6aa4de784d1783c049
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Tue Dec 27 16:22:42 2022 +0000
|
| Add some Si2435 configuration considerations.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+/trunk@2693 5505949e-d877-4686-9e03-c53b7a51b376
and:
| | icommit 67665a62778219ddebbcd55d6ec52922e95d47b1
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Fri Jan 20 20:21:01 2023 +0000
|
| Put the si2435 considerations into the silabs-10 config and make
| some adjustments.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+/trunk@2698 5505949e-d877-4686-9e03-c53b7a51b376
Patrice Fournier [Mon, 20 Nov 2023 19:50:33 +0000 (14:50 -0500)]
Try to cope with SiLabs OK result after +FRM/+FRH timeout
From Lee's work:
| commit 1d9a6464c57794015c272b13ba21a86c9bd38526
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Tue Apr 26 00:48:53 2022 +0000
|
| Try to cope with the Si2435/Si2417 resulting with an OK after timing
| out with +FRM/+FRH
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+/trunk@2676 5505949e-d877-4686-9e03-c53b7a51b376
Patrice Fournier [Mon, 20 Nov 2023 19:07:32 +0000 (14:07 -0500)]
Handle NO CARRIER results to AT+FRH=3 better
From Lee's work:
| commit 5acea904d6680964ba222b87367b55fdbbad3b76
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Wed May 21 18:27:29 2008 +0000
|
| This is a continuation of the same work to handle NO CARRIER after
| AT+FRH=3.
| It was needed in two spots, and I only managed to put it in one
| place before.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+@1956 5505949e-d877-4686-9e03-c53b7a51b376
Patrice Fournier [Thu, 16 Nov 2023 17:59:04 +0000 (12:59 -0500)]
Do not try to abort with CAN byte if Class1RecvAbortOK is 0
From Lee's changes:
| commit 93b731fc61f5f7a66970c83606f619f244fc66b8
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Wed Dec 8 16:15:27 2021 +0000
|
| The Si2435 is inconsistent in how it reacts to +FRH=3 aborts.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+/trunk@2663 5505949e-d877-4686-9e03-c53b7a51b376
and:
| commit b485d62e3b474099d3a654b3437950b362290758
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Tue Nov 1 02:43:26 2022 +0000
|
| If the modem isn't properly supporting character aborting with the
| CAN byte, then don't bother with the CAN byte at all, and just
| get on with it using the AT command.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+/trunk@2691 5505949e-d877-4686-9e03-c53b7a51b376
Patrice Fournier [Thu, 16 Nov 2023 11:05:50 +0000 (06:05 -0500)]
Set hasV34Trouble on Si2435/Si2417 V.34/V.8 connection glitch
From Lee's changes:
| commit 22243a57f2b54d83e78ecc64b663e476e8354abf
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Mon Nov 15 20:32:27 2021 +0000
|
| Add hasV34Trouble condition for Si2435/Si2417 case.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+/trunk@2658 5505949e-d877-4686-9e03-c53b7a51b376
| commit dd31221bd9c337f3c753630ffd938641ea5cba38
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Thu Nov 18 03:06:47 2021 +0000
|
| Cope with Si2435 V.34/V.8 connection glitch.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+/trunk@2659 5505949e-d877-4686-9e03-c53b7a51b376
and:
| commit ae5d1835fa4ecf6b06a696880507f23cd22cc334
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Fri Nov 19 14:30:53 2021 +0000
|
| The Si2435 appears to result OK on its own after 30 seconds' wait at
| this point.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+/trunk@2660 5505949e-d877-4686-9e03-c53b7a51b376
Patrice Fournier [Thu, 16 Nov 2023 10:49:29 +0000 (05:49 -0500)]
Fix timer when receiving DIS
From Lee's changes:
| commit a5d3b1c0309def560a3d4e4d01f3d4cdb67724b3
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Wed Oct 13 23:45:25 2021 +0000
|
| Consistently wait until T1 times out.
|
| Way back in r1740 (2007-09-04) there was an error in the calculation
| for a wait timeout. It was intended to wait until T1 times out,
| but instead caused the wait to be as long as had elapsed since the
| start of prologue - a bit confused. Furthermore, it missed changing
| an identical recvFrame() timeout from T2 to T1 in the same
| procedure.
|
| This commit now fixes those by waiting to the T1 timeout plus T2 -
| so that we at least wait a period of T2.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+/trunk@2650 5505949e-d877-4686-9e03-c53b7a51b376
| commit ef9c81cf1b02a053ce910453abd84ca2044d2a66
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Wed Oct 13 23:59:29 2021 +0000
|
| Order of operations.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+/trunk@2651 5505949e-d877-4686-9e03-c53b7a51b376
and:
| commit 5053f4c7575c43c18028da949261ac31c191683e
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Mon Nov 15 19:10:13 2021 +0000
|
| We should be waiting T1 rather than T2 in trying to detect the
| receiver's prologue frames.
|
| This is consistent with the changes made in r2650.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+/trunk@2657 5505949e-d877-4686-9e03-c53b7a51b376
Patrice Fournier [Thu, 16 Nov 2023 10:12:32 +0000 (05:12 -0500)]
Flush modem input before sending any command to modem
From Lee's changes:
| commit 18c1bfcad009f8552308a1f00a106d793ebf2be3
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Tue Oct 26 19:48:14 2021 +0000
|
| Cope with spurious messages from the modem interfering with expected
| responses from commands.
|
| The Si2417/Si2435 have a quirk where the cancelation of an +FRM
| command does not necessarily lead to the avoidance of +FCERROR
| messages. So, it may look like this:
|
| <-- AT+FRM=145
| (timeout)
| <-- abort
| --> NO CARRIER
| (wait, remote signals V.21 HDLC)
| --> +FCERROR
|
| Unfortunately, that spurious +FCERROR message is unpredictable and
| unexpected and will cause all sort of logical confusion to our
| operations.
|
| While the spurious +FCERROR usually will be seen at predictable
| commands (notably AT+FTH=3 and AT+FRS=7) and we could limit the
| flushing to those specific commands, it makes sense to flush modem input
| prior to every AT command because at no point will we be expecting
| messages from a preceding command to appear after we send a subsequent
| AT command.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+/trunk@2655 5505949e-d877-4686-9e03-c53b7a51b376
Patrice Fournier [Thu, 16 Nov 2023 09:53:33 +0000 (04:53 -0500)]
Adding suppport for SiLabs Si2417/Si2435 (Mainpine rev4)
Based on Lee's work:
| commit db71bc023fc9df4ca6cd7fc913e4d83bfc87a731
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Fri Feb 5 16:07:56 2021 +0000
|
| add support for SiLabs Si2417/Si2435
|
| The Si2435 supports V.34-Fax (SuperG3) but does not implement
| auto-fallback to G3 modes which requires us to implement the fallback
| in the DTE.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+/trunk@2580 5505949e-d877-4686-9e03-c53b7a51b376
| commit acf58db7a3caba2a58e92fb1b910e28bed6dfab7
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Thu Sep 30 21:28:47 2021 +0000
|
| More adjustments for Si2435
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+/trunk@2646 5505949e-d877-4686-9e03-c53b7a51b376
and:
| commit 2a83c97ea9eca7971cf9b02d24f9fde64fcedc28
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Sun Nov 14 23:56:19 2021 +0000
|
| Correction
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+/trunk@2656 5505949e-d877-4686-9e03-c53b7a51b376
Patrice Fournier [Thu, 16 Nov 2023 07:30:21 +0000 (02:30 -0500)]
Set hasV34Trouble on Class 1.0 "OK" and DLE+EOT dial responses
Based on Lee's work in:
| commit 82b66318b2ea22a8d383abda6aa33d0ec71f3b85
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Fri Oct 8 12:35:41 2010 +0000
|
| When some Class 1.0 modems respond OK after dialing it means that there
| was some kind of V.34/V.8 handshake incompatibility. Disable V.34
| automatically for those destinations.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+@2135 5505949e-d877-4686-9e03-c53b7a51b376
and:
| commit b0901cf480430d84479ee6474e7ae556c2033fa4
| Author: Lee Howard <faxguy@howardsilvan.com>
| Date: Sat Nov 20 19:59:09 2010 +0000
|
| detect hasV34Trouble for Class 1.0 DLE+EOT dial responses
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+@2149 5505949e-d877-4686-9e03-c53b7a51b376
Set FIFO response waiting flag earlier to prevent deadlock
We set the flag indicating we are waiting for a response before sending
our FIFO message so that if the response arrives before we enter the
dispatcher loop waiting for it, it correctly gets saved and we can
process it when we are ready instead of it being discarded and then
causing a deadlock where we are waiting for a message that will never
arrive.
Patrice Fournier [Tue, 20 Jun 2023 21:42:25 +0000 (17:42 -0400)]
Increasing file header buffer used to detect file type
We need to look at byte 513 to detect some Microsoft files, so our
512 bytes buffer is not enough. Doubling to 1024 for now until we
move to a better solution.
Newer PoDoFo packages require and are built with C++11 standard
We thus do the same for faxcover so we can compile against these
newer packages. We also make sure to only link faxcover against
the PoDoFo library.
Do not call shell to run external commands for hardened security
Based on Lee's work:
| commit ee202b04eb9d0704fc58ecfb0404fc2302b4777c
| Author: faxguy <faxguy@5505949e-d877-4686-9e03-c53b7a51b376>
| Date: Fri Jul 3 20:25:38 2020 +0000
|
| Run scripts directly rather than invoking them via a shell for security hardening.
|
| Johannes Segitz rightly pointed out that we can run our executable
| shell scripts directly rather than invoking them via a shell - and that
| doing so would harden security regarding various arguments that
| originate from user-supplied data.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+/trunk@2551 5505949e-d877-4686-9e03-c53b7a51b376
| commit f45f705b9e01bc9bd8e7d30cd40b140f46318309
| Author: faxguy <faxguy@5505949e-d877-4686-9e03-c53b7a51b376>
| Date: Sun Jul 5 19:52:54 2020 +0000
|
| Job::jobStatusName returns a static fxStr which seems to be
| problematic for use as an argv element, so this works around that.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+/trunk@2554 5505949e-d877-4686-9e03-c53b7a51b376
Patrice Fournier [Mon, 11 Feb 2019 03:21:56 +0000 (22:21 -0500)]
Getting a double-quote in a Caller*ID value causes problems.
From Lee:
| commit 91d837f7f0f4a6bff9a9c08b81dddc4eee3714c6
| Author: faxguy <faxguy@5505949e-d877-4686-9e03-c53b7a51b376>
| Date: Fri Nov 24 13:27:42 2006 +0000
|
| Getting a double-quote in a Caller*ID value causes problems.
|
| Furthermore, it poses a risk for Caller*ID doing mischevious things.
|
| So I'm changing the quote/enquote to ticks instead of double-quotes and then
| parsing through all quoted strings and coping with any ticks that appear.
|
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+@1503 5505949e-d877-4686-9e03-c53b7a51b376
Patrice Fournier [Mon, 11 Feb 2019 03:09:53 +0000 (22:09 -0500)]
Don't wait forever after +FRH:3.
From Lee:
| commit 3e1e3e54560ccc97a8a778d12d054ff9970258ab
| Author: faxguy <faxguy@5505949e-d877-4686-9e03-c53b7a51b376>
| Date: Mon Jun 18 18:27:30 2018 +0000
|
| Don't wait forever after +FRH:3.
|
| What was I thinking back in 2005 (commit r902) when I added several "waitFor(AT_CONNECT,0)"? The "0" in the waitFor allows for it to inherit the existing timer, but as best I can tell there are no timers to inherit.
|
| I must have either just mindlessly copied code from elsewhere in HylaFAX where the timer inheritance was probably appropriate, or maybe I thought that I'd go through it later to implement the timers since it wasn't really obvious how long the timer should be.
|
| git-svn-id: https://svn.code.sf.net/p/hylafax/HylaFAX+@2447 5505949e-d877-4686-9e03-c53b7a51b376
Allow Fax client parameters to start or end with double-quote
Having a double-quote character at the start or end of a parameter was causing
the fax client to send an invalid command to hfaxd causing syntax error.
Reorder destinations when a job is removed from runq
When a destination has multiple jobs and the first job gets removed
from the readyQ, the next job takes its place in the queue. So if the
next job priority differs from the one that got removed, it causes the
(destination) runq list to be unordered and any later sorted insert can
be fooled by it. e.g. if a job of priority 150 completes and the next
job to that destination is of priority 201, any job with priority 200
added after that will get put in front of that destination, preventing
all other destinations with jobs of priority 150 that were later in the
queue to be pushed back even lower.
We now re-sort the destination on the runq when a job is removed and
might have been on the destination readyQ.
Per the RFC, we must make sure MIME boundary is preceded by CRLF
NOTE: The CRLF preceding the boundary delimiter line is conceptually
attached to the boundary so that it is possible to have a part that does
not end with a CRLF (line break). Body parts that must be considered to
end with line breaks, therefore, must have two CRLFs preceding the
boundary delimiter line, the first of which is part of the preceding body
part, and the second of which is part of the encapsulation boundary.
Removed 'c' prefix to commid value in many templates.
Some (but not all) templates had the commid value prefixed by a 'c' letter.
This makes the commid match the communication log file, but does not match
the commid in xferfaxlog or other log files.
non-nul terminated messages on the PIPE will be accepted so that messages
can be sent with echo. But such message need to be parsed by the daemon
before a new message come in, else the behaviour is unspecified.
Aidan Van Dyk [Fri, 12 Nov 2010 17:27:28 +0000 (12:27 -0500)]
faxq: scanQueueDirectory fixup
We need to not wait forever here, but just a tiny pause, enough to let jobcontrol
make progress, and then dispatcher to reap child PIDs and proces jobcontrol's output.
But if no jobcontrol, we need to not wait "forever" until next fifo/alarm.
Patrice Fournier [Tue, 18 Dec 2012 18:17:58 +0000 (13:17 -0500)]
Replace non signal-safe signal handlers with simple ones setting a flag
We used non signal-safe functions in signal handlers (or functions called
in signal handlers) and this caused deadlocks in some occasions. (e.g.
when the signal is received while writing to syslog, the handler would
deadlock when trying to write to syslog itself, waiting on the interrupted
call to finish.)
We now set a simple variable to notify of a received signal and process
the signal in the regular loop.