Re: [lwip-users] Getting Raw ARP Packets

[David M. Zar]

Jan,

thanks for your thoughts. I think you are on to something in how you see 
things. To add color to the conversation, I will need to do IP4 
reassembly (we will get fragmented packets due to how we use IP4 in our 
environment) so we can do operations on the "packets" before passing 
them out of our box. But we do not need TCP/UDP operations, for sure 
(except examining headers which is easy). We will also be modifying 
packets but will do that at the raw frame level, really.

But, your point is well taken and I'll look at this. We do need as high 
performance (of course!) as possible so avoiding things is generally a 
good idea.

(As a side note, we have a software version of our proposed system 
running on a PC... it opens a BSD RAW_SOCKET and does everything at that 
level. Essentially, that's what I'm trying to emulate, here, but being 
as efficient as possible in an embedded environment. I do have an 
Ethernet driver working very well, it seems, so maybe I'm 90% there.)

Thanks,
Dave


On 5/22/2018 4:16 AM, Jan Menzel wrote:
> Hi Dave!
>         What you described looks like a bridge to me. If you don't have to
> process tcp/udp packets (send an receive data from your local device)
> you don't need lwip. You could just build an Ethernet driver (which you
> would have to do for lwip anyhow as its hardware related and not part of
> lwip) and forward all packets to your host. If you do need to send data
> and hence wont to make use of lwips features, I'd suggest to put the
> bridge related features into the Ethernet driver and keep lwip
> untouched. In that case you'll have to rethink your "My device will not
> have an IP address" clause.
>
>         Jan
>
> On 21.05.2018 18:26, David M. Zar wrote:
> > I'm somewhat new to using LWIP (version 2.0.3) and am making great
> > progress with my application which will include processing raw IP
> > packets. One problem is that we also need to accept and pass on ARP
> > packets. I don't see an easy way to do this without modifying code in
> > etharp.c. Would this be the accepted method?
> >
> > Some details... I am creating an application where my device will be a
> > "bump-on-the-wire." My device will not have an IP address and will
> > accept UDP/TCP packets (in raw mode) from the network and pass them on
> > to a host connected at the other side. Likewise, I will accept UDP/TCP
> > from the host and pass them on to the network side. I can do that. But I
> > also need to handle ARP. When an ARP packet shows up from the network
> > side, I need to pass it on to the host who will then respond. That
> > response will then need to go back to the network.
> >
> > Optionally, I could simply know the appropriate ARP response to send for
> > my host and send it as soon as I see an ARP packet with my host's IP
> > address, but that's a minor difference. I still need to accept ARP
> > packets and process them, myself, and not expect the LWIP stack to do so.
> >
> > Thanks for any insights/suggestions you may have.
> >
> > Dave
> >
> >
> > _______________________________________________
> > lwip-users mailing list
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/lwip-users
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users