我们最近安装了一个GPS基站，它是一个高精度GPS接收器，用于现场GPS设备的纠错。该设备（Trimble NetR9）使用嵌入式Linux操作系统，并将数据文件FTP到另一台FTP服务器（在我的例子中，是带有IIS的Windows 2012 Server）。设备可以在FTP服务器上创建目录，但无法将文件推送过来。
我想知道我的FTP服务器（Win 2012）上是否有一些设置让我对Linux客户端友好？
测试尝试：
权限 ：为了消除设置错误权限的可能性，我向用户提供了对ftproot文件夹和所有子文件夹的完全读/写权限，我也尝试以管理员用户身份登录。此用户的IIS设置也显示“读取”和“写入”。上述两个结果仍然存在。我还测试了使用相同的用户从工作站到FTP服务器执行相同的FTP过程，并且没有放下文件的问题。
网线： 为了消除以某种方式涉及网络布线的（非常远程）可能性，我们使用Fluke网络测试工具测试了从交换机到NetR9的所有布线，没有发现任何缺陷。
防火墙，路由器，NAT等： 为了消除某些防火墙规则或路由器配置的可能性，我将Windows Surface平板电脑配置为与NetR9完全相同的TCP / IP设置，从其数据插孔中拔出NetR9，并将Surface插入相同的插孔。因此，Surface从TCP / IP角度模拟了NetR9。从Surface，使用FTP，将文件放在具有相同凭据的同一FTP服务器上没有问题。
无源/有源 ：为了消除其中一种FTP方法比另一种更好的可能性，我在设备上尝试了所有3种FTP方法，结果没有区别。
Windows防火墙： 我们检查并发现在我们开始执行此操作之前，Windows防火墙确实已在此服务器上关闭。我们离开了。
Windows Server： 为了消除我的Windows 2012 Server上的IIS配置可能出现问题的可能性，我们在带有IIS的旧版Windows 2008 Server上复制了FTP服务器设置，并且具有相同的结果。
日志文件摘录 这是从设备到Widnows服务器的每次FTP推送后在日志文件中找到的内容。您可以看到它正在创建文件夹，但最后一部分（推送文件laco209x.T02）不起作用。
2016-07-28 00:00:02 - - - 21 ControlChannelOpened - - 0 0 0 0 0 - -
2016-07-28 00:00:02 - FTPSVC2 - 21 USER 331 0 0 23 14 0 - -
2016-07-28 00:00:02 \ FTPSVC2 - 21 PASS *** 230 0 0 21 18 0 / -
2016-07-28 00:00:02 \ FTPSVC2 - 21 CWD t02 / 250 0 0 29 10 0 / t02 -
2016-07-28 00:00:02 \ FTPSVC2 - 21 CWD 2016/250 0 0 29 11 16 / t02 / 2016 -
2016-07-28 00:00:02 \ FTPSVC2 - 21 CWD 209/250 0 0 29 10 0 / t02 / 2016/209 -
2016-07-28 00:00:02 \ FTPSVC2 - 21 CWD LACO / 250 0 0 29 11 0 / t02 / 2016/209 / LACO -
2016-07-28 00:00:02 \ FTPSVC2 - 21 TYPE I 200 0 0 20 8 0 - -
2016-07-28 00:00:02 \ FTPSVC2 - 21 PORT 10,40,55,108,234,136 200 0 0 30 27 0 - -
2016-07-28 00:00:03 \ FTPSVC2 - 21 STOR laco209x.T02 550 4294967295 0 48 19 1031 /t02 / 2016/2009 / LACO / lac209x.T02 -
2016-07-28 00:00:04 \ FTPSVC2 - 21 TYPE I 200 0 0 20 8 0 - -
2016-07-28 00:00:04 \ FTPSVC2 - 21退出 - 221 0 0 14 6 0 - -
2016-07-28 00:00:04 \ FTPSVC2 - 21 ControlChannelClosed - - 0 0 319 142 2218 - -
我也在跟供应商讨论这个问题，但是想在这里问一下有没有人看过linux FTP客户端和windows FTP服务器之间的类似行为。