Zitat von "Kieran Mansley" <[email protected]>:
On Sun, 2009-08-16 at 12:21 +0200, Christian Walter wrote:
My question is now how I can find the size of the headers depending on
the interface type. Otherwise I would always need to allocate the
maximum size.
Would using PBUF_LINK as the layer type and size of zero as arguments to
pbuf_alloc() do what you need? Probably not, as it just uses a constant
to determine the link header size. This would be the right place to make
it dynamic though if you wanted to improve things. That might requiring
passing a netif to pbuf_alloc though, which would be a bit of pain to
change. Perhaps we could add a "pbuf_alloc_for_netif()" function which
would wrap pbuf_alloc(), and leave the current behaviour when
pbuf_alloc() is called directly.
Thanks - I will think about this.
Still we would miss the following for a fullimplementation
- We would need some defragmentation code to handle fragmented UDP and
TCP pakets correctly. This is the most difficult one but is not need by
my customer right now. Still I would like to have the opportunity to add
this later. Are there some design issues I should take care of right now?
Couldn't we just forward the fragments?
The problem with this is that I can not track the state anymore since
I need the TCP and UDP headers for this. When I receive back an packet
I am currently checking if the tcp port belongs to a connection with
NAT. I only have the TCP header in the first paket of the fragment.
- We would need a more user friendly configuration interface for the NAT.
- We should have the possiblity to add application specific hooks -
For example for FTP forwarding or something like this.
Happy to leave those two to the port or application to sort out.
Okay. Thanks for your valuable feedback,
Christian
--
+--------------------------------------+-----------------------------------+
Embedded Solutions | DI Christian Walter
Lorenz B?hler Gasse 4/4, A-1200 Wien | [email protected]
http://www.embedded-solutions.at | +43-676-7278851
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
