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. > - The normal forwarding code can not handle PPP/Ethernet pakets due to > the header problem I have mentioned. Would a patch similar than the code > above be useful? Yes. > 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? > - 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. Thanks for your work on this. Kieran _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
