* lwip 1.3.1 testing @ 2009-08-21 7:11 Simon Kallweit 2009-08-21 7:43 ` John Dallaway 2009-08-21 18:43 ` Sergei Gavrikov 0 siblings, 2 replies; 24+ messages in thread From: Simon Kallweit @ 2009-08-21 7:11 UTC (permalink / raw) To: ecos-devel Hi If anyone volunteers, I'd be glad if you could test the current state of the lwip 1.3.1 port. It has been updated with the latest changes from the 1.3.1 release. I currently left in my changes for SLIP and PPP (see my last mail for details), but this should not matter for testing. The package can be installed by just replacing the existing lwip and eth drivers packages. http://download.westlicht.ch/lwip-20090821.tar.gz Thanks Simon ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: lwip 1.3.1 testing 2009-08-21 7:11 lwip 1.3.1 testing Simon Kallweit @ 2009-08-21 7:43 ` John Dallaway 2009-08-21 9:12 ` Edgar Grimberg 2009-08-21 18:43 ` Sergei Gavrikov 1 sibling, 1 reply; 24+ messages in thread From: John Dallaway @ 2009-08-21 7:43 UTC (permalink / raw) To: ecos-devel Simon Kallweit wrote: > If anyone volunteers, I'd be glad if you could test the current state of > the lwip 1.3.1 port. It has been updated with the latest changes from > the 1.3.1 release. I currently left in my changes for SLIP and PPP (see > my last mail for details), but this should not matter for testing. The > package can be installed by just replacing the existing lwip and eth > drivers packages. > > http://download.westlicht.ch/lwip-20090821.tar.gz Testing on big-endian targets would be especially welcome. John Dallaway ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: lwip 1.3.1 testing 2009-08-21 7:43 ` John Dallaway @ 2009-08-21 9:12 ` Edgar Grimberg 0 siblings, 0 replies; 24+ messages in thread From: Edgar Grimberg @ 2009-08-21 9:12 UTC (permalink / raw) To: ecos-devel On Fri, Aug 21, 2009 at 9:42 AM, John Dallaway<john@dallaway.org.uk> wrote: > Simon Kallweit wrote: > >> If anyone volunteers, I'd be glad if you could test the current state of >> the lwip 1.3.1 port. It has been updated with the latest changes from >> the 1.3.1 release. I currently left in my changes for SLIP and PPP (see >> my last mail for details), but this should not matter for testing. The >> package can be installed by just replacing the existing lwip and eth >> drivers packages. >> >> http://download.westlicht.ch/lwip-20090821.tar.gz > > Testing on big-endian targets would be especially welcome. > I need to shape up the TSEC driver for MPC8313 and then I'll give it a try. It will take some days, though.. Regards, Edgar -- Edgar Grimberg System Developer Zylin AS ZY1000 JTAG Debugger http://www.zylin.com/zy1000.html Phone: (+47) 51 63 25 00 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: lwip 1.3.1 testing 2009-08-21 7:11 lwip 1.3.1 testing Simon Kallweit 2009-08-21 7:43 ` John Dallaway @ 2009-08-21 18:43 ` Sergei Gavrikov 2009-08-24 20:18 ` Sergei Gavrikov 1 sibling, 1 reply; 24+ messages in thread From: Sergei Gavrikov @ 2009-08-21 18:43 UTC (permalink / raw) To: Simon Kallweit; +Cc: ecos-devel On Fri, Aug 21, 2009 at 09:12:02AM +0200, Simon Kallweit wrote: > Hi > > If anyone volunteers, I'd be glad if you could test the current state of > the lwip 1.3.1 port. It has been updated with the latest changes from > the 1.3.1 release. I currently left in my changes for SLIP and PPP (see > my last mail for details), but this should not matter for testing. The > package can be installed by just replacing the existing lwip and eth > drivers packages. > > http://download.westlicht.ch/lwip-20090821.tar.gz Hi Simon, I need a bit clarification from you. Does it mean that we should try 'lwip_eth' template only on real HW? I stub on 'left in' phrase. Did your SLIP/PPP hack leave this tarball? Does it mean what tests of SLIP, for example, will be useless just now? And more, could you, please, post a reason ECM (the legal eCos minimal configuration file for such a called 'Sequential' mode)? I hope you have something for synthetic target, IMO, it would help to setup tests more quickly, I see that real hardware will be to require the uploads and debugging via serial (at the least for my target), because, I will need to test the net tests. Well, that would be great and that will save a time for "digging"/uploading. If you did not save own ECM(s), the simplest question is, Did you use DHCP or static IPs in your tests? I'm going to try your lwip port on ARM-7 (LE) this weekend. FYI: My first compile-stop did occur in simple.c, then I send a patch. Thank you. Sergei > Thanks > Simon ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: lwip 1.3.1 testing 2009-08-21 18:43 ` Sergei Gavrikov @ 2009-08-24 20:18 ` Sergei Gavrikov 2009-08-25 6:09 ` Simon Kallweit 0 siblings, 1 reply; 24+ messages in thread From: Sergei Gavrikov @ 2009-08-24 20:18 UTC (permalink / raw) To: Simon Kallweit; +Cc: ecos-devel [-- Attachment #1: Type: text/plain, Size: 2321 bytes --] On Fri, Aug 21, 2009 at 09:43:36PM +0300, Sergei Gavrikov wrote: > On Fri, Aug 21, 2009 at 09:12:02AM +0200, Simon Kallweit wrote: > > Hi > > > > If anyone volunteers, I'd be glad if you could test the current state of > > the lwip 1.3.1 port. It has been updated with the latest changes from > > the 1.3.1 release. I currently left in my changes for SLIP and PPP (see > > my last mail for details), but this should not matter for testing. The > > package can be installed by just replacing the existing lwip and eth > > drivers packages. > > > > http://download.westlicht.ch/lwip-20090821.tar.gz > > Hi Simon, > > I need a bit clarification from you. Does it mean that we should try > 'lwip_eth' template only on real HW? I stub on 'left in' phrase. Did > your SLIP/PPP hack leave this tarball? Does it mean what tests of SLIP, > for example, will be useless just now? Hi Simon, Last weekend I tested a bit your lwip 1.3.1 port. Well, that was not any stress test, just compile and run a few net tests out from the box and pinging. Short summary the below Synth ARM-7 (LE) + http_simple + http_simple + http_sequential + http_sequntial + tcpecho + tcpecho External ping/arping worked for both targets. For the tests I used configs with DHCP support. For the followers I attach the ecos minimal configs which I used for simple and sequential modes for synth and real hardware and a small patch for simple.c, sequential.c. All build were started as ecosconfig new <target> lwip_eth I had got `stack overlow' in GDB with default stack's settings on real target when I enabled a tracing and turned off optimization, I tried multipy stack amounts (for interrupts, tcp_thread, eth_thread) x 2, x 4, but error did not go away. Perhaps, I should investigate more time for the issue, but may be in the next weekend. Thanks for the port! Regards Sergei Appendix Host and tools details ---------------------- Host Ubuntu 8.04.3 LTS eCos CVS updated + lwIP 1.3.1 package ecosconfig 3.net (Aug 23 2009 17:00:44) dhcpd3 V3.0.6 Synth target details -------------------- GCC 4.2.4 GDB GNU gdb 6.8-debian CFLAGS -g -O2 ARM target details ------------------ BOARD Olimex LPC-E2294 rev. B NIC DAVICOM DM900 32-bits STARTUP RAM ROM monitor RedBoot+GDB stubs GCC arm-eabi-gcc 4.3.2 CFLAGS -g -O2 [-- Attachment #2: lwip.patch --] [-- Type: text/x-diff, Size: 1858 bytes --] diff -r c04951f2b777 net/lwip_tcpip/current/src/ecos/sequential.c --- a/net/lwip_tcpip/current/src/ecos/sequential.c Fri Aug 21 20:43:16 2009 +0300 +++ b/net/lwip_tcpip/current/src/ecos/sequential.c Mon Aug 24 17:27:13 2009 +0300 @@ -75,6 +75,10 @@ #include <cyg/infra/diag.h> #include <cyg/kernel/kapi.h> +#ifdef CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT +#include <cyg/hal/hal_if.h> // HAL_CTRLC_CHECK +#endif + #ifdef CYGPKG_LWIP_ETH #include <cyg/io/eth/eth_drv.h> #include <cyg/io/eth/netdev.h> @@ -227,7 +231,7 @@ #endif sc->state &= ~ETH_DRV_NEEDS_DELIVERY; #if defined(CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT) - was_ctrlc_int = HAL_CTRLC_CHECK(*sc->funs->int_vector(sc), + was_ctrlc_int = HAL_CTRLC_CHECK(sc->funs->int_vector(sc), (int) sc); if (!was_ctrlc_int) // Fall through and run normal code #endif diff -r c04951f2b777 net/lwip_tcpip/current/src/ecos/simple.c --- a/net/lwip_tcpip/current/src/ecos/simple.c Fri Aug 21 20:43:16 2009 +0300 +++ b/net/lwip_tcpip/current/src/ecos/simple.c Mon Aug 24 17:27:13 2009 +0300 @@ -76,6 +76,10 @@ #include <cyg/infra/diag.h> #include <cyg/kernel/kapi.h> +#ifdef CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT +#include <cyg/hal/hal_if.h> // HAL_CTRLC_CHECK +#endif + #ifdef CYGPKG_LWIP_ETH #include <cyg/io/eth/eth_drv.h> #include <cyg/io/eth/netdev.h> @@ -291,7 +295,7 @@ #endif sc->state &= ~ETH_DRV_NEEDS_DELIVERY; #if defined(CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT) - was_ctrlc_int = HAL_CTRLC_CHECK(*sc->funs->int_vector(sc), + was_ctrlc_int = HAL_CTRLC_CHECK(sc->funs->int_vector(sc), (int) sc); if (!was_ctrlc_int) // Fall through and run normal code #endif [-- Attachment #3: synth_simple.ecm --] [-- Type: text/plain, Size: 171 bytes --] cdl_option CYGVAR_DEVS_ETH_ECOSYNTH_ETH0 { user_value 1 }; cdl_component CYGPKG_LWIP_DHCP { user_value 1 }; cdl_option CYGDAT_LWIP_ETH0_DHCP { user_value 1 }; [-- Attachment #4: synth_seq.ecm --] [-- Type: text/plain, Size: 407 bytes --] cdl_option CYGVAR_DEVS_ETH_ECOSYNTH_ETH0 { user_value 1 }; cdl_option CYGIMP_LWIP_MODE { user_value Sequential }; cdl_component CYGPKG_LWIP_NETIF_API { user_value 1 }; cdl_component CYGPKG_LWIP_NETCONN_API { user_value 1 }; cdl_component CYGPKG_LWIP_SOCKET_API { user_value 1 }; cdl_component CYGPKG_LWIP_DHCP { user_value 1 }; cdl_option CYGDAT_LWIP_ETH0_DHCP { user_value 1 }; [-- Attachment #5: lpc_simple.ecm --] [-- Type: text/plain, Size: 108 bytes --] cdl_component CYGPKG_LWIP_DHCP { user_value 1 }; cdl_option CYGDAT_LWIP_ETH0_DHCP { user_value 1 }; [-- Attachment #6: lpc_seq.ecm --] [-- Type: text/plain, Size: 344 bytes --] cdl_option CYGIMP_LWIP_MODE { user_value Sequential }; cdl_component CYGPKG_LWIP_NETIF_API { user_value 1 }; cdl_component CYGPKG_LWIP_NETCONN_API { user_value 1 }; cdl_component CYGPKG_LWIP_SOCKET_API { user_value 1 }; cdl_component CYGPKG_LWIP_DHCP { user_value 1 }; cdl_option CYGDAT_LWIP_ETH0_DHCP { user_value 1 }; ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: lwip 1.3.1 testing 2009-08-24 20:18 ` Sergei Gavrikov @ 2009-08-25 6:09 ` Simon Kallweit 2009-08-25 7:41 ` Simon Kallweit 0 siblings, 1 reply; 24+ messages in thread From: Simon Kallweit @ 2009-08-25 6:09 UTC (permalink / raw) To: Sergei Gavrikov; +Cc: ecos-devel Sergei Gavrikov wrote: > On Fri, Aug 21, 2009 at 09:43:36PM +0300, Sergei Gavrikov wrote: >> On Fri, Aug 21, 2009 at 09:12:02AM +0200, Simon Kallweit wrote: >>> Hi >>> >>> If anyone volunteers, I'd be glad if you could test the current state of >>> the lwip 1.3.1 port. It has been updated with the latest changes from >>> the 1.3.1 release. I currently left in my changes for SLIP and PPP (see >>> my last mail for details), but this should not matter for testing. The >>> package can be installed by just replacing the existing lwip and eth >>> drivers packages. >>> >>> http://download.westlicht.ch/lwip-20090821.tar.gz >> Hi Simon, >> >> I need a bit clarification from you. Does it mean that we should try >> 'lwip_eth' template only on real HW? I stub on 'left in' phrase. Did >> your SLIP/PPP hack leave this tarball? Does it mean what tests of SLIP, >> for example, will be useless just now? Sorry for the late answer, have been busy. The current release does still include the SLIP/PPP hacks yes, I'll try to get at least the SLIP modifications into lwip before a proper release of my port. PPP will be mostly useless in it's current state, but it's probably better to leave it as it is in the current lwip release than having my hacks in. > > Hi Simon, > > Last weekend I tested a bit your lwip 1.3.1 port. Well, that was not any > stress test, just compile and run a few net tests out from the box and > pinging. Short summary the below > > Synth ARM-7 (LE) > + http_simple + http_simple > + http_sequential + http_sequntial > + tcpecho + tcpecho Very nice, for some 'stress testing' you can run nc_test_slave. You'll need the nc_test_master which can be found in packages/net/common/current/tests > External ping/arping worked for both targets. For the tests I used > configs with DHCP support. > > For the followers I attach the ecos minimal configs which I used for > simple and sequential modes for synth and real hardware and a small > patch for simple.c, sequential.c. All build were started as > > ecosconfig new <target> lwip_eth The default lwip templates should probably be adapted to the new port. I'll look into that. > I had got `stack overlow' in GDB with default stack's settings on real > target when I enabled a tracing and turned off optimization, I tried > multipy stack amounts (for interrupts, tcp_thread, eth_thread) x 2, x 4, > but error did not go away. Perhaps, I should investigate more time for > the issue, but may be in the next weekend. That sounds interesting. I have not seen anything like that on the synth target, but stacks are at least 16k each, so it's not a good comparison. I also use lwip+ppp on a STM32, have not had any problems there either, but I don't use ethernet there. > Thanks for the port! Thanks a lot for testing!! Simon ^ permalink raw reply [flat|nested] 24+ messages in thread
* lwip 1.3.1 testing 2009-08-25 6:09 ` Simon Kallweit @ 2009-08-25 7:41 ` Simon Kallweit 2009-08-25 12:08 ` Sergei Gavrikov 2009-10-25 16:46 ` John Dallaway 0 siblings, 2 replies; 24+ messages in thread From: Simon Kallweit @ 2009-08-25 7:41 UTC (permalink / raw) To: Sergei Gavrikov; +Cc: ecos-devel [-- Attachment #1: Type: text/plain, Size: 1514 bytes --] Hi I have done a new lwip test release with the following changes: * incorporated Sergei's patch (ctrl-c support) * added an lwip_eth_simple and lwip_eth_sequential template The new test release can be downloaded from http://download.westlicht.ch/lwip-20090825.tar.gz To do synth tests do the following: create a new configuration: > ecosconfig new linux lwip_eth_simple or: > ecosconfig new linux lwip_eth_sequential enable eth0 synth device (file is attached): > ecosconfig import eth_synth.ecm build: > make > make -C build/net/lwip_tcpip/current tests run tests (a sample target.tdf is attached): ./build/install/tests/net/lwip_tcpip/current/tests/httpd_simple -t target.tdf -io -nw The current templates use DHCP to get an IP address. Just reconfigure for static IPs. To do some stress testing you can run the nc_test_slave testcase (only available in sequential mode). You will need the corresponding master test, which can be found in the ecos repository under packages/net/common/current/tests To build the nc_test_master go to the upper directory and type: > make -f make.host Also you should loosen up the very conservative default configuration of lwip pbufs to avoid dropped packets: > ecosconfig import pbufs.ecm > make && make -C build/net/lwip_tcpip/current tests Testing on real hardware would be especially useful. Also testing on big-endian targets might reveal some issues, as I've only been testing on little-endian platforms. Thanks a lot for testing! Simon [-- Attachment #2: eth_synth.ecm --] [-- Type: text/plain, Size: 63 bytes --] cdl_option CYGVAR_DEVS_ETH_ECOSYNTH_ETH0 { user_value 1 }; [-- Attachment #3: target.tdf --] [-- Type: text/plain, Size: 61 bytes --] synth_device ethernet { eth0 real eth1 logging 0 } [-- Attachment #4: pbufs.ecm --] [-- Type: text/plain, Size: 118 bytes --] cdl_option CYGNUM_LWIP_TCP_MSS { user_value 512 }; cdl_option CYGNUM_LWIP_PBUF_POOL_SIZE { user_value 64 }; ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: lwip 1.3.1 testing 2009-08-25 7:41 ` Simon Kallweit @ 2009-08-25 12:08 ` Sergei Gavrikov 2009-08-25 20:33 ` Sergei Gavrikov 2009-10-25 16:46 ` John Dallaway 1 sibling, 1 reply; 24+ messages in thread From: Sergei Gavrikov @ 2009-08-25 12:08 UTC (permalink / raw) To: Simon Kallweit; +Cc: ecos-devel On Tue, Aug 25, 2009 at 09:41:13AM +0200, Simon Kallweit wrote: > Hi > > I have done a new lwip test release with the following changes: > > * incorporated Sergei's patch (ctrl-c support) > * added an lwip_eth_simple and lwip_eth_sequential template > > The new test release can be downloaded from > http://download.westlicht.ch/lwip-20090825.tar.gz [snip] > Testing on real hardware would be especially useful. Also testing on > big-endian targets might reveal some issues, as I've only been testing > on little-endian platforms. Hi Simon, I'll retest new package ASAP. And it seems for me that you would get more volunteers if you will announce your nowadays work with those minimal setup instructions on the ecos-discuss list too. Thanks for a tip about the host's side setup for nc test, I will try it too. Sergei ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: lwip 1.3.1 testing 2009-08-25 12:08 ` Sergei Gavrikov @ 2009-08-25 20:33 ` Sergei Gavrikov 2009-08-26 6:38 ` Simon Kallweit 0 siblings, 1 reply; 24+ messages in thread From: Sergei Gavrikov @ 2009-08-25 20:33 UTC (permalink / raw) To: Simon Kallweit; +Cc: ecos-devel On Tue, Aug 25, 2009 at 03:08:20PM +0300, Sergei Gavrikov wrote: > On Tue, Aug 25, 2009 at 09:41:13AM +0200, Simon Kallweit wrote: > > Hi > > > > I have done a new lwip test release with the following changes: > > > > * incorporated Sergei's patch (ctrl-c support) > > * added an lwip_eth_simple and lwip_eth_sequential template > > > > The new test release can be downloaded from > > http://download.westlicht.ch/lwip-20090825.tar.gz > > [snip] > > > Testing on real hardware would be especially useful. Also testing on > > big-endian targets might reveal some issues, as I've only been testing > > on little-endian platforms. > > Hi > > Simon, I'll retest new package ASAP. And it seems for me that you would > get more volunteers if you will announce your nowadays work with those > minimal setup instructions on the ecos-discuss list too. Thanks for a > tip about the host's side setup for nc test, I will try it too. I retried nc master/slave test with your template and suggested pbuf values. For synthetic (I used tap interface) I got good results with lwIP, but, for real target, nc test passed for 100% master load and no load of slave side only. I got about 2Mbits per second with the DM900 Ethernet driver (that driver is too slow, it uses memcpy() on every 4 bytes arrived or sent), and my board gives only about 15 VAX Mips for RAM startup, and it seemed for me that was normal result. For small TCP packets ("y\n"), I had got good results yes | socat - tcp4:<board_ip>:7 ;# some stress tcp stream "tcpecho" test did return "y" very long time, until I did break pipe (^C). Unfortunately, I could not manage "udpecho" using socat as above neither for synthetic nor real hardware. So, my today score for lwIP 1.3.1 is + http_simple + http_sequential + ns_slave_test + tcpecho - udpecho What was your way to test "udpecho"? Thanks, regards, Sergei ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: lwip 1.3.1 testing 2009-08-25 20:33 ` Sergei Gavrikov @ 2009-08-26 6:38 ` Simon Kallweit 2009-08-26 8:43 ` Sergei Gavrikov 2009-08-26 20:46 ` Sergei Gavrikov 0 siblings, 2 replies; 24+ messages in thread From: Simon Kallweit @ 2009-08-26 6:38 UTC (permalink / raw) To: Sergei Gavrikov; +Cc: ecos-devel Sergei Gavrikov wrote: > On Tue, Aug 25, 2009 at 03:08:20PM +0300, Sergei Gavrikov wrote: >> On Tue, Aug 25, 2009 at 09:41:13AM +0200, Simon Kallweit wrote: >>> Hi >>> >>> I have done a new lwip test release with the following changes: >>> >>> * incorporated Sergei's patch (ctrl-c support) >>> * added an lwip_eth_simple and lwip_eth_sequential template >>> >>> The new test release can be downloaded from >>> http://download.westlicht.ch/lwip-20090825.tar.gz >> [snip] >> >>> Testing on real hardware would be especially useful. Also testing on >>> big-endian targets might reveal some issues, as I've only been testing >>> on little-endian platforms. >> Hi >> >> Simon, I'll retest new package ASAP. And it seems for me that you would >> get more volunteers if you will announce your nowadays work with those >> minimal setup instructions on the ecos-discuss list too. Thanks for a >> tip about the host's side setup for nc test, I will try it too. > > I retried nc master/slave test with your template and suggested pbuf > values. For synthetic (I used tap interface) I got good results with > lwIP, but, for real target, nc test passed for 100% master load and no > load of slave side only. I got about 2Mbits per second with the DM900 > Ethernet driver (that driver is too slow, it uses memcpy() on every 4 > bytes arrived or sent), and my board gives only about 15 VAX Mips for > RAM startup, and it seemed for me that was normal result. Did you use the old lwip port on that board too? Did you get similar results in performance? > For small TCP packets ("y\n"), I had got good results > > yes | socat - tcp4:<board_ip>:7 ;# some stress tcp stream > > "tcpecho" test did return "y" very long time, until I did break pipe > (^C). > > Unfortunately, I could not manage "udpecho" using socat as above neither > for synthetic nor real hardware. So, my today score for lwIP 1.3.1 is > > + http_simple > + http_sequential > + ns_slave_test > + tcpecho > - udpecho > > What was your way to test "udpecho"? I used nc (netcat) to send/receive UDP packets. But I did no stress testing with tcpecho, udpecho. Simon ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: lwip 1.3.1 testing 2009-08-26 6:38 ` Simon Kallweit @ 2009-08-26 8:43 ` Sergei Gavrikov 2009-08-26 20:46 ` Sergei Gavrikov 1 sibling, 0 replies; 24+ messages in thread From: Sergei Gavrikov @ 2009-08-26 8:43 UTC (permalink / raw) To: Simon Kallweit; +Cc: ecos-devel On Wed, Aug 26, 2009 at 08:38:42AM +0200, Simon Kallweit wrote: > Sergei Gavrikov wrote: >> I retried nc master/slave test with your template and suggested pbuf >> values. For synthetic (I used tap interface) I got good results with >> lwIP, but, for real target, nc test passed for 100% master load and no >> load of slave side only. I got about 2Mbits per second with the DM900 >> Ethernet driver (that driver is too slow, it uses memcpy() on every 4 >> bytes arrived or sent), and my board gives only about 15 VAX Mips for ^^^^^^^^^^^ I checked, I got 11 Mips on the board. >> RAM startup, and it seemed for me that was normal result. > > Did you use the old lwip port on that board too? Did you get similar > results in performance? Unfortunately, it is not possible run old nc_test_slave from the box, because it depends on SO_REUSE, and we cannot manage SO_REUSE from CDL, more that, if we force it, we'll get error include/lwip/opt.h:353 Well, I forced SO_REUSE=1 and built the test. I did not noticed that I got more Mbits with old lwip. The packets out of sequence often, but, at the least the slave side was responsible with a loading. FYI old "udpecho" is responsible on (while : ; do echo `date`; sleep 1; done)|nc -u -4 <board_ip> 7 and (while : ; do echo `date`; sleep 1; done)|socat - udp4:<board_ip>:7 but could not manage stress "yes|". old "tcpecho" could answer on stress "yes". Simon, thanks for the feedback and the port. It will be interesting to know other results from other sources (hardware). Regards, Sergei ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: lwip 1.3.1 testing 2009-08-26 6:38 ` Simon Kallweit 2009-08-26 8:43 ` Sergei Gavrikov @ 2009-08-26 20:46 ` Sergei Gavrikov 2009-08-27 7:17 ` Simon Kallweit 1 sibling, 1 reply; 24+ messages in thread From: Sergei Gavrikov @ 2009-08-26 20:46 UTC (permalink / raw) To: Simon Kallweit; +Cc: ecos-devel [-- Attachment #1: Type: text/plain, Size: 842 bytes --] On Wed, Aug 26, 2009 at 08:38:42AM +0200, Simon Kallweit wrote: > Sergei Gavrikov wrote: >> On Tue, Aug 25, 2009 at 03:08:20PM +0300, Sergei Gavrikov wrote: >>> On Tue, Aug 25, 2009 at 09:41:13AM +0200, Simon Kallweit wrote: >>>> Hi >>>> >>>> I have done a new lwip test release with the following changes: >>>> >>>> * incorporated Sergei's patch (ctrl-c support) >>>> * added an lwip_eth_simple and lwip_eth_sequential template >>>> >>>> The new test release can be downloaded from >>>> http://download.westlicht.ch/lwip-20090825.tar.gz Hi Simon, ya 2 cents. I found that the eth_tread's stack size is redefined in sequential.c:101. First, that stack size is defined in the package's header via CDL option. It seems the redefinition in sequetial.c can be quite removed, otherwise the CDL value (eth stack size) wont be applied. Sergei [-- Attachment #2: sequential.c.patch --] [-- Type: text/x-diff, Size: 481 bytes --] diff -r bed5605f7e6d net/lwip_tcpip/current/src/ecos/sequential.c --- a/net/lwip_tcpip/current/src/ecos/sequential.c Tue Aug 25 18:32:48 2009 +0300 +++ b/net/lwip_tcpip/current/src/ecos/sequential.c Wed Aug 26 23:28:54 2009 +0300 @@ -98,8 +98,6 @@ CYG_HAL_TABLE_BEGIN(__NETDEVTAB__, netdev); CYG_HAL_TABLE_END(__NETDEVTAB_END__, netdev); -#define ETH_THREAD_STACK_SIZE CYGNUM_HAL_STACK_SIZE_TYPICAL - static sys_thread_t eth_thread_handle; static cyg_sem_t eth_thread_sem; ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: lwip 1.3.1 testing 2009-08-26 20:46 ` Sergei Gavrikov @ 2009-08-27 7:17 ` Simon Kallweit 2009-08-27 8:03 ` Sergei Gavrikov 0 siblings, 1 reply; 24+ messages in thread From: Simon Kallweit @ 2009-08-27 7:17 UTC (permalink / raw) To: Sergei Gavrikov; +Cc: ecos-devel Sergei Gavrikov wrote: > On Wed, Aug 26, 2009 at 08:38:42AM +0200, Simon Kallweit wrote: >> Sergei Gavrikov wrote: >>> On Tue, Aug 25, 2009 at 03:08:20PM +0300, Sergei Gavrikov wrote: >>>> On Tue, Aug 25, 2009 at 09:41:13AM +0200, Simon Kallweit wrote: >>>>> Hi >>>>> >>>>> I have done a new lwip test release with the following changes: >>>>> >>>>> * incorporated Sergei's patch (ctrl-c support) >>>>> * added an lwip_eth_simple and lwip_eth_sequential template >>>>> >>>>> The new test release can be downloaded from >>>>> http://download.westlicht.ch/lwip-20090825.tar.gz > > Hi > > Simon, ya 2 cents. I found that the eth_tread's stack size is redefined > in sequential.c:101. First, that stack size is defined in the package's > header via CDL option. It seems the redefinition in sequetial.c can be > quite removed, otherwise the CDL value (eth stack size) wont be applied. That was some left-over. The real define is ETH_THREAD_STACKSIZE not ETH_THREAD_STACK_SIZE. So it actually did not have any effect. Thanks for the hint! In the meantime I have successfully committed my SLIP polling support to the lwip CVS, so it will be included in 1.4. I have also updated my port with these now official changes and did some testing. The new release: http://download.westlicht.ch/lwip-20090827.tar.gz Now I need to sort out PPP. Simon ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: lwip 1.3.1 testing 2009-08-27 7:17 ` Simon Kallweit @ 2009-08-27 8:03 ` Sergei Gavrikov 0 siblings, 0 replies; 24+ messages in thread From: Sergei Gavrikov @ 2009-08-27 8:03 UTC (permalink / raw) To: Simon Kallweit; +Cc: ecos-devel On Thu, Aug 27, 2009 at 09:18:23AM +0200, Simon Kallweit wrote: > In the meantime I have successfully committed my SLIP polling support to > the lwip CVS, so it will be included in 1.4. I have also updated my port > with these now official changes and did some testing. The new release: > > http://download.westlicht.ch/lwip-20090827.tar.gz Thank you! I will try SLIP tonight on my target. Sergei > > Now I need to sort out PPP. > > Simon > > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: lwip 1.3.1 testing 2009-08-25 7:41 ` Simon Kallweit 2009-08-25 12:08 ` Sergei Gavrikov @ 2009-10-25 16:46 ` John Dallaway 2009-10-26 13:00 ` Simon Kallweit 1 sibling, 1 reply; 24+ messages in thread From: John Dallaway @ 2009-10-25 16:46 UTC (permalink / raw) To: Simon Kallweit; +Cc: ecos-devel Hi Simon Simon Kallweit wrote: > Testing on real hardware would be especially useful. Also testing on > big-endian targets might reveal some issues, as I've only been testing > on little-endian platforms. Using your sources from lwip-20090827.tar.gz, I was able to build and run the httpd_simple test on a PowerPC (big-endian) target OK. DHCP over ethernet was also OK. The lwIP CDL script currently builds ecos/sio.c unconditionally so CYGPKG_IO_SERIAL is required even when both PPP and SLIP are disabled. It would be good to compile ecos/sio.c via a CDL option which is "calculated { CYGPKG_LWIP_PPP || CYGPKG_LWIP_SLIP }" if other source code will permit this. Some other source code files which look like they might benefit from conditional compilation: ecos/ppp.c ecos/sequential.c ecos/simple.c netif/slipif.c How is you own testing of lwIP 1.3.1 progressing? John Dallaway ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: lwip 1.3.1 testing 2009-10-25 16:46 ` John Dallaway @ 2009-10-26 13:00 ` Simon Kallweit 2009-10-26 13:54 ` John Dallaway 0 siblings, 1 reply; 24+ messages in thread From: Simon Kallweit @ 2009-10-26 13:00 UTC (permalink / raw) To: John Dallaway; +Cc: ecos-devel John Dallaway wrote: > Hi Simon > > Simon Kallweit wrote: > >> Testing on real hardware would be especially useful. Also testing on >> big-endian targets might reveal some issues, as I've only been testing >> on little-endian platforms. > > Using your sources from lwip-20090827.tar.gz, I was able to build and > run the httpd_simple test on a PowerPC (big-endian) target OK. DHCP over > ethernet was also OK. That's good to hear. > The lwIP CDL script currently builds ecos/sio.c unconditionally so > CYGPKG_IO_SERIAL is required even when both PPP and SLIP are disabled. > It would be good to compile ecos/sio.c via a CDL option which is > "calculated { CYGPKG_LWIP_PPP || CYGPKG_LWIP_SLIP }" if other source > code will permit this. sio.c is always compiled, but there is an #ifdef which includes the code only when either CYGPKG_LWIP_SLIP or CYGFUN_LWIP_PPPOS_SUPPORT is active. Also, CYGPKG_IO_SERIAL_DEVICES is only enabled if either SLIP or PPPoS support is enabled. Do you think solving that dependency in CDL is the better approach? > Some other source code files which look like they might benefit from > conditional compilation: > > ecos/ppp.c ecos/sequential.c ecos/simple.c netif/slipif.c Same principles apply here. > How is you own testing of lwIP 1.3.1 progressing? Well, I'm currently using devices with lwIP 1.3.1 in field tests. They run in the 'simple' mode (single-threaded) and use PPP for GPRS connections via a GSM modem. I have not seen any issues with the current port. The devices run for days until they may be power-cycled for updates or maintenance. Application development is done on the synthetic target, using a simulated GSM modem, simulating GPRS connections by spawning a local PPP server. No issues have occurred with this configuration either, although runtimes are usually only minutes to hours. Simon ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: lwip 1.3.1 testing 2009-10-26 13:00 ` Simon Kallweit @ 2009-10-26 13:54 ` John Dallaway 2009-10-26 14:29 ` Simon Kallweit 0 siblings, 1 reply; 24+ messages in thread From: John Dallaway @ 2009-10-26 13:54 UTC (permalink / raw) To: Simon Kallweit; +Cc: ecos-devel Hi Simon Simon Kallweit wrote: >> The lwIP CDL script currently builds ecos/sio.c unconditionally so >> CYGPKG_IO_SERIAL is required even when both PPP and SLIP are disabled. >> It would be good to compile ecos/sio.c via a CDL option which is >> "calculated { CYGPKG_LWIP_PPP || CYGPKG_LWIP_SLIP }" if other source >> code will permit this. > > sio.c is always compiled, but there is an #ifdef which includes the code > only when either CYGPKG_LWIP_SLIP or CYGFUN_LWIP_PPPOS_SUPPORT is > active. Also, CYGPKG_IO_SERIAL_DEVICES is only enabled if either SLIP or > PPPoS support is enabled. Do you think solving that dependency in CDL is > the better approach? OK, it seems that this issue has already been resolved. I was looking at a slightly older revision of sio.c. As a general rule, it's preferable to compile only those source code files which are needed. Clearly the most important thing is to ensure that the resulting binaries are not bloated with unused code/data. >> How is you own testing of lwIP 1.3.1 progressing? > > Well, I'm currently using devices with lwIP 1.3.1 in field tests. They > run in the 'simple' mode (single-threaded) and use PPP for GPRS > connections via a GSM modem. I have not seen any issues with the current > port. The devices run for days until they may be power-cycled for > updates or maintenance. > > Application development is done on the synthetic target, using a > simulated GSM modem, simulating GPRS connections by spawning a local PPP > server. No issues have occurred with this configuration either, although > runtimes are usually only minutes to hours. So I think we should roll this out to eCos CVS soon. This will help with further testing coverage. One minor point: It would be very useful for the stack to report its own IP address on the diagnostic channel. John Dallaway ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: lwip 1.3.1 testing 2009-10-26 13:54 ` John Dallaway @ 2009-10-26 14:29 ` Simon Kallweit 2009-10-26 17:13 ` John Dallaway 0 siblings, 1 reply; 24+ messages in thread From: Simon Kallweit @ 2009-10-26 14:29 UTC (permalink / raw) To: John Dallaway; +Cc: ecos-devel John Dallaway wrote: > Hi Simon > > Simon Kallweit wrote: > >>> The lwIP CDL script currently builds ecos/sio.c unconditionally so >>> CYGPKG_IO_SERIAL is required even when both PPP and SLIP are disabled. >>> It would be good to compile ecos/sio.c via a CDL option which is >>> "calculated { CYGPKG_LWIP_PPP || CYGPKG_LWIP_SLIP }" if other source >>> code will permit this. >> sio.c is always compiled, but there is an #ifdef which includes the code >> only when either CYGPKG_LWIP_SLIP or CYGFUN_LWIP_PPPOS_SUPPORT is >> active. Also, CYGPKG_IO_SERIAL_DEVICES is only enabled if either SLIP or >> PPPoS support is enabled. Do you think solving that dependency in CDL is >> the better approach? > > OK, it seems that this issue has already been resolved. I was looking at > a slightly older revision of sio.c. As a general rule, it's preferable > to compile only those source code files which are needed. Clearly the > most important thing is to ensure that the resulting binaries are not > bloated with unused code/data. I can still change that. I just wonder what's the best approach here. Currently there is an option CYGIMP_LWIP_MODE which lets the user select "Simple" or "Sequential" mode. Should I remove this option in favor of two mutually exclusive components so I can only compile the simple.c or sequential.c? I can also create two pseudo components which are calculated by CYGIMP_LWIP_MODE == "Simple/Sequential" to compile the respective file, but this will introduce bloat in the configuration tool. The same applies to sio. I can add a new package CYGPKG_LWIP_SIO which is required by both PPPoS and SLIPIF. I think the best place would be the "APIs" section as the SIO may be also used for other purposes than lwIP's internal. So a user could enable sio without using SLIPIF or PPPoS. What do you think? >>> How is you own testing of lwIP 1.3.1 progressing? >> Well, I'm currently using devices with lwIP 1.3.1 in field tests. They >> run in the 'simple' mode (single-threaded) and use PPP for GPRS >> connections via a GSM modem. I have not seen any issues with the current >> port. The devices run for days until they may be power-cycled for >> updates or maintenance. >> >> Application development is done on the synthetic target, using a >> simulated GSM modem, simulating GPRS connections by spawning a local PPP >> server. No issues have occurred with this configuration either, although >> runtimes are usually only minutes to hours. > > So I think we should roll this out to eCos CVS soon. This will help with > further testing coverage. There is still one area which needs cleanup, PPP :/ I'm still not sure what we're going to do with that. I need single-thread support for PPP in my applications, but unfortunately this breaks multi-thread support and adds code changes which are not currently in the lwIP tree. Best would be to go with the current lwIP code, but this is also broken in places! And I currently don't have much time to sort this out properly. > One minor point: It would be very useful for the stack to report its own > IP address on the diagnostic channel. I'll try to implement this. I guess you're mainly talking about DHCP IPs right? Simon ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: lwip 1.3.1 testing 2009-10-26 14:29 ` Simon Kallweit @ 2009-10-26 17:13 ` John Dallaway 2009-10-27 13:06 ` Simon Kallweit 0 siblings, 1 reply; 24+ messages in thread From: John Dallaway @ 2009-10-26 17:13 UTC (permalink / raw) To: Simon Kallweit; +Cc: ecos-devel Hi Simon Simon Kallweit wrote: > John Dallaway wrote: >> Hi Simon >> >> Simon Kallweit wrote: >> >>>> The lwIP CDL script currently builds ecos/sio.c unconditionally so >>>> CYGPKG_IO_SERIAL is required even when both PPP and SLIP are disabled. >>>> It would be good to compile ecos/sio.c via a CDL option which is >>>> "calculated { CYGPKG_LWIP_PPP || CYGPKG_LWIP_SLIP }" if other source >>>> code will permit this. >>> >>> sio.c is always compiled, but there is an #ifdef which includes the code >>> only when either CYGPKG_LWIP_SLIP or CYGFUN_LWIP_PPPOS_SUPPORT is >>> active. Also, CYGPKG_IO_SERIAL_DEVICES is only enabled if either SLIP or >>> PPPoS support is enabled. Do you think solving that dependency in CDL is >>> the better approach? >> >> OK, it seems that this issue has already been resolved. I was looking at >> a slightly older revision of sio.c. As a general rule, it's preferable >> to compile only those source code files which are needed. Clearly the >> most important thing is to ensure that the resulting binaries are not >> bloated with unused code/data. > > I can still change that. I just wonder what's the best approach here. > Currently there is an option CYGIMP_LWIP_MODE which lets the user select > "Simple" or "Sequential" mode. Should I remove this option in favor of > two mutually exclusive components so I can only compile the simple.c or > sequential.c? I can also create two pseudo components which are > calculated by CYGIMP_LWIP_MODE == "Simple/Sequential" to compile the > respective file, but this will introduce bloat in the configuration tool. I would recommend a "radio button" approach for mutually exclusive modes which have associated source files. Something like: cdl_interface CYGINT_LWIP_MODES { display "Enabled lwIP modes" no_define requires 1 == CYGINT_LWIP_MODES description "This interface is used to force mutually exclusive selection of the available lwIP modes." } cdl_option CYGFUN_LWIP_MODE_SIMPLE { display "Simple mode" implements CYGINT_LWIP_MODES compile ecos/simple.c } cdl_option CYGFUN_LWIP_MODE_SEQUENTIAL { display "Sequential mode" implements CYGINT_LWIP_MODES compile ecos/sequential.c } > The same applies to sio. I can add a new package CYGPKG_LWIP_SIO which > is required by both PPPoS and SLIPIF. I think the best place would be > the "APIs" section as the SIO may be also used for other purposes than > lwIP's internal. So a user could enable sio without using SLIPIF or PPPoS. It would be best to use another CDL interface to enable compilation of this code. Something like: cdl_interface CYGINT_LWIP_SIO_REQUIRED { no_define display "Items requiring lwIP serial operations" description "Items requiring use of the lwIP serial operations code should implement this interface." } cdl_option CYGFUN_LWIP_SIO { display "Serial operations support" calculated { CYGINT_LWIP_SIO_REQUIRED > 0 } compile ecos/sio.c } cdl_component CYGPKG_LWIP_SLIP { implements CYGINT_LWIP_SIO_REQUIRED compile ... ... } cdl_component CYGPKG_LWIP_PPP { implements CYGINT_LWIP_SIO_REQUIRED compile ... ... } This is a little more complicated than a simple "requires CYGFUN_LWIP_SIO" but ensures that CYGFUN_LWIP_SIO becomes disabled when the number of components requiring it falls to zero. >>>> How is you own testing of lwIP 1.3.1 progressing? >>> Well, I'm currently using devices with lwIP 1.3.1 in field tests. They >>> run in the 'simple' mode (single-threaded) and use PPP for GPRS >>> connections via a GSM modem. I have not seen any issues with the current >>> port. The devices run for days until they may be power-cycled for >>> updates or maintenance. >>> >>> Application development is done on the synthetic target, using a >>> simulated GSM modem, simulating GPRS connections by spawning a local PPP >>> server. No issues have occurred with this configuration either, although >>> runtimes are usually only minutes to hours. >> >> So I think we should roll this out to eCos CVS soon. This will help with >> further testing coverage. > > There is still one area which needs cleanup, PPP :/ I'm still not sure > what we're going to do with that. I need single-thread support for PPP > in my applications, but unfortunately this breaks multi-thread support > and adds code changes which are not currently in the lwIP tree. Best > would be to go with the current lwIP code, but this is also broken in > places! And I currently don't have much time to sort this out properly. I thought we had concluded that we should treat lwIP PPP as a separate project which would require liaison with the upstream lwIP maintainer(s). Is there anyone else in the eCos community who is able and willing to work on this? >> One minor point: It would be very useful for the stack to report its own >> IP address on the diagnostic channel. > > I'll try to implement this. I guess you're mainly talking about DHCP IPs > right? Yes, although it might sometimes also be helpful to confirm a static IP address. John Dallaway ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: lwip 1.3.1 testing 2009-10-26 17:13 ` John Dallaway @ 2009-10-27 13:06 ` Simon Kallweit 2009-11-20 10:24 ` John Dallaway 0 siblings, 1 reply; 24+ messages in thread From: Simon Kallweit @ 2009-10-27 13:06 UTC (permalink / raw) To: John Dallaway; +Cc: ecos-devel John Dallaway wrote: > I would recommend a "radio button" approach for mutually exclusive modes > which have associated source files. Something like: > > cdl_interface CYGINT_LWIP_MODES { > display "Enabled lwIP modes" > no_define > requires 1 == CYGINT_LWIP_MODES > description "This interface is used to force mutually exclusive > selection of the available lwIP modes." > } > cdl_option CYGFUN_LWIP_MODE_SIMPLE { > display "Simple mode" > implements CYGINT_LWIP_MODES > compile ecos/simple.c > } > cdl_option CYGFUN_LWIP_MODE_SEQUENTIAL { > display "Sequential mode" > implements CYGINT_LWIP_MODES > compile ecos/sequential.c > } > >> The same applies to sio. I can add a new package CYGPKG_LWIP_SIO which >> is required by both PPPoS and SLIPIF. I think the best place would be >> the "APIs" section as the SIO may be also used for other purposes than >> lwIP's internal. So a user could enable sio without using SLIPIF or PPPoS. > > It would be best to use another CDL interface to enable compilation of > this code. Something like: > > cdl_interface CYGINT_LWIP_SIO_REQUIRED { > no_define > display "Items requiring lwIP serial operations" > description "Items requiring use of the lwIP serial operations code > should implement this interface." > } > cdl_option CYGFUN_LWIP_SIO { > display "Serial operations support" > calculated { CYGINT_LWIP_SIO_REQUIRED > 0 } > compile ecos/sio.c > } > cdl_component CYGPKG_LWIP_SLIP { > implements CYGINT_LWIP_SIO_REQUIRED > compile ... > ... > } > cdl_component CYGPKG_LWIP_PPP { > implements CYGINT_LWIP_SIO_REQUIRED > compile ... > ... > } > > This is a little more complicated than a simple "requires > CYGFUN_LWIP_SIO" but ensures that CYGFUN_LWIP_SIO becomes disabled when > the number of components requiring it falls to zero. I have adapted to CDL to reflect your recommendations. The new version can be fetched from http://download.westlicht.ch/lwip-20091027.tar.gz > I thought we had concluded that we should treat lwIP PPP as a separate > project which would require liaison with the upstream lwIP > maintainer(s). Is there anyone else in the eCos community who is able > and willing to work on this? True. I just wanted to point out that in it's current state PPP can only be used with simple mode. >>> One minor point: It would be very useful for the stack to report its own >>> IP address on the diagnostic channel. >> I'll try to implement this. I guess you're mainly talking about DHCP IPs >> right? > > Yes, although it might sometimes also be helpful to confirm a static IP > address. I have implemented reporting of the netif configuration for both static configuration and DHCP on the interfaces loopif, slipif and eth. This is configurable by CYGFUN_LWIP_SHOW_NETIF_CONFIG which is now enabled by default. Simon ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: lwip 1.3.1 testing 2009-10-27 13:06 ` Simon Kallweit @ 2009-11-20 10:24 ` John Dallaway 2009-12-07 13:41 ` Simon Kallweit 0 siblings, 1 reply; 24+ messages in thread From: John Dallaway @ 2009-11-20 10:24 UTC (permalink / raw) To: Simon Kallweit; +Cc: ecos-devel Hi Simon Simon Kallweit wrote: >>>> One minor point: It would be very useful for the stack to report its >>>> own IP address on the diagnostic channel. >>> >>> I'll try to implement this. I guess you're mainly talking about DHCP IPs >>> right? >> >> Yes, although it might sometimes also be helpful to confirm a static IP >> address. > > I have implemented reporting of the netif configuration for both static > configuration and DHCP on the interfaces loopif, slipif and eth. This is > configurable by CYGFUN_LWIP_SHOW_NETIF_CONFIG which is now enabled by > default. Excellent. I would like to push through with final review and get your lwIP port checked in to CVS, replacing the existing lwIP 1.1.1 port. Is lwip-20091027.tar.gz still current or do you have further changes? Should I be comparing your package with the upstream lwIP 1.3.1 sources or is it now closer to lwIP 1.3.2 RC1? John Dallaway eCos maintainer ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: lwip 1.3.1 testing 2009-11-20 10:24 ` John Dallaway @ 2009-12-07 13:41 ` Simon Kallweit 2009-12-17 10:45 ` John Dallaway 2010-01-19 12:07 ` John Dallaway 0 siblings, 2 replies; 24+ messages in thread From: Simon Kallweit @ 2009-12-07 13:41 UTC (permalink / raw) To: John Dallaway; +Cc: ecos-devel John Dallaway wrote: > Hi Simon > > Simon Kallweit wrote: > >>>>> One minor point: It would be very useful for the stack to report its >>>>> own IP address on the diagnostic channel. >>>> I'll try to implement this. I guess you're mainly talking about DHCP IPs >>>> right? >>> Yes, although it might sometimes also be helpful to confirm a static IP >>> address. >> I have implemented reporting of the netif configuration for both static >> configuration and DHCP on the interfaces loopif, slipif and eth. This is >> configurable by CYGFUN_LWIP_SHOW_NETIF_CONFIG which is now enabled by >> default. > > Excellent. I would like to push through with final review and get your > lwIP port checked in to CVS, replacing the existing lwIP 1.1.1 port. Is > lwip-20091027.tar.gz still current or do you have further changes? > Should I be comparing your package with the upstream lwIP 1.3.1 sources > or is it now closer to lwIP 1.3.2 RC1? Sorry for the late answer, I have been on holidays. I think we should wait a few days for the lwIP 1.3.2 release. I'll merge the changes and do a few tests so we have a good initial version for a CVS checkin. It seems that some work has been done on the PPP code as well. I'll see how it fits with my current port. Simon ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: lwip 1.3.1 testing 2009-12-07 13:41 ` Simon Kallweit @ 2009-12-17 10:45 ` John Dallaway 2010-01-19 12:07 ` John Dallaway 1 sibling, 0 replies; 24+ messages in thread From: John Dallaway @ 2009-12-17 10:45 UTC (permalink / raw) To: Simon Kallweit; +Cc: ecos-devel Hi Simon Simon Kallweit wrote: > John Dallaway wrote: > >> Excellent. I would like to push through with final review and get your >> lwIP port checked in to CVS, replacing the existing lwIP 1.1.1 port. Is >> lwip-20091027.tar.gz still current or do you have further changes? >> Should I be comparing your package with the upstream lwIP 1.3.1 sources >> or is it now closer to lwIP 1.3.2 RC1? > > Sorry for the late answer, I have been on holidays. I think we should > wait a few days for the lwIP 1.3.2 release. I'll merge the changes and > do a few tests so we have a good initial version for a CVS checkin. It > seems that some work has been done on the PPP code as well. I'll see how > it fits with my current port. Great. It looks like lwIP 1.3.2 final will be released very soon now. John Dallaway eCos maintainer ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: lwip 1.3.1 testing 2009-12-07 13:41 ` Simon Kallweit 2009-12-17 10:45 ` John Dallaway @ 2010-01-19 12:07 ` John Dallaway 1 sibling, 0 replies; 24+ messages in thread From: John Dallaway @ 2010-01-19 12:07 UTC (permalink / raw) To: Simon Kallweit; +Cc: eCos development list Hi Simon Simon Kallweit wrote: > John Dallaway wrote: > >> Excellent. I would like to push through with final review and get your >> lwIP port checked in to CVS, replacing the existing lwIP 1.1.1 port. Is >> lwip-20091027.tar.gz still current or do you have further changes? >> Should I be comparing your package with the upstream lwIP 1.3.1 sources >> or is it now closer to lwIP 1.3.2 RC1? > > Sorry for the late answer, I have been on holidays. I think we should > wait a few days for the lwIP 1.3.2 release. I'll merge the changes and > do a few tests so we have a good initial version for a CVS checkin. It > seems that some work has been done on the PPP code as well. I'll see how > it fits with my current port. I've just noticed a new tarball lwip-20091224.tar.gz on your site. Were you intending to do any further work on this in the immediate future or shall we work towards an initial check-in of your port based on this tarball? John Dallaway eCos maintainer ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2010-01-19 12:07 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-08-21 7:11 lwip 1.3.1 testing Simon Kallweit 2009-08-21 7:43 ` John Dallaway 2009-08-21 9:12 ` Edgar Grimberg 2009-08-21 18:43 ` Sergei Gavrikov 2009-08-24 20:18 ` Sergei Gavrikov 2009-08-25 6:09 ` Simon Kallweit 2009-08-25 7:41 ` Simon Kallweit 2009-08-25 12:08 ` Sergei Gavrikov 2009-08-25 20:33 ` Sergei Gavrikov 2009-08-26 6:38 ` Simon Kallweit 2009-08-26 8:43 ` Sergei Gavrikov 2009-08-26 20:46 ` Sergei Gavrikov 2009-08-27 7:17 ` Simon Kallweit 2009-08-27 8:03 ` Sergei Gavrikov 2009-10-25 16:46 ` John Dallaway 2009-10-26 13:00 ` Simon Kallweit 2009-10-26 13:54 ` John Dallaway 2009-10-26 14:29 ` Simon Kallweit 2009-10-26 17:13 ` John Dallaway 2009-10-27 13:06 ` Simon Kallweit 2009-11-20 10:24 ` John Dallaway 2009-12-07 13:41 ` Simon Kallweit 2009-12-17 10:45 ` John Dallaway 2010-01-19 12:07 ` John Dallaway
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).