[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