LetoDBf Errors
489 views
Skip to first unread message
Ash
Mar 11, 2018, 7:11:37 AM3/11/18
to Harbour Users
Hello Rolf,
Errors when testing 2018-03-07 23:13 version without SMBSERVER.
Regards.
Ash
03.10.2018 09:18:30 INFO: LetoDBf Server 3.00, will run at port :2812 ( internal also used :2813 )
03.10.2018 09:18:30 INFO: DataPath=/volume1/bms/comp, ShareTables=1, NoSaveWA=1, max database=999
03.10.2018 09:18:30 INFO: LoginPassword=0, CacheRecords=30, LockExtended=0
03.10.2018 19:30:17 ERROR thread2() leto_SockRec(1) <> LETO_MSGSIZE_LEN [192.168.2.41: (104)]
03.10.2018 19:30:17
03.10.2018 19:33:23 ERROR thread2() leto_SockRec(1) <> LETO_MSGSIZE_LEN [192.168.2.41: (104)]
03.10.2018 19:33:23
elch
Mar 12, 2018, 8:14:29 AM3/12/18
to Harbour Users
Hello Ash,
these 'errors' are false alarm, or more precise: the description should be different.
( and independent of SMB_SERVER option )
---
Let me start here, it (may) explain also other 'error':
> Came across this error in log file today. I do not recognize the IP address.
> However, whois entry locates it in UK. Is someone trying to hack our server?
> 03.09.2018 13:53:39 ERROR thread2() leto_SockRec(43) != ulRecvLen(788529155) [185.222.211.22: (104)]
> 03.09.2018 13:53:39 *à Cookie: mstshash=Administr
> 03.09.2018 13:53:39 INFO: disconnect 185.222.211.22:2266 (null) users=(1 : 4 : 6), tables=(141 : 206)
> However, whois entry locates it in UK. Is someone trying to hack our server?
> 03.09.2018 13:53:39 ERROR thread2() leto_SockRec(43) != ulRecvLen(788529155) [185.222.211.22: (104)]
> 03.09.2018 13:53:39 *à Cookie: mstshash=Administr
> 03.09.2018 13:53:39 INFO: disconnect 185.222.211.22:2266 (null) users=(1 : 4 : 6), tables=(141 : 206)
Indeed! -- LetoDBf as intrusion (-try!) detector, what this software not all can do ;-)
OT about IP's:
don't know how ;-), but i know that an IP can be spoofed.
So you can be sure that if the IP is the real one, its a harmless beginner.
[ and if its point to Russia, its probably spoofed from US :-) ]
don't know how ;-), but i know that an IP can be spoofed.
So you can be sure that if the IP is the real one, its a harmless beginner.
[ and if its point to Russia, its probably spoofed from US :-) ]
I goggled a bit about the received data:
'someone' ( very probably a bot ) probed through the ports,
and in case of response ( an 'invite' string is send from LetoDBf )
'he' continued to check for Windows remote desktop (RDP) behind this port
This one got no further answer from LetoDBf, and its connection was closed.
'someone' ( very probably a bot ) probed through the ports,
and in case of response ( an 'invite' string is send from LetoDBf )
'he' continued to check for Windows remote desktop (RDP) behind this port
This one got no further answer from LetoDBf, and its connection was closed.
Errors when testing 2018-03-07 23:13 version without SMBSERVER.
03.10.2018 19:30:17 ERROR thread2() leto_SockRec(1) <> LETO_MSGSIZE_LEN [192.168.2.41: (104)]03.10.2018 19:30:1703.10.2018 19:33:23 ERROR thread2() leto_SockRec(1) <> LETO_MSGSIZE_LEN [192.168.2.41: (104)]03.10.2018 19:33:23
Error 104: 'Connection reset by peer' -- it have hung up after one single byte.
And same as the bot above: *missing* executable name after the IP address ':'
Executable name is ever transmitted by a LetoDBf client
--> this is *no LetoDBf app*
This evidence i take now to a write different 'debug' feedback ( if debug mode > 0 ).
----
As your LetoDBf server is reachable from internet, we may need to secure it a bit.
You can set up a firewall, so only traffic from 192.168.*.* gets to the NAS.
This may be unwanted, if someone have a 'home working' place.
* If a firewall is unwanted for the whole NAS, LetoDBf now got its own 'firewall' *
with new config option: IP_SPACE = 192.168.
will do the same -- we can put there multiple IP parts into, delimited by ';'
As your LetoDBf server is reachable from internet, we may need to secure it a bit.
You can set up a firewall, so only traffic from 192.168.*.* gets to the NAS.
This may be unwanted, if someone have a 'home working' place.
* If a firewall is unwanted for the whole NAS, LetoDBf now got its own 'firewall' *
with new config option: IP_SPACE = 192.168.
will do the same -- we can put there multiple IP parts into, delimited by ';'
If the connection is not in the range, it will be immediately closed.
( new section: 4.5 Security in ReadMe.txt )
best regards
Rolf
Ash
Mar 26, 2018, 8:11:21 PM3/26/18
to Harbour Users
Hello Rolf,
I have a utility application that builds all the index files for a selected company in BMS application. I have been using it for a number of months without any changes and it works well when used under Samba. However, when it is run in LetoDBf environment, it ends with the following error. The table being indexed contains over 200,000 records. The same table in an other company's database having 3,500 records gets its index-s built without any errors.
Regards.
Ash
Subsystem Call ....: LETO
System Code .......: 1000
Default Status ....: .F.
Description .......: Syntax error
Operation .........:
Arguments .........:
Involved File .....:
OS Error Code .....: 0
Trace Through:
----------------
ORDCREATE : 0 in Module:
ARCDX : 210 in Module: ..\source\aiprocs.prg
ALLCDX : 40 in Module: ..\source\aiprocs.prg
ACCIN : 73 in Module: ..\source\bmsindex.prg
MAIN : 46 in Module: ..\source\bmsindex.prg
Ash
Mar 27, 2018, 7:44:11 AM3/27/18
to Harbour Users
Hello Rolf,
LetoDBf is running in single server mode.
Regards.
Ash
Ash
Apr 2, 2018, 9:06:46 AM4/2/18
to Harbour Users
Hello Rolf,
This error appears when indexing a table with blank records containing character and date field types.
Regards.
Ash
Ash
Apr 5, 2018, 11:31:28 AM4/5/18
to Harbour Users
Hello Rolf,
Any help?
Regards.
Ash
elch
Apr 6, 2018, 6:34:09 AM4/6/18
to Harbour Users
Hello Ash,
This error appears when indexing a table with blank records containing character and date field types.
For sure no empty <date> fields will cause a problem:
in this case you get an <empty date>, e.g.: DTOS( date_field ) --> " ".
in this case you get an <empty date>, e.g.: DTOS( date_field ) --> " ".
I made even tests with a corrupted! DBF, containing <illegal letters> in the date field:
[ 8-byte! date-fields internally use literally numerics "0" to "9",
so i used a hex-editor to put there literally nonsense ]
also this case led in my tests to just only an <empty date>, no further RTE occur.
[ 8-byte! date-fields internally use literally numerics "0" to "9",
so i used a hex-editor to put there literally nonsense ]
also this case led in my tests to just only an <empty date>, no further RTE occur.
Further: RTE errors are save fetched at server side at multiple places,
as in example for index creation itself, and expected to be reported in server log files.
----
System Code .......: 1000
Error 1000 would common appear on connection shutdown
-- done by the server in case of serious!, non catchable Harbour/ system errors
-- done by the server in case of serious!, non catchable Harbour/ system errors
( -> hb_out.log with server 'crash' --> connection close without answer )
-- when the client did not receive an answer for explicitly given timeout timespan.
-- when the client did not receive an answer for explicitly given timeout timespan.
Client application send requests to server, in this case: create index
When server have completed this task,
When server have completed this task,
a confirming answer with info about the new order is send back to client.
* By default, the client waits *120000* ms ( = 120 seconds = 2 minutes ) for answers *
Such timeout value is enough to create even a complex index key for millions of records,
because the order is created locally at server without network traffic during the process.
( and e,g, enough to execute complex server side UDF functions )
After this timespan without an answer to a request, client assume server ( or connection ) is down.
Probably conclusion:
you are 'playing' with the 4th param [ timeout in ms ] of Leto_Connect() ???
best regards
Rolf
Ash
Apr 6, 2018, 8:17:07 AM4/6/18
to Harbour Users
Hello Rolf,
Probably conclusion:
you are 'playing' with the 4th param [ timeout in ms ] of Leto_Connect() ???
You are right. I had the timeout set to 1000. I meant it to be 10000.
Thank you.
This error condition only appears as DEBUG information in letodb.log file when Debug level is 10 or above. Might I suggest that this condition be reported as an ERROR no matter what the Debug level is. Debug level was 1 (default) in this case.
Below is the information I had at hand to resolve the error but I failed. Attached files were of no help either.
Regards.
Ash
-- letodb.log.
Highlighted lines appear only when Debug level is 10 or above.
04.06.2018 07:36:17 INFO: connected 192.168.2.41:57921 bmsindex.exe CP: EN DF: MM/DD/YYYY conn-ID 1
04.06.2018 07:36:17 DEBUG thread3() 2. socket for client at address: 192.168.2.201:2812 :57921
04.06.2018 07:36:36 DEBUG thread2() socket error ETIMEOUT (2) - maybe closed ..
04.06.2018 07:36:36 INFO: disconnect 192.168.2.41:57921 bmsindex.exe users=(2 : 2 : 2), tables=(0 : 3)
Ash
Apr 19, 2018, 9:21:45 AM4/19/18
to Harbour Users
Helo Rolf,
This error condition only appears as DEBUG information in letodb.log file when Debug level is 10 or above. Might I suggest that this condition be reported as an ERROR no matter what the Debug level is. Debug level was 1 (default) in this case.
Would you be able to make this change?
Regards.
Ash
elch
Apr 24, 2018, 7:57:15 PM4/24/18
to Harbour Users
Hello Ash,
Multiple ways to solve yourside:
e.g to set errorblock() to your 'panic_handler() at begin of your_handler,
and so i.e. possible suppress RTE during your error function is working,
[ and restore CB after processed ... ]
I assume, that DbUseArea() is checked for return value or ALIAS(),
to verify for success before proceeding, at very least in your_handler().
####
i have still *not* uploaded any above fix, in a low urgent 'testing-phase' ;-)
Would you be able to make this change?
> you are 'playing' with the 4th param [ timeout in ms ] of Leto_Connect() ???
You are right. I had the timeout set to 1000. I meant it to be 10000.
This error condition only appears as DEBUG information in letodb.log file when Debug level is 10 or above. Might I suggest that this condition be reported as an ERROR no matter what the Debug level is. Debug level was 1 (default) in this case.
04.06.2018 07:36:17 DEBUG thread3() 2. socket for client at address: 192.168.2.201:2812 :57921
this is a positive! debug feedback, expected to regularly happen.
Occur for debug level >= 10
Occur for debug level >= 10
04.06.2018 07:36:36 DEBUG thread2() socket error ETIMEOUT (2) - maybe closed ..
? debug level > 1 :
because this is not specific bound to error: ETIMEOUT,
aka it may occur with other socket 'problem' at server,
because this is not specific bound to error: ETIMEOUT,
aka it may occur with other socket 'problem' at server,
*and* this server timeout is not the timeout from client ...
----
Instead changing debug level, for a 'problem' at the other side ...
... i like to clarify about *timeout* value of Leto_Connect():
is the maximum timespan,
you give the client application to wait for an answer from server.
If got no response after only 1[0] !! s:
---> RunTimeError [ --> your error handler --> (**) ] --> QUIT
By using Leto_Connect() *without* given timeout value, a default value is used.
*correction* of last post/ ReadMe: actually this is '-1' == wait infinite.
[ 120 s are default value for other kinds of initial connect to a server ]
I like to sync above:? aka default also 120[000m]s for LetoConnect() ?
* you likely agree, that even your 10 seconds are low to activate RTE 'panic-mode' ? *
likely a user sits in front of terminal: tip tip tip <enter>:
give you 10 seconds!, else we quit! :-))
----
(**)
you reported an 'OS error 6005' Exception error
in your error handler at LOGERROR(322).
Because ..: ;-)
in your error handler, DbUseArea() send request to server,
this request gets the ( meanwhile ready and outstanding ) answer of
former OrdCreate() request.
This answer used for DbUseArea() will crash ...
Instead changing debug level, for a 'problem' at the other side ...
... i like to clarify about *timeout* value of Leto_Connect():
is the maximum timespan,
you give the client application to wait for an answer from server.
If got no response after only 1[0] !! s:
---> RunTimeError [ --> your error handler --> (**) ] --> QUIT
By using Leto_Connect() *without* given timeout value, a default value is used.
*correction* of last post/ ReadMe: actually this is '-1' == wait infinite.
[ 120 s are default value for other kinds of initial connect to a server ]
I like to sync above:? aka default also 120[000m]s for LetoConnect() ?
* you likely agree, that even your 10 seconds are low to activate RTE 'panic-mode' ? *
likely a user sits in front of terminal: tip tip tip <enter>:
give you 10 seconds!, else we quit! :-))
----
(**)
you reported an 'OS error 6005' Exception error
in your error handler at LOGERROR(322).
Because ..: ;-)
in your error handler, DbUseArea() send request to server,
this request gets the ( meanwhile ready and outstanding ) answer of
former OrdCreate() request.
This answer used for DbUseArea() will crash ...
... i need to fix in the kind that it lead to another Harbour RTE, but no OS exception
* --> you will get an infinite logerror() handler call, as error in error ! *
* --> you will get an infinite logerror() handler call, as error in error ! *
Multiple ways to solve yourside:
e.g to set errorblock() to your 'panic_handler() at begin of your_handler,
and so i.e. possible suppress RTE during your error function is working,
[ and restore CB after processed ... ]
I assume, that DbUseArea() is checked for return value or ALIAS(),
to verify for success before proceeding, at very least in your_handler().
####
i have still *not* uploaded any above fix, in a low urgent 'testing-phase' ;-)
and
# set with Leto_Connect() the timeout for new *OR* active connection,
then changeable for special [temporary?] occasions
# fix error 6005 for out-of-sync connection
# an unique error number (1012?) for a timed-out aka 'out of sync' connection,
to possible be better identified in your client error log.
# planned <default> values in future:
6 seconds for the fresh initial Leto_Connect(),
[ aka timeout for initial first request/answer: hello ? -> here ! ],
then 120 s for all following action.
( suggest <defaults> can be adapted with Leto_Connect() )
# solved problem reported by Itamar
# ...
then changeable for special [temporary?] occasions
# fix error 6005 for out-of-sync connection
# an unique error number (1012?) for a timed-out aka 'out of sync' connection,
to possible be better identified in your client error log.
# planned <default> values in future:
6 seconds for the fresh initial Leto_Connect(),
[ aka timeout for initial first request/answer: hello ? -> here ! ],
then 120 s for all following action.
( suggest <defaults> can be adapted with Leto_Connect() )
# solved problem reported by Itamar
# ...
best regards
Rolf
Reply all
Reply to author
Forward
0 new messages