以太网调试记录（DoIP 车载以太网，诊断）

以太网调试记录（DoIP 车载以太网，诊断）

①问题：电脑通过以太网与下位机直接相连，则可以正常通信，中间串联一个网关转发报文，则无法正常通信。

②具体原因：

• 如果直接相连，在下位机复位后，网卡也复位，电脑与下位机的连接自动断开，因为物理层link down（相当于插拔一下网线），导致上层TCP链接也直接断开，不用四次挥手，即可断开。
  
• 但是如果中间连接网关，在下位机断开之后，ETH2网卡link down，而ETH1网卡还处于Link up的状态，所以电脑认为下位机还处于连接状态，再次通信之前会与下位机断开链接，即四次挥手，但是此时下位机却不理会，因为下位机的网卡已经复位，导致双方链接处于失效状态，多次断开没有成功之后，下位机会自动发送复位链接报文，此后重新开始，可以正常连接。

③通过网络监控报文来仔细思考其中的过程。

  1、电脑ETH1的网络与ETH2的网络通信通过网关自带的上位机进行监控（CANOE界面，下图，），可以抓通信报文，分析数据，比如DoIP。

  2、上位机发送指令：15:45:37秒 10 02（ETH1 RX） 10 02（ETH2 TX）（下位机从APP跳到BT）

  ETH1 ：电脑-》网关 （RX） ETH2：网关-》下位机 （TX） TX与RX针对网关来说

  3、ETH2复位：15:45.37 15:45:40 大概3秒

  4、15:45:42 电脑向下位机挥手，即断开TCP链接，FIN，但是此时下位机没有回应，因为已经复位，从ETH2看出，因为下位机复位，所以连接的ETH2连接断开，即物理层的断开，TCP的连接自然断开。

   5、之后上位机尝试断开链接失败后（两次尝试），下位机发送复位TCP连接（RST），因为下位机并不知道这是哪来的包，不断的发送，就很麻烦，所以就发送个RST强制关闭链接了，不然下位机会一直发送。

  6、之后下位机从BT跳到APP，网卡复位，所以又重新Link up与Link Down

  7、在BT中大概5S中无诊断数据交互，则就跳到APP中，时间在37s-43s之间，包含跳转的时间，而在跳转之后的这段时间里，上位机一致忙着断开链接，想着怎么就这么难断开，好不容易断开了，下位机也跳回APP里了，白忙活了。

  8、之后可以正常进行TCP链接，三次握手。

  9、之后进行路由激活（0x0005 Routing activation request），