Re: [lwip-users] LwIP tweaking the TCP stack behavior

[Patrick Klos]

On 2/20/2020 11:00 AM, eitan via lwip-users wrote:

Hello,

I have a small device that sends data over TCP at a fast rate, this is a
small and not very cable hardware.
Now, LwIP is (as it should) maintains an acknowledge Q of ACKed packets so
it could re-transmit if it has to.
In my implementation, there is no need to handle ACKs at all.
Obviously it could be argued why not use UDP or RAW socket?
Well I wish I could, but the other listening device is an old and slow
machine that knows only TCP and can't be changed.

Since I don't care about respecting re-transmissions, and loosing few
packets is not an issue,
I assume that removing the ACK handling logic from the TCP stack will create
a non standard TCP server,
but a very fast transmitter with low memory requirements and with very
little delay between each call to tcp_write(),
since packets will not have to be buffred until the other side acknowledge
them.

Can someone here guide me through this? or better, is there any magical flag
that does this?
Thank you
Eitan.


I think you answered your own question.  You said "the other listening 
device is an old and slow machine that knows only TCP and can't be 
changed".  If you change the behavior of your LwIP TCP stack, the "other 
listening device" will not understand your broken TCP implementation and 
won't work properly with it.


Patrick Klos


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] https server woes.

[goldsi...@gmx.de]

Also, please don't send empty mails with just an attachment. What are we
supposed to do with that attachment?

Describe what's in it. What did you do, which stations do we see, what
do you think is happening, etc.

You're trying to get help. Do as best as you can to make it easy for
people to help you.

Regards,
Simon

Am 20.02.2020 um 21:01 schrieb Trampas Stern:
>
>
> On Thu, Feb 20, 2020 at 2:53 PM Simon Goldschmidt  > wrote:
>
>
> On 20.02.2020 18:20, Trampas Stern wrote:
> > [..]
> > I am fairly new to TCP/IP so hold my hand in interpreting the wire
> shark
> > results.
> >
> > image.png
>
> Please send pcap files, not images, while ensuring the pcap files only
> contain things they need (so don't send a file that is too large).
>
> Thanks,
> Simon
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org 
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>


___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] https server woes.

[Trampas Stern]

On Thu, Feb 20, 2020 at 2:53 PM Simon Goldschmidt  wrote:

>
> On 20.02.2020 18:20, Trampas Stern wrote:
> > [..]
> > I am fairly new to TCP/IP so hold my hand in interpreting the wire shark
> > results.
> >
> > image.png
>
> Please send pcap files, not images, while ensuring the pcap files only
> contain things they need (so don't send a file that is too large).
>
> Thanks,
> Simon
>
> ___
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users


https.pcap.pcapng
Description: Binary data
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] https server woes.

[Simon Goldschmidt]

On 20.02.2020 18:20, Trampas Stern wrote:

[..]
I am fairly new to TCP/IP so hold my hand in interpreting the wire shark
results.

image.png


Please send pcap files, not images, while ensuring the pcap files only
contain things they need (so don't send a file that is too large).

Thanks,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] LwIP tweaking the TCP stack behavior

[goldsimon]

Am 20. Februar 2020 17:00:46 MEZ schrieb eitan via lwip-users 
:
>Hello,
>
>I have a small device that sends data over TCP at a fast rate, this is
>a
>small and not very cable hardware.
>Now, LwIP is (as it should) maintains an acknowledge Q of ACKed packets
>so
>it could re-transmit if it has to.
>In my implementation, there is no need to handle ACKs at all.

Short answer: disable the whole tcp code by setting LWIP_TCP to 0 and implement 
it yourself by using raw a pcb.

You won't easily do this by changing our tcp code.

And yes, I wouldn't do this at all ;-)

Regards,
Simon

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[lwip-users] LwIP tweaking the TCP stack behavior

[eitan via lwip-users]

Hello,

I have a small device that sends data over TCP at a fast rate, this is a
small and not very cable hardware.
Now, LwIP is (as it should) maintains an acknowledge Q of ACKed packets so
it could re-transmit if it has to.
In my implementation, there is no need to handle ACKs at all. 
Obviously it could be argued why not use UDP or RAW socket? 
Well I wish I could, but the other listening device is an old and slow
machine that knows only TCP and can't be changed.

Since I don't care about respecting re-transmissions, and loosing few
packets is not an issue, 
I assume that removing the ACK handling logic from the TCP stack will create
a non standard TCP server, 
but a very fast transmitter with low memory requirements and with very
little delay between each call to tcp_write(), 
since packets will not have to be buffred until the other side acknowledge
them.

Can someone here guide me through this? or better, is there any magical flag
that does this?
Thank you
Eitan.






--
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/lwip-users

Re: [lwip-users] Need support on TCP/IP packet transmission

[goldsimon]

Am 20. Februar 2020 15:23:55 MEZ schrieb praveenkumar raavi 
:
>Hi,
>
>Any update on my query...

I'm not sure I even understand what your actual problem is. But being stuck in 
the timer function surely sounds like a threading problem...

Regards,
Simon

>
>Regards,
>PraveenKumar.
>
>On Thu, 13 Feb 2020, 09:54 praveenkumar raavi,
>
>wrote:
>
>> Hi Everyone,
>>
>>
>>
>> we are using LWIP 2.0.3 for one of our project to establish the TCP
>> connection from ECU and Atmel micro.
>> We got the LWIP from Atmel itself and I have modified little to
>support
>> VLAN data receive and transmit.
>>
>>
>>
>> But now we are seeing some issue during data transmission.
>> When the ECU goes to sleep, it cut down the Ethernet link and when it
>> wakes up it will establish the Ethernet connection.
>> But here when the ECU wakes up the communication is not going well
>from
>> our LWIP stack. We are seeing multiple re transmissions which are
>causing
>> issues in data transmission.
>>
>> So we planned to reinitialize the LWIP stack after ECU goes to sleep.
>> But when I do shut down the connection, the connection is not closing
>as
>> there is no FIN request response from ECU and its getting stuck in
>tcp_slow
>> timer.
>> Also I have seen new behavior like when i received new frame on TCP,
>I am
>> trying to ACK back using ACK now function(pcb->prio = TCP_PRIO_MAX;
>> tcp_send_empty_ack(pcb);  tcp_output(pcb);), but I am seeing the ACK
>> packet transmitted after my data packet is been transferred.
>> This I didn't understand like why the ACK packet is transferred after
>data
>> packet? this is also one of the reason for us to see communication
>failure.
>>
>> I am attaching the images for our communication issues.
>> Here LWIP_IP: 192.168.6.182
>>  ECU IP : 192.168.6.144
>> If you see LWIP_TCP_DataSentoutFirst.JPG, the data is send first and
>ACK
>> is sent after that even though the ACK transmission is initiated
>first with
>> priority level set to MAX.
>>
>> Please let us know how to solve this issue.
>>
>>
>>
>> I am adding following steps during lwip init.
>>
>> TCPIP_STACK_INTERFACE_0_init(st_ETH_ConfigStruct.u8_SourceMacAddress,
>> Src_IP, gw);
>>
>> netif_set_up(_STACK_INTERFACE_0_desc);
>>
>> netif_set_default(_STACK_INTERFACE_0_desc);
>>
>> mac_async_enable();
>>
>> etharp_add_static_entry(_IP, (struct eth_addr
>> *)_ETH_ConfigStruct.u8_DestMacAddress[0]);
>>
>> pcb_tcp = tcp_new();
>>
>> error = tcp_bind(pcb_tcp, ,
>st_ETH_ConfigStruct.u16_SourcePortNum);
>>
>> pcb_tcp = tcp_listen(pcb_tcp);
>>
>> tcp_accept(pcb_tcp, Etherdo_connected);
>>
>>
>>
>> After link established, below functions are used to do data transfer.
>>
>>
>>
>> tcp_write(pcb_tcp,u8_DataBuff,u16_DataLen,TCP_WRITE_FLAG_MORE);
>>
>> tcp_output(pcb_tcp));
>>
>>
>>
>> This is how I initialized LWIP stack and transmitting data over
>ethernet.
>> Here I have used static MAC address as we should connect to
>particular MAC
>> address.
>>
>>
>> Regards,
>>
>> PraveenKumar.
>>

___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Re: [lwip-users] Need support on TCP/IP packet transmission

[praveenkumar raavi]

Hi,

Any update on my query...

Regards,
PraveenKumar.

On Thu, 13 Feb 2020, 09:54 praveenkumar raavi, 
wrote:

> Hi Everyone,
>
>
>
> we are using LWIP 2.0.3 for one of our project to establish the TCP
> connection from ECU and Atmel micro.
> We got the LWIP from Atmel itself and I have modified little to support
> VLAN data receive and transmit.
>
>
>
> But now we are seeing some issue during data transmission.
> When the ECU goes to sleep, it cut down the Ethernet link and when it
> wakes up it will establish the Ethernet connection.
> But here when the ECU wakes up the communication is not going well from
> our LWIP stack. We are seeing multiple re transmissions which are causing
> issues in data transmission.
>
> So we planned to reinitialize the LWIP stack after ECU goes to sleep.
> But when I do shut down the connection, the connection is not closing as
> there is no FIN request response from ECU and its getting stuck in tcp_slow
> timer.
> Also I have seen new behavior like when i received new frame on TCP, I am
> trying to ACK back using ACK now function(pcb->prio = TCP_PRIO_MAX;
> tcp_send_empty_ack(pcb);  tcp_output(pcb);), but I am seeing the ACK
> packet transmitted after my data packet is been transferred.
> This I didn't understand like why the ACK packet is transferred after data
> packet? this is also one of the reason for us to see communication failure.
>
> I am attaching the images for our communication issues.
> Here LWIP_IP: 192.168.6.182
>  ECU IP : 192.168.6.144
> If you see LWIP_TCP_DataSentoutFirst.JPG, the data is send first and ACK
> is sent after that even though the ACK transmission is initiated first with
> priority level set to MAX.
>
> Please let us know how to solve this issue.
>
>
>
> I am adding following steps during lwip init.
>
> TCPIP_STACK_INTERFACE_0_init(st_ETH_ConfigStruct.u8_SourceMacAddress,
> Src_IP, gw);
>
> netif_set_up(_STACK_INTERFACE_0_desc);
>
> netif_set_default(_STACK_INTERFACE_0_desc);
>
> mac_async_enable();
>
> etharp_add_static_entry(_IP, (struct eth_addr
> *)_ETH_ConfigStruct.u8_DestMacAddress[0]);
>
> pcb_tcp = tcp_new();
>
> error = tcp_bind(pcb_tcp, , st_ETH_ConfigStruct.u16_SourcePortNum);
>
> pcb_tcp = tcp_listen(pcb_tcp);
>
> tcp_accept(pcb_tcp, Etherdo_connected);
>
>
>
> After link established, below functions are used to do data transfer.
>
>
>
> tcp_write(pcb_tcp,u8_DataBuff,u16_DataLen,TCP_WRITE_FLAG_MORE);
>
> tcp_output(pcb_tcp));
>
>
>
> This is how I initialized LWIP stack and transmitting data over ethernet.
> Here I have used static MAC address as we should connect to particular MAC
> address.
>
>
> Regards,
>
> PraveenKumar.
>
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users