Sockets 套接字编程-调用accept（）时发生了什么

我有一个基于飞思卡尔MPC5200B的系统，运行VxWorks，它有一个奇怪的问题

该系统有一组自检，可以向世界打开一个套接字服务器。有一些PC软件可以在服务器上打开一个用于通信的插座，然后PC上的用户可以在卡上运行电池测试

系统还具有固件上载程序。它以相反的方式工作——PC软件打开一个套接字服务器。嵌入式客户端与之连接后，PC机向其发送新的应用软件，该应用软件被嵌入式软件烧掉

现在的问题是：在99%的卡片上，这种方法很有效。在一些卡上，上传器可以工作，但是自检软件失败了——固件调用accept（），永远不会返回，也不会看到PC试图打开插槽。这是一致的——不起作用的牌，不起作用的牌，其他的都起作用

你可能会说这不完全是软件问题，我也同意，但我制作软件的公司在问我：什么设备出了故障，他们需要更换？如果上传程序正在工作，则以太网驱动程序和处理器正在工作

那么，现在解释通过了，下面是问题：在调用套接字“accept（）”时，与“connect（）”相反的方向有什么不同之处？如果accept（阻塞）永远不会返回，那么发生了什么可能会指向“坏”卡集上的问题

---

谢谢

你的意思是，即使在重新灰化之后，那些不起作用的卡仍然不起作用，而那些仍然起作用的卡？顺便说一句：在大多数情况下，海森堡似乎是（失败的）初始化相关。坚持让事情变得奇怪。这可能与MAC地址/rev DNS有任何关系吗？您需要嗅探来自嵌入式设备的数据包，以发现它在尝试升级时是否发出任何数据包。由于

accept（）

从未接收到连接，人们可能会认为它不正确。我认为这与地址无关。这里使用的唯一地址是固定IP地址（所有卡上都相同，作为固件的一部分烧录）。Celada-这不是在尝试升级期间。Accept（）位于嵌入式端，它看不到PC（）的连接。我认为嵌入式卡此时不应发出任何数据包。