Christiaan Simons | 1 Dec 09:22 2005
Picon

Re: ARP Queueing memory leak


lwip-users-bounces+christiaan.simons=axon.tv@... wrote
on 30-11-2005
13:07:07:

>
> After getting the latest revision in CVS, the inet.c (line 75) file is
> updated with "dataptr = ((char*)dataptr+2);" is replaced with line "(void
> *)((u16_t *)dataptr + 1);"
>
> This seems to be a bug or?
>

We've noticed this may be bug.

I was just fiddling to get it in
a workable state for the 16 bit c16x mcu.

The void pointer increment was clearly wrong,
the u16_t increment is only correct for aligned
input data.

The "two char" increment looks more correct,
but the routine will still fail for the c16x.

I'm a bit lost on how to get the checksumming
right for all architectures, both little-
an big-endian, 16-bit aligned and unaligned access.

The best thing you can do is stick with the lwip
(Continue reading)

Kjell-Erik Klevan | 1 Dec 09:34 2005

inet.c bug


Oops, seems that I posted the message below with wrong heading - sorry.

My question below is still open.

Regards,

Kjell-Erik

  _____  

From: Kjell-Erik Klevan [mailto:kek@...] 
Sent: Wednesday, November 30, 2005 1:07 PM
To: 'Mailing list for lwIP users'
Subject: ARP Queueing memory leak

Hi!

After getting the latest revision in CVS, the inet.c (line 75) file is
updated with "dataptr = ((char*)dataptr+2);" is replaced with line "(void
*)((u16_t *)dataptr + 1);"

This seems to be a bug or?

Regards,

Kjell-Erik

(Continue reading)

Cedric VINCENT | 1 Dec 20:11 2005
Picon

Re: help! performance of lwip?

On 11/16/05, Cedric VINCENT <cedric.vincent@...> wrote:
> On 11/15/05, wang youramulet <wzroom@...> wrote:
> > hi,
> >
> > Is there anybody know lwip reasonable range of speed, such as send and
> > receive udp pakets? With and without the os, such as psos or ucosII.
>
> For instance, I reach up
> to 600 kBytes/s (receiving UDP packets) with current Xilinx drivers (on
> PPC 405   <at>  350 MHz, without OS),

When I-cache and D-cache are enabled, the target can receive (UDP) up
to 2 MBytes/s.

Regards,
Cedric.

--
------------------------------------------
http://cedric.vincent.perso.free.fr/
------------------------------------------
remy.newsgroup | 3 Dec 09:58 2005
Picon

RE: PPP without an OS

Hi Karl,

Thank you for your reply, I would not used SLIP because the remote peer is not
windows and supports only PPP with authentication. I'll modify PPP to support
NO-OS version of lwIP.

Rémy

Hi Rémy,

I also looked at using PPP without an OS and changed my mind after
finding out that Windows supports SLIP. I don't need the authentication
and security.

I have a version of a SLIP driver that I could share, although it's
probably not public release ready.

Karl

Hello,

I'am trying to use the PPP stack for lwIP without an OS.
The ppp stack assumes that you use a multithreaded OS.

1) I'am wondering if someone has already used the PPP stack without an
OS.
2) I guess I have to rewrite the pppMain() function.
3) It seems that the sio_xxx functions are blocking functions, am I
right?
4) Is there a PPP port on win32 using the serial communication ports?
(Continue reading)

Michael Portmann | 5 Dec 03:33 2005

RE: PPP without an OS

Rémy,

  I attempted to do this and could get a PPP connection established with my
windows xp system (COM1 <-> COM2), I think I got it connecting over GPRS PPP
as well. I had some trouble with serving up all items of the test web page.
Ping worked fine. I haven't done any more work on this since early this
year.

  I built starting with the ports/msvc6 code base, adding in the ppp code
and opened up the while loop in
pppMain() so it becomes a function that is called repetitively like the
other tcp calls rather than the main() function of a process.

  Other work has to be done with the sys functionality which isn't too bad.
I set NO_SYS
and created the following functions:
dotimeouts function that handles struct sys_timeouts
Sys_arch_block function that busy waits.

And basic do nothing versions of:
sys_mbox_new, sys_mbox_free, sys_mbox_post, sys_arch_mbox_fetch,
sys_sem_new, sys_arch_sem_wait, sys_sem_signal, sys_sem_free, sys_init,
sys_arch_timeouts, sys_thread_new.

Regards
Mike
Prateek Jain | 5 Dec 09:40 2005
Picon

Re: PPP without an OS

Hi Remy,
 
   I am not sure whether you can do it or not. The way ppp is started is
 
tcpip_init(YourcallbackFunc,NULL);
pppInit();
 
First call starts a tcpip thread and second one starts a pp thread.
 
There is some interaction between tcpip and ppp threads ( tcpip_callback(pppStartCB, arg) call in pppMain).
So until unless you have a mutithreaded OS, it will not be very easy. You will have to understand the interaction and implement it in one thread somehow.
 
I also feel that sio_XXX are blocking functions.
 
Reagrding item 4, I feel it's not very difficult. You will get serrial comm code on net. Just call the read function from your sio_read fuinction.
 
Prateek

 
On 11/29/05, remy.newsgroup-GANU6spQydw@public.gmane.org <remy.newsgroup-GANU6spQydw@public.gmane.org> wrote:


Hello,

I'am trying to use the PPP stack for lwIP without an OS.
The ppp stack assumes that you use a multithreaded OS.

1) I'am wondering if someone has already used the PPP stack without an OS.
2) I guess I have to rewrite the pppMain() function.
3) It seems that the sio_xxx functions are blocking functions, am I right?
4) Is there a PPP port on win32 using the serial communication ports?

I use the lwip CVS head version (26/11/2005).

Thanks,
Rémy


_______________________________________________
lwip-users mailing list
lwip-users <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users
Prateek Jain | 5 Dec 09:44 2005
Picon

Re: help! where can I get the latest and detailed document about lwip!

Hi Wang,
 
   Just have a look at the
if you want to know the theory.
t has some examples in the end to..Hope it helps.

Prateek



 
On 11/21/05, Wang Zheng <wzroom <at> yahoo.com.cn> wrote:
hi all,
 
where can I get the latest and detailed document about lwip!  The *.txt in the lwip1.1.0 is not detailed enough. I am interesting in the structure and theory of the lwip.
 
Is anybody can give me some demo about how to use lwip sequential API and BSD sockets API ,such as udp or tcp send and receive data.I want to know if I made mistakes in my project.
 
thanks!

雅虎免费G邮箱-中国第一绝无垃圾邮件骚扰超大邮箱
雅虎助手¨D搜索、杀毒、防骚扰


_______________________________________________
lwip-users mailing list
lwip-users <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users


_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users
Prateek Jain | 5 Dec 09:57 2005
Picon

Re: LCP Termination Request missing

Hi Ghislain,
 
    Just a suggestion.
PPP thread waits on sio_read. When you call pppCLose, It calls pppMainWakeup which in turn calls sio_read_abort. In case if you have not implemented sio_read_abort, it may give some problems. I feel with this function call, the PPP thread should no longer wait in sio_read. it should come out.
 
Prateek

 
On 11/9/05, Ghislain Mary <ghislain.mary-L+G57L1VLRbR7s880joybQ@public.gmane.org> wrote:
Thanks for these explanations. Maybe that will help be to solve the
problem I encounter.

Ghislain


David Empson wrote:
> David Haas <dhaas-pIzyFAQJLTv2fBVCVOL8/A@public.gmane.org> wrote:
>
>>LCP is a layer on PPP.
>>
>>I don't know that code. Who is the expert on PPP? How do you tell the
>>link to go up and down?
>
>
> I'm no expert either, but I read the RFC a while ago and have a general
> understanding of it, at least up to the LCP layer.
>
> Assuming a simple PPP implementation (IP only), terminating a connection may
> require an exchange of IPCP packets (Internet Protocol Control Protocol) to
> negotiate termination of the IP connection. This should be followed by an
> LCP "terminate-request". The other side is supposed to respond with LCP
> "terminate-ack", and then both sides can drop the connection. The
> terminate-request should be retried if no terminate-ack is received.
>
> This should all be done in lwIP's PPP driver, which is below the IP layer.
>
>>From a quick glance at the code in src/netif/ppp, particularly fsm.c, lcp.c
> and ppp.c, it looks like the code is trying to send a TERMREQ (with retries)
> and expects to get a TERMACK response. lcp_close() calls fsm_close(), which
> sets the state to CLOSING and sends the first TERMREQ.
>
> According to Ghislain Mary's earlier message, it seemed that the TERMREQ
> wasn't being sent even if lcp_close() was called directly by application
> code.
>
> This suggests a possible problem relating to delays waiting for the LCP
> state to reach CLOSED. Perhaps the physical disconnect is happening
> prematurely.
>
> Looking at pppClose(), it triggers the LCP shutdown via a kill_link flag,
> then waits for LCP to reach PHASE_DEAD before returning, but only if there
> is no link status callback function. If that function has been provided,
> pppClose() will return immediately, and the LCP close won't have finished
> yet. There may be a separate mechanism to poll the state until LCP is DEAD,
> but I haven't looked for it.
>
> I'm not familiar enough with how lwIP's ppp interfaces to the serial driver
> (which must be application specific) but I expect details like physically
> hanging up the modem connection (dropping DTR or sending an ATH command) are
> the responsibility of the serial/modem driver.
>
>
>>Kieran Mansley wrote:
>>
>>
>>>On Tue, 2005-11-08 at 09:07 +0100, Ghislain Mary wrote:
>>>
>>>
>>>>Nobody's having an idea of how to tell lwIP to send an LCP Termination
>>>>Request?
>>>
>>>I don't know what LCP is, but lwIP shouldn't have to do anything unusual
>>>to transmit particular parts of a higher layer protocol - it's all just
>>>a stream of bits as far as lwIP is concerned.
>>>
>>>Kieran
>
>
>
>
> _______________________________________________
> lwip-users mailing list
> lwip-users <at> nongnu.org
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>


_______________________________________________
lwip-users mailing list
lwip-users-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
http://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users
Jan Ulvesten | 6 Dec 23:25 2005
Picon

NIOS II port: Request for memory alignement macro to be included in lwip source

Hi

In Alteras uCOS II port of lwIP for NIOS II, 3 source files have been
changed.

__attribute__ ((aligned (MEM_ALIGNMENT))) is added to a few defs (5) to
control the memory alignment (gnu C syntax).

Patching the standard code base is by no mean the preferred method of
targeting alignment. I suppose that an array is always aligned at an
even boundary, but the 4-byte alignment is only achieved using
__attribute__ ((aligned (4))). 

It could easily be avoided adding a macro the defs below, e.g.:

#define MEM_ALIGMENT_ATTR __attribute__ ((aligned (MEM_ALIGNMENT)))

- or -

#define MEM_ALIGMENT_ATTR

The definition could then be:

static u8_t ram[MEM_SIZE + sizeof(struct mem) + MEM_ALIGNMENT]
MEM_ALIGMENT_ATTR;

Altera changes:

------------------------------------------------------------------------
----
mem.c                 
static u8_t ram[MEM_SIZE + sizeof(struct mem) + MEM_ALIGNMENT]
__attribute__ ((aligned (MEM_ALIGNMENT)));

------------------------------------------------------------------------
----ipfrag.c:
static u8_t ip_reassbuf[IP_HLEN + IP_REASS_BUFSIZE] __attribute__
((aligned (MEM_ALIGNMENT)));

static u8_t ip_reassbitmap[IP_REASS_BUFSIZE / (8 * 8)] __attribute__
((aligned (MEM_ALIGNMENT)));

static u8_t ip_reassbuf[IP_HLEN + IP_REASS_BUFSIZE] __attribute__
((aligned (MEM_ALIGNMENT)));

------------------------------------------------------------------------
----pbuf.c
static u8_t pbuf_pool_memory[(PBUF_POOL_SIZE *
MEM_ALIGN_SIZE(PBUF_POOL_BUFSIZE + sizeof(struct pbuf)))] __attribute__
((aligned (MEM_ALIGNMENT)));

------------------------------------------------------------------------
----

+ in dhcp.h a 
#if LWIP_DHCP==1 could be used to avoid defining protos when DHCP is
disabled.

Jan Ulvesten
SICOM
Derek Guerdon | 7 Dec 06:46 2005
Picon
Picon

Re: NIOS II port: Request for memory alignement macro to be included in lwip source

Jan Ulvesten wrote:
>In Alteras uCOS II port of lwIP for NIOS II, 3 source files have been
>changed.
>
>__attribute__ ((aligned (MEM_ALIGNMENT))) is added to a few defs (5) to
>control the memory alignment (gnu C syntax).
>
>Patching the standard code base is by no mean the preferred method of
>targeting alignment. I suppose that an array is always aligned at an
>even boundary, but the 4-byte alignment is only achieved using
>__attribute__ ((aligned (4))). 
>
>It could easily be avoided adding a macro the defs below, e.g.:
>
>#define MEM_ALIGMENT_ATTR __attribute__ ((aligned (MEM_ALIGNMENT)))
>
>- or -
>
>#define MEM_ALIGMENT_ATTR
>
>The definition could then be:
>
>static u8_t ram[MEM_SIZE + sizeof(struct mem) + MEM_ALIGNMENT]
>MEM_ALIGMENT_ATTR;

That works well for those who have the problem and use gcc, but it
doesn't help those with the same problem who are not using gcc. I
don't think the solution requires the use of extensions, anyhow. If
the user can determine a data type with the greatest alignment
requirements, the compiler can do the dirty work -- in an ANSI-C
manner to boot.

For the code below, assume that in "cc.h" there is a typedef named
'max_align_t' that defines a data type that has the maximum alignment
requirements of the data types in the system.

>
>
>Altera changes:
>
>------------------------------------------------------------------------
>----
>mem.c                 
>static u8_t ram[MEM_SIZE + sizeof(struct mem) + MEM_ALIGNMENT]
>__attribute__ ((aligned (MEM_ALIGNMENT)));
>
Use max_align_t to ensure the RAM buffer is maximally aligned:

static union {
    max_align_t m; /* Guarantees this union has maximum alignment */
    u8_t ram[MEM_SIZE + sizeof(struct mem) + MEM_ALIGNMENT];
} rambuf;

static u8_t * const ram = rambuf.ram;

>------------------------------------------------------------------------
>----ipfrag.c:
>static u8_t ip_reassbuf[IP_HLEN + IP_REASS_BUFSIZE] __attribute__
>((aligned (MEM_ALIGNMENT)));
>
>static u8_t ip_reassbitmap[IP_REASS_BUFSIZE / (8 * 8)] __attribute__
>((aligned (MEM_ALIGNMENT)));
>
>static u8_t ip_reassbuf[IP_HLEN + IP_REASS_BUFSIZE] __attribute__
>((aligned (MEM_ALIGNMENT)));
>
Use struct ip_hdr to ensure that &ip_reassbuf[0] is a validly aligned
address for a struct ip_hdr object.

static union {
    struct ip_hdr h; /* Guarantees this union has proper alignment */
    u8_t buf[IP_HLEN + IP_REASS_BUFSIZE];
} ip_reass;

static u8_t * const ip_reassbuf = ip_reass.buf;

I don't think reassbitmap needs to be aligned since it appears to be
always accessed as a character array (although I may have missed some
code where it isn't). 

>------------------------------------------------------------------------
>----pbuf.c
>static u8_t pbuf_pool_memory[(PBUF_POOL_SIZE *
>MEM_ALIGN_SIZE(PBUF_POOL_BUFSIZE + sizeof(struct pbuf)))] __attribute__
>((aligned (MEM_ALIGNMENT)));
>
>------------------------------------------------------------------------
>----

As above, this object could be created as a union containing
max_align_t to ensure the buffer is properly aligned. This module
would probably benefit more from a replacing the u8_t array with just
an array of structures. They do not appear to be used in any other
way.

Just my suggestion for trying to keep the solution within hailing
distance of ANSI-C.

--

-- 
Derek Guerdon

Gmane