IP fragmentation

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

IP fragmentation

Thomas Taranowski
I'm looking at the code to do the IP reassembly, and notice that it appears that it is only able to handle a single fragmented payload at a time.  Is this really true, or am I seeing things again?  If so, the implementation is somewhat problematic in that if one of the fragments of an IP datagram is lost, then the ip_reass_tmr has to expire before the stack can handle a fragment belonging to a new IP datagram.  By default, this timer is set to expire every seconds.



_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

RE: IP fragmentation

Goldschmidt Simon
>I'm looking at the code to do the IP reassembly, and notice that it
appears
>that it is only able to handle a single fragmented payload at a time.
Is
>this really true, or am I seeing things again?  If so, the
implementation
>is somewhat problematic in that if one of the fragments of an IP
datagram is
>lost, then the ip_reass_tmr has to expire before the stack can handle a
>fragment belonging to a new IP datagram.  By default, this timer is set
to
>expire every seconds.

As far as I can see, you're right. What also disturbs me is that,
because
there is only one reassembly-buffer, you can only receive fragmented
IP-packets
from one host at a time. That's because I didn't enable IP_REASSEMBLY...
Or am I wrong and this would never happen??

Simon
       
       
       



_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

Re: IP fragmentation

Jonathan Larmour
Goldschmidt Simon wrote:

>>I'm looking at the code to do the IP reassembly, and notice that it
>
> appears
>
>>that it is only able to handle a single fragmented payload at a time.
>
> Is
>
>>this really true, or am I seeing things again?  If so, the
>
> implementation
>
>>is somewhat problematic in that if one of the fragments of an IP
>
> datagram is
>
>>lost, then the ip_reass_tmr has to expire before the stack can handle a
>>fragment belonging to a new IP datagram.  By default, this timer is set
>
> to
>
>>expire every seconds.
>
>
> As far as I can see, you're right. What also disturbs me is that,
> because
> there is only one reassembly-buffer, you can only receive fragmented
> IP-packets
> from one host at a time. That's because I didn't enable IP_REASSEMBLY...
> Or am I wrong and this would never happen??

This is correct and intentional - more frags to reassemble means more
memory, it's as simple as that. You should try and avoid getting
fragmented packets in the first place!

Of course if lwIP could implement path MTU discovery, it could keep up its
side of the bargain.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

RE: IP fragmentation

Goldschmidt Simon
> > What also disturbs me is that,
> > because there is only one reassembly-buffer, you can only receive
> > fragmented IP-packets from one host at a time. That's because I
didn't
> > enable IP_REASSEMBLY...
> > Or am I wrong and this would never happen??
>
> This is correct and intentional - more frags to reassemble
> means more memory, it's as simple as that.

If fragmented packets would be temporarily stored in their corresponding
pbuf instead of copying them into reassbuf, you would waste less memory
since you don't have to provide the maximum memory all the time using
only pbuf memory if you really have something to reassemble. And the
amount of pbufs being in the reassembly buffer could easily be
configured.
(see task #6861 for my ideas about that)

> You should try and
> avoid getting fragmented packets in the first place!
> Of course if lwIP could implement path MTU discovery, it
> could keep up its side of the bargain.

Agree, but isn't reassembly the wrong side for that?


Simon


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

Re: IP fragmentation

Jonathan Larmour
Goldschmidt Simon wrote:

>>> What also disturbs me is that,
>>> because there is only one reassembly-buffer, you can only receive
>>> fragmented IP-packets from one host at a time. That's because I
> didn't
>>> enable IP_REASSEMBLY...
>>> Or am I wrong and this would never happen??
>> This is correct and intentional - more frags to reassemble
>> means more memory, it's as simple as that.
>
> If fragmented packets would be temporarily stored in their corresponding
> pbuf instead of copying them into reassbuf, you would waste less memory
> since you don't have to provide the maximum memory all the time using
> only pbuf memory if you really have something to reassemble. And the
> amount of pbufs being in the reassembly buffer could easily be
> configured.
> (see task #6861 for my ideas about that)

The main problem I see, as mentioned in that task, is you have to use up a
whole PBUF_POOL_BUFSIZE (or even multiple) worth of bytes from the pbuf pool.

Suppose PBUF_POOL_BUFSIZE is 256, and there is an MTU somewhere between
this host and the remote peer of 576 - not uncommon given that's the
internet standard. Then you may waste 192 bytes per frag. Storing a 32K
(for example) PDU would take 57 pbufs, with about 11KiB wasted (ignoring
pbuf structure overheads).

Maybe we could copy them into PBUF_RAMs, rather than having a separate
buffer. I'm undecided whether that would be worth it.

>> You should try and
>> avoid getting fragmented packets in the first place!
>> Of course if lwIP could implement path MTU discovery, it
>> could keep up its side of the bargain.
>
> Agree, but isn't reassembly the wrong side for that?

That's what I meant be keeping up its side of the bargain. If you want to
avoid fragmentation, you have to avoid sending packets larger than any MTU.
So if lwIP doesn't want fragmented packets, it should equally be trying to
avoid sending them. More relevantly, if an lwIP device was talking to an
lwIP device, then unless they've already been configured with a sensible
MSS (or MTU) they may always fragment. If _everyone_ implements path MTU
discovery, fragmentation is not needed. For TCP anyway.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

RE: IP fragmentation

Goldschmidt Simon
> The main problem I see, as mentioned in that task, is you
> have to use up a whole PBUF_POOL_BUFSIZE (or even multiple)
> worth of bytes from the pbuf pool.
>
> Suppose PBUF_POOL_BUFSIZE is 256, and there is an MTU
> somewhere between this host and the remote peer of 576 - not
> uncommon given that's the internet standard. Then you may
> waste 192 bytes per frag. Storing a 32K (for example) PDU
> would take 57 pbufs, with about 11KiB wasted (ignoring pbuf
> structure overheads).

That is a general pool vs. heap issue. My proposal at least lets
you use the pbuf pool without dead-locking the stack. to use it
or not (e.g. 'wasting' the memory for it or not) would be the
Decision of the developer (and I chose to have mem_malloc() using
pools, which also wastes a lot of RAM). The point is I would like
to be able to chose. That way you can configure lwIP running slow
on small targets or running fast on bigger targets (a marketing
guy would probably say it scales?).

>
> Maybe we could copy them into PBUF_RAMs, rather than having a
> separate buffer. I'm undecided whether that would be worth it.

That would make the ip_frag code a little cleaner, but you could
instead pass pbuf_refs pointing into ip_reassbuf to ip_input, so
either way you would end up copying only once (from the received
PBUF_POOL to ip_reassbuf or to PBUF_RAM), which is better as the
current situation.
At least you would allow easy switching between single-copy using
PBUF_RAM and zero-copy using PBUF_POOL, which I think would be
a good compromise.

>
> >> You should try and
> >> avoid getting fragmented packets in the first place!
> >> Of course if lwIP could implement path MTU discovery, it
> could keep
> >> up its side of the bargain.
> >
> > Agree, but isn't reassembly the wrong side for that?
>
> That's what I meant be keeping up its side of the bargain. If
> you want to avoid fragmentation, you have to avoid sending
> packets larger than any MTU.
> So if lwIP doesn't want fragmented packets, it should equally
> be trying to avoid sending them. More relevantly, if an lwIP
> device was talking to an lwIP device, then unless they've
> already been configured with a sensible MSS (or MTU) they may
> always fragment. If _everyone_ implements path MTU discovery,
> fragmentation is not needed. For TCP anyway.

Agree again. Do you implment it? ;-)


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

Re: IP fragmentation

Jonathan Larmour
Goldschmidt Simon wrote:

>> The main problem I see, as mentioned in that task, is you
>> have to use up a whole PBUF_POOL_BUFSIZE (or even multiple)
>> worth of bytes from the pbuf pool.
>>
>> Suppose PBUF_POOL_BUFSIZE is 256, and there is an MTU
>> somewhere between this host and the remote peer of 576 - not
>> uncommon given that's the internet standard. Then you may
>> waste 192 bytes per frag. Storing a 32K (for example) PDU
>> would take 57 pbufs, with about 11KiB wasted (ignoring pbuf
>> structure overheads).
>
> That is a general pool vs. heap issue. My proposal at least lets
> you use the pbuf pool without dead-locking the stack. to use it
> or not (e.g. 'wasting' the memory for it or not) would be the
> Decision of the developer (and I chose to have mem_malloc() using
> pools, which also wastes a lot of RAM). The point is I would like
> to be able to chose. That way you can configure lwIP running slow
> on small targets or running fast on bigger targets (a marketing
> guy would probably say it scales?).

Personally I don't have trouble with things as config options.

>> Maybe we could copy them into PBUF_RAMs, rather than having a
>> separate buffer. I'm undecided whether that would be worth it.
>
> That would make the ip_frag code a little cleaner, but you could
> instead pass pbuf_refs pointing into ip_reassbuf to ip_input, so
> either way you would end up copying only once (from the received
> PBUF_POOL to ip_reassbuf or to PBUF_RAM), which is better as the
> current situation.

You still have to have the dedicated buffer with that approach. At least
memory for PBUF_RAMs can be shared with other parts of the system. There is
the overhead of the pbuf structure admittedly - probably 16 bytes +
possible alignment bytes. Hopefully that is small compared to the fragment
size which should be at a minimum 576 bytes. Arguably it could be a
footprint increase for some people, but I'm not sure it's enough to be
concerned about.

> At least you would allow easy switching between single-copy using
> PBUF_RAM and zero-copy using PBUF_POOL, which I think would be
> a good compromise.

If the config option can be cleanly done, then feel free :).

[path mtu discovery]
> Agree again. Do you implment it? ;-)

Heh. I wasn't proposing anyone implementing it right now (unless they want
to :-)). It was just a throwaway comment.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

Re: IP fragmentation

Thomas Taranowski
In general, I always try to design my software such that it respects the MTU of whatever network it's going to be operating on.  However, an application I want to support needs to receive 3k UDP datagrams from a remote target on a standard Ethernet network.  I think this is a perfectly reasonable and normal operation for lwIP to support, and is well within the bounds of the UDP protocol, which allows datagrams up to 65k in size (although very few stacks support a limit this high).

I like the idea of temporarily storing the fragments in their respective pbuf chains.  It makes sense to handle the incoming payloads as little as possible, so just keeping the fragments where they are rather than memcpying them into a reassembly buffer seems like a good idea.

The only thing that bothers me about this solution is that there can be a sizeable chunk of pbufs floating around in limbo waiting for the rest of the fragments to arrive.  This means if a large number of fragments are incomplete at any given moment, say from a very unreliable link or greatly mismatched targets, then the stack could exhaust it's pool of pbufs, and be deadlocked.  I would support a limit on the number of pbufs that can be used for fragmented packets at any one time.  This way, there will always be pbufs in reserve to receive new packets.  Then again, maybe the reassembly timer is good enough to protect against this scenario.  Every 3 seconds, or whatever it is set to, it flushes the stale fragments, releasing the previously bound pbufs.

From reading the above, it sounds like we're trying to decide whether to go with a malloc/memcpy approach to efficiently allocate heap space for fragments as they arrive, or to use the pbufs, which don't require a memcpy, but aren't necessarily as efficient, space-wise.  In some respects it depends on the implementation of the malloc.  Many embedded OSes use a pool based allocation scheme to handle fragmentation issues, while most general purpose OSes use whatever suits their fancy.  This argues that we need to have some sort of configuration item to select between the two.  However, I would seem to me that the implementation of the malloc/memcpy approach and the pbuf approach would be largely divergent, leaving fairly large tracts of #ifdef'd code, which is something I'm not too keen on.   Maybe there is some sort of unified approach that could be used to cleanly unite the two implementations, and allow for the advantages of both.  If so, I opt for that approach.  If not, then I much prefer the pbuf approach.

On 5/9/07, Jonathan Larmour <[hidden email]> wrote:
Goldschmidt Simon wrote:

>> The main problem I see, as mentioned in that task, is you
>> have to use up a whole PBUF_POOL_BUFSIZE (or even multiple)
>> worth of bytes from the pbuf pool.
>>
>> Suppose PBUF_POOL_BUFSIZE is 256, and there is an MTU
>> somewhere between this host and the remote peer of 576 - not
>> uncommon given that's the internet standard. Then you may
>> waste 192 bytes per frag. Storing a 32K (for example) PDU
>> would take 57 pbufs, with about 11KiB wasted (ignoring pbuf
>> structure overheads).
>
> That is a general pool vs. heap issue. My proposal at least lets
> you use the pbuf pool without dead-locking the stack. to use it
> or not (e.g. 'wasting' the memory for it or not) would be the
> Decision of the developer (and I chose to have mem_malloc() using
> pools, which also wastes a lot of RAM). The point is I would like
> to be able to chose. That way you can configure lwIP running slow
> on small targets or running fast on bigger targets (a marketing
> guy would probably say it scales?).

Personally I don't have trouble with things as config options.

>> Maybe we could copy them into PBUF_RAMs, rather than having a
>> separate buffer. I'm undecided whether that would be worth it.
>
> That would make the ip_frag code a little cleaner, but you could
> instead pass pbuf_refs pointing into ip_reassbuf to ip_input, so
> either way you would end up copying only once (from the received
> PBUF_POOL to ip_reassbuf or to PBUF_RAM), which is better as the
> current situation.

You still have to have the dedicated buffer with that approach. At least
memory for PBUF_RAMs can be shared with other parts of the system. There is
the overhead of the pbuf structure admittedly - probably 16 bytes +
possible alignment bytes. Hopefully that is small compared to the fragment
size which should be at a minimum 576 bytes. Arguably it could be a
footprint increase for some people, but I'm not sure it's enough to be
concerned about.

> At least you would allow easy switching between single-copy using
> PBUF_RAM and zero-copy using PBUF_POOL, which I think would be
> a good compromise.

If the config option can be cleanly done, then feel free :).

[path mtu discovery]
> Agree again. Do you implment it? ;-)

Heh. I wasn't proposing anyone implementing it right now (unless they want
to :-)). It was just a throwaway comment.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

RE: IP fragmentation

Goldschmidt Simon
> The only thing that bothers me about this solution is that there can
be a
> sizeable chunk of pbufs floating around in limbo waiting for the rest
of
> the fragments to arrive.  This means if a large number of fragments
are
> incomplete at any given moment, say from a very unreliable link or
greatly
> mismatched targets, then the stack could exhaust it's pool of pbufs,
and be
> deadlocked.  I would support a limit on the number of pbufs that can
be
> used for fragmented packets at any one time.  This way, there will
always
> be pbufs in reserve to receive new packets.

This is what I proposed. Then you just have to have enough pbufs in the
pool
so that your pools doesn't get empty. And you could still allocate them
at
startup exchanging them for the received (so that the amount of pbufs in
the
pool stays the same whether you are receiving fragmented IP or not, you
just
statically allocate some of them for ip_reass).


> Then again, maybe the reassembly timer is good enough to protect
against
> this scenario.  Every 3 seconds, or whatever it is set to, it flushes
the
> stale fragments, releasing the previously bound pbufs.

I don't think so. You could still be receiving so much that, after
freeing some
timed out fragments, you immediately run out of pbufs again if you only
have a
timeout for each fragment instead of a maximum count of fragments ...
       
> From reading the above, it sounds like we're trying to decide whether
to go
> with a malloc/memcpy approach to efficiently allocate heap space for
fragments
> as they arrive, or to use the pbufs, which don't require a memcpy, but
aren't
> necessarily as efficient, space-wise.  In some respects it depends on
the
> implementation of the malloc.

I think it's a very simple ifdef: hold the PBUF_POOL (and maybe free
another
on in exchange) or allocate a PBUF_RAM and do some memcpy(), the rest
stays
the same.

> Many embedded OSes use a pool based allocation scheme to handle
fragmentation
> issues, while most general purpose OSes use whatever suits their
fancy.

That's why I want to eliminate the heap in lwIP (at least as an
option)...


[...]
> If not, then I much prefer the pbuf approach.

As I said, in my opinion, they are both pbuf approaches... :-)



Simon


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

additional/optional protocols

Decker, Paul
In reply to this post by Jonathan Larmour
Hello everyone,

I apologize in advance if this is going to the wrong group, if so,
please kindly identify where a question like this would generally be
posted.

As some of you know, we have made a port of the LwIP sources to our
Blackfin processors.  At this time, we have not submitted our port back
to the LwIP community, however, this is something we are looking at
doing.

We are also looking at various other projects and extensions to deliver
with our LwIP offering.  Some of these ideas include support for
protocols such as DNS(client), SNTP, SMTP, PPPoE, RTP, SIG and IGMP.  We
are also looking at various applications and protocols such as Telenet,
FTP, TFTP, and POP3.

Now for the question(s).   Do you have any recommendations on these?
Such as, are there already existing ports of these which have a similar
BSD style license?  Are there any plans or desires to move any of these
into the lwIP deliverable package?  


Thanks in advance and
Best regards,
Paul Decker
Analog Devices


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

RE : additional/optional protocols

Frédéric BERNON
Hi Paul,

For IGMP, it include in current CVS HEAD, due to the fact there is some real interactions with internal components of the stack. We have already talk to add in contrib modules some kind of sources using raw or sequential api.

A DNS client could be something to share, because it's something than everyone could need. From memory, Jim Pettinato has ported the uIP resolver to lwIP. You can ask him if he can share it with you. Look for the thread "BSD API tcp echo server port" in April, in mailing list archives...

PPPoE could be an extension because I think like classic PPP, there is real interaction with the stack.

But SNTP, SMTP, RTP, Telnet, FTP, TFTP are only working with the lwIP's API, and not with other parts. So, I don't think it is in the scope of lwIP. But it's my point of view, wait for others answers...

About SIG, what kind of protocol is it?
 
====================================
Frédéric BERNON
HYMATOM SA
Chef de projet informatique
Microsoft Certified Professional
Tél. : +33 (0)4-67-87-61-10
Fax. : +33 (0)4-67-70-85-44
Email : [hidden email]
Web Site : http://www.hymatom.fr 
====================================
P Avant d'imprimer, penser à l'environnement
 


-----Message d'origine-----
De : lwip-devel-bounces+frederic.bernon=[hidden email] [mailto:lwip-devel-bounces+frederic.bernon=[hidden email]] De la part de Decker, Paul
Envoyé : mercredi 23 mai 2007 22:12
À : lwip-devel
Objet : [lwip-devel] additional/optional protocols


Hello everyone,

I apologize in advance if this is going to the wrong group, if so, please kindly identify where a question like this would generally be posted.

As some of you know, we have made a port of the LwIP sources to our Blackfin processors.  At this time, we have not submitted our port back to the LwIP community, however, this is something we are looking at doing.

We are also looking at various other projects and extensions to deliver with our LwIP offering.  Some of these ideas include support for protocols such as DNS(client), SNTP, SMTP, PPPoE, RTP, SIG and IGMP.  We are also looking at various applications and protocols such as Telenet, FTP, TFTP, and POP3.

Now for the question(s).   Do you have any recommendations on these?
Such as, are there already existing ports of these which have a similar BSD style license?  Are there any plans or desires to move any of these into the lwIP deliverable package?  


Thanks in advance and
Best regards,
Paul Decker
Analog Devices


_______________________________________________
lwip-devel mailing list
[hidden email] http://lists.nongnu.org/mailman/listinfo/lwip-devel

_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel

=?iso-8859-1?Q?Fr=E9d=E9ric_BERNON=2Evcf?= (810 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: RE : additional/optional protocols

Decker, Paul
Hi Frederic,

Thank you for the quick answer, it is very good information to know.  I think SIG is a voip protocol, but I haven't researched it enough yet to know.  With the others that are on the application layer, do you know of any projects similar to lwip that have implemented these?

Best regards,

Paul Decker
Analog Devices



-----Original Message-----
From: lwip-devel-bounces+paul.decker=[hidden email] [mailto:lwip-devel-bounces+paul.decker=[hidden email]] On Behalf Of Frédéric BERNON
Sent: Wednesday, May 23, 2007 5:01 PM
To: lwip-devel
Subject: RE : [lwip-devel] additional/optional protocols

Hi Paul,

For IGMP, it include in current CVS HEAD, due to the fact there is some real interactions with internal components of the stack. We have already talk to add in contrib modules some kind of sources using raw or sequential api.

A DNS client could be something to share, because it's something than everyone could need. From memory, Jim Pettinato has ported the uIP resolver to lwIP. You can ask him if he can share it with you. Look for the thread "BSD API tcp echo server port" in April, in mailing list archives...

PPPoE could be an extension because I think like classic PPP, there is real interaction with the stack.

But SNTP, SMTP, RTP, Telnet, FTP, TFTP are only working with the lwIP's API, and not with other parts. So, I don't think it is in the scope of lwIP. But it's my point of view, wait for others answers...

About SIG, what kind of protocol is it?
 
====================================
Frédéric BERNON
HYMATOM SA
Chef de projet informatique
Microsoft Certified Professional
Tél. : +33 (0)4-67-87-61-10
Fax. : +33 (0)4-67-70-85-44
Email : [hidden email]
Web Site : http://www.hymatom.fr
====================================
P Avant d'imprimer, penser à l'environnement
 


-----Message d'origine-----
De : lwip-devel-bounces+frederic.bernon=[hidden email] [mailto:lwip-devel-bounces+frederic.bernon=[hidden email]] De la part de Decker, Paul Envoyé : mercredi 23 mai 2007 22:12 À : lwip-devel Objet : [lwip-devel] additional/optional protocols


Hello everyone,

I apologize in advance if this is going to the wrong group, if so, please kindly identify where a question like this would generally be posted.

As some of you know, we have made a port of the LwIP sources to our Blackfin processors.  At this time, we have not submitted our port back to the LwIP community, however, this is something we are looking at doing.

We are also looking at various other projects and extensions to deliver with our LwIP offering.  Some of these ideas include support for protocols such as DNS(client), SNTP, SMTP, PPPoE, RTP, SIG and IGMP.  We are also looking at various applications and protocols such as Telenet, FTP, TFTP, and POP3.

Now for the question(s).   Do you have any recommendations on these?
Such as, are there already existing ports of these which have a similar BSD style license?  Are there any plans or desires to move any of these into the lwIP deliverable package?  


Thanks in advance and
Best regards,
Paul Decker
Analog Devices


_______________________________________________
lwip-devel mailing list
[hidden email] http://lists.nongnu.org/mailman/listinfo/lwip-devel


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

RE : RE : additional/optional protocols

Frédéric BERNON
In reply to this post by Frédéric BERNON
Isn't it SIP (Session Initiation Protocol)? For application protocols, I usually implement them from RFC. Lot of them are easy to implement, if you don't want to be at 100% RFC compliant...
 
====================================
Frédéric BERNON
HYMATOM SA
Chef de projet informatique
Microsoft Certified Professional
Tél. : +33 (0)4-67-87-61-10
Fax. : +33 (0)4-67-70-85-44
Email : [hidden email]
Web Site : http://www.hymatom.fr 
====================================
P Avant d'imprimer, penser à l'environnement
 


-----Message d'origine-----
De : lwip-devel-bounces+frederic.bernon=[hidden email] [mailto:lwip-devel-bounces+frederic.bernon=[hidden email]] De la part de Decker, Paul
Envoyé : mercredi 23 mai 2007 23:19
À : lwip-devel
Objet : RE: RE : [lwip-devel] additional/optional protocols


Hi Frederic,

Thank you for the quick answer, it is very good information to know.  I think SIG is a voip protocol, but I haven't researched it enough yet to know.  With the others that are on the application layer, do you know of any projects similar to lwip that have implemented these?

Best regards,

Paul Decker
Analog Devices



-----Original Message-----
From: lwip-devel-bounces+paul.decker=[hidden email] [mailto:lwip-devel-bounces+paul.decker=[hidden email]] On Behalf Of Frédéric BERNON
Sent: Wednesday, May 23, 2007 5:01 PM
To: lwip-devel
Subject: RE : [lwip-devel] additional/optional protocols

Hi Paul,

For IGMP, it include in current CVS HEAD, due to the fact there is some real interactions with internal components of the stack. We have already talk to add in contrib modules some kind of sources using raw or sequential api.

A DNS client could be something to share, because it's something than everyone could need. From memory, Jim Pettinato has ported the uIP resolver to lwIP. You can ask him if he can share it with you. Look for the thread "BSD API tcp echo server port" in April, in mailing list archives...

PPPoE could be an extension because I think like classic PPP, there is real interaction with the stack.

But SNTP, SMTP, RTP, Telnet, FTP, TFTP are only working with the lwIP's API, and not with other parts. So, I don't think it is in the scope of lwIP. But it's my point of view, wait for others answers...

About SIG, what kind of protocol is it?
 
====================================
Frédéric BERNON
HYMATOM SA
Chef de projet informatique
Microsoft Certified Professional
Tél. : +33 (0)4-67-87-61-10
Fax. : +33 (0)4-67-70-85-44
Email : [hidden email]
Web Site : http://www.hymatom.fr ====================================
P Avant d'imprimer, penser à l'environnement
 


-----Message d'origine-----
De : lwip-devel-bounces+frederic.bernon=[hidden email] [mailto:lwip-devel-bounces+frederic.bernon=[hidden email]] De la part de Decker, Paul Envoyé : mercredi 23 mai 2007 22:12 À : lwip-devel Objet : [lwip-devel] additional/optional protocols


Hello everyone,

I apologize in advance if this is going to the wrong group, if so, please kindly identify where a question like this would generally be posted.

As some of you know, we have made a port of the LwIP sources to our Blackfin processors.  At this time, we have not submitted our port back to the LwIP community, however, this is something we are looking at doing.

We are also looking at various other projects and extensions to deliver with our LwIP offering.  Some of these ideas include support for protocols such as DNS(client), SNTP, SMTP, PPPoE, RTP, SIG and IGMP.  We are also looking at various applications and protocols such as Telenet, FTP, TFTP, and POP3.

Now for the question(s).   Do you have any recommendations on these?
Such as, are there already existing ports of these which have a similar BSD style license?  Are there any plans or desires to move any of these into the lwIP deliverable package?  


Thanks in advance and
Best regards,
Paul Decker
Analog Devices


_______________________________________________
lwip-devel mailing list
[hidden email] http://lists.nongnu.org/mailman/listinfo/lwip-devel


_______________________________________________
lwip-devel mailing list
[hidden email] http://lists.nongnu.org/mailman/listinfo/lwip-devel

_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel

=?iso-8859-1?Q?Fr=E9d=E9ric_BERNON=2Evcf?= (810 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: RE : additional/optional protocols

Goldschmidt Simon
In reply to this post by Frédéric BERNON


> A DNS client could be something to share, because it's
> something than everyone could need. From memory, Jim
> Pettinato has ported the uIP resolver to lwIP. You can ask
> him if he can share it with you. Look for the thread "BSD API
> tcp echo server port" in April, in mailing list archives...

Agree

>
> PPPoE could be an extension because I think like classic PPP,
> there is real interaction with the stack.

Agree

>
> But SNTP, SMTP, RTP, Telnet, FTP, TFTP are only working with
> the lwIP's API, and not with other parts. So, I don't think
> it is in the scope of lwIP. But it's my point of view, wait
> for others answers...

I'd like to see them in CVS/contrib or somehow create another
pool of available application code using lwip API.


Simon


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

Re: additional/optional protocols

Kieran Mansley
In reply to this post by Decker, Paul
On Wed, 2007-05-23 at 16:12 -0400, Decker, Paul wrote:
> Hello everyone,
>
> I apologize in advance if this is going to the wrong group, if so,
> please kindly identify where a question like this would generally be
> posted.

This sort of thing might benefit from a wider audience in lwip-users
mailing list as you might find others there have already implemented
some of this for you.


> Are there any plans or desires to move any of these
> into the lwIP deliverable package?  

Such things would I'm sure be welcome in the lwip contrib module,
subject to the requirement that they have an active maintainer!

Kieran



_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

RE: RE : additional/optional protocols

JamminJimP
In reply to this post by Goldschmidt Simon

We have discussed the benefit of adding an 'apps/raw_api' and an
'apps/seq_api' area to the contrib module... and there are plans (right,
Kieran?) to do so soon. I don't recall exactly but perhaps we are
waiting until the next stable release before attacking the CVS
repository layout? And I know Kieran was looking for some assistance in
the form of volunteers for that endeavor as well... (and I'm certainly
willing to help!)


-----Original Message-----
From: lwip-devel-bounces+jim.pettinato=[hidden email]
[mailto:lwip-devel-bounces+jim.pettinato=[hidden email]] On Behalf
Of Goldschmidt Simon
Sent: Thursday, May 24, 2007 3:00 AM
To: lwip-devel
Subject: RE: RE : [lwip-devel] additional/optional protocols




> A DNS client could be something to share, because it's
> something than everyone could need. From memory, Jim
> Pettinato has ported the uIP resolver to lwIP. You can ask
> him if he can share it with you. Look for the thread "BSD API
> tcp echo server port" in April, in mailing list archives...

Agree

>
> PPPoE could be an extension because I think like classic PPP,
> there is real interaction with the stack.

Agree

>
> But SNTP, SMTP, RTP, Telnet, FTP, TFTP are only working with
> the lwIP's API, and not with other parts. So, I don't think
> it is in the scope of lwIP. But it's my point of view, wait
> for others answers...

I'd like to see them in CVS/contrib or somehow create another pool of
available application code using lwip API.


Simon


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel