ttory wrote:
Thank you Alexandre :)
After reading your reply, I immediately installed Wireshark program.
And I can confirm this.
Some reply packet's sequence number included ICMP header is same.
Is this uIP's bug?
Before 5 hours, I let remote PC request ICMP to AVR host. But no reply.
But now I can see reply on the PC monitor.
But that is similar in situation "50% loss"
I think internet line is not responsible for it.
Because If I let remote PC request ICMP to my local PC, it gave me perfect
reply with 0% loss.
Um... so lonely winter...
I have uip working over a serial line. despite quite high ping times, it
works flawlessly for hours with 0% loss and no dups. I also tried it's
demo on unix and it "pongs" ok.
I suspect there's a bug on your looping scheme, have you deviated from
uip's demos?
Perhaps your ethernet device has a ring-buffer, and when uip gots
notified of an incoming frame, it reads from a fixed location on that
buffer? If that's the case for the first position on the buffer, it
would have the effect of uip replying correct to the first packet, but
when the other(s) arrive, the ethernet controller won't put it on the
same position, so uip will read the old packet and reply to it again.
See if your wireshark logs shows something like:
- icmp echo request with sequence number x
- icmp echo reply with sequence number x
- icmp echo request with sequence number x+1
- icmp echo reply with sequence number x
- icmp echo request with sequence number x+2
- icmp echo reply with sequence number x+2
.. or something. If I tough of it correctly, that would mean that you
have space for two packets on the ethernet controller buffer (two
slots), but uip (or more correctly, your ethernet "driver") is only
reading from the first one.Something like that would get you close to
50% dups, computed as losses, as in your example ...
- Alexandre
