Application freerdp failed with an error 131

2021-07-31 16:08:28,226 INFO: Remote Desktop Options : /f /sec:nla /cert-ignore /sound:sys:alsa,format:1,quality:high /rfx /gfx /gfx-h264 /multitransport /network:auto -bitmap-cache -glyph-cache /gdi:hw -fonts +auto-reconnect /auto-reconnect-max-retries:5 /multimon:force +async-input +async-update
2021-07-31 16:08:28,820 INFO: Subprocess: [WARN] [com.freerdp.core.nla] - SPNEGO received NTSTATUS: STATUS_LOGON_FAILURE [0xC000006D] from server
2021-07-31 16:08:28,820 INFO: Subprocess: [ERROR] [com.freerdp.core] - nla_recv_pdu:freerdp_set_last_error_ex ERRCONNECT_LOGON_FAILURE [0x00020014]
2021-07-31 16:08:28,820 INFO: Subprocess: [ERROR] [com.freerdp.core.rdp] - rdp_recv_callback: CONNECTION_STATE_NLA - nla_recv_pdu() fail
2021-07-31 16:08:28,820 INFO: Subprocess: [ERROR] [com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -1
2021-07-31 16:08:28,825 INFO: Subprocess: [INFO] [com.freerdp.core] - freerdp_connect:freerdp_set_last_error_ex resetting error state
2021-07-31 16:08:28,825 INFO: Subprocess: [INFO] [com.freerdp.client.common.cmdline] - loading channelEx rdpdr
2021-07-31 16:08:28,825 INFO: Subprocess: [INFO] [com.freerdp.client.common.cmdline] - loading channelEx rdpsnd
2021-07-31 16:08:28,826 INFO: Subprocess: [INFO] [com.freerdp.client.common.cmdline] - loading channelEx cliprdr
2021-07-31 16:08:28,826 INFO: Subprocess: [INFO] [com.freerdp.client.common.cmdline] - loading channelEx drdynvc
2021-07-31 16:08:28,826 INFO: Subprocess: [INFO] [com.freerdp.primitives] - primitives autodetect, using optimized
2021-07-31 16:08:28,826 INFO: Subprocess: [INFO] [com.freerdp.core] - freerdp_tcp_is_hostname_resolvable:freerdp_set_last_error_ex resetting error state
2021-07-31 16:08:28,826 INFO: Subprocess: [INFO] [com.freerdp.core] - freerdp_tcp_connect:freerdp_set_last_error_ex resetting error state
2021-07-31 16:08:28,830 ERROR: Remote desktop exited with error. (code 131)

• Печать

Тема: [РЕШЕНО] Вопросы по freerdp  (Прочитано 21527 раз)

evil_bofh

• Печать

remmina «Cannot connect to the RDP server … via TLS. Check that the client and server support a common TLS version»

Bug #1954970 reported by
Dmitry G.
on 2021-12-16

This bug affects 14 people

[marcos@Nomad01 ~]$ remmina
Remmina plugin glibsecret (type=Secret) has registered but not yet initialized/activated. Initialization order is 2000.
Secret plugin glibsecret has been successfully initialized and will be your default secret plugin
StatusNotifier/Appindicator support: not supported by desktop. Remmina will try to fallback to GtkStatusIcon/xembed
Running under Gnome Shell version 3.34.1

(org.remmina.Remmina:64372): Gtk-WARNING **: 15:35:38.740: gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem

(org.remmina.Remmina:64372): Gtk-CRITICAL **: 15:35:38.742: gtk_toggle_action_set_active: assertion 'GTK_IS_TOGGLE_ACTION (action)' failed
[15:35:42:823] [64372:64376] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[15:35:42:823] [64372:64376] [INFO][com.freerdp.client.common.cmdline] - loading channelEx drdynvc
[15:35:42:832] [64372:64376] [INFO][com.freerdp.gdi] - Local framebuffer format  PIXEL_FORMAT_BGRX32
[15:35:42:832] [64372:64376] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_BGR24
[15:35:42:832] [64372:64376] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel disp
[15:35:42:872] [64372:64376] [ERROR][com.freerdp.core.update] - [0x03] Cache Glyph - SERVER BUG: The support for this feature was not announced! Use /relax-order-checks to ignore
[15:35:42:872] [64372:64376] [ERROR][com.freerdp.core.update] - order flags 03 failed
[15:35:42:872] [64372:64376] [ERROR][com.freerdp.core.update] - update_recv_order() failed
[15:35:42:872] [64372:64376] [ERROR][com.freerdp.core.update] - UPDATE_TYPE Orders [0] failed
[15:35:42:872] [64372:64376] [ERROR][com.freerdp.core.rdp] - DATA_PDU_TYPE_UPDATE - update_recv() failed
[15:35:42:872] [64372:64376] [ERROR][com.freerdp.core.rdp] - rdp_recv_data_pdu() failed
[15:35:42:872] [64372:64376] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -1
[15:35:42:872] [64372:64376] [ERROR][com.freerdp.core] - freerdp_check_fds() failed - 0

[marcos@Nomad01 ~]$ pacman -Ss remmina
community/remmina 1:1.3.6-1 [installed]
    remote desktop client written in GTK+

[marcos@Nomad01 ~]$ pacman -Ss rdp
extra/libwpd 0.10.3-1 [installed]
    Library for importing WordPerfect (tm) documents
extra/libwpg 0.3.3-1 [installed]
    Library for importing and converting Corel WordPerfect(tm) Graphics images.
extra/xorgproto 2019.2-1 [installed]
    combined X.Org X11 Protocol headers
community/freerdp 1:2.0.0_rc4-7 [installed]
    Free implementation of the Remote Desktop Protocol (RDP)
community/wordpress 5.2.4-1
    Blog tool and publishing platform
community/wpscan 1:3.7.5-1
    Black box WordPress vulnerability scanner

это действительно похоже на проблему со шлюзом. Вы отслеживали http-запросы на стороне сервера? Ответ Retries exceeded исходит от шлюза, так что, возможно, срабатывает какое-то ограничение скорости или подобное?

Это тестовые шлюзы, поэтому на них нет никакой нагрузки, и во время моих тестов я единственный, кто пытается подключиться. Соединения от клиента Windows и клиента HTML 5 выполнены успешно. Также работают подключения из xfreerdp с использованием RPC. Не работают только HTTP-запросы от xfreerdp.

Я просмотрел шлюзы в поисках журналов любого типа, которые имеют отношение к неудавшимся запросам, но нашел только один тип записи, который я указал выше. Если есть другой способ отследить активность шлюза, мне было бы интересно попробовать его.

FWIW, сообщение Retries exceeded приходит от второго вызова http_response_recv() в rdg_establish_data_connection() . На первый вызов приходит ответ 401 .

Похоже на проблемы с аутентификацией.
Есть несколько различий между MSTSC и FreeRDP, которые нужно проверить:

• FreeRDP в настоящее время не поддерживает керберос
• FreeRDP не отправляет данные домена неявно, так что, может быть, вы просто используете неправильные учетные данные? (попробуйте добавить домен)

Я спрашиваю, потому что у нас также есть несколько тестовых настроек, и случай connection close возникает только в том случае, если user , domain или password неверны.

Ноутбук с Windows, с которого я подключаюсь, находится в отдельном ненадежном домене. При использовании клиента Windows я указываю имя домена, имя пользователя и пароль.

С xfreerdp я использую / u: / p: и / d: и просто добавление / gt: rpc в командную строку приводит к успешному соединению.

Я также подозревал проблему аутентификации и безуспешно пытался найти связанную с ней проблему в конфигурации шлюза. Я не обнаружил, что RPC работает позже. Используется ли другой метод аутентификации?

Нет, он использует другой транспорт. ( http использует хакерский минимальный HTTP-запрос / ответ с аутентификацией в freerdp), тогда как rpc просто туннелирует весь rdp с аутентификацией, как при использовании прямых соединений.
так что да, мне было бы действительно интересно, что здесь не так: /

Думаю, приятно иметь интересную проблему, но я надеялся, что кто-нибудь скажет мне, что мы делаем не так.

Когда вы говорите « connection close case», вы имеете в виду именно этот второй вызов http_response_recv() возвращающий NULL? Я надеялся, что в этом случае можно будет перевернуть флаг rpcFallback, чтобы он попробовал RPC. (Я пробовал это, и в моем случае это работает.) Однако, возможно, это не очень хорошая идея, если такой случай случится с неверными учетными данными.

да, это проблема с автоматическим откатом: /
Единственное, что я могу предложить для вашего случая, — это небольшой сценарий, выполняющий этот откат, если первая попытка не удалась (или просто всегда используйте RPC ), но ничего, что мы можем исправить здесь в ближайшее время.

Не уверен, связано это или нет, но с прошлой недели я больше не могу подключаться через какой-либо RDG 2012 R2 и выше, который раньше работал нормально. Были ли в последнее время какие-либо обновления, которые могли бы изменить способ обработки подключений RDG? Я попробую добавить / gt: rpc, чтобы посмотреть, изменится ли это в моем случае.

@ CeeMac-git никаких обновлений с нашей стороны. Нет проблем с. 2016 и 2019 тоже нужно проверить 2012, но здесь тоже работал, в отличие от стартера потоков.

@akallabeth спасибо. Можете ли вы подтвердить свою версию и то, как вы ее используете, например, автономно или с помощью remmina? Я дважды проверю свою настройку. Просто кажется странным, что он перестал работать, поскольку мы не внесли никаких изменений в нашу среду RDG. Если только это не связано с окружающей средой или какое-то другое обновление моего ПК вызывает проблемы.

@ CeeMac-git xfreerdp и некоторые специальные клиенты, основанные на freerdp, не пробовали remmina в течение нескольких недель. Раньше работала безупречно, но может проверить позже.

@ CeeMac-git, мне любопытно, возникает ли у вас такая же ошибка. Кроме того, в настоящее время у нас нет шлюза 2012R2, поэтому я не могу сравнивать его с этим случаем.

@ r-barnett @ CeeMac-git только что подтвердил, наши тестовые настройки корректно работают с http. Кажется, это настройка с аутентификацией (есть ли на вашем сервере какие-либо определенные настройки / политики в отношении этого?)

Наши проблемы начались во время установки, так что почти все настройки по умолчанию. Мы просмотрели все настройки, которые могли найти, связанные с аутентификацией, и не нашли ничего, что могло бы повлиять на них. Это не означает, что здесь нет никаких проблем, поэтому, если у вас есть что-то конкретное, я займусь этим.

@ r-barnett ну, наши тестовые настройки тоже вполне «по умолчанию», но, похоже, они все еще различаются: /

Да, просто хотел бы я знать, что это было.

@akallabeth Сегодня вечером я

@akallabeth так, из / buildconfig
Это FreeRDP версии 2.0.0-dev5 (n / a)

CFLAGS: -g -O2 -fdebug-prefix-map = / build / freerdp2-ULbysn / freerdp2-2.0.0 ~ git202002281153

Так что похоже, что это версия, выпущенная пару недель назад.

Я пробовал работать с / gt: rpc, и это не помогло, так что, возможно, у меня другая проблема с @ r-barnett.

Ошибка, которую я получаю для подключения без rpc:
[22: 50: 58: 096] [3940: 3941] [ОШИБКА] [com.freerdp.core.connection] — Тайм-аут ожидания активации

и для / gt: rpc
[22: 55: 03: 455] [4072: 4073] [ИНФОРМАЦИЯ] [com.freerdp.core.gateway.tsg] — Успешное подключение к шлюзу TS
[22: 55: 14: 872] [4072: 4073] [ОШИБКА] [com.freerdp.core.connection] — Тайм-аут ожидания активации

Есть ли простой способ вернуться к версии до 2.0.0 ~ git202002281153

Вы хотите, чтобы я поднял новый вопрос по этому поводу?

@ CeeMac-git это больше похоже на проблему конфигурации на шлюзе, поскольку это сообщение Timeout waiting for activation означает, что после установления соединения от сервера нет ответа.

Доброе утро @akallabeth Я согласен с вами, за исключением того, что проблема одинакова в трех разных средах, все разные версии, которые все работали. Все это очень странно. Можно ли установить предыдущую версию freerdp для тестирования?

@ CeeMac-git, вы всегда можете собрать старую версию из git, но я вообще не знаю, как вы собираете;)

Установка @akallabeth через apt (Linux mint) все еще немного нова для всей сборки из git, но я

@akallabeth просто смотрела на это. Отдам назад!

@ CeeMac-git вы можете начать с тега 2.0.0-rc4 и использовать git bisect для двоичного поиска версии, которая перестала работать (если она работает со старой)

Спасибо @akallabeth сообщит, если я что-нибудь найду

@akallabeth Я могу подтвердить, что новая сборка из тега 2.0.0-rc4 работает во всех моих средах RDG / RDS. С git bisect, предположительно, мне придется строить из каждого коммита, прежде чем я смогу протестировать и отметить хорошее / плохое? И как лучше всего добиться того, чтобы ша коммитов выполнялась пополам?

@ CeeMac-git интересно. Да, строить нужно. Вам нужно только 2 начальных ревизии, остальные делятся пополам (он напечатает вам ша первой неисправной после завершения)

Мы с @akallabeth получаем начальные изменения от …..: D Раньше я действительно делал это только с gerrit, поэтому я немного не уверен в некоторых командах git. Возможно, мне понадобится время, чтобы получить некоторые результаты, так как у меня не так много свободного времени в ближайшие несколько дней, но я вернусь с чем-нибудь.

@ CeeMac-git проверит, смогу ли я достать w2k12. Не может быть много, но, похоже, он чем-то отличается от 2k16 и 2k19, которые у меня есть для тестирования

@akallabeth: да, в период с 2012 по 2016 год Microsoft внесла много изменений в RDS, включая добавление новых процедур RPC. 2016/2019 очень похожи. К вашему сведению, я тестирую среду 2012R2 с 2FA и среду 2016 года без 2FA. Оба работают на rc4 и не работают на dev5. Я могу попробовать против 2019 года, если найду тот, который не настроен для опубликованных приложений.

@ CeeMac-git, что интересно. Вы можете где-нибудь выложить конфигурацию на 2016 год?
Настройка на воспроизведение — это 70% работы;)

@akallabeth , дайте мне знать, какая именно информация вам нужна, я постараюсь выкопать ее в понедельник.

@akallabeth Я думаю, что подходящие параметры конфигурации указаны ниже, дайте мне знать, если вам нужно / нужно что-то еще. Это из RDG, созданного в 2016 году:

Настроить развертывание

• Шлюз удаленных рабочих столов
  Метод входа в систему: аутентификация по паролю
  Использовать учетные данные шлюза удаленных рабочих столов для удаленных компьютеров — отмечено галочкой
  Обход сервера шлюза удаленных рабочих столов для локальных адресов — не отмечен

Свойства коллекции

• Безопасность
  Уровень безопасности: переговоры
  Уровень шифрования: Совместимость с клиентом
  Разрешить подключения только с компьютеров, на которых запущен удаленный рабочий стол с проверкой подлинности на уровне сети — установлен флажок

@ CeeMac-git не может воспроизвести, вот эти настройки: /
у вас есть учетная запись test которой я могу подключиться? Хотелось бы отладить поток данных и проверить, что происходит.

@akallabeth — нельзя делать с тестовой учетной записью, к сожалению, это нарушит корпоративную политику.

Дайте мне посмотреть, что я могу найти с помощью git-bisect. Это может быть связано даже с тем, как freerdp был встроен в Reminna PPA. Я мог бы сразу перейти к чистой сборке от мастера и на самом деле сначала ее протестировать.

Есть ли какие-нибудь другие настройки, которые могут быть уместны?

@akallabeth с какими параметрами вы строите? (при условии, конечно, cmake)

dpkg-buildpackage , он же ночная сборка

подробности в packaging/deb/freerdp-nightly/rules

это использует определенный набор параметров сборки для различных настроек WITH_ *?

нет никаких реальных параметров, которые влияют, кроме WITH_KRB5 или WITH_GSSAPI с включенной поддержкой Kerberos (все еще экспериментальной / неработающей, поэтому отключите)

OK. попробует использовать ночное время в качестве слепого контроля, чтобы увидеть, сохраняется ли проблема.

@ CeeMac-git, возможно, вы захотите объединить https://github.com/FreeRDP/FreeRDP/pull/5757 для теста, он исправляет несколько проблем и улучшает ведение журнала.
(Все еще не готово к производству, но может помочь в диагностике проблемы)

@akallabeth есть ли для этого вишенка или тег, который я могу получить?

Ненавижу быть «я тоже». У меня также возникла проблема с ERRCONNECT_SECURITY_NEGO_CONNECT_FAILED. К сожалению, / gt: rpc даже не помогает.

@akallabeth только что скомпилирован из мастера, выполнив тот же процесс, что и для тега rc4, и я вернулся с «тайм-аутом, ожидающим активации»

Протестировано против 2016 RDG / RDS

Это FreeRDP версии 2.0.0-dev5 (3b673be37)

Я попробую настроить git bisect в ближайшие несколько дней, если у меня будет время.

@akallabeth результаты git bisect находятся в:

`a48e7f8b473f2d97e0eb5b6a1011507888c5e837 — первая неудачная фиксация
совершить a48e7f8b473f2d97e0eb5b6a1011507888c5e837
Автор: Норберт Федера [email protected]
Дата: Чт, 20 февраля, 17:26:27 2020 +0100

core: fix endless loops waiting for activation

There are two loops polling the transport pdu receiver in non-blocking mode
when waiting for reaching CONNECTION_STATE_ACTIVE rdp state.

In case of an invalid pdu size in the tpkt header this leaded to an endless
loop, utilizing 100% of a cpu core.

Added a sleep and limited the max loop time to the tcp ack timout value.

: 040000 040000 8257297ff16159cdbe6948ab1981e6e2f545b0a8 8f90568164f0a0e8409bbfe7e028f01aa09351a5 M libfreerdp
`
Вероятно, стоит отметить, что я использую спутниковую широкополосную связь дома, где у меня возникла эта проблема со средним RTT 600-700 мс. Для активации сеанса удаленного рабочего стола может потребоваться несколько секунд, поэтому мне интересно, не устаревают ли внесенные изменения при попытке подключения слишком агрессивно?

Дайте мне знать, если вам нужно, чтобы я попробовал что-нибудь еще или нужна дополнительная информация.

@akallabeth Итак, я немного поработал, и если я установлю settings->TcpAckTimeout = 15000 в ./libfreerdp/core/settings.c с проверкой фиксации a48e7f8b4, это, похоже, решит проблему. Мне удалось снизить его до 12000, но это оказалось непоследовательным, в то время как до сих пор 15000, похоже, неоднократно работали в ограниченных тестах, которые я запускал (в основном, 3 подряд).

@akallabeth Я могу подтвердить, что изменение этого параметра в мастере также, похоже,

@ CeeMac-git хорошо, да, ссылки с высокой задержкой всегда являются проблемой: / Теперь вернемся к проблемам, с которыми сталкиваются другие в этой ветке.

@ r-barnett Я немного разобрался с этим, ошибка, которую вы получаете ( Request_Cancelled ), отправляется с сервера, поэтому это подтверждает мою теорию о том, что некоторая политика на сервере не выполняется.
Я предполагаю, что какая-то политика в отношении вашего HTTP-сервера в отношении ddos ​​или подобного слишком жесткая, поскольку FreeRDP выполняет на 1 или 2 запроса больше, чем mstsc .

спасибо @akallabeth и извините @ r-barnett за кражу нити, надеюсь, вы решите свою проблему.

@akallabeth , вы нашли компонент Windows, который генерирует сообщение «Request_Cancelled»?

FWIW, мы создали еще одну ферму RDS 2016 в другой тестовой лаборатории и столкнулись с той же проблемой.

@ r-barnett Поскольку я все еще не могу воспроизвести вашу проблему, нет.

freerdp-2.0.0_rc4

Old Certificate details:
    Subject:     CN = #######
    Issuer:      CN = #######
    Thumbprint:  f6:fc:26:ca:0f:49:9a:ac:44:1c:4e:9a:10:14:c4:00:09:26:67:9c

До обновления и после понижения все работает нормально:

[20:34:08:507] [20312:20313] [ERROR][com.winpr.timezone] - Unable to get current timezone rule
[20:34:24:815] [20312:20313] [INFO][com.freerdp.gdi] - Local framebuffer format  PIXEL_FORMAT_BGRX32
[20:34:24:815] [20312:20313] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_RGB16
[20:34:24:823] [20312:20313] [INFO][com.winpr.clipboard] - initialized POSIX local file subsystem

freerdp-2.1.1

New Certificate details:
    Common Name: #######
    Subject:     CN = #######
    Issuer:      CN = #######
    Thumbprint:  b0:ae:d0:b3:d9:3d:00:7f:9c:d0:04:7a:02:36:ad:c7:23:fc:65:9d:22:52:0d:9b:a1:cd:03:07:42:ab:e0:f4

После обновления:

[20:24:00:001] [16310:16311] [INFO][com.freerdp.core] - freerdp_connect:freerdp_set_last_error_ex resetting error state
[20:24:00:001] [16310:16311] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpdr
[20:24:00:001] [16310:16311] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpsnd
[20:24:00:001] [16310:16311] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[20:24:00:310] [16310:16311] [INFO][com.freerdp.primitives] - primitives autodetect, using optimized
[20:24:00:312] [16310:16311] [INFO][com.freerdp.core] - freerdp_tcp_is_hostname_resolvable:freerdp_set_last_error_ex resetting error state
[20:24:00:312] [16310:16311] [INFO][com.freerdp.core] - freerdp_tcp_connect:freerdp_set_last_error_ex resetting error state
[20:24:00:488] [16310:16311] [WARN][com.freerdp.crypto] - Certificate verification failure 'unable to get local issuer certificate (20)' at stack position 0
[20:24:00:488] [16310:16311] [WARN][com.freerdp.crypto] - CN = #######
[20:24:01:190] [16310:16311] [ERROR][com.winpr.timezone] - Unable to get current timezone rule
[20:24:09:506] [16310:16311] [ERROR][com.freerdp.core.connection] - Timeout waiting for activation

PS Обработал откат с 2.1.1 на 2.0.0_rc4 (Gentoo X64 4.19.97), 2.0.0-r1 тоже НЕ работал.
Сервер PPS: Windows 7 x64 SP1

@ In-Flight, значит, после перехода на более раннюю версию тоже больше не работало? Извините, ваше последнее предложение немного сбивает с толку.

@ In-Flight извините, нет, это изменение, связанное с локальным хранилищем (никаких изменений для подключения)

@ In-Flight, если у вас есть время и вы можете скомпилировать FreeRDP самостоятельно, вы можете сделать git bisect и узнать, с какой фиксацией он перестал работать для вас.

@ In-Flight, Timeout waiting for activation я видел, с некоторым исчерпанием ресурсов на стороне сервера (слишком много одновременных сеансов вошли в систему)

Не уверен, что основная причина та же, но у меня возникли аналогичные проблемы — Timeout waiting for activation — попытка подключиться к NLA с использованием 2 туннелей ssh ​​(удаленный туннель с сервера RDP Windows + локальный туннель от клиента RDP Linux), но без шлюза RDP . С помощью отпечатков отладки com.freerdp.core.nla я мог видеть, что тайм-аут произошел сразу после передачи токена аутентификации:

[17:03:15:954] [22:23] [DEBUG][com.freerdp.core.nla] - Sending Authentication Token
[17:03:15:954] [22:23] [DEBUG][com.freerdp.core.nla] - 0000 4e 54 4c 4d 53 53 50 00 01 00 00 00 b7 82 08 e2 NTLMSSP.........
[17:03:15:955] [22:23] [DEBUG][com.freerdp.core.nla] - 0016 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[17:03:15:955] [22:23] [DEBUG][com.freerdp.core.nla] - 0032 06 01 b1 1d 00 00 00 0f                         ........
[17:03:15:955] [22:23] [DEBUG][com.freerdp.core.nla] - [length=40]

а затем тайм-аут. Я увеличил TcpAckTimeout 1000 раз, и теперь это работает.

diff --git a/libfreerdp/core/settings.c b/libfreerdp/core/settings.c
index 25d2390c0..5e0916e27 100644
--- a/libfreerdp/core/settings.c
+++ b/libfreerdp/core/settings.c
@@ -566,7 +566,7 @@ rdpSettings* freerdp_settings_new(DWORD flags)
        settings->TcpKeepAliveRetries = 3;
        settings->TcpKeepAliveDelay = 5;
        settings->TcpKeepAliveInterval = 2;
-       settings->TcpAckTimeout = 9000;
+       settings->TcpAckTimeout = 9000000;

        if (!settings->ServerMode)
        {

Хотя это не похоже на «решение».

@pptaszni FreeRDP уже позволяет настраивать таймаут без перекомпиляции;)

/timeout:<time in ms>             Advanced setting for high latency links:
                                      Adjust connection timeout, use if you
                                      encounter timeout failures with your