1 Reply by da

(3 replies, posted in wolfSSL)

thank you for the answer
it would be great indeed to find out why the alerts happen, but i haven't dived yet into the details of the tcp implementation
so i will indeed increase it for now to over 255, now that i know it is never reset
the app runs continuously so over time it is normal it will accumulate alerts
i will say though that it would be great if i could reset manually the alert count, so i'd like it if you could expose a method that resets the alert count
from my understanding is that the alert count is there to ward off dos attacks, but in my opinion it is one thing to get 5 alerts in 5 milliseconds and completely another to get 5 alerts over 5 days, so it would be great for all users of the library if they could keep track of the alerts themselves this way, since the user would know for how long the object existed, could keep the number of alerts in a bigger int etc, and they could decide at runtime whether they are facing a dos or not

Go to forum: wolfSSL

2 Topic by da

(3 replies, posted in wolfSSL)

i have a question regarding the .options.alertCount member of a wolfssl object:
when/where is this byte reset in the wolfssl object?
i can see where it is incremented, but i don't see when/where is it reset. i assume there is a memset somewhere, but i can't seem to find it.

i am getting the -427 error sometimes in a client app (so i don't care about dos attacks), and i am wondering if it makes sense to increase the limit to something big like 100 instead of the default 5, or would it still get tripped eventually (because it is not reset)?

thank you in advance for the help

Go to forum: wolfSSL

3 Topic by da

(1 replies, posted in wolfSSL)

hello

i have a c++ app that connects to another machine and (rarely) gets sigpipe, which is bad since i want the app to keep running and try again later
the stacktrace looks like this:
wolfSSL_write ->
SendData ->
SendBuffered.part.0 ->
EmbedSend ->
"../sysdeps/unix/sysv/linux/send.c", line 23, in __libc_send ->
"../sysdeps/unix/sysv/linux/send.c", line 28, in __libc_disable_asynccancel

i assume that the other machine disconnects between the app checking the validity of the connection and wolfSSL_write
obviously, i can make a signal handler that throws an exception on sigpipe and then catches the exception outside wolfSSL_write
but i am curious whether i can make a signal handler that ignores the sigpipe, and then just continue with the wolfSSL_write
i assume wolfSSL_write should return -1, and then i would get the exact error with wolfSSL_get_error

my questions are
1. did i understand correctly that on sigpipe while writing, although sigpipe is raised, wolfssl will return -1?
2. what is the error i would receive from wolfSSL_get_error in this case?

thank you

Go to forum: wolfSSL

4 Topic by da

(1 replies, posted in wolfSSL)

i have a c++ single-threaded app that uses wolfssl c library for the tls
the app receives data on existing connections and constantly closes and creates new connections
i have benchmarked the app and noticed that the 

wolfSSL_connect

function takes about 400 microseconds (btw i have setup the library to not check certificates), which means my messages get delayed by up to 400 microseconds, i create a lot of new connections which means a lot of spikes
i have lightly gone over the code in wolfssl and i have seen a lot of situations where there is a switch with cases like:

TLS_ASYNC_BEGIN
TLS_ASYNC_BUILD
TLS_ASYNC_DO
TLS_ASYNC_VERIFY
TLS_ASYNC_FINALIZE

between them there is 

FALL_THROUGH;

what i want is to remove the fallthrough or to return so that the wolfssl function is basically broken into multiple pieces, which might only cause 50 microseconds (or even less)
i would then have to call it more times and it obviously take longer to create a new connection, but i don't care because it would not impact the latency of the messages of my existing connection
---
it seems like a big undertaking though, and i would like some help/advice
is there an easy solution for what i want that i am just not seeing?
if not:
is there some documentation specifically for this case?
what are the things that i should watch out for?
is there some specific approach that i should take?
thank you in advance

Go to forum: wolfSSL