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

Eric W. Biederman ebiederm at xmission.com
Tue Oct 18 11:57:29 PDT 2011


"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.

Eric



More information about the Syslinux mailing list