Changes between Version 1 and Version 4 of Ticket #12723


Ignore:
Timestamp:
Jun 1, 2022, 4:57:35 PM (2 years ago)
Author:
QIU Quan
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #12723

    • Property Resolution → rejected
    • Property Status new → closed

  • Ticket #12723 – Description

    v1 v4  
    22
    33{{{
    4 +------------+   +----------------|------+   +--------------+
    5 |  my client |   |      NAT router       |   | their server |
    6 | 172.21.x.x +---+ 192.168.200.32 | 10.x +---+ 10.10.x.x    |
    7 +------------+   +----------------|------+   +--------------+
     4+-----------+   +-------------|------+   +--------------+
     5| my client |   |    NAT router      |   | their server |
     6| 172.x.x.x +---+ 192.168.x.x | 10.x +---+   10.x.x.x   |
     7+-----------+   +-------------|------+   +--------------+
    88}}}
    99
    … …  
    1616> Destination IP of data connection does not match peer IP of control connection. Not binding source address of data connection.
    1717
    18 Having searched this message in the source code, I arrived at a function `CTransferSocket` :: `SetupPassiveTransfer`, and found that its `host` argument seems to be assigned in the function `CFtpRawTransferOpData` :: `ParsePasvResponse`.
     18Having searched this message in the source code, I arrived at function `CTransferSocket` :: `SetupPassiveTransfer`, and found that its `host` argument seemed to be assigned in the function `CFtpRawTransferOpData` :: `ParsePasvResponse`.
    1919
    20 Inside `ParsePasvResponse`, the condition to assign the `peerIP` from the control socket to the `host_` of the passive data connection is an ''un-routable data peer address'' as well as a ''routable control peer address''. Unfortunately, with all un-routable, internal addresses for both data and control, my scenario effectively bypasses this mechanism.
     20Inside `ParsePasvResponse`, the condition for assigning the `peerIP` from the control socket to the `host_` of the passive data connection is an ''un-routable data peer address'' as well as a ''routable control peer address''. Unfortunately, with all un-routable, internal addresses for both data and control, my scenario effectively bypasses this mechanism.
    2121
    22 At the end of the `ParsePasvResponse` function, I noticed that I can instruct the client to ''always use server address'' by setting the option `OPTION_PASVREPLYFALLBACKMODE` to `2`, which is set by an option named `Pasv reply fallback mode`, stored in `%appdata%\FileZilla\filezilla.xml`. I wonder the intention to omit this option in the settings UI, but it indeed provides a workaround for my situation in the current version.
     22At the end of the `ParsePasvResponse` function, I noticed that I can instruct the client to ''always use server address'' by setting the option `OPTION_PASVREPLYFALLBACKMODE` to `2`, which is set by an option named `Pasv reply fallback mode`, stored in `%appdata%\FileZilla\filezilla.xml`. I wonder the intention on omitting this option in the settings UI, although it indeed provides a workaround for my situation in the current version.