Scott Gilbertson wrote:
I've done some crude patches to make UDP and the ping server

Indeed a bit crude... ;)

automatically solicit missing host addresses, similar to the rtnetproxy
change I did earlier. The changes aren't perfect, in that the first
transmission fails to go out, because it doesn't wait for the ARP
transaction to complete. The second send generally works, though, which
I can live with in my application. Ideally, the task attempting to write
to the particular host would be blocked while the ARP completes, with a
timeout and perhaps some re-tries on the operation, but that would be a
lot harder to code.

My changes only do anything when trying to send a frame to a host for
which no route is available, so they have zero performance impact in the
fully pre-routed real time case. I therefore think they'd be harmless
for all RTNET users, and helpful (although admittedly not ideal) for
those who, like me, need to avoid hard-coded routes.

For ping, I modified icmp, changing rt_icmp_send_reply thus:
        /* SCOTT'S PATCH:
        was:
         if (rt_ip_route_output(&rt, daddr) != 0)
           return;
        */
        if (rt_ip_route_output(&rt, daddr) != 0)
        {
           rt_arp_solicit (skb->rtdev, daddr);
              return;
        }
        /* END OF SCOTT'S PATCH */

There is a better way for this case: take the information about the ICMP reply destination from the request packet. This was the way RTnet worked before we revised the routing system. As such a check for unknown routes for every incoming packet is redundant in a hard real-time environment (RTcfg or the user will care for it), we dropped it.

Now if you ping the unit, it might miss the first one, but will
respond to the second, after resolving the client's ip address..

I patched udp.c to do a similar thing when sending UDP frames. In the
rt_udp_sendmsg function, I inserted this code:

    /* SCOTT'S PATCH:
    was:
    if (rt_ip_route_output(&rt, daddr) != 0)
        return;
    */
    if (rt_ip_route_output(&rt, daddr) != 0)
    {
        rt_arp_solicit (skb->rtdev, daddr);
        return;
    }
    /* END OF SCOTT'S PATCH */


Another option: let your application trigger the arp solicitation at startup and wait let it wait for a reply.

With this change, the first attempt to contact the device via UDP may
fail, but the second one will succeed, provided enough time has been
left for the ARP transaction to complete.


As both patches touch the core in a critical way and even do not provide a clean solution, please understand that they will not become an official add-on. But, of course, you are always free to use a customised version of RTnet for your application.

Jan

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to