OpenSSL server - FreeBSD/Ubuntu

[G Hasse]

So... The problem was solved. The high latancy was because an antenna
with bad "quality". We changed antenna and now we have the performance
as should be expected.

Hm...

// GH


Den 2021-02-04 kl. 08:47, skrev Niklas Hallqvist via BUS:
> 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 <mailto: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 <mailto: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 <mailto:gorhas at raditex.nu>
>>>> _________________________________________________
>>>> BSD Users Sweden -- BUS at stacken.kth.se <mailto:BUS at stacken.kth.se>
>>>> https://lists.stacken.kth.se/mailman/listinfo/bus
>>>>
>>> _________________________________________________
>>> BSD Users Sweden -- BUS at stacken.kth.se <mailto: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
> 
> 
> _________________________________________________
> 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
tel: 070 5530148
mail: gorhas at raditex.nu