lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] packet filtering support


From: Kieran Mansley
Subject: Re: [lwip-users] packet filtering support
Date: Fri, 17 Jul 2009 08:50:41 +0100

On Fri, 2009-07-17 at 10:51 +0530, Mandeep Sandhu wrote:
> But IP fwding between 2 interfaces is possible w/o any modifications
> to the stack...right?

Yes, I think so - see the IP_FORWARD option and associated code.

> For intercepting DNS request, I plan to do the following:
> 
> * Implement a very limited DHCP server (one which offers addr
>   to only 1 DHCP client. This would return the DNS server's IP as
>   my own.
> * Now if the client tries to resolve a domain name, that request will
>   come to my IP.
> * If I have raw socket support, I can inspect the packet and if it's for
>   the domain I want to resolve, I can fwd it to an external resolver using
>   the DNS client functions.
> 
> Does this sound feasible?

Sort of.  lwIP does already have DHCP and DNS support, but just not with
the limitations that you want (e.g. to only serve one DHCP client).  I'm
also not sure about forwarding DNS requests and whether that is the best
strategy.  I suppose you could try it and see if it works.

> Is there any doc available exapling the raw socket API in lwIP? Currently
> I'm looking at;
> http://lwip.wikia.com/wiki/Raw/native_API

I think you might be confusing lwIP's "raw API" with a "raw socket API".
The two are very different: lwIP's raw API is just an efficient way of
sending and receiving data over TCP and UDP connections; the raw socket
API allows you to send and receive ethernet frames with direct access to
the packet headers.  The lwIP raw API does not give you access to the
packet headers, which I think you'd need.  There is I think some limited
support in lwIP for raw sockets, but I'm not sure how well used it is.  

> As for the IP filtering, I think I'll have to alter the stack! :(
> 
> Do you think it makes sense to provide API's to configure such filters?

If you know that the filters will always need to be the same, then you
can just configure them statically.  If you application will need to
change them at any time then you'll need an API for it to do so.  Which
one of these makes most sense depends on your application.

Kieran





reply via email to

[Prev in Thread] Current Thread [Next in Thread]