lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] upgrading to 1.3.0 from 1.2.0


From: David Shmelzer
Subject: [lwip-users] upgrading to 1.3.0 from 1.2.0
Date: Sat, 27 Dec 2008 16:58:17 -0500

I think I may have fixed my problem by setting ETH_PAD_SIZE to 2.
I say 'I think' because it doesn't seem like the right solution as my
implementation with 1.2.0 had a PAD size of 0.
While I was stepping through the 1.3.0 code I noticed the low word of
the ipaddr was garbage if I stepped through the C code. However, if I
stepped through the disassembly, it would NOT get corrupted which makes
me think it's an ISR or locking issue.

I thought maybe this had to do with ipaddr being aligned to 2 bytes
instead of 4.
caused by:
        pbuf_header(p, (s16_t)-sizeof(struct eth_hdr));
in ethernetif.c because the eth_hdr struct size is 14.
Does anyone know why this may have worked? I'm using an STR9.


in 1.2.0 version of ethernetif_input(), the example code I had was:

        case ETHTYPE_IP:
                etharp_ip_input(s_pxNetIf, p);
                /* skip Ethernet header */
                pbuf_header(p, (s16_t)-sizeof(struct eth_hdr));
                /* pass to network layer */
                if (s_pxNetIf->input(p, s_pxNetIf) != ERR_OK)
                        ...

>From what I understand, the 
        etharp_ip_input(s_pxNetIf, p);
is no longer necessary?


Also, if it helps anyone else porting to 1.3.0 my IAR compiler did not
warn on the following line which has an incorrect order of parameters:
  return etharp_output(netif, ipaddr, p); 
the correct order is now:
  return etharp_output(netif, p, ipaddr); 


Dave


Did you notice the interface for netifs has changed a little with 1.3.0?
a) netif->output is set to etharp_output so your ethernetif_output is
not needed any more
b) incoming ARP packets are sent to the tcpip_thread before processing
them as processing them directly lead to multithreading race conditions.

Maybe there's more than that, but as far as I can remember, the port
needs to be updated when moving from 1.1.0 to 1.3.0.


Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]