Ситуация такова: на удалённом объекте есть некий контроллер, который собирает инфу с датчиков, и отдает по RS232. прикрутили к нему mikrotik RB912 - его COM-порту дали remote-accesss, всё как положено.. через 4g/lte и моб. инет по pptp связан с сетью предприятия, на виртуалке крутится scada, которая забирает эти данные с контроллера (у наладчиков такая же "десктопная" на ноуте).
НО: пока микротик "на столе в лаборатории", в локалке, или если приехать на объект с ноутом и воткнуться в него в eth (или даже подцепиться по wifi)- всё прекрасно читается, все хорошо. а вот через pptp всё плохо - то не видит контроллер, то видит, но не видит половины датчиков, даже номера датчиков перевирает безбожно. что только не делали - софту подняли таймауты, меняли симку на другого оператора, с mtu игрались - не помогает.. где могут быть грабли?
PS: есть таки смутное подозрение, что где-то в mtu собака порылась - у eth стандартное mtu 1500, у lte - 1480, а у pptp вообще 1450...
объекте есть некий контроллер, который собирает инфу с датчиков, и отдает по RS232. прикрутили к нему mikrotik RB91
а можно больше подрбностей именно в этой части преобразований, если это rs to usb стоит забыть о перендачэ этого кроме как на usb(com to uart может и переварит но не сеть), в ответе ниже точнее описаны проблемы преобразований поточной передачи с rs232, хотите rs to eth ставте именно его он именно для этого
Ps ограничение на уровне разностей протоколов и их преобразований
Pss rs232(com protocol как и rs485) слишком древний и не преднозначен для интернета, только локалка, и даже там может глючить на bit lock если приемник не настроен на определенный bit rate
контроллер точно modbus rtu гонит, не что-то другое? если да — дело не в mtu, tcp гарантирует порядок и целостность, цифры датчиков сами по себе не должны съезжать. похоже на джиттер lte: modbus rtu режет кадры паузой в 3.5 символа, а rfc2217 (com-порт микротика поверх tcp) эту паузу через pptp+мобильный теряет, отсюда и путаница с номерами. глянь baud/parity/stop bits с обеих сторон, а по-хорошему поставь на объекте modbus rtu→tcp шлюз вместо прозрачного com-порта, надёжнее выйдет.