[syslinux] [PATCH][GIT-PULL] lwIP undiif: Fixes for VMware platforms and general fixes

[Gene Cumm]

On Tue, Oct 18, 2011 at 14:57, Eric W. Biederman <ebiederm at xmission.com> wrote:
> "H. Peter Anvin" <hpa at zytor.com> writes:
>
>> On 10/14/2011 06:23 PM, Gene Cumm wrote:
>>>>
>>>> Hi Gene,
>>>>
>>>> I have merged this... I'm still not convinced it is the right solution -- in
>>>> particular I'm not convinced we should *ever* call ethernet_input() -- but
>>>> it's a lot better than the previous (known broken) code.
>>>>
>>>> Thanks!
>>>
>>> Thanks also to Simon Goldschmidt who saw the issue and suggested the
>>> direction of the fix.
>>>
>>> It seems the more important question is what could go wrong.  What if
>>> it's non-Ethernet and calls ethernet_input() or is Ethernet and
>>> doesn't call ethernet_input() but just ip_input() instead?
>>>
>>
>> The difference, as far as I can tell, is that ethernet_input() expects a
>> 14-byte Ethernet header, and will handle ARP.  Since the UNDI code
>> should be doing ARP on its own (it has to, we might not be using
>> Ethernet; consider Infiniband for example) then we should be able to
>> just pass the IP packets to ip_input().
>
> As I recall the practical difference how we are talking to the undi
> stack.  In one mode the UNDI stack can give us a raw ethernet header and
> let us process that according to the ethertype in the packet.  In
> another mode the undi stack will give us a packet without the link layer
> header that undi has already classified into as an ip, arp or a rarp
> packet.  We then have to process that.  Which means undi absolutely
> requires a network that uses arp to support ip (which includes IB),
> and that even in undi mode we have to process arp packets.
>
> If someone can give me a pointer I will be happy to give this change
> a bit of review.  Somehow I lost the thread of this conversation.

tcpip_input() drops a packet into tcpip_thread()'s mbox which then
calls ethernet_input() or ip_input() as "appropriate" which allows the
sending thread to finish creating the socket before the response
packet is processed in tcp_input().

I think we either need to always not set NETIF_FLAG_ETHARP in
undiif.flags (and handle ARP inside undiif.c) OR logic in
tcpip_thread() needs to change such that we can choose where it goes
by msg.type (probably with 2 new types to force either
ethernet_input() or ip_input) or by a new field in the struct
tcpip_msg.

-- 
-Gene