Alexander Velkov

OK. Thanks once again! Alex

Because the output buffer may be up to twice the size of the input buffer from the device, the read for telnet is only half the buffer size. And you don't want telnet because some data might be modified by the protocol. Alright, is that because of special characters that are being added to the output in case of 'telnet'? Regards Alex

Because the output buffer may be up to twice the size of the input buffer from the device, the read for telnet is only half the buffer size. And you don't want telnet because some data might be modified by the protocol. Alright, is that because of special characters that are being added to the output in case of 'telnet'? And if that is the case, was it the <enter> character that required more buffer ?</enter> Regards Alex

Because the output buffer may be up to twice the size of the input buffer from the device, the read for telnet is only half the buffer size. And you don't want telnet because some data might be modified by the protocol. Alright, is that because of special characters that are being added to the output in case of 'telnet'? Regards Alex

Hi Corey, thanks for your feedback. I have good news regarding the tests. We didn't notice that we had configured the protocol type to 'telnet', instead of 'raw'. Once we changed it to 'raw', we got the expected results! I am not really sure why this setting has an effect on the buffer but it was definitely a misconfiguration on our side. I have tested with using the latest version of Ser2Net in the 3.5.x branch + the two patches you sent to me. I think the reset_buffer_on_empty.patch is important...

Hi Corey, thanks for your feedback. I have good news regarding the tests. We didn't notice that we had configured the protocol type to 'telnet', instead of 'raw'. Once we changed it to 'raw', we got the expected results! I am not really sure why this setting has an effect on the buffer but it was definitely a misconfiguration on our side. I have tested with using the latest version of Ser2Net in the 3.5.x branch + the two patches you sent to me. I think the reset_buffer_on_empty.patch is important...

Looking at this, what are your chardelay settings? right, we were testing these settings as well. So in the test above: chardelay-min=40000 chardelay-max=200000

Hi Corey, we've made a few tests in our Lab with a collegue of mine. I am sending you a few Infos regarding our tests and results. I am now using ser2net 3.5.x in the latest patch level of the 3.5.x branch (including [69195f]) plus the 2 patches for the net-to-dev/dev-to-net buff size configuration and resetting the circular buffer that you have sent to me. The configuration parsing is now working, the dev-to-net-bufsize is now set to the correct value 80. But the circular buffer patch is not changing...