This differentiates between faxnumber and "fromfax" in the q-files.
sendJobDone deletes the req for us
suseconds_t tv.tv_usec needs to be cast to long to avoid a warning on systems where it is defined as long long.
Fail a job sooner if shared call failures cause it to reach maxdials.
spelling
This appears to be needed, like in all the others.
Prevent G3Decoder.c++ SIGABRT when clang optimization is used.
Make faxrm work again when a job is running.
Unfortunately, using a one-byte rcvBuf in OpenBSD seems to have the opposite effect from what is desired. It seems to make the issue worse.
Add support for 230400 ModemRate - from Larry Moore
Credit for r2857
Refactor the previous commit as it was problematic on some systems.
Fix possible SIGABRT in HylaFAXServer::getServerStatus
These should be static - from Larry Moore.
OpenBSD experiences SIGABRT on the read() in loggingThread after ten thousand or so bytes are processed.
Updates from Frank Brock
Four times, not three.
Cope with senders that repeatedly corrupt the last frame of a page.
Prevent hfaxd from logging errors about incomplete job files during their submission.
Properly create a detached thread so that we don't leak resources.
Add some comments to help explain what may be seen.
Add the senderFumblesSSLFax feature.
Only set emsg when emsg is empty.
Correct operation for multi-block pages and remove the "extraneous" loggin as it is likely to be misunderstood.
We expect a successful ECM operation to result in valid image data. However, there's no assurance of this, and we have seen senders which sometimes send null Phase C image data (properly ECM framed) in response to PPR. If MH or MR are being used then the result is merely a corrupt page image nearly the same as if ECM were not used. On the other hand, if MMR is used, then the image will be truncated at the point of corruption, and there's no way to fix that.
Add senderFumblesMMR feature.
Bump
Avoids build warning/error. Optimizes code.
I think that we're leaking a little bit of memory for every SSL Fax proxy connection without this.
Prevent fax protocol delays caused by updating the modem status on the server.
Permit SSL Fax to proceed even if TCF had a timeout.
The Si2435 can respond with DLE+ETX, ERROR to +FRH=3.
A umask can interfere with the expected mode on file creation. This prevents that.
These were not quite right. If a job failed after a few pages sent then the retry would usually end up with problematic settings.
A bit of explanation for the needs reset usage for the Si2435.
We don't need +FRS before +FRH - we only should need +FRS before +FTH and +FTM.
Update.
Waiting T2 is probably too long and may lead to missing parts of the repeated signals. T4 is good for the reset need.
If the prologue signal is interrupted in the right way then SiLabs (and possibly others) can have the +FRH=3 command stop functioning as expected. So, we just reset it as needed.
The "bizarre situation" only refers to the first transmission of the block.
Some equipment out there sometimes reverses the bitorder on RCP frames.
Initialize it better.
Add full duplex capability during sendTraining()
Further to the previous commit... we also don't double it if we had a timeout.
Cope with a particular variety of "3CX Fax Machine" using spandsp and sitting behind a T.38 gateway of some kind where it sends short meaningless signal before each response (CFR and MCF, particularly).
When we last sent RTN the expectation of the sender is a bit different.
Handle CNG detection in Phase D non-ECM.
Avoid confusion if we send CRP and the other side responds with CRP.
Turn off full duplex before returning false.
It's probably a little more clear this way.
This switching pause needs to include the gap between DCS and TCF if we're not full-duplex.
We turn checkReadOnWrite off because we expect there to be times when the +FRH:3 response comes before we're done writing HDLC data to the modem, and we need to pick up the response afterwards.
Add Class1FullDuplexTrainingSync for +FAR=2.
Add initial support for +FAR=2 iaxmodem feature to detect V.21 HDLC frames while sending them.
If somehow we missed the sender's initial response they should repeat their response after T4 lapses, somewhere between 2550 and 5175 ms later (more probably between 2550 and 3450 ms). But if they somehow missed our initial signal then they could be expecting us to repeat them before T2 lapses (6 +/- 1s) before they give up.
Add Class1SendNSF configuration option.
The point of decrementing prevPage here was to counteract the incrementation directly above it. However, this is a problem because prevPage really just tells the protocol whether we're entering Phase C for the first time after DCS or not. So...
Fix (again) the logic in repeatCED.
Improve the logic in r2806
Stop trying to print binary data as strings. The administrator can set I/O logging if they want to see the hex values.
Unfortunately, rcpcnt is not reliable for this purpose because we fake RCP signals sometimes.
When using ECM we do expect there to sometimes be very short Phase C periods. So, pay attention to RCPs to discern.
Follow the same logic as r2774 (21 Aug 2024) for ECM.
+FRCNG handling in Phase C non-ECM
Doing CED more than one time extra may be silly.
Do the same as the last commit but for CSI+DIS
Try to cope with broken TSI+DCS signals.
Try to cope with some types of poor HDLC frame formatting...
Correct the interpretation of ndials, ntries, tottries, and totdials when a proxy is used.
Log dataSent and dataMissed in the session log as it may be convenient to get it there.
We need to wait here before responding to CRP.
bump
With iaxmodem throwing +FRCNG results to +FRH and +FRM when CNG is detected there will be a number of adjustments needed to handle returns to Phase B. This is the first.
Add the Class1PhaseBRecvTimeoutCmd configuration option.
Add Class1ExpectedPageSize configuration parameter.
fix build for GCC v15 on Fedora 42
Fix warnings about ‘/*’ within comment
If the sender can't get anything through to us after four attempts at 2400 bps, then let's mark them as fumbling ECM.
Correct the logic in yesterday's commits.
Continuation of the previous commit.
bump
If Phase C terminates suddenly with a fast stuttering tone, then our Phase D reception attempts may quickly report a bunch of bad frames, several in a second, perhaps. This change extends the time we try receiving Phase D to at least 4-5 seconds so that a brief audio glitch can be overcome.
Ignore DTMF presentation in Class 1 when dialing.
Spelling corrections by Friedhelm Mehnert
Also try SSL Fax if recvFrame times out on DCS reception but we got TSA.
When receiving if we happen to get TSA but not DCS, then it seems best to start up the SSL Fax connection and then repeat Phase B.
Add error codes for "Unspecified failure to train with receiver" and "fax page transmission failure"
This status indicator should default to retry rather than failed.
Add support for libtiff 4.7.x
Try to cope with T.38 invite stutter at beginning of receive.
Mark sender as confusing RTN if they just hang up after RTN.
Stop TSI and DCS from interfering with our PPMseq
Just updating the code comments. There's nothing more, really, to do about this situation.
lastPPM and prevPPM cannot be trusted for the purpose of detecting senders who confuse RTN because we specifically modify lastPPM in the event that we send RTN.
A sender who transmits MPS and then, on the Phase C subsequent to RTN, transmits EOP does not appear to be retransmitting the page and has confused RTN.
... let's try this again.
Cope with non-ECM phase C fast carrier restart.