RE: [uip-users] ICMP is not perfect?

[ttory]

Hi Alexandre.

I understand what you said.
But I didn't modify Louis's src ported atmega128 with rtl8019. 
I'm a rookie. So I must trust his work. This situation make me gloomy.


Today morning, Finally I decide to delay solving this problem. (T.T)
Now I'm going to implement ping application from AVR to other host pc.
I have no more time to implement. It also make me gloomy..




-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Alexandre Pereira Nunes
Sent: Thursday, February 01, 2007 12:35 AM
To: uip-users@sics.se
Subject: Re: [uip-users] ICMP is not perfect?

ttory wrote:
> In src code(line 659, uip.c , uIP version 0.9) 
> ============================================================
> /* Check if the packet is destined for our IP address. */  
>   if(BUF->destipaddr[0] != uip_hostaddr[0]) {
>     UIP_STAT(++uip_stat.ip.drop);
>     UIP_LOG("ip: packet not for us.");        
>     goto drop;
>   }
>   if(BUF->destipaddr[1] != uip_hostaddr[1]) {
>     UIP_STAT(++uip_stat.ip.drop);
>     UIP_LOG("ip: packet not for us.");        
>     goto drop;
>   }
> ============================================================
>
> I implemented UIP_LOG function that send input parameter to UART TX.
> So by using terminal program, I can confirm this message "ip : packet not
> for us."
> What is that mean? 
>
>
>   
It means that the destination ip address of the received packet does not 
match the local ip address configured for uip; this can happen for a 
number of reasons, for example if:

    * Your code is somehow running uip_input() against your own sent
      data. for instance, you have a shared tx/rx ring buffer on the
      ethernet and you are assuming data on a tx slot is a rx data, that
      would cause this behaviour;
    * The received ip is somehow not destinated to your address. It
      could be broadcast/multicast ip data;
    * There's a buffer misalignment either at uip or at ethernet
      (driver?) handling. I didn't look at the code, but I think ip
      checksumming is checked before that, so it should not be the case.
    * Other scenarions I didn't think of as of now :-)

Good luck,

Alexandre