If I remember correctly, you plan on releasing a bug-fix
version of the 1.4 code-base in the next few weeks.
Is this still true? Do you have an approximate idea when
a 1.4.1 version would be available?
--
Regards.
_______________________________________________
lwip-users mailing list
lwip-...@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Well, there are 2 bugs and 2 tasks open targeted for 1.4.1 (plus 2 other bugs not targeted yet but I'd like to fix them for 1.4.1, too).
There is already a 1.4.1 branch in git which has the rest of the bugs fixed, if you'd like to test that.
I hope to find the time to do the rest of the work in the next weeks...
Simon
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
> Mason wrote:
>
>> If I remember correctly, you plan on releasing a bug-fix
>> version of the 1.4 code-base in the next few weeks.
>>
>> Is this still true? Do you have an approximate idea when
>> a 1.4.1 version would be available?
>
> Well, there are 2 bugs and 2 tasks open targeted for 1.4.1
> (plus 2 other bugs not targeted yet but I'd like to fix them
> for 1.4.1, too).
I see that several bugs targeted for 1.4.1 were fixed recently.
http://savannah.nongnu.org/bugs/index.php?35305
http://savannah.nongnu.org/bugs/index.php?35291
http://savannah.nongnu.org/bugs/index.php?35151
I also see that bug #25882 is targeted for 1.4.1, but the status
is "Need Info".
http://savannah.nongnu.org/bugs/index.php?25882
What other bugs would you liked fixed before you release an
"official" 1.4.1 revision?
> There is already a 1.4.1 branch in git which has the rest of
> the bugs fixed, if you'd like to test that.
The DEVEL-1_4_1 branch?
http://git.savannah.gnu.org/cgit/lwip.git/log/?h=DEVEL-1_4_1
I'm confused because it hasn't been updated since 2011-12-15.
So it does not include the recent bug fixes?
--
Regards.
That one is "in progress" but I guess we haven't reached a consensus yet of how to fix it.
> What other bugs would you liked fixed before you release an
> "official" 1.4.1 revision?
None, or they would have been marked as targeted for 1.4.1. Any yes, that means there is (once again) only 1 bug left to be fixed before the release.
> > There is already a 1.4.1 branch in git which has the rest of
> > the bugs fixed, if you'd like to test that.
>
> The DEVEL-1_4_1 branch?
> http://git.savannah.gnu.org/cgit/lwip.git/log/?h=DEVEL-1_4_1
Yes.
> I'm confused because it hasn't been updated since 2011-12-15.
> So it does not include the recent bug fixes?
That's because I fix bugs on the master branch and have to backport them to the 1.4.1 branch. I simply haven't found the time to do so for the latest fixes.
Simon
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
_______________________________________________
> Mason wrote:
>
>> I also see that bug #25882 is targeted for 1.4.1, but the status is "Need Info".
>> http://savannah.nongnu.org/bugs/index.php?25882
>
> That one is "in progress" but I guess we haven't reached a consensus
> yet of how to fix it.
Have you and Kieran made any progress on bug #25882? :-)
(Maybe the Status field should be changed to "In Progress".)
>> What other bugs would you liked fixed before you release an
>> "official" 1.4.1 revision?
>
> None, or they would have been marked as targeted for 1.4.1. Any yes,
> that means there is (once again) only 1 bug left to be fixed before
> the release.
I see that bug #35435 has also been targeted for 1.4.1
http://savannah.nongnu.org/bugs/index.php?35435
>>> There is already a 1.4.1 branch in git which has the rest of
>>> the bugs fixed, if you'd like to test that.
>>
>> The DEVEL-1_4_1 branch?
>> http://git.savannah.gnu.org/cgit/lwip.git/log/?h=DEVEL-1_4_1
>
> Yes.
>
>> I'm confused because it hasn't been updated since 2011-12-15.
>> So it does not include the recent bug fixes?
>
> That's because I fix bugs on the master branch and have to backport
> them to the 1.4.1 branch. I simply haven't found the time to do so
> for the latest fixes.
Is there something I can help with for the 1.4.1 release?
--
Regards.
Yes, as that one is minor (a simple matter of checking states) compared
to the other one, so it doesn't hold back the release and is nice to have.
> Is there something I can help with for the 1.4.1 release?
Aside from actively discussing a fix fo bug #25882, testing the 1.4.1
branch is always welcome! Again, I hope to just get a fix out for that
bug in the next weeks, so we can have a beta/RC for 1.4.1. I still also
need to merge the lates bugfixes from master to 1.4.1, but as these are
not much, that doesn't take long.
Simon
> Aside from actively discussing a fix fo bug #25882, testing the 1.4.1
> branch is always welcome! Again, I hope to just get a fix out for that
> bug in the next weeks, so we can have a beta/RC for 1.4.1. I still
also
> need to merge the lates bugfixes from master to 1.4.1, but as these
are
> not much, that doesn't take long.
Hi Simon,
Thanks for your work on merging bug fixes to the 1.4.1 branch.
I use this branch and test it regularly. It globally works fine.
I need to check/fix 3 things:
1. fix bug #35531 I discovery today
2. check TCP close() with the recent changes
3. I will need SNMP soon and I think there's a bug in request handling
(receive a GET with more requests than pool size can contain)
Would be nice to have:
- use only one include directory (merge v4 and v6 into lwIP, remove v6
on 1.4.1 ?, posix sub-directories for in.h/inet.h/sockets.h ?)
- split public and internal APIs to separate header files
--
Stephane
> Thanks for your work on merging bug fixes to the 1.4.1 branch.
>
> I use this branch and test it regularly. It globally works fine.
> I need to check/fix 3 things:
> 1. fix bug #35531 I discovery today
Thanks For reporting, I'll fix that one.
> 2. check TCP close() with the recent changes
> 3. I will need SNMP soon and I think there's a bug in request handling
> (receive a GET with more requests than pool size can contain)
Please report any bugs you find as soon as possible, I'd like to release 1.4.1 soon. Although we'll have RC releases first, I guess.
> Would be nice to have:
> - use only one include directory (merge v4 and v6 into lwIP, remove v6
> on 1.4.1 ?, posix sub-directories for in.h/inet.h/sockets.h ?)
> - split public and internal APIs to separate header files
These two really would be nice to have, but as a bug fix release, I want the upgrade to be as simple as possible, so I wouldn't want to change the directory layout.
Simon
I am wondering, if there is a forecast for introducing fragmented udp support ?
That maximum size of a UDP datagram should only be limited by the protocol and your resources, so 64K should work, yes.
Simon
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
_______________________________________________
With UDP being unreliable, that implies that one or more fragments could be
dropped in a large UDP send, right?
Bill
>>
>> Would be nice to have:
>> - use only one include directory (merge v4 and v6 into lwIP, remove v6
>> on 1.4.1 ?, posix sub-directories for in.h/inet.h/sockets.h ?)
>> - split public and internal APIs to separate header files
>
> These two really would be nice to have, but as a bug fix release, I want the upgrade to be as simple as possible, so I wouldn't want to change the directory layout.
I agree, and wouldn't take anything like that into a 1.4.1 release. We need it to be just straight forward bug fixes only.
Kieran
>> That maximum size of a UDP datagram should only be limited by the
>> protocol and your resources, so 64K should work, yes.
>
> With UDP being unreliable, that implies that one or more fragments could be
> dropped in a large UDP send, right?
Yes, but if one fragment is lost then the whole datagram should be discarded by the receiving stack.
Kieran
> On other hand, if UDP checksum is omitted and under certain
> conditions (long UDP datagram timeout, high communcation speed and as
> a result IP overlapping while still within a UDP datagram timeout) -
> one might expect to get a wrong, but "valid" datagram with IP
> fragment belonging to another UDP datagram. - I think, it might
> happen with IPv4.
Attributing fragments of one datagram to a different datagram
would definitely be a bug in the network stack.
That's the purpose of the Identification field.
(and Fragment Offset to a lesser degree.)
--
Regards.