Hi nikolas,
Are you able to detect the cause of the issue.
We are also facing similar issue.
--
Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/
Are you running over pppos or not? Why did your remove "pppos" from the
2nd mail?
On 01.02.2018 12:49, Kiran wrote:
Hi,
I'm using lwip 2.0.3 with freertos.
I'm running tcp server in my Linux pc and tcp client on atmel
microcontroller with lwip 2.0.3.
I got succeeded in establishing a successful
Hi,
I'm using lwip 2.0.3 with freertos.
I'm running tcp server in my Linux pc and tcp client on atmel
microcontroller with lwip 2.0.3.
I got succeeded in establishing a successful tcp connection with my Linux
pc,but when I start sending tcp messages from client using *send* function I
see it stops
Hi,
I'm using lwip 2.0.3 with freertos.
I'm running tcp server in my Linux pc and tcp client on atmel
microcontroller with lwip 2.0.3.
I got succeeded in establishing a successful tcp connection with my Linux
pc,but when I start sending tcp messages from client using *send* function I
see it stops
Nikolas Karakotas wrote:
True for not providing enough information.
Deducing wireshark information I can say:
1. Remote host send a Modbus request
2. For whichever reason we don't respond to it as it may have been
lost because of network or Ethernet driver
3. The remote host then re sends the re
Hi,
True for not providing enough information.
Deducing wireshark information I can say:
1. Remote host send a Modbus request
2. For whichever reason we don't respond to it as it may have been
lost because of network or Ethernet driver
3. The remote host then re sends the request and we are able
Nikolas Karakotas wrote:
I'm facing an issue on-site where there is quite a lot of traffic.
Sometimes I can see from the log that we have a TCP re-transmission
and we once the packet is re transmitted the data we receive is
impartial. As a result our modbus driver responds with and error.
I can s
Sergio R. Caprile wrote:
> Anyway, glad you managed to solve your issue Michael, next user with an
> STM bug will be charged ;^) I wonder if the SICS can take donations...
I would take donations as well :-) I'm not getting paid for this, and my slooow
2007er MacBook is one of the reasons I disl
For any Dragon Ball Z fans out there, this STM bug looks like Majin Buu
to me...
Anyway, glad you managed to solve your issue Michael, next user with an
STM bug will be charged ;^) I wonder if the SICS can take donations...
As per the tcp_poll() vs tcp_sent() in your scenario, it depends on what
i
deft wrote
> Just to clarify, there are two flavours of the STM bug:
GOTCHA!
When I've looked for the fix, somehow I missed the loop in the
low_level_input(). I'm really blind...
I've also fixed the bad ARP checksum, caused by my driver.
The throughput reaches 22 MBit/s, now!
Thank you all
--
e rx thread wakes up. (and by
doing this you actually don't need a counting semaphore)
BR /Jens
>Ursprungligt meddelande
>Från: m.p.steine...@gmail.com
>Datum: 2014-09-18 13:30
>Till:
>Ärende: Re: [lwip-users] TCP retransmission flooding at end of stream
>
>Simo
Simon Goldschmidt wrote
> Michael Steinecke wrote:
>> Sergio R. Caprile wrote
>/ The FW Library bug in the Ethernet IRQ, eating fast packets is
fixed./
So no, this does not seem to be the standard STM issue...
>>>
>>> Oh, I see, missed that part. Should we believe the vendor ? (terrified
>>
Michael Steinecke wrote:
> Sergio R. Caprile wrote
/ The FW Library bug in the Ethernet IRQ, eating fast packets is fixed./
>>>So no, this does not seem to be the standard STM issue...
>>
>> Oh, I see, missed that part. Should we believe the vendor ? (terrified
>> face)
>
> I think there is an
Sergio R. Caprile wrote
>>>/ The FW Library bug in the Ethernet IRQ, eating fast packets is fixed./
>>So no, this does not seem to be the standard STM issue...
>
> Oh, I see, missed that part. Should we believe the vendor ? (terrified
> face)
I think there is another related bug as well. The sema
>>/ The FW Library bug in the Ethernet IRQ, eating fast packets is fixed./
>So no, this does not seem to be the standard STM issue...
Oh, I see, missed that part. Should we believe the vendor ? (terrified face)
Anyway, here are my 2 cents:
- Frame 16: bad FCS on ARP response from MCU to PC, why ?
Sergio,
Michael Steinecke wrote:
> The FW Library bug in the Ethernet IRQ, eating fast packets is fixed.
So no, this does not seem to be the standard STM issue...
Simon
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mail
Is this the (in)famous ST-lost-frames bug again ?
Translation: is your port running on an RTOS with an Rx task fired from
Eth interrupt and taking only the first frame out of the chip ?
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.non
goldsi...@gmx.de wrote
> Which version of lwIP are you using? Do you know that we support TCP
> window scaling by now (LWIP_WND_SCALE)?
Indeed, i forgot this one. Its the version provided by the STM32CubeMX tool.
Diff shows its identical to LWIP 1.4.1. I didn't knew that. I guess you
refer to pat
I> need to achieve a throughput of at least 2 MBit/s, according our
> requirements. Due to the HW this should be possible.
I am not sure why you decided to go in such extreme direction with your
changes.
We are almost able to saturate 100MBit connection (>8 MB/s) and upload
about 2MB/s from SD C
Michael Steinecke wrote:
currently I'm struggling while creating an application for a custom
STM32F429ZG based custom board using LwIP.
Too sad the F429 discovery board doesn't have an ethernet connector or I
could try to reproduce this :-)
To achieve maximum throughput, I have done some furthe
Hello Folks,
currently I'm struggling while creating an application for a custom
STM32F429ZG based custom board using LwIP.
I need to achieve a throughput of at least 2 MBit/s, according our
requirements. Due to the HW this should be possible.
The application is based on the STMCubeMX V4.3.0 and
Hi Jens, hi Sergio,
Yes that's exactly my problem. Here's the patch I've came up with on my
driver :
int packetCount = 0;
static void eth_notify (ARM_ETH_MAC_EVENT event) {
/* Send notification on RX event */
if (event == ARM_ETH_MAC_EVENT_RX_FRAME) {
packetCount++;
}
}
void etherneti
Alright, I also use the ST drivers (the ones from STM32Cube 1.0.0) on an
STM32F4
I haven't verified that my fix is 100% accurate but I think it looks
safe so I'm sending it to ST anyway so they can figure it out if they
want to.
My fix goes something like this:
At the bottom of HAL_ETH_Get
Yes Jens, looks like you are absolutely right, missed that, there is no
frame loss here, the receiving process must be getting only the first
frame in the "chip" cue.
Julien is using some ST microcontroller, I guess it has a built-in eth
controller, probably with DMA.
I've studied the Linux drive
Hi
Yes you're probably right, that would be a better solution. What looks
like happens next in the wireshark capture is that the interrupt
triggered by the retransmission signals your code to read and ack the
queued old packet. Then there's an ACK in packet 26 triggering another
interrupt tha
> I am a bit surprised that the ethernet interrupt just raises a flag :
Don't be surprised, lwIP is single threaded, meaning you shouldn't call
an lwIP memory allocation routine from inside an interrupt, since it
might have interrupted another lwIP memory allocation routine... (I
might be wrong si
Hi Sergio,
I've found this drop packet thing in my driver, however it doesn't seem to
break there.
I've had a look at the driver code but I can't find anything...
I am a bit surprised that the ethernet interrupt just raises a flag :
static void eth_notify (ARM_ETH_MAC_EVENT event) {
/* Send no
Hi Julien.
Yes, there is a TCP retransmission from your host.
I bet that is because when the two packets come in such a close
proximity your Ethernet driver is losing the second one. This, in fact,
can be because there is a problem with the driver itself, or you have a
really low-memory condition a
Hello !
I use lwip in a MCU running a small TCP command server. The commands are
sent from a desktop computer. They have a body, and an optional payload.
When I send commands with no payload, everything works fine. But when I send
a command with a payload (very small, about 6-7 bytes), the TCP t
29 matches
Mail list logo
