lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] lwip ARP reply delay at first time (Dmitriy Zabotlin)


From: arcolight
Subject: Re: [lwip-users] lwip ARP reply delay at first time (Dmitriy Zabotlin)
Date: Mon, 10 Aug 2015 15:32:03 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0

Thank you for your reply.

I'm using Atmel SAM4E16E CPU with DMA driver from Atmel XDK-ASF, so there is no polling, only interrupts.
Cable ok, I trying with different cables, with switch and without switch.
And I've noticed, that windows have more problems with bad FCS.

I see in wireshark, that all replies comes at one time. It seems like that they somewhere collected and than pushed away from some buffer.
May it be caused by bad FCS? Or this is different problem?

On 04/15/2015 07:00 PM, address@hidden wrote:
Send lwip-users mailing list submissions to
        address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.nongnu.org/mailman/listinfo/lwip-users
or, via email, send a message with subject or body 'help' to
        address@hidden

You can reach the person managing the list at
        address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of lwip-users digest..."


Today's Topics:

    1. Re: lwip ARP reply delay at first time (Sergio R. Caprile)


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

Message: 1
Date: Wed, 15 Apr 2015 09:32:28 -0300
From: "Sergio R. Caprile" <address@hidden>
To: address@hidden
Subject: Re: [lwip-users] lwip ARP reply delay at first time
Message-ID: <address@hidden>
Content-Type: text/plain; charset=utf-8

Dmitriy, you seem to have a non-working port and/or a non-working driver.
FCS errors are not intentionally generated, so you can't correct them
unless you know why they are there. So... I'll assume you mean those
errored frames belong to the lwIP board. FCS should be correctly
generated by a correctly initialized Ethernet chip; check your driver,
check your cable.
The delay between frames can be because of an RTOS task polling the chip
instead of an interrupt driven rx framework. Check your port.
The initial delay... if you connect two machines together without a
hub/switch, one of them needs to reverse its function (unless you use a
crossover cable), that might be both Ethernet chips trying to satisfy
the other. A correctly configured chip shouldn't take long, but... check
your driver, try with a switch or a crossover cable if you can't get a
switch.
In any case, you should step through your code to find some answers.
Regards





reply via email to

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