[lwip-users] Default AVR32 framework LwIP input path
Hi,
Here is what the
lwip-port/AT32UC3A/netif/ethernetif.c::ethernetif_input() function from
the AVR32-SoftwareFramework-1.0.0-AT32AP7000 looks like:
static void ethernetif_input(void * pvParameters) {
-wait for macb and loop packet input, not important- {
if( ERR_OK != ethernet_input( p, netif ) ) {
-free, ..., not important-
}
}
}
And netif_add() is:
netif_add(MACB_if, xIpAddr, xNetMask, xGateway, NULL,
ethernetif_init, tcpip_input);
Experimental CORE/INPUT locking is not enabled and this is obviously
running all the input path out of the LwIP thread. I am wrong saying
that this is just defective by design and MUST be replaced by
netif-input(p, netif) which calls tcpip_input() and put the packet on
the packet input box ?
Regards,
Sylvain
signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Default AVR32 framework LwIP input path
Hi,
On Fri, Apr 27, 2012 at 04:23:11PM +0200, Simon Goldschmidt wrote:
Sylvain Rochet grada...@gradator.net wrote:
lwip-port/AT32UC3A/netif/ethernetif.c::ethernetif_input() function from
the AVR32-SoftwareFramework-1.0.0-AT32AP7000 looks like:
static void ethernetif_input(void * pvParameters) {
-wait for macb and loop packet input, not important- {
if( ERR_OK != ethernet_input( p, netif ) ) {
-free, ..., not important-
[..]
I am wrong saying
that this is just defective by design and MUST be replaced by
netif-input(p, netif) which calls tcpip_input() and put the packet on
the packet input box ?
That looks indeed wrong (at least when using lwIP with NO_SYS==0,
which seems like what they do, seeing they pass 'tcpip_input' to
'netif_add) and your suggested fix (calling netif-input() instead of
ethernet_input()) is correct, yes.
Thanks for the confirmation.
So, for all of us using the Atmel AVR32 framework, we need to fix this
design bug which might send us into deep trouble :-)
By the way, I wrote a AVR32UC3 LwIP port working with the current LwIP
HEAD revision, what's the best way to contribute this one to the
community ?
Sylvain
signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Default AVR32 framework LwIP input path
Hi Cyrille, On Fri, Apr 27, 2012 at 06:13:32PM +0200, Boulanger, Cyrille wrote: Best is to check the online ASF bugzilla (asf.atmel.com/bugzilla). Btw I found this bug (http://asf.atmel.com/bugzilla/show_bug.cgi?id=959) This bugzilla seems to only really work for those actually working for Atmel :-) Host norvm-tools-m.norway.atmel.com not found: 3(NXDOMAIN) And links to related bugs almost always finish in You are not authorized to access bug #x.. (it's not the lwIP HEAD but it's probably closer to what was in the AVR32-SoftwareFramework-1.0.0-AT32AP7000 package). For the record, the faulty behavior about ethernet_input() is fixed in ASF(Atmel Software Framework) 3.0.1 (and probably some previous releases). Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Default AVR32 framework LwIP input path
Hi Kieran, On Fri, Apr 27, 2012 at 07:57:37PM +0100, Kieran Mansley wrote: On 27 Apr 2012, at 16:03, Sylvain Rochet wrote: By the way, I wrote a AVR32UC3 LwIP port working with the current LwIP HEAD revision, what's the best way to contribute this one to the community ? If you're willing to maintain it so that it works with CVS head as that moves on (i.e. keep the port up to date) then we can add it to the contrib module. Let me know if you're happy to do that and I'll arrange appropriate commit access for you. Yeah, I will be happy to do that, as long as I use AVR32UC3 target or having a EVK1100 demo board lying around :-) Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] SNTP Problem
Hi Nick,
On Sat, Apr 28, 2012 at 04:17:31PM +0300, N.Karakotas wrote:
Hi,
Im trying to update the time with SNTP but the timestamp received is
wrong. Then ctime printf rubbish. I also checked the received
timestamp is seems wrong. This is strange. I cant understand why its
not wornking. Any pointers?
What Wireshark says about those SNTP packets ?
Beware, NTP Era 0 origin is 1st Jan 1900 at midnight UTC, not 1970 like
the unix timestamp.
Here is what you need to do to convert from Unix to NTP timestamp:
/* NTP timestamp to UNIX timestamp
*
* NTP timestamp limits:
* - Era 0
* - Epoch is Jan 1 00:00:00 UTC 1900
* - Last value given 32 bits (4294967295) is Feb 7 06:28:15 UTC 2036
* - Era 1
* - Epoch is Feb 7 06:28:16 UTC 2036
* - Last value given 32 bits (4294967295) is Mar 15 12:56:31 UTC 2172
*
* Today is Jul 28 UTC 2011, Unix timestamp at midnight is 1311811200,
* NTP timestamp Era 0 at midnight is 352080
*
* NTP wrap coverage is 136 years, we don't except this product to live
* this long, we consider NTP values after 352080 as Era 0, and
* values before 352080 as Era 1
*
*/
datetime_t ntp_to_datetime_timestamp(ntpts ts) {
ts = 32; // We don't care about second fraction
// Era 0
// - NTP Timestamp 352080 to 4294967295
// - Jul 28 00:00:00 UTC 2011 to Feb 7 06:28:15 UTC 2036
// - UNIX Timestamp 1311811200 to 2085978495
if( ts = 352080UL )
return ts - 2208988800LL;
// Era 1
// - NTP Timestamp 0 to 352079
// - Feb 7 06:28:16 UTC 2036 to Sep 3 06:28:15 UTC 2147
// - Unix Timestamp 2085978496 to 5606778495
return ts + 2085978496LL;
}
/* UNIX timestamp to NTP timestamp
*
*/
ntpts datetime_to_ntp_timestamp(datetime_t dt) {
dt += 2208988800UL;
return dt32;
}
Sylvain
signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] LCP Termination Request steps
Hi, In fsm_rtermreq(), if f-state equals LS_OPENED, which is the Connection terminated by peer condition, we send a Termination Ack, which seems logical. But, in this case, we call TIMEOUT(fsm_timeout, ...), but we don't send any request at this time, what are we waiting for exactly ? With PPP_DEBUG, here is what I get, which seems to be a faulty behavior for me: pppoe: GENERIC ERROR: Shutting Down === OK!, we received a PADT, discarded because there was no Host-Uniq tag, so sc is NULL, maybe we should fallback to Session ID if Host-Uniq is absent, but this is not the subject now. pppoe_data_input: enu: pkthdr.len=0, pppoe.len=40 pppInput[0]: LCP len=38 fsm_input(LCP):5,3,38 fsm_rtermreq(LCP): Rcvd id 3 state=9 (LS_OPENED) LCP terminated by peer () link_down: 0 upap_lowerdown: 0 s=1 ipcp: down np_down: 0 proto=21 sifdown: unit 0: linkStatusCB= errCode=-2147471276 pppLinkStatusCallback: PPPERR_CONNECT IPCP: lowerdown state 9 (LS_OPENED) - 1 (LS_STARTING) IPCP: close reason=LCP down state 1 (LS_STARTING) - 0 (LS_INITIAL) pppLinkDown: unit 0 ppp_send_config[0]: outACCM=FF FF FF FF ppp_recv_config[0]: inACCM=0 0 0 0 pppoe: enu (0) state=34916, session=0x3 output - x:x:x:x:x:x, len=1 === OK!, we received a LCP Termination Request Packet, then we called upper layers functions so that we set the PPP session down. === We also called the PPPoE callback correctly. fsm_sdata(LCP): Sent code 6,3,4. pppInput[0]: packet processed === OK!, we ack'ed the Termination. Then, a few seconds later, due to the timeout set: LCP: timeout sending Terminate-Request state=5 (LS_STOPPING) link_terminated: 0 Connection terminated. pppLinkTerminated: unit 0 pppLinkTerminated: finished. pppoe: enu: timeout pppoe: enu: disconnecting pppHupCB: unit 0 link_required: 0 LCP: lowerdown state 3 (LS_STOPPED) - 1 (LS_STARTING) link_terminated: 0 pppStop: unit 0 LCP: close reason=User request state 1 (LS_STARTING) - 0 (LS_INITIAL) pppLinkStatusCallback: PPPERR_PROTOCOL === Of course we timeouted, we didn't sent any request. === And we consider this is a protocol error. Is this a bug in fsm.c ? Should we send a Termination Request as well ? Or is the timeout set by mistake ? Regards, Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi, On Mon, May 07, 2012 at 10:15:52PM +0200, goldsi...@gmx.de wrote: This is not really an answer to your post, rather a clarification about our PPP code in general: I know I have said this before and it sounds like a lame excuse, but the PPP code is not our own code - we just copied it from pppd (http://ppp.samba.org/) and adapted it to lwIP. Unfortunately, not many here know their way around it. One or two years ago, we took the effort to see which version of pppd our code relates to and we're pretty much on 2.3.11 with some bugs from 2.4.x backported (thanks to Ioardan Neshev!). Pppd have a well established codebase, this is probably not so hard to backport 2.4.5 or at least check the diff between all pppd releases, will try :-) There are some files that are different, however: - chpms.c/.h are named chap_ms.c/.h in the original pppd 2.3.11 sources - pap.c/.h are named upap.c/.h in the original pppd 2.3.11 sources - randm.c is a random generator not included in the original pppd - magic.c does not use the C library, but uses randm.c instead - vj.c/.h is an implementation of the Van Jacobson header compression algorithm adapted to lwIP pbufs, probably copied from one of the vjcompress.c files from pppd. - ppp.c, ppp.h and ppp_impl.h contain the adaption from pppd to lwIP. This is the OS-dependent part like there is an implementation for linux, xBSD etc. in the pppd sources. - ppp_oe.c is Marc Boucher's implementation based on NetBSD's if_pppoe.c There is of course potential for bugs in it, but when analyzing of reporting bugs, it is strongly encouraged to compare the code in question to pppd 2.3.11 (our basis) and newer versions (perhaps it's already fixed?) and to share this knowledge with us when reporting a bug. Yeah, will do. Being like that, aside from bugs that are already fixed in 2.4.x and bugs we made while adapting the sources, most of the bugs will be found in ppp.c (lwIP specific code) and ppp_oe.c (i.e. in its interaction with ppp.c - due to the fact that this is now a mix between BSD PPP code and pppd). Well, but pppd is forked per connection, so it probably don't really care how it ends, I guess the original pppd code does not handle the termination perfectly, as it always finish with an exit() somewhere. A bug in fsm.c is a thing I really can't comment on: I'm simply not an expert in ppp to help you there, Sorry :-( No worry ;-), I will investigate this more. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
[lwip-users] Git URL for lwip-contribs
Hi, Probably a dumb question, but how can we fetch the lwIP contrib Git ? I saw one commit on it but failed to find the related Git URL. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Git URL for lwip-contribs
Hi, On Fri, May 11, 2012 at 11:08:47PM +0200, goldsi...@gmx.de wrote: [...], the link to the contrib rep vanished from the website when we moved from CVS to git. Also, we haven't found a volunteer to update the landing site on savannah to provide more useful information than right now, which could also include: http://git.savannah.gnu.org/cgit/lwip/lwip-contrib.git Based on that, for those who wonder, git clone procedure is: git clone git://git.savannah.nongnu.org/lwip/lwip-contrib.git Thanks! Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Kieran, On Mon, May 14, 2012 at 05:20:22PM +0100, Kieran Mansley wrote: On Mon, 2012-05-07 at 23:10 +0200, Sylvain Rochet wrote: Pppd have a well established codebase, this is probably not so hard to backport 2.4.5 or at least check the diff between all pppd releases, will try :-) If anyone wants to help maintain the PPP code they would be very welcome! I started porting PPPd 2.4.5 to lwIP this week-end. With additional patchs fetched from Debian, as PPPd is a dead project since 2009. I got some grey hair, I agree, but it works ! Well, it only works with PPPoE at the moment, because this is easy to test with the unix port. I still have to find a way to test PPPoS, which require a SIO somewhere, maybe I will do a unix SIO port, this seems easier than using a takes-minutes-to-flash-and-hard-to-debug uC. However, it works, but this is not sufficient for lwIP, a lot of code is still using the Linux basement, and should be evicted before any patch. I am going to push this port in production where I work, with a remote flash boot loader so that I will be able to fix all the bugs I added, being a very good bugs provider :-) But the way, all the strangeness I found in the current PPPd port included in lwIP are fixed the way I thought in the latest PPPd, which is a good news ! Also, with PPPd 2.4.5, PPP + IPv6 support is on its way, as well as new authentification methods. And maybe we could add in the future L2TP support, allowing lwIP users to do PPP tunnels behing NAT using UDP as a transport protocol. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Nick, On Mon, May 14, 2012 at 08:37:18PM +0300, N.Karakotas wrote: Hi, I can help you to debug the PPPoS over my end. Yeah, will need :-) I'm currently using it in my project and have found some issues with it. Especially when I initiate a PPP connection, send data and then close the connection. After a while I'm out of memory so there must be a memory leak somewhere. PPPd design, especially for the old 2.3.11, used in lwIP, is designed to run as a heavy process (a daemon), and do not care much about what is going on at the end of the PPP session, which stops the pppd process in almost all cases. PPPd 2.4.5, with the requirements of the ML-PPP support, seems to handle much nicely what to do in the lost channel case. Anyway, if it still does not, we will fix that. Currently, using the current lwIP PPP, I have to reset my uC at the end of the PPPoE session, else I get into deep troubles. Probably with reasons close to those you have with PPPoS. I do not want to find bugs in PPPd 2.3.11 while I am porting the latest, that would be ridiculous. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Kieran, On Mon, May 14, 2012 at 07:22:33PM +0100, Kieran Mansley wrote: Why don't we get this pushed into the default branch of the git repo so that others can experiment with it. There should be time before 1.5.0 to sort it all out. It obviously wouldn't get backported to the 1.4.1 branch! Humm, I don't think this is a good idea to commit that into the default branch now, at this early stage of development, it still require the help of a Linux kernel/GNU libc to work (syslog, crypt(), ...). Working into a ppp-new branch until it works enough to be pushed to the default branch would be a better option, I guess. Sylvain: if you apply for membership of the lwIP project through the savannah site I'll approve that and it will result in push access to the git repositories. Done! As well as the ability to assign bugs to you! Oh... Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Simon, On Mon, May 14, 2012 at 09:08:04PM +0200, Simon Goldschmidt wrote: That would be great! If 2.4.x really fixes bugs where we found them, that overrides the argument of staying with the 2.3.x code base because of smaller code size PPPd 2.4.x is at least used in all major Linux distributions, and benefits from patchs from them. For example, there are 37 patchs for PPPd into Debian, and some of them fixes bugs. I guess this is because PPPd upstream does not answer. The PPPd bugs tracker do not work anymore too and one bug I sent there went into the middle of nowhere. (since 2.4.x brings in some features that are seldom used and are not conditionally compiled). We can add the necessary compile-time conditions, this is pretty easy to do, I am planning to do so with the previous compile-time options used. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwip whole performance down
Hi, On Wed, May 16, 2012 at 12:25:09PM -0400, Bill Auerbach wrote: In my experience, most performance issues have been in my driver or hardware platform, not in lwIP. I don't use a real OS so I can't speak to its added overhead. Added to that, considering lwIP is working almost without lock (or just small one around memory allocation) and being totally non-blocking by the way it is designed should never be the reason of slowness over time. DMA issues, interrupt issues, bus matrix overloading, etc, are in most cases the reason and obviously where to look first. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwip whole performance down
Hi Vincent, On Thu, May 17, 2012 at 09:51:55AM +, vincent cui wrote: It is really odd... This is not. I enable display lwip stats, it shows that there is packet dropped.. So, lwIP probably knows it had to drop the SYN packet, you only need to find out why. Again, you HAVE TO get and check a TCP trace first in order to be able to know where to look. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwip whole performance down
Hi Vincent, On Thu, May 17, 2012 at 10:15:36AM +, vincent cui wrote: When lwIP performance goes down, the Ethernet DMA's RX buffer unavailable flag is always set ... don't know why, it seems HW problem. This is kind of a hazardous way to suspect first a hardware problem before checking the software driver. From here, it looks like a faulty behavior in the DMA interrupt handler of your MAC driver. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwip whole performance down
Hi Vincent, On Thu, May 17, 2012 at 11:19:28PM +, vincent cui wrote: Hi all: I found the root cause and got it done. The Ethernet interrupt handler has a potential bug . Ah ah!, I knew it! Thank you for all your help.. You're welcome :-) Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi, On Sun, May 20, 2012 at 04:37:02PM +0300, N.Karakotas wrote: Im having trouble compiling the ppp-new for micro. In the auth.c a lot of the includes are dependent on linux operating system. Yeah, maybe you should read this thread more conscienciously :-) I already said the port is not ready yet because it still require Linux calls, or more precisely POSIX calls, if you take a look at the recent commits on ppp-new, you'll see that I am currently removing those dependencies one by one. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] CyaSSL 2.2.0 Released
Hi Bernard, On Thu, May 24, 2012 at 01:21:29PM +0800, bernard wrote: NOTE: RT-Thread Application will be dynamic linked when running. Basically: .o(GPL) + .o(BSD) = GPL (i.e. GPL source code compiled with BSD source code) .so(GPL) + .o(BSD) = GPL (i.e. BSD software using a GPL library) .so(LGPL) + .o(BSD) = BSD + GPL (i.e. BSD software using a LGPL library) ELF(GPL) + ELF(BSD) = BSD + GPL (i.e. 2 heavy processes communicating through IPC, unix socket, TCP) Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] CyaSSL 2.2.0 Released
Hi Bernard, On Thu, May 24, 2012 at 04:34:47PM +0800, bernard wrote: Thank Sylvain, That is: RT-Thread RTOS (GPLv2) Application (GPLv2, PIC ELF) #1 + CyaSSL like (GPLv2) Application (close source, PIC ELF) #2 Where did you saw that RT-Thread is able to parse and run ELF binaries ? As far as I can see, there is just a dlopen()-like mechanism[1], and ITC[2], no heavy process and IPC at all. Sylvain [1] http://en.rt-thread.org/documents/rttdoc_0_4_0/group___module.html [2] http://en.rt-thread.org/documents/rttdoc_0_4_0/group___i_p_c.html signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Nick, On Wed, May 16, 2012 at 08:44:18AM +0300, N.Karakotas wrote: Hi, Is the PPP port available so I can test it? I have a SIO port for LPC17xx. I removed all POSIX-centric code and re-enabled the PPPoS code in the ppp-new branch, it builds, maybe it works :-) I changed a bit the API (without compatibility defines available for now), so you should check what changed in ppp.h, which is mostly de-CamelCase-isation. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Nick, On Sun, Jun 03, 2012 at 11:49:24PM +0300, N.Karakotas wrote: Ok most probably know don't try and code after a few glasses of whine!! :) I got it to compile for now, had to comment out pwd.h,unistd.hand fcntl also undef __P for Redlib as it defines it as __P 1 somewehere in its libraries. Maybe we should cleanup all __P(x) declarations, this is deprecated for years and probably still there in the pppd code only for historical reasons. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Nick,
On Mon, Jun 04, 2012 at 10:52:44AM +0300, N.Karakotas wrote:
Hello Sylvain,
Im trying to get it to run, almost there. A few things need added
and addressed.
In lcp.c line 425 I added:
phase = PHASE_INITIALIZE;
This was left out it cause the the input thread to exit the thread
loop and crash. I mentioned this in a previous post but no one was
warm with PPP at the time.
Will check that, from here it looks like this is more a PPP input thread
bug than a LCP bug.
In ppp.c if I don't add vTaskDelete(pppInputTh); it will crash.
Want this cause a memory leak in other OS's? We need to add a
mechanism to address this.
static void ppp_input_thread(void *arg) {
[...]
vTaskDelete(...);
}
Good catch, this is obviously a bug, some RTOS require a end-of-thread
call and lwIP does not a have a end-of-thread sys_ function.
To all lwIP maintainers: can I change the sys_ API in master adding the
missing sys_thread_delete() call ?
Sylvain
signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Nick, On Mon, Jun 04, 2012 at 12:17:17PM +0300, N.Karakotas wrote: Hey Sylvain, Got it to connect to my ISP through PPPoS! It got an IP back..WOW its fast!!! Same here. I had access to my AVR32 target today, PPPoE worked out of the box with the new PPP stack. \o/ Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwIP API mysql or stack
Hi Bill, On Mon, Jun 04, 2012 at 09:17:41AM -0400, Bill Auerbach wrote: Sha1 is specified as GPL2. Is that OK to mix with lwIP? No, it is not. Does it change lwIP's license or effect the application that includes lwIP? Yep, GPL is viral and changes whole project license. However, there is a SHA1 BSD implementation used in the ppp-new branch that you can fetch and use. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Nick,
On Mon, Jun 04, 2012 at 07:43:13PM +0300, N.Karakotas wrote:
After all it was in the file ipcp.c . You have a comment: do we
really need this and returns 0.
mask = get_mask(go-ouraddr);
It default the netmask to zero so all the data was routed to pp0
instead of em0.
Yep, I found that too when I pushed the new PPP stack on my test device
behind a DSL link which require the help of the netmask and the default
route (or netif in the lwIP terminology), this is fixed :-)
Netmask on PPP link is only used for those wanting multiple addresses
behind a PPP link, with a DHCP server to server multiple clients for
example. lwIP will probably never support that so I set the netmask to
255.255.255.255, which is the default for a PPP link.
Also I added a thread remove to ppp_input_thread:
static void ppp_input_thread(void *arg) {
[...]
sys_thread_t t = sys_arch_thread_current();
sys_arch_thread_remove(t);
}
Yup, I like the idea, we are just waiting for lwIP gurus to accept this
new sys_ entry :-)
Sorry for bombarding you with mails. Im appreciate what you have
done to port the new PPP and im trying to contribute as much as
possible.
Nah, don't think that, I love mails :-)
Sylvain
signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Nick, On Mon, Jun 04, 2012 at 06:08:23PM +0300, N.Karakotas wrote: I have noticed that once I add the interface pp I cant connect to the Ethernet httpd but can ping. I cant seem to spot the change from the previous code. I did a test where I removed the pp and the Ethernet came back fine. Unless the pp thread now is consuming more task time and the httpd isnt getting a chance to run. Beside the netmask and the default route issue, which are fixed, I am also pretty sure that the M[TR]U handling port in ppp-new is faulty, so don't try to send big packets :-) Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Nick, On Mon, Jun 04, 2012 at 02:21:38PM +0300, N.Karakotas wrote: Nice, Can we strip away some of the debug stuff, as I see it has a 1024 buffer. Yeah, I already noticed the char buf[1024]; in the logit() function, which is a huge stack requirement. PPPd for sure require an heavy work concerning stack and globals requirements reduction, which are way too much for small embedded devices. Also from an older post: /* @todo: do we really need such a large buffer? The typical 1500 bytes seem too much. */ static u_char nak_buffer[PPP_NACK]; /* where we construct a nak packet */ #define PPP_NACK 8 This works. 2K+ saved already! It depends on the number of options we need to NAK, 8 bytes is probably too short. Anyway, setting nak_buffer below PPP_MRU is not as easy as just reducing the buffer size. With nak_buffer size = PPP_MRU, we don't need to check for buffer overflow, because it just can't happen. With nak_buffer size PPP_MRU, we absolutely need to check for buffer overflow. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Nick, On Mon, Jun 04, 2012 at 10:40:39AM +0200, Sylvain Rochet wrote: On Mon, Jun 04, 2012 at 10:52:44AM +0300, N.Karakotas wrote: Hello Sylvain, Im trying to get it to run, almost there. A few things need added and addressed. In lcp.c line 425 I added: phase = PHASE_INITIALIZE; This was left out it cause the the input thread to exit the thread loop and crash. I mentioned this in a previous post but no one was warm with PPP at the time. Will check that, from here it looks like this is more a PPP input thread bug than a LCP bug. Fixed, phase was not initialised in ppp_init() while it is in the original pppd code (in main() function). Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Ivan, On Tue, Jun 05, 2012 at 10:05:52AM -0600, Ivan Delamer wrote: Sylvain: can you post this as a task in Savannah, then we can discuss this addition there. Yep, will do. Some small RTOSes are configured without support for deleting threads so we need to see how to handle this. Maybe just an empty #define in those cases... or the PPP code needs to recycle the thread... Actually PPP_INPROC_OWNTHREAD start a dedicated RX thread per PPP session, which is probably used when using blocking serial input. But is there any case of MUC without IRQ on USARTs ?, I don't know, the feature exists in the current PPP implementation so someone need (or use to) it for sure. So, in the PPP_INPROC_OWNTHREAD case, we ~need~ a way to delete threads. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Nick, On Wed, Jun 06, 2012 at 10:40:25AM +0300, N.Karakotas wrote: Hey Sylvain, Does your system run OK? After 2 days mine died and unfortunately I did have my debug open to catch the fault! Humm it is, but I am still resetting my MUC at the end of the connection, because the current PPPoE support does not handle that correctly (I am currently working on :p), so I don't know what is happening over time yet. Do you have enough stack for the lwIP task ? I set mine to 4096 until stack requirements are being lowered. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Hard Fault on PPP thread delete
Hi Alex,
On Wed, Jun 06, 2012 at 10:52:11PM -0700, Alex2051 wrote:
static void sys_thread_wrapper(void * arg)
{
sys_thread_timeouts_mark_empty();
vTaskDelete(0);// after this operator program goes to hard fault exeption
}
But if I setup low ptimisation for best debug support I have no fail!
What happens if you add a while(1) after vTaskDelete() ?
It means that some memory regions used by another process in good
optimisation are freed by PPP, but must not be freed.. I cant find
what I do wrong.
Don't think so.
Sylvain
signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Hard Fault on PPP thread delete
Hi Alex, On Thu, Jun 07, 2012 at 02:20:22AM -0700, Alex2051 wrote: unbelievable! thank You Sylvain. it works... but I can not eplain why... Why? Well, you'll have to look at what your compiler does when optimizing that, I agree, troubleshooting ASM-optimized output is not the easy part :-) Maybe Richard from FreeRTOS knows what is happening in this case. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Nick, On Wed, Jun 06, 2012 at 01:36:06PM +0300, N.Karakotas wrote: Hi, Hmm thats a dirty trick! :-) I have the lwip stack to 1200 bytes The ppp thread 1200 bytes. The only thing running is the ppp the ethernet is idle. It looks that something is overflowing or there is a leak in the PPP not freeing a pbuf. Before I tried to open a PPP connection send data and close the PPP connection but after 2 days I got ApplicationMallocFailedHook fired! I don't think the 2 days is a coisidence?? This is strange, PPP does not allocate memory from malloc(). The only one used malloc() left is in chap_ms.c in case of chap ms auth fail, (and maybe one from EAP auth code). I guess you are not using MSCHAP nor EAP auth. Anyway, you are right about pbuf, ppp_input() does not free pbuf in some cases, this is my fault, but I don't see why it may end with a ApplicationMallocFailedHook() which seems to be a hook when pvPortMalloc() (or something) fails while pbuf are not allocated using malloc()/free() but from a static pre-allocated buffer pool. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Nick, On Thu, Jun 07, 2012 at 03:36:51PM +0200, Sylvain Rochet wrote: [...], ppp_input() does not free pbuf in some cases, this is my fault, [...] I just pushed an early fix about that, but shouldn't change anything in most cases. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Nick, On Thu, Jun 07, 2012 at 10:17:20PM +0300, N.Karakotas wrote: The drop calls the snmp_inc_ifindiscards, this will work if you have snmp enabled I just have defines so it doesn't complain. Should it call something more suitable? Nope, snmp_inc_ifindiscards() is defined as an empty function if snmp is not enabled, this is how snmp.h is designed. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] PPP down not detected
Hi, On Tue, Jun 19, 2012 at 10:11:36PM +0300, Mehmet Ali Ekici wrote: Hi All, I have seen a problem at PPP stack. I saw that GPRS modem sends NO CARRIER but PPP stackt doesn't recognize it and doensn't shut the connection down. Is it the PPP stack has to detect it or driver ? The PPP stack only support the PPP protocol (+ serial and Ethernet lower layer), not the modem chat script, the NO CARRIER is sent before entering into PPP mode, so the driver should catch it and don't start the PPP stack. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] PPP down not detected
Hi, On Wed, Jun 20, 2012 at 04:03:54PM +1200, David Empson wrote: I don't know offhand if this is a standard feature of LWIP's PPP stack. It is. This method is likely to be considerably slower to react to a connection loss than a hard-wired DCD signal. Yeah, considering the required time to establish a PPP session over PSTN, this should not be a problem at all. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Nick, On Wed, Jun 13, 2012 at 08:30:01PM +0300, N.Karakotas wrote: Hello Sylvain, However im having a problem when the link is lost. This is the debug: [] I tried to simulate it by removing the SIM card. It never reaches the drop the packet and I get a Hard Fault somewhere in the FreeRtos which is probably produced by trying to free a null. Whenever I try to debug it with JTAG it doesn't follow the above sequence and unfortunately I cant catch it. Where do you think the problem might be caused? It really looks like a bug when optimisation is enabled. I guess you are debugging without optimisation so you don't see the bug when debugging. Maybe you should check what is happening when the PPPoS thread is destroyed and/or try without PPP_INPROC_OWNTHREAD or even better without PPP_INPROC_MULTITHREADED. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Simon, On Tue, May 15, 2012 at 10:02:20PM +0200, goldsi...@gmx.de wrote: I tested it with the Win32 port from contrib. There is (by now) a working SIO port included which should work with PPPoS. I tested that against window's PPP-Server, which still did not work fully. But given the bugs you found in the code recently, that might have changed. Seeing this nice result, a unix SIO port shouldn't be too hard. Actually someone already contributed a quick and dirty unix SIO/TTY port, which seems to be specifically written to test the PPPoS support. A few changes later and it is working ;-) ( lwip-contrib/ports/unix/netif/sio.c ) Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Ivan, On Tue, May 15, 2012 at 09:52:32AM -0600, Ivan Delamer wrote: Just wanted to say, that this is a great project to take on, thanks Sylvain. I can volunteer to test your port as I have a test PPP client running 24/7 here in the office. We are almost to the point where it should work at least as good as the previous port, checks are welcome :-) I also wanted to update the PPP code using more pbufs vs. static buffers, without affecting the base samba code too much. Maybe it will make sense once the 2.4.x is stable. Can probably be improved, but this is done. There is no more (big) I/O static buffer in the PPP support. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Simon, On Mon, May 14, 2012 at 09:37:53PM +0200, goldsi...@gmx.de wrote: It's sad that this project seems to die though, given the fact that (at least in germany), PPPoE is still use pretty often in DSL routers, and many of them use linux. Same here (in France), because operators allow others to use their *DSL networks as a transport service, PPP is used along with Radius realms to create a tunnel from the DSL subscriber to the tiny-operator L2TP LNS. We can add the necessary compile-time conditions, this is pretty easy to do, I am planning to do so with the previous compile-time options used. Of course we can, but this means a) effort and effort part is done. b) giving up the initial hope of having zero changes against the original sources to let bugfixing be a simple matter of copying the fixed original sources. But then again, it seems like we can forget that :-/ Well, considering all the required changes just to remove the POSIX/unix-dependencies, file system I/O, and so on, this is an impossible goal to achieve. And I am not talking about features I added which pppd does not support, like having multiple PPP sessions running concurrently in the same process, which require no global variables everywhere and passing a context to all functions... while pppd use statically here and here the element number 0 of the PPP interface table. I kid you not. In any case, your work is much appreciated!! Thanks ;-) Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Nick, On Sat, Jun 23, 2012 at 06:34:05PM +0300, N.Karakotas wrote: Hello Sylvain, Im trying the new port but I cant connect. I then receive a NO CONNECT from the modem. I have tried AUTH_PAP and AUTH_ANY. Well, this is not really helpful... could you send the output with PPP_DEBUG and SIO_DEBUG set to LWIP_DBG_ON as well as PRINTPKT_SUPPORT set to 1 ? Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] PPP
Hi Nick, On Sat, Jun 23, 2012 at 07:40:58PM +0300, N.Karakotas wrote: sent [proto=0x237d] c0 21 7d 21 7d 21 7d 20 7d 34 7d 22 7d 26 7d 20 7d 20 7d 20 7d 20 7d 25 7d 26 7d 5e dc fb 9a 7d ... The issue is there, 0xc021, the protocol ID for PPP LCP seem to suffer from 2 a byte offset. However, the packet seem corrupted, if 0xc021 is the LCP header, then the 2 previous bytes should be the PPP header, which are always 0xff 0x03 (more or less from the HDLC protocol). Next bytes are for sure HDLC framing control flag sequence... 7d 21 7d 21 7d 20 7d 34 7d 22 7d 26 7d 20 7d 20 7d 20 7d 20 7d 25 7d 26 7d 5e dc fb 9a 7d. I guess you are overlaping a buffer somewhere that goes to corrupt the lwIP memory. By the way, the sio_read() + USART IRQ should be implemented in a great-circular buffer or a loosely double-buffering with lock support. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] PPP
Hi Nick, On Sat, Jun 23, 2012 at 08:38:04PM +0300, N.Karakotas wrote: Hi Sylvain, The uart is a circular buffer and is protected by a lock. Im looking at the dump: dump_packet(sent, (unsigned char *)nb-payload+2, nb-len-2); Maybe that's why you are not seeing the 0xff 0x03? dump_packet() takes as argument a PPP payload without the HDLC 2 byte header, because this is meaningless to display and above all because PPPoE don't have it. What I tried to explain is that in the dump you sent, we can extract: sent [proto=0x237d] c0 21 7d 21 7d 21 7d 20 7d 34 7d 22 7d 26 7d 20 ^^^ HDLC Framing ^ LCP header ^ HDLC Framing A 2 byte offset packet would look like: [proto=0xff03] c0 21 ... LCP payload ... This is why I said that even the PPP HDLC header seem corrupted if it was only an offset issue. I commented it out but got jargon: 0x07 0x23 Looks like HDLC framing as well. The dump_packet() function is called just after PPP created a control packet, at least in the latest revision of the ppp-new branch, that was not ever the case. The PPP control stack do not know anything about PPPoS HDLC-like Framing, so this is impossible, except memory corruption, to get HDLC Framing there. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] PPP
Hi Nick, On Sat, Jun 23, 2012 at 10:13:28PM +0300, N.Karakotas wrote: Hey Sylvain, I grabbed the latest push you made and it work now. I pushed this morning fixes about PPPoS and you sent your first mail way after my latest push about that. So I made the assumption that you were trying the PPPoS stack with the today's change... Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Nick, On Sat, Jun 23, 2012 at 07:06:28PM +0300, N.Karakotas wrote: Hi, Yes I thought so :-) Didn't know about the PRINTPKT_SUPPORT. Attached is the output. rcvd [LCP ConfReq id=0x1 asyncmap 0xa auth pap] fsm_input(0): Rcvd packet in state 0 This is almost impossible too... ppp_over_serial_open() set pcb-phase to PHASE_INITIALIZE (1) before starting PPP. pcb-phase can't be set to 0 at this time. int ppp_over_serial_open(...) [...] new_phase(pcb, PHASE_INITIALIZE); ppp_start(pcb); [...] } This is either a compiler bug, because ppp_pcb use compiler generated bitfield from struct, or a memory corruption. You can check the first by replacing bitfield to u8_t type for each bitfield entry in all structures used by PPP. Here is a sed regexp that, applied to all headers files, should do the job: s/^\(.*\)u_int\(.*\):[^1]*1[^;]*\(.*\)$/\1u8_t\2\3/ Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LCP Termination Request steps
Hi Ivan, On Mon, Jun 25, 2012 at 09:38:21AM -0600, Ivan Delamer wrote: Hello Sylvain, Great news! I will download the ppp branch and start testing it this week. Sounds like really good work you've done. Hey!, you might be interested, I added IPv6 support to PPP, LL assignation work (the PPP/IP6CP protocol only provide assignation of EUI64 on LL). However I did not check (yet) if all the IPv6 ND-stuff are working on POINTTOPOINT lwIP link type, I guess it should. Question: could you clarify what's happened with PolarSSL and license requirements? Are we having GPL code now? We are using the latest PolarSSL released under BSD[1]. Sylvain [1] http://polarssl.org/news?item=011f signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP - last_unsent-oversize_left = oversize_used asserts
Hi, On Sun, Jul 01, 2012 at 08:20:23PM +0200, Sylvain Rochet wrote: On Sat, Jun 30, 2012 at 06:43:43PM +0200, Krzysztof Wesolowski wrote: last_unsent-oversize_left = oversize_used unsent_oversize mismatch (pcb-unsent is NULL) I have encounter same assert line while streaming big chunks of data using netconn API, so this is rather OVERSIZE related issue. Actually, as expected, it was my fault :-) Well well well, I am sometimes s dumb. The RAW API is indeed not thread safe, this is explicitly written in the documentation, oh dear. To be honest, I actually based my work from previous code written, and yes, we now have to redesign some stuff in our products :-) Luckily, using the UDP raw API outside the lwIP thread, UDP being not a timeout-hungry protocol, seem to cope well. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Handling link-up/down, netif-up/down events in LwIP
Hi, On Sat, Jul 07, 2012 at 11:56:45AM +0100, Kieran Mansley wrote: They probably wouldn't. TCP is designed to cope with links coming and going, and will just retransmit if any packets are lost while the link is down for example. Connections should survive link being removed and restored. I agree. TCP idle sessions without link between the hosts can live as long as no end try to send data. However there is some limitations set by equipments doing connections tracking for NAT, stateful firewall, and such. Linux connections tracking feature defaults to 5 days idle timeout on established session: net.netfilter.nf_conntrack_tcp_timeout_established = 432000 I would experiment on Linux or similar to see what happens there, but my guess is that setting the interface down (not quite the same as the link state being down) will result in the route being invalid and you'll get an error such as host unreachable or no route to host. Yep, Interface down = administratively down, so voluntarily down Link state down = carrier lost, unplug media, fiber cut, ... Linux remove all routes going to an interface switched to administratively down: # ip route show dev tap1 192.168.1.0/24 proto kernel scope link src 192.168.1.1 # ip route add 172.16.0.0/24 via 192.168.1.10 # ip route show dev tap1 172.16.0.0/24 via 192.168.1.10 192.168.1.0/24 proto kernel scope link src 192.168.1.1 # ip link set down dev tap1 # ip route show dev tap1 # Other OSes, like most *BSD ones IIRC, keep the routes in the routing table, both approach seem valid for me. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] PPP
Hi Nick, On Sun, Jul 29, 2012 at 01:07:56PM +0300, N.Karakotas wrote: Hello, I tried the latest revision of the PPP code but im having problems. I had to increase the tcp_input_thread from 300 to 500 or else it crashed. Then the ppp thread connected to the ISP and got ip etc. But it seems from then on that the data is routed. I also tried to use SO_REUSE flag but it didn't work. Older code prior to the last changes you have done the last month worked OK. Can you please give any pointers. 500 bytes stack should be enough if you are using PAP authentication, but not for CHAP authentication which require about 1 KiB stack size. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] PPP
Hi Nick, On Sun, Jul 29, 2012 at 11:58:49PM +0300, N.Karakotas wrote: Hi Sylvain, When it configures the ip,gateway and adds pp to the netif list etc I cant connect to the internet. Sounds like a routing issue, is your PPP netif interface set as your default route through ppp_set_default() if called from the lwIP thread or pppapi_set_default() otherwise ? Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Re opening LWIP for new HTTP message
Hi, On Wed, Aug 08, 2012 at 06:14:52AM -0700, H.A. wrote: Do you mean that I should check if the connection is open in the interrupt routine? If open send the message. If not open, open the connection, return and let the connect callback send the message? Can the connection be closed between the check and the transmit inside the interrupt routine? Is this mix of different contexts really safe? Of course not ! You have to read lwip/doc/rawapi.txt in order to understand how to use lwIP with threads. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Re opening LWIP for new HTTP message
Hi, On Wed, Aug 08, 2012 at 06:29:47AM -0700, H.A. wrote: Of course not what? I had at least 3 questions. This is why I quoted only the relevant part. I do understand that the LWIP stack is not reentrant but the Stellaris code is using tcp_write and tcp_output from the serial interrupt and it is even sold a a commercial product. (serial to ethernet module using telnet). Sorry to say that, but this is defective by design. Every lwIP raw API call must be run from the lwIP context, no exception. NO_SYS == 1 : everything should be done in the main() context. NO_SYS == 0 : lwIP is running in its own thread (started from TCPIP API init function). sequential (netconn) or socket API must be used outside of the lwIP thread. So it must work somehow but I don't undestand how. By chance... actually it depends if you are in the in watchdog we trust way of designing things or not. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] No ARP reply by using two NICs
Hi, On Tue, Aug 14, 2012 at 03:01:59PM +0200, Stefan Lankes wrote: Hi LwIP users, I have an ARP problem and I am not sure, if this a problem of LwIP. In our academic operating system, we use LwIP 1.4.0 as TCP/IP stack. My test system posses two network devices and each device belongs to its own subnet. I enabled IP forwarding to transfer IP packets between the subnets and it seems to work. However, if a member of subnet A broadcasts an ARP request to determine the physical address of a member of subnet B, our system does not forward these broadcasts to subnet B. LwIP drops the requests with the message ARP request was not for us. Is this behavior correct? With your wanted behavior, a broadcast Ethernet frame sent to a router connected to the global IP space would be received by all IP equipments connected, which is about billions of systems. And you are considering the whole Internet is only made of Ethernet links, which is false. Maybe you have to learn the difference between layer 2 and layer 3. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ethernetif_input usage with Ethernet over SPI
Hi, On Thu, Aug 23, 2012 at 04:21:30PM +0200, Tomás Svec wrote: Well, to clarify, I send whole Ethernet frames via SPI. ARP should be handled by the external chip, though, as it does not let any ARP packages through and responds to ARP queries without the TCP/IP stack. Maybe you should tell which SPI-Ethernet chip you are using. From here it sounds like this is something with an already embedded IP stack. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LWIP crash
Hi Anil, On Fri, Sep 07, 2012 at 11:09:47AM +0530, Anil kumar wrote: We are using lwip as a linux kernel module in a multi threaded environment. Here is the sequence of events that are leading to the crash in my case. As the application is continuously sending data, do_write continuously calls do_writemore, which internally calls tcp_write. At some point tcp_write returns ERR_MEM and do_write waits on semaphore op_completed. [...] What could be the reason for the crash in the first case, is it i am using lwip threads incorrectly ? It looks like you are using the raw API with threads, raw API is -NOT- thread safe, you have to use netconn or socket API. Please read doc/rawapi.txt, but no worry, we all (At least I did) made the mistake until we find out this file :-) Also, if you are allocating pbuf outside of the lwIP thread, you have to set SYS_LIGHTWEIGHT_PROT=1 in your lwipopts.h Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Getting started with an ethernet driver for linux
Hi, On Tue, Sep 18, 2012 at 08:51:13PM +1200, A G wrote: Thanks, where you say it uses a pseudo network interface that somehow passes raw ethernet packets, what do you mean by somehow; is this functionality provided by lwip, or do I need to do the lwip to raw ethernet packet interface? The unix port uses the TUN/TAP virtual Ethernet interfaces facility of the Linux(and others) kernel. But this is mostly for tests purpose, debugging is easier and we don't have to wait for uC flash. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] where is the contribute part
Hi Yueyue, On Thu, Nov 01, 2012 at 09:17:29AM +0800, yueyue papa wrote: Hi I coudl only check out lwIP in the GIT repository.Where is the lwIP contrib part in the GIT? http://git.savannah.gnu.org/cgit/lwip/lwip-contrib.git Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Assertion memp sanity failed at line 463 in ../lwip_1_4_0/Src/core/memp.c
Hi, On Fri, Nov 16, 2012 at 10:28:17AM +0100, Mikael Eiman wrote: Hi, I had a similar problem recently, and in my case I was first using lwIP functions from multiple threads (it's not thread safe, don't do that), and then causing a double free() by calling essentially tcp_close() twice on the same handle. My guess: you're corrupting memory somewhere, somehow. Another hint, SYS_LIGHTWEIGHT_PROT must be set if you are allocating memory from threads other than the lwIP core TCPIP thread. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] IP6 address autoconfig problem when using hub
Hi, On Sun, Dec 09, 2012 at 10:53:58AM +0100, Simon Goldschmidt wrote: Zach Smith wrote: I am having a problem when I connect my IPv6 device running lwip to a hub instead of a switch. [..] Since a hub forwards all packets received onto all ports it is echoing my devices neighbor discovery messages back. I haven't had the chance to test lwIP on a hub, yet (we only have switches, all hubs were thrown away a long time ago...). However, if your hub really sends back all your frames, I guess IPv6 autoconfig will not be the only protocol having problems. Added to that, a hub being half duplex by design is not supposed to bounce back packets, because it can only have one RX port at a time while all other should be TX ports (or there is a collision). So, a hub DOES NOT forwards all packets received onto all ports, a hub DOES forwards all packets received onto all ports EXCEPT the sender port, if this is not the case, this is because there is an Ethernet loop somewhere or a faulty device that should be fixed/replaced. Anyway, a switch without a populated MAC forwarding table is working like a hub and bounce packets to all ports except the sender' one. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] socket write hangs, in LwIP 1.4.? (ppp-new branch but not ppp related)
Hi Mark, On Thu, Dec 20, 2012 at 11:55:19AM -0800, Mark Lakata wrote: I'm using the head of the ppp-new branch. I'm going to plead almost complete ignorance of how git works (haven't gotten around to learning it) and learned just enough to download the ppp-new branch. So if I understand correctly you fetched the head a while ago, which is probably not the head anymore :-) Has the ppp-new branch being pushed back into the main line? Nope. Is there an easy way of merging the two branches together? You don't have to, I am regularly merging master changes into the ppp-new branch. But you have to update (pull) your clone if you want an up to date copy. Does that sentence even make sense? I need the ppp-new branch, since I had trouble with the released ppp code, which I think was 1.4.0. Well, depending on your IPv6 and PPP needs, you can use the latest release (no IPv6, old PPP), the current master branch (+IPv6), or the ppp-new branch (+IPv6 +reworked PPP). Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Closing netconn, application or lwip bug?
Hi Szymon,
On Mon, Jan 14, 2013 at 03:25:22PM +0100, Szymon Tarnowski wrote:
Hi,
I am developing a commercial application for embedded device using lwip.
My device is listening on specific tcp port for incomming message, if client
connects can send request and get response then decide if want to keep
connection or disconnect. My device is based on AVR32 processor, and
under this device application is working correct. As a part of my quality
assurance test I must recompile this application under linux and test
memory leaks and stability. Under valgrind I receive some exceptions
about invalid memory reads deep inside lwip, then application crash with
exception segmentation fault. Inside my application I have such code:
(listening task)
if (netconn_acept(listening_conn, new_conn) == ERR_OK)
{
add_new_client(new_conn)
}
(client support task)
for (i=0; iclients; i++)
{
if client_wants_close
}
This is probably not thread safe, I guess add_new_client() change the
clients value, which might be changed as well with your
client_wants_close. This is probably not the segfault cause, but you
must lock using a mutex or a critical section the clients value. Like
this pattern:
mutex_lock(clients_lock);
clients++;
mutex_unlock(clients_lock);
mutex_lock(clients_lock);
clients--;
mutex_unlock(clients_lock);
mutex_lock(clients_lock);
for(i=0; iclients; i++) {
...
}
mutex_unlock(clients_lock);
Sylvain
signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Update LWIP 1.2.0 to 1.4.1
Hi, On Wed, Jan 23, 2013 at 07:38:17AM +0100, Simon Goldschmidt wrote: Unfortunately, we don't have documents on how-to-upgrade between versions (yet?). lwip/UPGRADING seems quite complete for me, well this is not a step-by-step how-to strictly speaking but should be enough for anyone who wrote a lwip port and so already had to give a deeper look inside the lwip stack. However, I do know that from 1.2.0 to 1.3.0, ARP handling has been changed: until 1.2.0, ARP packets were passed to etharp_input() from your ethernetif_input function. Since that had threading issues, ARP packets now must be passed to netif-input() AND the payload pointer must point to the ARP header now, not the IP header. And most sys_arch prototypes changed from 1.3.0 to 1.4.0 from returned pointer to pointer passed by reference, which provides better error handling, like this: from sys_sem_t sys_sem_new(u8_t count); toerr_t sys_sem_new(sys_sem_t *sem, u8_t count); Well, this is not such a big deal. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] PPP new Stack
Hi Nikolas, On Mon, Feb 18, 2013 at 11:52:02PM +1100, Nikolas Karakotas wrote: Hello Sylvain, I have been using latest ppp-new commit from git and also lwip but im experiencing a problem ONLY when I close the ppp connection. When the ppp thread is left open (running always) everything is OK. Let me explain to you what happens: I initiate a connection and once the link is up I send my data. I then close the connection and use ppp_delete(). After around 5 tries it seems that I get an LCP timeout. This occurs because I don't have any pbuf available. It seems that there might be a memory leak when closing the connection and deleting ppp? I have attached serial output. Humm, what about the ptr value of ppp_pcb-rx-in_head and ppp_pcb-rx-in_tail in this case ? I guess we might need to call ppp_free_current_input_packet() before releasing the ppp pcb in ppp_delete(), and will do because this is totally harmless, but this will be better if the memory leak issue is solved with facts :-) Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] PPP new Stack
Hi Nikolas, On Tue, Feb 19, 2013 at 02:55:27PM +1100, Nikolas Karakotas wrote: Hi Sylvain, Ok I think I found the problem. I use PPP_INPROC_OWNTHREAD and once I added ppp_delete() to the end it seems to fix the problem. I also removed the ppp_delete from the linkStatusCB. Somehow a clean up wasn't completed and a pbuf was always allocated but not freed as you can here: Well, this is one of the reason why I consider to remove the PPP_INPROC_OWNTHREAD crap in ppp-new, as said in bugs #37278 and #37353. 1. It requires to be modified to match user system, like you did adding the vTaskDelete(NULL); FreeRTOS call at the end of the function. This is a tiny-tiny fonction that should be, in my opinion, on the user port, like the Ethernet input thread we see in many Ethernet port. 2. It is actually not thread safe. 2.1. pcb-phase IS modified by the lwIP core thread so it should at least be set to volatile, otherwise the pcb-phase copy may live indefinitely in CPU register. It works because of the sio_read() function call which without doubt flush pcb-phase copy from CPU register. 2.2. This function assume PCB still exists whatever is happening, which is not the case after you called ppp_delete() function outside of this thread. If sio_read() is blocking waiting data and pcb destroyed, it is going to read a deallocated pcb which luckily should still have pcb-phase set to 0 (=PHASE_DEAD) due to preallocated control block structures of lwIP. 3. I dislike the sys_msleep(1), it means that systems should have at least a 11 chr buffer at 115200/10 byte/s, and bigger with higher serial speed, for example with 3G/HSDPA modems accessed through SPI, at 20 Mbits/s this is a ~2000 bytes buffer required to keep incoming data during this sleep, I don't see why we require systems to do so, sio_read() should obviously be a blocking call. Of course, I do not want to call ppp_delete() at the end of this thread, keeping the PPP PCB live over (re-)connections is necessary to keep the netif interface that might be used with udp_sendto(), ppp_over_l2tp_open() (for L2TP-VPN over PPPoE/oS), ... and this is why the ppp-new branch creates the netif early during ppp_new(), so that you can start to use this netif elsewhere in the code whatever the PPP session state is. Deleting a PPP PCB is as hard as removing an Ethernet netif. If I were you I should rewrite the ppp_input_thread() on your side with your FreeRTOS-related change and with the necessary signaling to kill this thread -before- you call ppp_delete() from another thread, this will fix the threading issue you might have (but unlikely to happen, luckily) and this will help me removing this one so that you can upgrade to the updated branch without PPP_INPROC_OWNTHREAD ;-) But, honestly, deleting a PPP session control block using ppp_delete() (or pppapi_delete()) requires you to ensure that are not using anymore the pcb ptr nor the PPP netif, which requires in my opinion a quite difficult signaling all over your threads to tell them to stop using those objects. I am going to check if adding the ppp_free_current_input_packet() in ppp_delete() is necessary, it depends if I already do so at the end of the connection or not which I don't remember. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] IPV6 compilation
Hi Fabian, On Mon, Feb 25, 2013 at 11:00:33AM +0100, Fabian Cenedese wrote: I'm using the official 1.4.1 lwip, not current from git. [...] Should the ipv6 code be compilable (I don't worry about functionable now)? IPv6 is not available from the 1.4.1 release but it is available (and working perfectly for me ! ;) from the HEAD of the Git repository. Is there some other way around this except leaving out the ipv6 files? Not in the 1.4.1 release. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] PPP new Stack
Hi Nikolas, On Wed, Feb 20, 2013 at 07:07:29PM +1100, Nikolas Karakotas wrote: Hi Sylvain, Ok I followed your suggestions and it works nicely. I just call ppp_close and don't delete the thread. When I want to reconnect I call ppp_reopen and it simply changes the netif interface to match the new ip. I also removed the sys_msleep(1) and added a semaphore to the uart rx interrupt. Yeah, happy to hear that :-) Anyway, I fixed the memory leak when using ppp_delete() on a PPPoS PCB with input pbuf left, which can actually happens. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] netconn_write/recv from two different tasks..
Hi Thomas, On Wed, Mar 06, 2013 at 01:14:57AM -0800, ThomasJ wrote: Could it be the fact I'm using netconn_write in one task and netconn_recv in another? Would it help using them in the same task? (First check for received data and then send data if any to send?) Yes, this is the issue, a UDP or TCP control block through netconn must NOT be used from different threads. However, I must agree, lwIP documentation is probably not clear enough about what is (dis)allowed in a multi-threaded context. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] netconn_write/recv from two different tasks..
Hi Thomas, On Wed, Mar 06, 2013 at 03:03:55AM -0800, ThomasJ wrote: or is it better to use a semaphore around the netconn_recv and netconn_write, so no write can be done during receiving and no receive during wrie? How does you handle it? This is exactly the same from the lwIP point of view, however, I personally prefer message passing over mutexes, because this is less subject to dead locks or priority swap issues. By the way, netconn_new_with_callback() allows lwIP users to write fully-event based user code, which I also personally prefer over some kind of rx polling. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] netconn_write/recv from two different tasks..
Hi Thomas, On Wed, Mar 06, 2013 at 06:43:15AM -0800, ThomasJ wrote: Hi Just an idea... and would it work? If I keep my TX task and RX task. I then make make sure the TXTask does not use the netconn_write while the RXTask is in the netconn_recv call. Would that be ok or must the net connection be handle only by the same task? I already told you about that. This is exactly the same thing from the lwIP point of view or generally speaking for any multithreading environment, this is not strictly lwIP-specific. The point is that netconn_ functions are not reentrant for -a- UDP or TCP control block, so serializing them through a mutex/semaphore from sparse threads will work. But beware of dead locks conditions!, you are going to run a mutex/semaphore over a message passing system which of course cause contexts switchs (so priority reordering), this requires strict checking of any possible locking cases between 3 threads, a mutex/semaphore, and a mbox. Sylvain ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Problem with connection reset
Hi, On Sat, Mar 09, 2013 at 04:31:28PM +0100, Maciej Gajdzica wrote: Hello After solving issue with fragmented 3G packets I ran into some performance related problems. [...] Further investigation revealed that problem is probably caused by limited memory for memp objects and pbufs. At some point there is not enough space on the heap to allocate one of memp objects. [...] I cannot see what's wrong with lwIP here, network with very high latency like 3G networks obviously require more memory for TCP, because TCP need to keep all packets that have not been ACKed yet. Maybe you should reduce pbuf size and increase their number as well as reducing the TCP window to prevent keeping large non-ACKed packets in memory, of course this will decrease the TCP performance, especially on high latency networks, but you cannot have both on low memory targets. If your STM32 chip have an external bus interface (EBI) you might consider adding SRAM to allow lwIP to use a bigger TCP window. Or I am missing something ? Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Problem with tcp_listen
Hi Christian, On Wed, Mar 20, 2013 at 03:59:13PM +0100, Christian Fuchs wrote: ..., the pcb is in state ESTABLISHED and goes then to FIN_WAIT_1. So the memory for MEMP_TCP_PCB_LISTEN will never be freed. So, what I'm doing wrong? It looks like your port timers are not working properly. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Interface with PPPoE and DHCP?
Hi Simon, On Fri, Mar 22, 2013 at 09:14:39AM +0100, Richner Simon wrote: Would it be possible to use PPPoE and DHCP on the same interface in parallel? It depends on what you mean by interface, on the same Ethernet hardware interface: yes on the same lwIP software interface (i.e. netif): no, Ethernet require a netif and PPPoE is going to create a PPP netif Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LPC1768/9 LAN8720 FreeRTOS 7.4 LWIP 1.4.1
Hi, On Thu, May 23, 2013 at 12:56:07PM -0400, Pomeroy, Marty wrote: Do not call tcp_new() or netconn_new() from outside the lwip thread. Not true, netconn API *IS* thread-safe. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] LPC1768/9 LAN8720 FreeRTOS 7.4 LWIP 1.4.1
Hi, On Fri, May 24, 2013 at 07:35:49AM +0200, Furiantes Furiantes wrote: Is tcp_new() thread safe too ? or just netcon. My scenario is that: No, as said in doc/rawapi.txt :-) Raw API is *NOT* thread safe: udp_*(), tcp_*(), netif_*(), ... Netconn API is thread safe: netconn_*() Socket API is thread safe: lwip_accept(), lwip_bind(), lwip_connect(), ... NetifAPI is thread safe: netifapi_*() - i will call a TCP staff only in seperated threads. Like do_download = tcp_new() in one thread and than like listen to some port initialized in seperated thread etc. etc. Is that ok to do or not ? With global access can I access from TCP_1 thread to TCP_2 thread like TCP_2 kill TCP_1 thread. Nah, this is wrong, you *have to* use netconn or socket API. Also, and this is very important too, Netconn and Socket API are thread safe against lwIP thread but NOT against themselves, so a UDP or a TCP PCB must be handled by only one thread. If you want to share a PCB between threads you can of course add the necessary mutex around Netconn or Socket calls. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Receive path stuck due to pbuf_alloc returning NULL
Hi Sebastian,
On Mon, May 27, 2013 at 10:01:44AM -0700, Sebastian Gonzalez wrote:
Hi,
I am using lwIP 1.3.2 with an Atmel AT91SAM7X512, and FreeRTOS. We have
already used this combination in other projects with no problem, but now we
using our design in a network with high density of UDP broadcast traffic
causing the system to stop receiving.
The transmission path keeps working as I can see ARP request messages coming
out in the wireshark traces.
After debugging and searching I found that several people had the same
issue: The pbuf_alloc call from low_level_input in the ethernet driver
returns NULL during the packet storm and keeps returning NULL, as if the
TCP/IP task wasn't fast enough to free the pbufs, and thus the packets from
the EMAC do not move to the upper layers.
I do understand that during a packet storm all the packets that can't be
processed are dropped, actually that's the behaviour that I expect. But I
don't get why the consumer process is unable to free the packets that have
already been passed to the upper layer.
I have tried giving the TCP/IP thread the higher priority with no results.
Also changed the number of pbufs from 8 to 16 and noticed that the problem
happened later in time.
Is there a recommended value for the number of pbufs, considering my reduced
schema of memory?
As usual, looks like a bug in the MACB driver, you have to check
carefully if the lwIP pbug get free()d whatever is happening along the
input and output path.
I can't talk about the AT91 MACB driver, but the AT32 MACB driver suffer
a huge bug about that, it only free()s MACB TX buffers of successfully
sent frames, which ends up by locking the TX path, RX path is still live
and is allocating all pbuf.
void vClearMACBTxBuffer(void) {
// The first buffer in the frame should have the bit set automatically. */
if( xTxDescriptors[ uxNextBufferToClear ].U_Status.status
AVR32_TRANSMIT_OK ) {
[...]
}
}
Before a transmission, bit 31 is the used bit which must be zero
when the control word is read. It is written to one when a frame has
been transmitted.
Guess what happens if the transmit ok bit is not set and the should
have the bit set ... going to be false :
If it helps, I attached my patch against the AT32 MACB driver which
helps the system to recover, maybe the AT91 driver is similar. The patch
is not perfect, because it drops all queued frames, which I consider
adequate because it only happens a few times per week on a very very
loaded ethif.
Sylvain
Modified: asf/avr32/drivers/macb/macb.c
===
--- branches/axima/src/asf/avr32/drivers/macb/macb.c 2013-02-22 10:58:08 UTC (rev 339)
+++ branches/axima/src/asf/avr32/drivers/macb/macb.c 2013-02-22 14:15:06 UTC (rev 340)
@@ -572,31 +572,29 @@
// Tx buffer within the frame just transmitted. This marks all the buffers
// as available again.
- // The first buffer in the frame should have the bit set automatically. */
- if( xTxDescriptors[ uxNextBufferToClear ].U_Status.status AVR32_TRANSMIT_OK )
- {
-// Loop through the other buffers in the frame.
-while( !( xTxDescriptors[ uxNextBufferToClear ].U_Status.status AVR32_LAST_BUFFER ) )
-{
- uxNextBufferToClear++;
+ xTxDescriptors[ uxNextBufferToClear ].U_Status.status |= AVR32_TRANSMIT_OK;
- if( uxNextBufferToClear = ETHERNET_CONF_NB_TX_BUFFERS )
- {
-uxNextBufferToClear = 0;
- }
-
- xTxDescriptors[ uxNextBufferToClear ].U_Status.status |= AVR32_TRANSMIT_OK;
-}
-
-// Start with the next buffer the next time a Tx interrupt is called.
+ // Loop through the other buffers in the frame.
+ while( !( xTxDescriptors[ uxNextBufferToClear ].U_Status.status AVR32_LAST_BUFFER ) )
+ {
uxNextBufferToClear++;
-// Do we need to wrap back to the first buffer?
if( uxNextBufferToClear = ETHERNET_CONF_NB_TX_BUFFERS )
{
uxNextBufferToClear = 0;
}
+
+xTxDescriptors[ uxNextBufferToClear ].U_Status.status |= AVR32_TRANSMIT_OK;
}
+
+ // Start with the next buffer the next time a Tx interrupt is called.
+ uxNextBufferToClear++;
+
+ // Do we need to wrap back to the first buffer?
+ if( uxNextBufferToClear = ETHERNET_CONF_NB_TX_BUFFERS )
+ {
+uxNextBufferToClear = 0;
+ }
}
static void prvSetupDescriptors(volatile avr32_macb_t *macb)
signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Understanding MTU and Max ETH Frame size
Hi Dimax, On Tue, May 28, 2013 at 03:19:41PM +0300, Dimax wrote: Hi, Thanks for your answer. But I need to clarify it If I set MTU=1500 am I guaranteed not to get Ethernet frames bigger then 1514 bytes? You are not, MTU is Maximum -Transmission- Unit, not receive. You might receive giant frames from your Ethernet scope (802.1q, 802.1ad, MPLS Frames, ...), but your hardware MAC should drop giant frames if you haven't configured it to handle/pass them. I need to know it to make proper DMA buffers allocation. As far as I understand MTU is exchanged between two ETH peers via management packets and each side should respect peers MTU? MTU is not exchanged, at least not on the Ethernet layer. All hosts on a Ethernet subnet should have the same configured MTU. On the IP side, ICMP might be used to discover the maximum usable MTU over a layer 3 network path. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp_new gprs
Hi Ahmed,
On Sat, Jun 01, 2013 at 04:22:56AM -0700, Ahmed Fayek wrote:
Hi,
My application is a GPRS router that route data to/from eathernet
interface and serial GPRS module usin ti stellaris LM3S6918.
I try to use the ppp_new code, I need to know the sequence to start
the pppos using the new functions. I am asking if there is an example
project.
This is quite easy, ppp.h is well documented about that.
Basically:
ppp_pcb *ppps;
int fd;
fd = open_serial_port();
ppps = ppp_new();
ppp_set_auth(ppps, PPPAUTHTYPE_PAP, login, password);
ppp_over_serial_create(ppps, fd, ppp_link_status_cb, NULL);
your_chatscript(fd) {
[ ... ]
ppp_open(ppps, 0);
}
while(1) {
u8_t buffer[128];
int len;
len = sio_read(fd, buffer, 128);
if(len 0) {
pppapi_sighup(ppps);
} else {
pppos_input(ppps, buffer, len);
}
}
You have to use pppapi_ functions if lwIP is already started, ppp_
functions are not thread safe.
Closing a running session:
ppp_close(ppps); /* or pppapi_close(ppps);, as usual */
/* --- wait for callback, do NOT destroy the PPP PCB until PPP finished
* the cleaning job
*/
Dummy callback, called from the lwIP thread, should be non-blocking:
void ppp_link_status_cb(ppp_pcb *pcb, int err_code, void *ctx) {
switch(err_code) {
case PPPERR_NONE: {
struct ppp_addrs *ppp_addrs = ppp_addrs(pcb);
fprintf(stderr, ppp_link_status_cb: PPPERR_NONE\n\r);
fprintf(stderr,our_ipaddr = %s\n\r,
ip_ntoa(ppp_addrs-our_ipaddr));
fprintf(stderr,his_ipaddr = %s\n\r,
ip_ntoa(ppp_addrs-his_ipaddr));
fprintf(stderr,netmask = %s\n\r,
ip_ntoa(ppp_addrs-netmask));
fprintf(stderr,dns1= %s\n\r,
ip_ntoa(ppp_addrs-dns1));
fprintf(stderr,dns2= %s\n\r,
ip_ntoa(ppp_addrs-dns2));
#if PPP_IPV6_SUPPORT
fprintf(stderr,our6_ipaddr = %s\n\r,
ip6addr_ntoa(ppp_addrs-our6_ipaddr));
fprintf(stderr,his6_ipaddr = %s\n\r,
ip6addr_ntoa(ppp_addrs-his6_ipaddr));
#endif /* PPP_IPV6_SUPPORT */
break;
}
default: {
fprintf(stderr, ppp_link_status_cb: err code %d\n\r,
err_code);
restart_chatscript(pcb, 5); /* Should trigger
chatscript, in another thread for example, so that you are not locking the lwIP
thread */
/* You can also use ppp_delete() here */
break;
}
}
}
another question about sio.c specially reading data, what is the
criteria to end reading? length or a certain character received? As I
found an application dealing with fixed max. length data passed to
sio_read()
In ppp-new branch, you have to call pppos_input() when you get new data
from your serial port. This function is thread safe and can be called
from a dedicated RX-thread or from a main-loop.
Sylvain
signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp_new gprs
Hi Nikolas, On Wed, Jun 12, 2013 at 10:38:07PM +1000, Nikolas Karakotas wrote: Hi Sylvain, At what case does your sio_read returns len 0 ? This is just an example, mine never return 0, however, a read() function which is conforming to POSIX.1-2001 returns -1 in case of error: READ(2) read - read from a file descriptor On error, -1 is returned, and errno is set appropriately. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp_new gprs
Hi Nikolas, On Thu, Jun 13, 2013 at 09:39:59AM +1000, Nikolas Karakotas wrote: Hi, I thought so, by the way where is the best place to call pppapi_sighup? When DCD state change to NO CARRIER, but DCD is rarely wired nor relevant with GPRS modems, so you just have to wait for LCP timeout. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] redefining LWIP_PLATFORM_DIAG(x)
Hi Joe,
On Tue, Jun 25, 2013 at 12:49:31AM +1000, Joe Bloggs84 wrote:
Hi All,
I am interested in whether there is already a way to do this and I
am missing something or whether a change like I am proposing would
be useful to others.
cc.h defines LWIP_PLATFORM_DIAG(x)
as
#define LWIP_PLATFORM_DIAG(x) printf x;
I have a situation where I have to call a function other than printf
for any diagnostic output (to support logging).
So I had to modify cc.h and now I have to keep making the patch each
time I jump to a new version of lwip.
What about declaring LWIP_PLATFORM_DIAG and LWIP_PLATFORM_ASSERT
only if they are not already declared.
So something trivial like:
#ifndef LWIP_PLATFORM_DIAG
#define LWIP_PLATFORM_DIAG(x) printf x;
#endif
#ifndef LWIP_PLATFORM_ASSERT
#define LWIP_PLATFORM_ASSERT(x) do { printf(Assertion \%s\ failed
at line %d in %s\n, \
x, __LINE__, __FILE__);
fflush(NULL); /* abort(); */ } while (0)
#endif
Or is there already a way of achieving this without having to patch
the lwip source?
Humm... cc.h is part of your lwip port which is actually not, strictly
speaking, part of the lwip source.
Sylvain
signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] a question!?
Hi, On Tue, Jun 25, 2013 at 12:25:02PM -0400, Bill Auerbach wrote: Maybe because the protocol and type checks are 2 byte checks while the ip address and hwaddr checks total 10 bytes to check? And maybe because ARP/IPv6/PPPoE are dealing with broadcast/multicast addresses, so checking the address validity require knowing the protocol used. Maybe as well because I am too lazy to read the source code, I have no doubt it is perfect on this point ;-) Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp problem
Hi Stefano, On Sat, Sep 14, 2013 at 02:02:43PM +0200, Stefano Marini wrote: I'm using ppp-new branch donwloaded from git repositories and it works fine with vodafone SIM Card (see vodafone.txt attached file). When I change SIM Cards and I try to use TIM, I receive and LPC error (see tim.txt attached file). I attach two files with log Please someone can help me to understand what happen? 16:24:19-004 tcpip.: LCP terminated by peer (PDP context activation failed, no network protocol running) As yueyue papa said, you have to setup correctly your PDP link before starting PPP. PDP context activation failed, no network protocol running is an optional failed reason string sent by your GPRS/3G modem. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] TCP/IP with PPP
Hi Dave, On Mon, Oct 07, 2013 at 10:42:13PM +0700, Dave McLaughlin wrote: Hi all, I am new to the group and new to the library and looking for a bit of advice. I have a project to build a sensor interface with a GSM modem and I need to have the ability to connect via TCP/IP over PPP to the GPRS network. The modem has built in TCP/IP as do a number of them these days but it is limited to 1 connection at a time and does not integrate with any TCP/IP stack in the processor firmware. I need to be able to have multiple connections at the same time. I am targeting a Cortex M4 processor from ST and looking to use the Coocox development software as I am familiar with this from another project. Would the TCP/IP driver work with the likes of FreeRTOS and how easy is it to get it working? This is the easiest part, FreeRTOS itself provide an example port for lwIP. [1] Since you don't need the board-specific Ethernet port, then you only need the memory/thread/mutex/semaphore OS port, thus you can use any lwIP port for FreeRTOS and crush everything related to the Ethernet low level driver. Would you recommend any books on the subject or examples on any websites? I am not looking for a complete working solution, just the basics as I am keen to learn how this all connects together so would really like to do the main work myself but a few pointers along the way would speed up the process. :) If you wish, you can try the lwIP ppp-new branch, which is a complete rework of the lwIP stack. $ git clone -b ppp-new git://git.savannah.nongnu.org/lwip.git You have to write a SIO port (i.e. serial port) for lwIP. The SIO port interface is described in lwip/src/include/lwip/sio.h and is, IMHO, pretty obvious. There are a few examples in the lwip-contrib package: $ git clone git://git.savannah.nongnu.org/lwip/lwip-contrib.git $ find -iname sio.c ./ports/unix/netif/sio.c ./ports/win32/sio.c ./ports/old/ecos/ecos/net/lwip_tcpip/current/src/ecos/sio.c The new PPP interface is described in lwip/src/include/netif/ppp/ppp.h , this should be pretty self-explanatory (Well, I hope it is ;p), look for PUBLIC FUNCTIONS section The following thread, which is exactly what you want to do, may help you: http://lists.nongnu.org/archive/html/lwip-users/2013-06/msg1.html Hope it helps ! :) Sylvain [1] http://www.freertos.org/embeddedtcp.html signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] The lwip linux port - how to use another ip on the existing subnet
Hi Enrique, On Sun, Oct 20, 2013 at 11:33:11AM +0200, Enrique Wellborn wrote: Hi, I was wondering whether it is possible to use the lwip linux port so that it'll use an ip address on my existing subnet. The scenario i'm trying to create is as follows: My Ubuntu machine has a single ethernet device (eth0) with ip: 192.168.0.3/24, gw: 192.168.0.1. I want to create an lwip application that will have ip addr 192.168.0.4 and the same mask and gw. I managed to do it using the windows port (that utilizes winpcap for the task) and it worked great, but when I'm running the simhost app(from the linux port) with the relevant arguments it just fails (I think it has something to do with it trying to create a tun device with an ip address that belongs to the existing subnet of eth0). So, I have 2 questions: 1. Is it possible to create a tun device with ip addr in the existing subnet of eth0? 2. Is there a linux alternative for winpcap that works well on linux (I saw that pcap was not supported on linux), in a way that will enable the above scenario? What you are looking for is a Linux bridge: brctl addbr br0 ifconfig br0 192.168.0.3 netmask 255.255.255.0 ifconfig eth0 0.0.0.0 route del default # probably not nessary route add default gw 192.168.0.1 ifconfig br0 up brctl addif br0 eth0 brctl addif br0 tap0 # once lwIP is running ifconfig tap0 up brctl show # should display the following: bridge name bridge id STP enabled interfaces br0 xxx no eth0 tap0 Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Works with Win7, not Windows XP?
Hi, On Thu, Oct 31, 2013 at 08:34:06AM +, Niall Donovan wrote: Hi, There is evidence that Windows 7 and 8 ignore the MSS value if it is less 576. I have TCP links working between my embedded app and both Windows XP and Windows 7. In my case XP was always working (TCP_MSS = 1518) but when I moved to windows 7 I had tried TCP_MSS 256 to start and it ignored it and defaulted to MSS=576 (windows sent me 576 byte chunks, overflowing my pbufs). I now have TCP_MSS = 576 in my embedded system and it works for both Win XP and Win 7. Well, but there is nothing wrong here, Windows behavior is perfectly fine. Every IPv4 host *MUST* accept IP packets of at least 576 octets, thus you must be ready to receive packets up to 576 octets even if you absolutely don't want to. MSS field in TCP is what you *want* the other side to do when sending frames back to you, setting MSS below 536 might be refused by the other host, since you *must* receive IP packets of at least 576 octets, so there is no reason of setting a MSS below 536. RFC 879 - The TCP Maximum Segment Size and Related Topics, page 2, section 2: The maximum size datagram that all hosts are required to accept or reassemble from fragments is 576 octets. And this is exactly the same for IPv6, except every IPv6 host *MUST* accept IPv6 packets of at least 1280 octets. RFC 2460 - Internet Protocol, Version 6 (IPv6) Specification, page 24, section 5: IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6. So, as well, setting a MSS below 1220 in TCP over IPv6 will probably be refused by the other side. In lwIP, the TCP_MSS option is used to limit the *transmitted* TCP fragment size and sending the MSS TCP option. lwIP accept anything that is passed from the netif, so we conform to the RFC. You also need to ensure that you have allocated pbufs of the necessary size for this MSS to work. Nah, this is wrong, PBUF are chained, so you can use any PBUF size as long as IP and transport headers fit into the first pbuf for performance reasons. But the PBUF_POOL_SIZE * PBUF_POOL_BUFSIZE must be at least 576+LLH bytes long to receive a IPv4 packet. I hope it is or your system does not meet at all minimum requirements for the IP world :p Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Avoid connection close by lwIP server
Hi, On Mon, Dec 16, 2013 at 07:41:06AM +0100, Satz Klauer wrote: Hi, I'm currently new to lwIP and so I'm still trying to understand it. Thus I used the httpserver_raw example as starting point for my application. Since I do not need a http-connection which closes socket after every successfull transmission, but a connection where data are exchanged in both directions for a longer until the client drops the connection, I modified the http-example a bit: parsing for GET / was removed, data are received permanentely and http_parse_request() generates some test-response. Now http_parse_request() returns ERR_OK but the connection is still closed after transmission of my test data. So my question: where is this planned closing of http-connection done? You should learn a little bit how HTTP work. What you actually have to do is adding a HTTP Keep-Alive support, which is a bit more difficult than just keeping the TCP connection open :) See: http://en.wikipedia.org/wiki/HTTP_persistent_connection Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] [ppp-new] Problems connection on Windows7
Hello Felipe, On Sun, Jan 12, 2014 at 10:26:31PM -0200, Felipe Provenzano wrote: Hello guys, My name is Felipe i am working in a device using the Lwip, and we are trying to connect it in a pc using the PPPoS. The first test in the Windows XP worked very well. But nothing worked when we tested in the Windows 7 and higher. I know that Microsoft changed some things after Vista, and thats the reason i started to use the ppp-new branch, i was thinking that with the CHAP-MS support the things could just works. No. :( I am trying to debug the communication, and as far as i arrived there is a problem in the authentication, but i do not know if is possible to solve, or not. Do you could help me figure out whats wrong?? Something is messy around protocol accept/reject. I hope your target have enough RAM/FLASH for heavy debug, so could you enable PRINTPKT_SUPPORT ? :-) Add `#define PRINTPKT_SUPPORT LWIP_DBG_ON` in your lwipopts.h, this will show packet details. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] [ppp-new] Problems connection on Windows7
Hi Felipe, On Tue, Jan 14, 2014 at 01:06:12PM -0200, Felipe Provenzano wrote: Thank you Sylvain, Fortunately, yes, we have enough RAM/FLASH for the extra log \o/ [...] [ 116:23: tcp] rcvd [proto=0x80fd] 01 02 00 0a 12 06 00 00 00 01 [ 116:23: tcp] Unsupported protocol 0x80fd received Everything is fine until this point, 0x80fd is CCP, Compression Control Protocol which is not supported for lwIP. [ 116:23: tcp] sent [LCP ProtRej id=0x2 80 fd 01 02 00 0a 12 06 00 00 00 01] [ 116:23: tcp] ppp_write[1]: len=24 So, we are refusing it, everything still fine. [ 116:23: tcp] tcpip_thread: CALLBACK 6807cbf8 [ 116:23: tcp] rcvd [LCP ProtRej id=0x3 80 21 01 01 00 1c 02 06 00 2d 0f 01 03 06 00 00 00 00 81 06 00 00 00 00 83 06 00 00 00 00] [ 116:23: tcp] Protocol-Reject for 0x8021 received 0x8021 is IPCP, we receive a frame telling us that IPCP is -not- supported, this is weird. The windows host is rejecting our IPCP request, wtf. [ 116:37: tcp] --- Received 35 [ 116:37: tcp] pppos_input[1]: got 35 bytes [ 116:23: tcp] tcpip_thread: CALLBACK 6807cbf8 [ 116:23: tcp] rcvd [LCP TermReq id=0x4 Z\342\032\3777651\000\315t\000\000\000\000] [ 116:23: tcp] LCP terminated by peer (ZM-b^ZM-)^@M-Mt^@^@^@^@) Packets looks corrupted, this might explain the previous behavior. But this is strange... there is CRC16-CCITT on HDLC frames, parsing corrupted frames is nearly-impossible. Are they actually corrupted after low-level PPPoS checked the CRC and before passing them to lwIP PPP stack ? If yes, this looks like a driver corruption issue. I am not saying that this isn't my fault, we don't know yet, this is just what it looks like :) If you need more logs i believe i still having some space to include it. I guess you are using a RS232 link between your Windows host and your target using some kind of USB to Serial convertir, so, could you dump the binary stream by sniffing the Rx + Tx wires using two additional USB to Serial converters ? Or an oscilloscope with protocol decoding able to export the Rx+Tx binary streams. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] [ppp-new] Problems connection on Windows7
Hi Felipe,
On Tue, Jan 14, 2014 at 02:58:02PM -0200, Felipe Provenzano wrote:
Hi Sylvain,
I have news, just after send the last email, the equipment started to work
with my computer.
It was looking suspicious because i was changing the windows register
trying a lot of different stuff.
So i tried it in another virgin computer with windows 7, and i had the
log in the file log.ppp. There is a lot of corrupted packages.
Oh dear, so much dead packets, this is pretty sad :)
Well, this is kind of a lossy link, you cannot expect to set up a PPP
tunnel with such crap. Anyway, this doesn't explain why we get good
checksums with such packets, maybe we are stressing the CRC16 over its
limit.
We changed it to use a physical connection and worked as well, i mean, i
was able to ping the equipment.
So, maybe a good part of the problem was the usb-driver corrupting data,
apparently.
Are you using CTS/RTS flow control ?
I guess the Windows PPP stack expect CTS and RTS signals to be wired by
default, because POTS modems use them by default. Anyway, there is
no hope of having a working PPP serial link without any flow control,
either using CTS/RTS or XON/XOFF. I personally prefer the CTS/RTS way
since embedded USART usually handle that by hardware.
I will make some more tests, but i do not understand why suddenly it
started to work, spirits maybe? I will put it in quarantine before be sure
that there is no problem :)
After be able to ping the equipment i tried to open a connection, it worked
in the direction equipment-pc but not pc-equipment.
Entering in the code i saw the response was dropped at:
case PPP_VJC_COMP: /* VJ compressed TCP */
PPPDEBUG(LOG_INFO, (ppp_input[%d]: vj_comp in pbuf len=%d\n,
pcb-num, pb-len));
/*
* Clip off the VJ header and prepend the rebuilt TCP/IP header and
* pass the result to IP.
*/
if ((vj_uncompress_tcp(pb, pcb-vj_comp) = 0)
(pcb-netif.input)) {
pcb-netif.input(pb, pcb-netif);
return;
}
/* Something's wrong so drop it. */
PPPDEBUG(LOG_WARNING, (ppp_input[%d]: Dropping VJ compressed\n,
pcb-num));
break;
Apparently pcb-netif.input was initialized with 0.
So, I changed from:
if (!netif_add(pcb-netif, pcb-addrs.our_ipaddr, pcb-addrs.netmask,
pcb-addrs.his_ipaddr, (void *)pcb, ppp_netif_init_cb,
*NULL*)) {
memp_free(MEMP_PPP_PCB, pcb);
PPPDEBUG(LOG_ERR, (ppp_new[%d]: netif_add failed\n, pcb-num));
return NULL;
}
To:
if (!netif_add(pcb-netif, pcb-addrs.our_ipaddr, pcb-addrs.netmask,
pcb-addrs.his_ipaddr, (void *)pcb, ppp_netif_init_cb,
*ip_input*)) {
memp_free(MEMP_PPP_PCB, pcb);
PPPDEBUG(LOG_ERR, (ppp_new[%d]: netif_add failed\n, pcb-num));
return NULL;
}
And it worked, my question is, can it cause some side effects?
PS: I am using the last version of ppp_new branch i found in the
repository(downloaded a couple of days ago)
Good catch !, this is obviously a bug, which is now fixed in the ppp_new
branch. Thank you.
Thank you very much for your support!
You are welcome :)
Sylvain
signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] How to use PPP with NULL-MODEM serial cable
Hello, On Mon, Mar 24, 2014 at 03:20:25PM +0800, zfb...@zju.edu.cn wrote: Hi everyone, I have transplanted LWIP -1.4.0 to an Oribta board, which don't have NIC， so I want to use ppp to connect it to a Linux PC using a NULL-MODEM serial cable. On the PC ,I set up a PPP sever to listen connect from the board. The OS in the board is similar to vxworks. Now, it came the problem that how to use PPP to set up a client on the board and make the socket API available. I have no idea to use PPP in this situation, can anyone help me? This does not look like an uncommon PPP situation from my point of view. If you are looking for a beginner documentation, PPP lwIP API is quite well documented in include files and lwip-contrib have working PPP examples for Linux or Win32 serial or pipe stack, which are pretty good at how to write the PPPoS low-level driver required by lwIP. lwip-contrib/ports/win32/sio.c lwip-contrib/unix/netif/sio.c Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Which PPP implementation should be used? PPP-new or PPP from the master branch
Hello LMao, On Mon, Mar 31, 2014 at 12:57:56PM +, l...@moog.com wrote: Hi there, I am new to the lwIP community and try to use lwIP v1.4.1 to implement a gateway between an Ethernet interface and PPP on ATM91SAM7x. I found a port (with lwIP 1.3) in FreeRTOS community contributions and migrated to lwIP 1.4.1. It works fine with the Ethernet part, but the port doesn't contain PPP part. Therefore I need add PPP application by myself. Are you sure Atmel does not provide a working and well-written lwIP port in their lovely ASF ? I guess there is one along with a MAC driver for AT91SAM µC in the same way they do for AT32 µC. I have read the lwIP PPP wiki and some archived messages regarding PPP from this mail list. In the wiki, it talks about the PPP implementation contained in the master branch, but in the mail list, it seems everybody uses ppp-new. My question is which one should I use? Well, cannot answer, because I am the ppp-new maintainer, so my answer is pretty obvious on this point ;-) What are their differences? ppp-new is a fresh new port of the latest pppd codebase for lwIP, including 10 missing years of pppd improvement in lwIP and some features are added. So, IIRC, at least: + MSCHAP support (pppd) + EAP support (pppd) + multiple PPP sessions support (me) + L2TPv2 LAC support (me) + IPv6 support (pppd+me) + 10 years of bugfixes (pppd) And, I guess this is worth considering it, but I am willing to help you if you encounter issues with ppp-new, but I will NOT for master branch, and no one will. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Which PPP implementation should be used? PPP-new or PPP from the master branch
Hello Charles, On Mon, Mar 31, 2014 at 08:17:59PM +, l...@moog.com wrote: Thanks, Sylvain. I think the answer is quite obvious now: ppp-new is the way to go since it has you and the community's support. I couldn't find a complete example code of using ppp-new's PPP implementation. Especially an example at application layer shows how to specify IP address for a PPP interface, etc. This is kind of unusual, since our PPP stack only supports PPP client the IP address is usually given by the server. If you really need this we can add macro to set the necessary field in the PPP neg-configuration. Could you quickly sketch a code snippet for PPP application layer? It mostly depends on which lower level protocol you wish to use, PPPoS, PPPoE or PPPoL2TP, I am sure I already provided hints on this list which should be on the list archive. Anyway, this isn't hard, the API is fully documented in headers and should be explanatory enough to give you the way to proceed. If you really need an example, you can checkout the ppp-new branch of the contrib Git repository, it contains my quick'n'dirty source code I use to test the ppp-new branch in lwip-contrib/ports/unix/proj/minimal. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Which PPP implementation should be used? PPP-new or PPP from the master branch
Hello Charles, On Tue, Apr 01, 2014 at 11:57:03AM +, l...@moog.com wrote: Hi Sylvain, Thanks for your support. I didn't know it doesn't support PPP server. Any plans to add PPP server ? What needs be done in order to support PPP server? Answering both in one bundle, since answers to them ended up to be mixed. First, it builds if you set PPP_SERVER for a unix build because I already done all the required port to lwIP on this part, there are some remaining FIXME inside PPP_SERVER parts which must be fixed before expecting doing a build for an embedded device, but none of them are looking hard to fix for any experienced C developer. However, some work is required to add a way to get logins and passwords in order to authenticate clients. pppd code using /etc/ppp/pap-secrets and /etc/ppp/chap-secrets is obviously disabled. But, a huge work is required to add passive interface (= waiting for something, = server) support to lwIP PPP stack (in ppp.c), and PPP lower layers require attention as well, which should be only waiting for PPPoS, PADO and PADS for PPPoE and full LNS support for PPPoL2TP. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] lwipopts questions (updating to 1.4.1 from 1.3.2)
Hi, On Wed, Apr 02, 2014 at 07:19:42AM +0300, Dimax wrote: I have some questions regrading proper configuration of the lwip in lwipopts.h file. I'm running lwip 1.4.1 on STM32F2x7 with FreeRTOS 1. SYS_LIGHTWEIGHT_PROT When do I need this protection? Considering that lwip stack run in a single thread do I need inter-task protection? Probably, this is required if you are using pbuf_alloc() outside of lwIP thread, this is very likely in your Ethernet rx thread. 2. CHECKSUM_GEN_ICMP If my CPU has HW checksum should I set it to 0 (like GEN_IP) ? In former lwip-1.3.2 there was no such define so I do not know how to configure it properly. Try and see :) I had a problem due to a same name of the file timers.c in FreeRTOS and lwIP as my Makefile puts all output modules to the same directory. Well, you should not do that when you are using 3rd party softwares. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Missing typedef in vj.h fsm.h ppp.h etc
Hello Charles, On Fri, Apr 04, 2014 at 03:54:07PM +, l...@moog.com wrote: Sylvain, I try to compile ppp-new and my compiler(Keil) gave compiling errors like this: I find the missing typedefs are defined in ppp_impl.h file. It seems vj.h etc doesn't include ppp_impl.h. Am I doing something wrong? Well, but vj.c includes netif/ppp/ppp_impl.h before netif/ppp/vj.h, so this should not happen. Looks like a buggy preprocessor/compiler at first sight, could you tell on which .c files it happens ? Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Missing typedef in vj.h fsm.h ppp.h etc
Hello Charles, On Fri, Apr 04, 2014 at 04:47:38PM +, l...@moog.com wrote: A few files have the problem: init.c, memp.c, pbuf.c, timers.c, ppp.c, api_lib.c, api_msg.c, pppapi.c, sockets.c and tcpip.c Well, this is not helping much, could you paste the full compiler output from a cleaned source tree, including compiler command line ? Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Missing typedef in vj.h fsm.h ppp.h etc
Hello Charles, On Fri, Apr 04, 2014 at 05:44:17PM +, l...@moog.com wrote: Hi Sylvain, The compiler log is in the attached file. Keil uVision use ARMCC compiler, here's the command line options for compiling: Thank you, this is helpful, I pushed a little change about the order of u_* type compat declarations, does it work for you ? Anyway, this is quite surprising to still find a compiler without u_* type native support. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Missing typedef in vj.h fsm.h ppp.h etc
Hello Gavin, On Mon, Apr 07, 2014 at 11:28:02AM +1200, Gavin Lambert wrote: I'm surprised that you think that there would be a compiler with native support for those. They're not in any compiler standard that I'm aware of. (They do come from BSD sockets, but that's hardly guaranteed to always be there or else why does lwIP exist?) I hate answering to that, this is pointless and time-consuming, this is in no way useful for lwIP and it should have been sent off-list, but since this is addressed to me, I guess I have to answer because I hate not answering things :-) So, yup, you are right, however the missing (misplaced, to be exact) u_type declaration is there for quite a while and this is the first evidence of someone tripping over it. I know there is a very few users of lwIP PPP stack but it looks like most compilers supports non-standard u_type by default. I hope my thought is explained :-) Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
