OpenSSL server - FreeBSD/Ubuntu

[Niklas Hallqvist]

Well, even when you are debugging "high-level" applications, low-level tools can help you
tremendously.  For example tcpdump can tell you which party, the client or the server, is the
one who is causing the slowdown/halt.  If you have the capability of running it at both ends
you can also come to terms with if you should blame the network and any external providers/services,
by matching the packet streams.  Just ruling out one side of the setup, and the intermediary network
you will have come a lot closer to the culprit.

Anyway, I might have time to help you commercially. Send me a private email, if you get desperate.

/Niklas

> On 3 Feb 2021, at 20:14, gorhas via BUS <bus at stacken.kth.se> wrote:
> 
> Yes... I am a little bit vague - since I don't fully understand what is going on.
> 
> I have a OpenSSL-server and a OpenSSL-client. The client are sending "binary" data to the server with SSL_write and the server is receiving with SSL_read. I am using a function call like
> 
> no_bytes = SSL_read(ssl, ssl_buffer, SSL_BUFFER_SIZE);
> 
> This works suprisingly good. I always get a full buffer. If I run the application on the local network between two machines, i get exteemly good performance. If I run from our IoT devicd I get not so good performance. This is expected since this is connected by a BG95 (mobile module). But the problem is that sometimes the packet rate slows down and sometimes it comes to a halt.
> 
> Since I am using high level calls like SSL_read/write I have not mutch use of tools like tcpdump, strace et.al. since I can't influence the packet flow from the high level api:s.
> 
> Since the data I am transfereing is about 5MB (a sound file) I belive that the network provider (Telenor) have som kind of "trafic shaping" in action. And I don't understand how I can investigate this.
> 
> This is a rather important application for me (commercial) and if some  wants to cut in and investigate the problem please let me know.
> 
> // GH
> 
> Den 2021-02-03 kl. 11:35, skrev Niklas Hallqvist via BUS:
>> It's a rather open question you are posing, your problem could be almost anything.
>> Please provide more input.  Does this happen even in the simplest localhost scenario?
>> When you say thee server "stops", what does that a mean?  Does it crash, spin, block on network input,
>> Block on anything else (like on getting some resource it needs to deal with the client provided data, like an output pipe)?
>> 
>> You just have to give a lot more information.
>> t
>> Otherwise tcpdump, various system call tracers (like Astrid hinted about), potential libcall tracers (like ltrace) and
>> Since you are writing your own server, a debugger like gdb, are your friend.
>> 
>> /Niklas
>> 
>> 
>>> On 2 Feb 2021, at 21:32, G Hasse via BUS <bus at stacken.kth.se> wrote:
>>> 
>>> Hi!
>>> 
>>> I don't know if this is a BUS question - but if not - forgive me!
>>> 
>>> I am trying to write an openssl server, and have som problem.
>>> 
>>> A client is sending binary packets with SSL_write, and a server is reveiving with
>>> SSL_read. Everyting is OK until about 1500000 bytes are sent. Then the server
>>> just stops...
>>> 
>>> Is there any ideas how to investigate this?
>>> 
>>> // GH
>>> 
>>> -- 
>>> Göran Hasse
>>> Raditex Control AB
>>> Boo 229, 715 91 ODENSBACKEN
>>> tel: 070 5530148
>>> mail: gorhas at raditex.nu
>>> _________________________________________________
>>> BSD Users Sweden -- BUS at stacken.kth.se
>>> https://lists.stacken.kth.se/mailman/listinfo/bus
>>> 
>> _________________________________________________
>> BSD Users Sweden -- BUS at stacken.kth.se
>> https://lists.stacken.kth.se/mailman/listinfo/bus
> 
> -- 
> Göran Hasse
> Raditex Control AB, Boo 229, 715 91  ODENSBACKEN
> email: gorhas at raditex.nu <mailto:gorhas at raditex.nu>  mobile: +46 70 5530148
> 
> _________________________________________________
> BSD Users Sweden -- BUS at stacken.kth.se <mailto:BUS at stacken.kth.se>
> https://lists.stacken.kth.se/mailman/listinfo/bus <https://lists.stacken.kth.se/mailman/listinfo/bus>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.stacken.kth.se/pipermail/bus/attachments/20210204/a0158b39/attachment.htm>