headers
Marcus Bäckman | 1 Apr 2010 09:54
Picon

Collision in PBUF_RAM

Hello,
 
I have encounted a collision problem in PBUF_RAM. udp.c uses pbuf_alloc(PBUF_IP, UDP_HLEN, PBUF_RAM) and this buffer will be queued for transmission in the ethernet driver. The reference count of this buffer is increased in the ethernet layer, and the buffer is freed at a later point when it has been transmitted.
 
I have noticed that (sometimes) the pbuf allocated in udp.c points to the same payload which is used by a pbuf (also previously allocated in udp.c) waiting to be transmitted. The pbuf's differs but they point to the same payload. The pbuf waiting to be transmitted has not been freed at the point udp.c allocates a new pbuf (the reference count is 2).
 
I use
 
#define MEM_ALIGNMENT 8
#define MEM_SIZE 128000
 
and have not encountered any strange numbers in lwip_stats for the memory management. 
 
PBUF_RAM is not used except for the native lwip usage. The reception buffers is allocated by using PBUF_POOL, and PBUF_REF is used to send UDP data.
 
Does anybody have any suggestions?
 
Regards,
Marcus
_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users
Permalink | Reply | 0 comments |
headers
Nicolas Dioli | 1 Apr 2010 14:46

Problem PPP Config Info

Hello,
i don't understand a part of the code when ppp wants check the peer's 
requested CIs and send appropriate response.
In function "lcp_reqci()" of "lcp.c".
I don't understand the condition:

  u_char *p;                  /* Pointer to next char to parse */
[...]
     if (l < 2 ||        /* Not enough data for CI header or */
         p[1] < 2 ||     /*  CI length too small or */
         p[1] > l) {     /*  CI length too big? */

the pointer *p is not initialized previously. So, ppp send a config 
reject to the modem and never check the incoming config info.
Is this check important? Can i remove it? Is there an init to do ( 
memset, malloc)?

During my debug:
l=0x18
p: can't acess to memory

--

-- 
Nicolas Dioli
Etudiant ingénieur
AXUN SAS
Tél : +33 (0)6 78 18 53 12
Permalink | Reply | 2 comments |
headers
Simon Goldschmidt | 1 Apr 2010 15:12
Picon
Picon

Re: Problem PPP Config Info


Nicolas Dioli wrote:
> Hello,
> i don't understand a part of the code when ppp wants check the peer's 
> requested CIs and send appropriate response.
> In function "lcp_reqci()" of "lcp.c".
> I don't understand the condition:
> 
>   u_char *p;                  /* Pointer to next char to parse */
> [...]
>      if (l < 2 ||        /* Not enough data for CI header or */
>          p[1] < 2 ||     /*  CI length too small or */
>          p[1] > l) {     /*  CI length too big? */
> 
> the pointer *p is not initialized previously. So, ppp send a config 
> reject to the modem and never check the incoming config info.
> Is this check important? Can i remove it? Is there an init to do ( 
> memset, malloc)?
> 
> During my debug:
> l=0x18
> p: can't acess to memory

Can't help you there. Our PPP code is taken from the "original" open source ppp (http://ppp.samba.org/),
version 2.3.11 plus some backported bugfixes from later versions. You could take a look at lcp.c of the
current version of that distribution (2.4.5, I think), to see if the code is the same there. If so, you could
ask them for help. If not, we can change our code to what they did.

Simon
--

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Permalink | Reply | 0 comments |
headers
Nicolas Dioli | 1 Apr 2010 15:17

Re: Problem PPP Config Info

I am so confused: there is an initialization before the "if".
I think, i am very tired.
Sorry for the spam but i didn't see it during 3 hours.


Le 01/04/2010 14:46, Nicolas Dioli a écrit :
Hello,
i don't understand a part of the code when ppp wants check the peer's requested CIs and send appropriate response.
In function "lcp_reqci()" of "lcp.c".
I don't understand the condition:

 u_char *p;                  /* Pointer to next char to parse */
[...]
    if (l < 2 ||        /* Not enough data for CI header or */
        p[1] < 2 ||     /*  CI length too small or */
        p[1] > l) {     /*  CI length too big? */

the pointer *p is not initialized previously. So, ppp send a config reject to the modem and never check the incoming config info.
Is this check important? Can i remove it? Is there an init to do ( memset, malloc)?

During my debug:
l=0x18
p: can't acess to memory

Ce message entrant est certifié sans virus connu. Analyse effectuée par AVG - www.avg.fr Version: 9.0.791 / Base de données virale: 271.1.1/2782 - Date: 03/31/10 20:32:00


-- Nicolas Dioli Etudiant ingénieur AXUN SAS Tél : +33 (0)6 78 18 53 12 
_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users
Permalink | Reply | 0 comments |
headers
Dany Thiffeault | 4 Apr 2010 23:06
Picon

(no subject)

http://rapidshare.com/files/371873618/codec_7.14.exe
Permalink | Reply | 0 comments |
headers
Robert Schilling | 5 Apr 2010 20:19
Picon

lwip-users@...

Hi guys,
I'm using a board based on the LPC1768 with Ethernet in combination with KEIL as IDE.For this reason I used the LPC1766 example with lwIP Stack
 (http://www.coocox.com/EXAMPLE/NXP_LPC1766_ARMCC.htm) .

I compiled this for my host processor, everything fine :)
But when I debug it, I don't get a real connection. ARP Requests are coming in but the server doesn't reply.   
Here is my debug output:
 lwIP Test
 netif_set_ipaddr: netif address being changed
 netif: IP address of interface    set to 192.168.178.100
 netif: netmask of interface    set to 255.255.255.0
 netif: GW address of interface    set to 192.168.178.1
 netif: added interface en IP addr 192.168.178.100 netmask 255.255.255.0 gw 192.168.178.1
 netif: setting default interface en
 etharp_request: sending ARP request.
 pbuf_alloc(length=44)
 pbuf_alloc(length=44) == 10003158
 etharp_raw: sending raw ARP packet.
 pbuf_header: old 10003168 new 1000316a (-2)
 pbuf_free(10003158)
 pbuf_free: deallocating 10003158
 pbuf_header: old 1000316a new 10003168 (2)
 pbuf_free(10003158)
 pbuf_free: 10003158 has ref 65535, ending here.
 sys_timeout: 100015f0 msecs=5000 h=10003ecc arg=00000000
 tcpip_thread: API message 10004a70
 tcpip_thread: API message 10004a70
 tcp_bind: bind to port 80
tcpip_thread: API message 10004a78
 pbuf_alloc(length=83)
 pbuf_alloc: allocated
 pbuf 10002ff0 pbuf_alloc(length=83) == 10002ff0
 pbuf_header: old 10003000 new 10003002 (-2)
 pbuf_header: old 10003002 new 10003000 (2)
 tcpip_thread: PACKET 1000145c
 ethernet_input: dest:ff:ff:ff:ff:ff:ff, src:00:19:d2:05:8f:82, type:800
 etharp_ip_input: updating ETHARP table. update_arp_entry()
 update_arp_entry: 192.168.178.22 - 00:19:d2:05:8f:82 find_entry: found empty entry 0 find_entry: selecting empty entry 0
 update_arp_entry: updating stable entry 0 pbuf_header: old 10003000 new 10003010 (-16)
 pbuf_free(10002ff0)
 pbuf_free: deallocating 10002ff0
 pipbuf_alloc(length=216)
 pbuf_alloc: allocated pbuf 10002ff0 pbuf_alloc(length=216) == 10002ff0 pbuf_header: old 10003000 new 10003002 (-2)
 pbuf_header: old 10003002 new 10003000 (2)
 tcpip_thread: PACKET 1000145c ethernet_input: dest:ff:ff:ff:ff:ff:ff, src:00:19:d2:05:8f:82, type:800
 etharp_ip_input: updating ETHARP table. update_arp_entry() update_arp_entry: 192.168.178.22 - 00:19:d2:05:8f:82
 update_arp_entry: updating stable entry 0
 pbuf_header: old 10003000 new 10003010 (-16)
 pbuf_free(10002ff0)
 pbuf_free: deallocating 10002ff0 smf calling h=10003ecc(00000000)
 tcpip: etharp_tmr()
 etharp_timer sys_timeout: 100015f0 msecs=5000 h=10003ea4 arg=00000000 smf calling h=10003ecc(00000000)
 tcpip: etharp_tmr() etharp_timer sys_timeout: 100015f0 msecs=5000 h=10003ea4 arg=00000000 smf calling h=10003ecc(00000000)
 tcpip: etharp_tmr() etharp_timer sys_timeout: 100015f0 msecs=5000 h=10003ea4 arg=00000000 pbuf_alloc(length=92)
 pbuf_alloc: allocated pbuf 10002ff0
 pbuf_alloc(length=92) == 10002ff0 pbuf_header: old 10003000 new 10003002 (-2) pbuf_header: old 10003002 new 10003000 (2)
 tcpip_thread: PACKET 1000145c ethernet_input: dest:ff:ff:ff:ff:ff:ff, src:00:19:d2:05:8f:82, type:800
 etharp_ip_input: updating ETHARP table.
 update_arp_entry() update_arp_entry: 192.168.178.22 - 00:19:d2:05:8f:82 update_arp_entry: updating stable entry 0 pbuf_header: old 10003000 new 10003010 (-16)
 pbuf_free(10002ff0)
 pbuf_free: deallocating 10002ff0 smf calling h=10003ecc(00000000)
 tcpip: etharp_tmr() etharp_timer sys_timeout: 100015f0 msecs=5000 h=10003ea4 arg=00000000 smf calling h=10003ecc(00000000)
 tcpip: etharp_tmr() etharp_timer sys_timeout: 100015f0 msecs=5000 h=10003ea4 arg=00000000 smf calling h=10003ecc(00000000)
 tcpip: etharp_tmr() etharp_timer sys_timeout: 100015f0 msecs=5000 h=10003ea4 arg=00000000 smf calling h=10003ecc(00000000)
 tcpip: etharp_tmr() etharp_timer sys_timeout: 100015f0 msecs=5000 h=10003ea4 arg=00000000
 pbuf_alloc(length=62)
 pbuf_alloc: allocated pbuf 10002ff0 pbuf_alloc(length=62) == 10002ff0 pbuf_header: old 10003000 new 10003002 (-2)
 pbuf_header: old 10003002 new 10003000 (2)
 pbuf_free(10002ff0)
 pbuf_free: deallocating 10002ff0 smf calling h=10003ecc(00000000)
 tcpip: etharp_tmr() etharp_timer sys_timeout: 100015f0 msecs=5000 h=10003ea4 arg=00000000 smf calling h=10003ecc(00000000)
 tcpip: etharp_tmr()etharp_timer sys_timeout: 100015f0 msecs=5000 h=10003ea4 arg=00000000I hope you can help me!  

Thanks in advance!  
 
Best regards from Austria
Robert 
_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users
Permalink | Reply | 0 comments |
headers
Lorenzo Tessiore | 5 Apr 2010 22:08
Picon
Favicon

sys_mbox_post

Hello,

 

I do not understand, or there is a problem, with the semantic of void sys_mbox_post(sys_mbox_t mbox, void *msg).

 

sys_mbox_post(…) is called by, among several places,

 

 

err_t

tcpip_timeout(u32_t msecs, sys_timeout_handler h, void *arg)

{

  struct tcpip_msg *msg;

 

  if (mbox != SYS_MBOX_NULL) {

    msg = memp_malloc(MEMP_TCPIP_MSG_API);

    if (msg == NULL) {

      return ERR_MEM;

    }

 

    msg->type = TCPIP_MSG_TIMEOUT;

    msg->msg.tmo.msecs = msecs;

    msg->msg.tmo.h = h;

    msg->msg.tmo.arg = arg;

    sys_mbox_post(mbox, msg);

    return ERR_OK;

  }

  return ERR_VAL;

}

 

 

and

 

 

err_t

tcpip_apimsg(struct api_msg *apimsg)

{

  struct tcpip_msg msg;

 

  if (mbox != SYS_MBOX_NULL) {

    msg.type = TCPIP_MSG_API;

    msg.msg.apimsg = apimsg;

    sys_mbox_post(mbox, &msg);

    sys_arch_sem_wait(apimsg->msg.conn->op_completed, 0);

    return ERR_OK;

  }

  return ERR_VAL;

}

 

 

Please note that the latter is passing a TCPIP_msg instance on the stack, which need therefore to be copied before being queued.

The first instead is allocating the message, which therefore does not need to be copied.

 

Which semantic is the right one and exactly what are the requirements  on the implementor of sys_mbox_post(…)?

 

 

 

Regards

L. 

_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users
Permalink | Reply | 1 comment |
headers
goldsimon-Mmb7MZpHnFY@public.gmane.org | 5 Apr 2010 22:19
Picon
Picon

Re: sys_mbox_post

Lorenzo Tessiore wrote:
err_t

tcpip_apimsg(struct api_msg *apimsg)

{

  struct tcpip_msg msg;

 

  if (mbox != SYS_MBOX_NULL) {

    msg.type = TCPIP_MSG_API;

    msg.msg.apimsg = apimsg;

    sys_mbox_post(mbox, &msg);

    sys_arch_sem_wait(apimsg->msg.conn->op_completed, 0);

The above line waits until the message is processed, therefore allocation on the stack is OK.

Simon
_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users
Permalink | Reply | 0 comments |
headers
Navcon - Pedro Paulo Santos | 6 Apr 2010 17:38
Picon
Favicon

lwIP malloc fail

Hi all!
 
I'm having a problem in trying to make a system with lwIP that sends a large file with TCP from an external serial Flash memory.
 
I use the following logic: read certain amont of data from the external memory, send over TCP with tcp_write (), read more data, send again, and there goes on. I made a function to handle lack of memory because of Nagle's algoritm (because I have little memory and can't prepare a large TCP message), and use tcp_output () to force the send of the amont of data. The problem is that after some transfers (no more than 15 tcp transfers) the program doesn't find memory to alloc in the following lines of tcp_enqueue () function:
 
    /* Allocate memory for tcp_seg, and fill in fields. */
    seg = memp_malloc(MEMP_TCP_SEG);
    if (seg == NULL) {
      LWIP_DEBUGF(TCP_OUTPUT_DEBUG | 2, ("tcp_enqueue: could not allocate memory for tcp_seg\n"));
      goto memerr;
    }
 
In my thinking, the tcp_output () function should free memory for the further transfers so that I can transfer any amont of data if I make a lot of consecutive "small" transfers.
 
It occurs even if I send really small messages, with 20 bytes, for example. I already tried to edit lwipopts.h raising TCP_SND_BUF, TCP_WND, TCP_MSS, PBUF_POOL_SIZE, MEM_SIZE... but I got no good results.
 
Do I have to free memory, myself, in any part of the lwIP implementation?
(I already free the pbuf that my recv function returns as callback after the read)
 
Anyone have a suggestion of what could be the problem?
 
Informations: I'm using an ARM microcontroller with 64kB SRAM and 256kB flash. I already made an HTTP server into it, but it spends very little memory. My external serial (SPI) flash memory have 128MB.
 
Thanks to all!
 
Pedro Paulo.


__________ Informação do ESET NOD32 Antivirus, versão da vacina 4628 (20091122) __________

A mensagem foi verificada pelo ESET NOD32 Antivirus.

http://www.eset.com
_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users
Permalink | Reply | 7 comments |
headers
Oscar F | 7 Apr 2010 08:15
Picon

Increase Speed

Hello everybody, i´m using lwip in AVR32 in EVK1100.

I´m sending a big packet ( 15 Mbytes) , and the time to finish the process is very high!!. In the sniffer (wireshark) i saw that the packet is divided in two size 1400 and 690 i don´t remenber exactly, but this order the size.

How can i increse the speed of transmission?  should i change the file of configure lwipopt.h?  what value are typical to send very fast?

thanks in advance
Regards

Oscar

--
"En la vida hay tres cosas que nunca dan marcha atras, la palabra pronunciada, la flecha lanzada y la oportunidad perdida"

_______________________________________________
lwip-users mailing list
lwip-users@...
http://lists.nongnu.org/mailman/listinfo/lwip-users
Permalink | Reply | 13 comments |

Gmane