mobin.seven | 21 Oct 14:45 2014

Get IP address of client in RAW API

Hi

my question is the title!
How to get IP address of client in RAW API in server side?

thanks

--
View this message in context: http://lwip.100.n7.nabble.com/Get-IP-address-of-client-in-RAW-API-tp23416.html
Sent from the lwip-users mailing list archive at Nabble.com.
Markus | 16 Oct 22:31 2014
Picon
Picon

Closing TCP-Connection

Hello,

 

I have written a simple iPerf client which works quite good, but I can’t close the Connection after finishing the transfer. When I try to close a TCP-Connection by calling tcp_close () the connection goes into the state TIME_WAIT and is not closing.  I’m using the master-branch of lwIP.

Any hint what I could do to close the connection?

 

Thanks and Regards

 

Markus

 

_______________________________________________
lwip-users mailing list
lwip-users@...
https://lists.nongnu.org/mailman/listinfo/lwip-users
Markus | 16 Oct 22:03 2014
Picon
Picon

Closing tcp-Connection

Hello,

 

I have written a simple iPerf client which works quite good, but I can’t close the Connection after finishing the transfer. When I try to close a TCP-Connection by calling tcp_close () the connection goes into the state TIME_WAIT and is not closing.  I’m using the master-branch of lwIP.

Any hint what I could do to close the connection?

 

Thanks and Regards

 

Markus

 

_______________________________________________
lwip-users mailing list
lwip-users@...
https://lists.nongnu.org/mailman/listinfo/lwip-users
Slava Zilberfayn | 15 Oct 23:28 2014

Lwip 1.4.1, lpc1788, problem with missing packets

Hello lwip-users,

sorry, I previous posted this under an old thread.

I'm having some issues with lwip stack, or rather with the system as
whole. At this point I studied the stack relatively well at seems to
work as intended. However I might be still mistaken, so I'm posting
here.

The root of the problems is that sometimes packets are being
lost for no reason. This can happen even if I connect my PC directly
to the lwip device.

When I look at the WireShark trace, it shows as "TCP Previous Segment
not captured". See attachment. It is certainly not just "not captured", as this is
always accompanied by problems on receiving end and netconn_write
takes longer time to be completed. Eventually the packets are
retransmitted, but it could take like 10 seconds, which is not very
good.

I already instrumented the driver (lpc17_emac), and logs confirm that all packets
are leaving my device strictly in order. What could be the reason for
router to ignore my packets? I also tried with two different routers and it
is the same. Could the problem be with MAC-PHY link?

Can anybody suggest further steps for debugging?

Thanks, Slava

--

-- 
Slava Zilberfayn mailto:szilber@...
Phone: 416 7289367

Home Electronics, www.home-electro.com
100 Drumlin Circle,
Suite 205
Concord, ON, L4K 3E6
CANADA
Becker Markus | 14 Oct 12:03 2014

lwip processing of posts

Hi,

I am currently implementing a proxy between HTTP and another protocol
using a different library. So far the proxying works pretty well for
GETs. I am now implementing proxying of POSTs as well. The POSTs will
_not_ be multipart/form-data or application/x-www-form-urlencoded. So
then MHD_create_post_processor won't work as it is. Should raw POSTs be
handled along that code path (to be implemented) or is there a different
way to get to the POST payload (already implemented)?

Thanks,
Markus
________________________________________________________
The contents of this e-mail and any attachments are confidential
to the intended recipient. They may not be disclosed to or used
by or copied in any way by anyone other than the intended recipient.
If this e-mail is received in error, please immediately notify
the sender and delete the e-mail and attached documents.

Please note that neither the sender nor the sender's company
accept any responsibility for viruses and it is your responsibility
to scan or otherwise check this e-mail and any attachments.
jbhoi | 10 Oct 12:11 2014
Picon

pbuf_alloc failed after sometime at driver side.

I am using lwip 1.4.1 for lpc1833 microcontroller with freeRTOS version
7.3.0.Have used driver for lpc18xx_43xx family 

http://docs.lpcware.com/lpcopen/v1.03/lpc18xx__43xx__emac_8c.html
<http://docs.lpcware.com/lpcopen/v1.03/lpc18xx__43xx__emac_8c.html>  

I am successfully able to up and run the stack and ping this controller from
other device. But this work for sort time(around 2 to 3 minutes) after that
pbuf_alloc from driver return NULL.I have trace the issue in which
**mem_malloc** function fails to allocate memory. Now i seems here driver
allocate memory for received packet and pass it to upper layer of lwip
stack. Now this upper layer is not fast enough to free that packets and
getting outofmemory issue at lower layer.

Any one have idea regarding this issue?

Regards,
Jayesh

--
View this message in context: http://lwip.100.n7.nabble.com/pbuf-alloc-failed-after-sometime-at-driver-side-tp23381.html
Sent from the lwip-users mailing list archive at Nabble.com.
jbhoi | 8 Oct 12:26 2014
Picon

Memory allocation fail after some time in lwip stack for lpc1833 controller

I am working on LPC1833 microcontroller and used lwip stack *v1.4.1* and
freeRTOS *v7.3.0.*

I am successfully able to up and run the stack and ping this controller from
other device. But this work for sort time(around 2 to 3 minutes) after that
ping is lost.I have trace the issue in which **mem_malloc** function fails
to allocate memory.

The Flow of code it as follows(From top to bottom)

    vPacketReceiveTask
         |
    lpc_enetif_input
         |
    lpc_low_level_input
         |
    lpc_rx_queue
         |
    pbuf_alloc
         |
    mem_malloc

Now one interesting thing is ping is successfully working until **1536
bytes** successfully allocated and when allocation fail start for those
bytes then ping is lost. 1536 bytes is buffer length of ethernet buffer.

Any one idea about issue?

--
View this message in context: http://lwip.100.n7.nabble.com/Memory-allocation-fail-after-some-time-in-lwip-stack-for-lpc1833-controller-tp23377.html
Sent from the lwip-users mailing list archive at Nabble.com.
Grzegorz Niemirowski | 8 Oct 00:23 2014
Picon

Re: lwip stall

It seems you have similar problem as me (Re: [lwip-users] lwIP hangs after some data transferred). When the stack stalls, what value do you have in the DMASR register (EthHandle.Instance->DMASR)? Is the RBUS bit set?
 
Pozdrawiam,
Grzegorz Niemirowski
http://www.grzegorz.net/
----- Wiadomość oryginalna -----
Wysłano: 7 października 2014 19:33
Temat: Re: [lwip-users] lwip stall

Thanks Michael,

I had actually missed that and have now applied it, which seems to have fixed the intermittent speed problem,  but I am still having some issues.

After a number of successful packets, everything seems to stall. Looking at the wireshark capture, and TCP Output/ Input debugging here:


It looks as though lwip stops acking, and the python end keeps retransmitting the same packet. 

58 2.257102 192.168.1.64 192.168.1.24 TCP 58 52478→9000 [PSH, ACK] Seq=664403702 Ack=48441 Win=65270 Len=4
59 2.556697 192.168.1.64 192.168.1.24 TCP 58 [TCP Retransmission] 52478→9000 [PSH, ACK] Seq=664403702 Ack=48441 Win=65270 Len=4
60 3.156804 192.168.1.64 192.168.1.24 TCP 58 [TCP Retransmission] 52478→9000 [PSH, ACK] Seq=664403702 Ack=48441 Win=65270 Len=4
61 4.356948 192.168.1.64 192.168.1.24 TCP 58 [TCP Retransmission] 52478→9000 [PSH, ACK] Seq=664403702 Ack=48441 Win=65270 Len=4

In the lwip logs, all is well up until the first line saying:

tcpip_thread : tcp_receive: duplicate seqno 664403702, so its receiving the retransmitions,

however straight after this, the logging reports 

tcpip_thread : tcp_output: sending ACK for 664403706

which is in the function tcp_send_empty_ack()

Presumably this ack has already been sent, along with the 2 byte reply data before (although this doesn't seem to be printed out as debug info), and due to there currently being more data to send, its just sending an empty ack() - fine. However, none of these acks appear on the wireshark trace. The filter is set to "eth.addr eq 22:a3:11:14:65:22", but even without any filtering and looking by eye, I cannot find these acks. 

I am suspecting this may well be a driver bug, but I have yet to manage to narrow it down. I've turned on all DMA error interrupts and have a handler with a loops in it that should get hit if there is anything wrong as far as the MAC goes, but so far it has not been hit. So its either the driver, or or a problem with lwip itself. But these packets never seem to get on the wire as far as I can see?

Any suggestions would be greatly appreciated.

Thanks

Rob.


> Date: Mon, 6 Oct 2014 08:36:39 -0700
> From: m.p.steinecke-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> To: lwip-users-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
> Subject: Re: [lwip-users] lwip stall
>
> Hi,
>
> actually, STM made only a partial bugfix. I've ran in the same mistake. The
> do/while loop in ethernetif_input() is still missing in the CubeMX software.
>
>
> void ethernetif_input( void const * argument )
> {
> struct pbuf *p;
> struct netif *netif = (struct netif *) argument;
>
> for( ;; )
> {
> if (osSemaphoreWait( s_xSemaphore, TIME_WAITING_FOR_INPUT)==osOK)
> {
> do
> {
> p = low_level_input( netif );
> if (p != NULL)
> {
> if (netif->input( p, netif) != ERR_OK )
> {
> pbuf_free(p);
> }
> }
> }while(p!=NULL);
> }
> }
> }
>
>
>
> --
> View this message in context: http://lwip.100.n7.nabble.com/lwip-stall-tp23366p23370.html
> Sent from the lwip-users mailing list archive at Nabble.com.
>
> _______________________________________________
> lwip-users mailing list
> lwip-users-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
lwip-users-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
lwip-users@...
https://lists.nongnu.org/mailman/listinfo/lwip-users
rmawatson rmawatson | 6 Oct 00:36 2014
Picon

lwip stall

<!-- .hmmessage P { margin:0px; padding:0px } body.hmmessage { font-size: 12pt; font-family:Calibri } -->
Hello,

I am using lwip 1.41 on an STM32F4 with a DP83848 PHY, running under FreeRTOS 8.1.2 . The driver I have taken from the new Stmcubex software, which generates code for lwip 1.41, and an older version of FreeRtos. I am having lwip appear to just stall, and am suspecting configuration problems are the cause of my issues, but I am having a hard time figuring out 
what exactly might be wrong.

I have an extremely simple setup with the tcp_ip task, running at priority 6, the EthIf task running at priority 5, and my own task that uses the socket layer running at priority 3.

After initializing lwip with the following..

    netif_set_addr(&netiface,&ipaddr,&netmask,&gateway);
    netif_add(&netiface, &ipaddr, &netmask, &gateway, NULL, &ethernetif_init, &tcpip_input);
    netif_set_default(&netiface);
    netif_set_up(&netiface);
Inside my task, I am creating a socket, binding, listening, accepting.. 

I then have a python script on my desktop that connects to the stm32f4 server, and starts sending 4 bytes, then receiving 2 bytes - forever.
the server runs the following after it has accepted the connection  - Accepts 2 bytes, then accepts 2 more, then replies with 2 bytes.

    while(1)
    {

            int count = 0;
            char buff[4];

            printf("\r\n\r\n-----------------------\r\n\r\n");
            printf("--- REC1\n");

            count = recv(fd_new_client,(char*)buff,2,0);

            if (count != 2){
                while(1) {  __NOP(); }
            }

            printf("--- REC2\n");
            count = recv(fd_new_client,(char*)buff,2,0);

            if (count != 2){
                while(1) {  __NOP(); }
            }

            char response[2] = {'o','k'};
            printf("--- SEND\n");
            int8_t sent = send(fd_new_client,response,2,0);

            if (sent != 2) {
                while(1) { __NOP(); }
            }
    }

After anywhere from a few messages to a few thousand, the connection stalls, my 20 second timeout on the PYTHON socket kicks in an that times out, and lwip keeps printing. Judging by the log, its stuck somewhere in the first recv(fd_new_client,(char*)buff,2,0); - I also have breakpoints set on my while(1) { __NOP(); } loops should the call return -1 or something. These are not getting hit.

tcp_output: snd_wnd 65044, cwnd 536, wnd 536, seg == NULL, ack 7931

to my serial connection window. This seems to go on indefinitely. I have pasted a debug log below with the following defines.


#define SOCKETS_DEBUG LWIP_DBG_ON
#define API_LIB_DEBUG LWIP_DBG_ON
#define MEMP_DEBUG LWIP_DBG_ON
#define MEM_DEBUG  LWIP_DBG_ON
#define RAW_DEBUG  LWIP_DBG_ON
#define TCP_INPUT_DEBUG LWIP_DBG_ON
#define TCP_CWND_DEBUG LWIP_DBG_ON

any help as to where to start debugging what is breaking would be greatly appreciated - or indeed what settings configuration parameters might be the trouble.

Thanks,

Rob.


Here is the log of the last few messages up to the 277th where it stopped.
....
--- REC1
lwip_recvfrom(1, , 536872532, 0x2, ..)
lwip_recvfrom: top while sock->lastdata=
+-+-+-+-+-+-+-+-+-+-+-+-+-+- tcp_input: flags -+-+-+-+-+-+-+-+-+-+-+-+-+-+
tcp_receive: congestion avoidance cwnd 14735
tcp_receive: ACK for 7049, unacked->seqno 7047:7049
tcp_receive: removing 7047:7049 from pcb->unacked
tcp_output: snd_wnd 65390, cwnd 14735, wnd 14735, seg == NULL, ack 7049
netconn_recv_data: received , len=536904428
lwip_recvfrom: netconn_recv err=0, netbuf=
lwip_recvfrom: buflen=4 len=2 off=0 sock->lastoffset=0
lwip_recvfrom(1): addr=192.168.1.64 port=34736 len=2
lwip_recvfrom: lastdata now netbuf=
--- REC2
lwip_recvfrom(1, , 536872532, 0x2, ..)
lwip_recvfrom: top while sock->lastdata=
lwip_recvfrom: buflen=4 len=2 off=0 sock->lastoffset=2
lwip_recvfrom(1): addr=192.168.1.64 port=34736 len=2
lwip_recvfrom: deleting netbuf=
--- SEND
lwip_send(1, data=, size=536872528, flags=0x2)
tcp_output: snd_wnd 65390, cwnd 14735, wnd 14735, effwnd 2, seq 7049, ack 7049
tcp_output: snd_wnd 65390, cwnd 14735, wnd 14735, effwnd 2, seq 7049, ack 7049, i 0
lwip_send(1) err=0 written=2


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

--- REC1
lwip_recvfrom(1, , 536872532, 0x2, ..)
lwip_recvfrom: top while sock->lastdata=
+-+-+-+-+-+-+-+-+-+-+-+-+-+- tcp_input: flags -+-+-+-+-+-+-+-+-+-+-+-+-+-+
tcp_receive: congestion avoidance cwnd 14754
tcp_receive: ACK for 7051, unacked->seqno 7049:7051
tcp_receive: removing 7049:7051 from pcb->unacked
tcp_output: snd_wnd 65388, cwnd 14754, wnd 14754, seg == NULL, ack 7051
netconn_recv_data: received , len=536904428
lwip_recvfrom: netconn_recv err=0, netbuf=
lwip_recvfrom: buflen=4 len=2 off=0 sock->lastoffset=0
lwip_recvfrom(1): addr=192.168.1.64 port=34736 len=2
lwip_recvfrom: lastdata now netbuf=
--- REC2
lwip_recvfrom(1, , 536872532, 0x2, ..)
lwip_recvfrom: top while sock->lastdata=
lwip_recvfrom: buflen=4 len=2 off=0 sock->lastoffset=2
lwip_recvfrom(1): addr=192.168.1.64 port=34736 len=2
lwip_recvfrom: deleting netbuf=
--- SEND
lwip_send(1, data=, size=536872528, flags=0x2)
tcp_output: snd_wnd 65388, cwnd 14754, wnd 14754, effwnd 2, seq 7051, ack 7051
tcp_output: snd_wnd 65388, cwnd 14754, wnd 14754, effwnd 2, seq 7051, ack 7051, i 0
lwip_send(1) err=0 written=2


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

--- REC1
lwip_recvfrom(1, , 536872532, 0x2, ..)
lwip_recvfrom: top while sock->lastdata=
+-+-+-+-+-+-+-+-+-+-+-+-+-+- tcp_input: flags -+-+-+-+-+-+-+-+-+-+-+-+-+-+
tcp_receive: congestion avoidance cwnd 14773
tcp_receive: ACK for 7053, unacked->seqno 7051:7053
tcp_receive: removing 7051:7053 from pcb->unacked
tcp_output: snd_wnd 65386, cwnd 14773, wnd 14773, seg == NULL, ack 7053
netconn_recv_data: received , len=536904428
lwip_recvfrom: netconn_recv err=0, netbuf=
lwip_recvfrom: buflen=4 len=2 off=0 sock->lastoffset=0
lwip_recvfrom(1): addr=192.168.1.64 port=34736 len=2
lwip_recvfrom: lastdata now netbuf=
--- REC2
lwip_recvfrom(1, , 536872532, 0x2, ..)
lwip_recvfrom: top while sock->lastdata=
lwip_recvfrom: buflen=4 len=2 off=0 sock->lastoffset=2
lwip_recvfrom(1): addr=192.168.1.64 port=34736 len=2
lwip_recvfrom: deleting netbuf=
--- SEND
lwip_send(1, data=, size=536872528, flags=0x2)
tcp_output: snd_wnd 65386, cwnd 14773, wnd 14773, effwnd 2, seq 7053, ack 7053
tcp_output: snd_wnd 65386, cwnd 14773, wnd 14773, effwnd 2, seq 7053, ack 7053, i 0
lwip_send(1) err=0 written=2


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

--- REC1
lwip_recvfrom(1, , 536872532, 0x2, ..)
lwip_recvfrom: top while sock->lastdata=
tcp_slowtmr: cwnd 536 ssthresh 7386
tcp_output: snd_wnd 65386, cwnd 536, wnd 536, effwnd 2, seq 7053, ack 7053
tcp_output: snd_wnd 65386, cwnd 536, wnd 536, effwnd 2, seq 7053, ack 7053, i 0
tcp_output: snd_wnd 65386, cwnd 536, wnd 536, seg == NULL, ack 7053
+-+-+-+-+-+-+-+-+-+-+-+-+-+- tcp_input: flags -+-+-+-+-+-+-+-+-+-+-+-+-+-+
tcp_receive: slow start cwnd 1072
tcp_receive: ACK for 7055, unacked->seqno 7053:7055
tcp_receive: removing 7053:7055 from pcb->unacked
tcp_output: snd_wnd 65384, cwnd 1072, wnd 1072, seg == NULL, ack 7055
netconn_recv_data: received , len=536904428
lwip_recvfrom: netconn_recv err=0, netbuf=
lwip_recvfrom: buflen=4 len=2 off=0 sock->lastoffset=0
lwip_recvfrom(1): addr=192.168.1.64 port=34736 len=2
lwip_recvfrom: lastdata now netbuf=
--- REC2
lwip_recvfrom(1, , 536872532, 0x2, ..)
lwip_recvfrom: top while sock->lastdata=
lwip_recvfrom: buflen=4 len=2 off=0 sock->lastoffset=2
lwip_recvfrom(1): addr=192.168.1.64 port=34736 len=2
lwip_recvfrom: deleting netbuf=
--- SEND
lwip_send(1, data=, size=536872528, flags=0x2)
tcp_output: snd_wnd 65384, cwnd 1072, wnd 1072, effwnd 2, seq 7055, ack 7055
tcp_output: snd_wnd 65384, cwnd 1072, wnd 1072, effwnd 2, seq 7055, ack 7055, i 0
lwip_send(1) err=0 written=2


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

--- REC1
lwip_recvfrom(1, , 536872532, 0x2, ..)
lwip_recvfrom: top while sock->lastdata=
+-+-+-+-+-+-+-+-+-+-+-+-+-+- tcp_input: flags -+-+-+-+-+-+-+-+-+-+-+-+-+-+
tcp_receive: slow start cwnd 1608
tcp_receive: ACK for 7057, unacked->seqno 7055:7057
tcp_receive: removing 7055:7057 from pcb->unacked
tcp_output: snd_wnd 65382, cwnd 1608, wnd 1608, seg == NULL, ack 7057
netconn_recv_data: received , len=536904428
lwip_recvfrom: netconn_recv err=0, netbuf=
lwip_recvfrom: buflen=4 len=2 off=0 sock->lastoffset=0
lwip_recvfrom(1): addr=192.168.1.64 port=34736 len=2
lwip_recvfrom: lastdata now netbuf=
--- REC2
lwip_recvfrom(1, , 536872532, 0x2, ..)
lwip_recvfrom: top while sock->lastdata=
lwip_recvfrom: buflen=4 len=2 off=0 sock->lastoffset=2
lwip_recvfrom(1): addr=192.168.1.64 port=34736 len=2
lwip_recvfrom: deleting netbuf=
--- SEND
lwip_send(1, data=, size=536872528, flags=0x2)
tcp_output: snd_wnd 65382, cwnd 1608, wnd 1608, effwnd 2, seq 7057, ack 7057
tcp_output: snd_wnd 65382, cwnd 1608, wnd 1608, effwnd 2, seq 7057, ack 7057, i 0
lwip_send(1) err=0 written=2


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

--- REC1
lwip_recvfrom(1, , 536872532, 0x2, ..)
lwip_recvfrom: top while sock->lastdata=
+-+-+-+-+-+-+-+-+-+-+-+-+-+- tcp_input: flags -+-+-+-+-+-+-+-+-+-+-+-+-+-+
tcp_receive: slow start cwnd 2144
tcp_receive: ACK for 7059, unacked->seqno 7057:7059
tcp_receive: removing 7057:7059 from pcb->unacked
tcp_output: snd_wnd 65380, cwnd 2144, wnd 2144, seg == NULL, ack 7059
netconn_recv_data: received , len=536904428
lwip_recvfrom: netconn_recv err=0, netbuf=
lwip_recvfrom: buflen=4 len=2 off=0 sock->lastoffset=0
lwip_recvfrom(1): addr=192.168.1.64 port=34736 len=2
lwip_recvfrom: lastdata now netbuf=
--- REC2
lwip_recvfrom(1, , 536872532, 0x2, ..)
lwip_recvfrom: top while sock->lastdata=
lwip_recvfrom: buflen=4 len=2 off=0 sock->lastoffset=2
lwip_recvfrom(1): addr=192.168.1.64 port=34736 len=2
lwip_recvfrom: deleting netbuf=
--- SEND
lwip_send(1, data=, size=536872528, flags=0x2)
tcp_output: snd_wnd 65380, cwnd 2144, wnd 2144, effwnd 2, seq 7059, ack 7059
tcp_output: snd_wnd 65380, cwnd 2144, wnd 2144, effwnd 2, seq 7059, ack 7059, i 0
lwip_send(1) err=0 written=2


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

--- REC1
lwip_recvfrom(1, , 536872532, 0x2, ..)
lwip_recvfrom: top while sock->lastdata=
+-+-+-+-+-+-+-+-+-+-+-+-+-+- tcp_input: flags -+-+-+-+-+-+-+-+-+-+-+-+-+-+
tcp_receive: slow start cwnd 2680
tcp_receive: ACK for 7061, unacked->seqno 7059:7061
tcp_receive: removing 7059:7061 from pcb->unacked
tcp_output: snd_wnd 65378, cwnd 2680, wnd 2680, seg == NULL, ack 7061
netconn_recv_data: received , len=536904428
lwip_recvfrom: netconn_recv err=0, netbuf=
lwip_recvfrom: buflen=4 len=2 off=0 sock->lastoffset=0
lwip_recvfrom(1): addr=192.168.1.64 port=34736 len=2
lwip_recvfrom: lastdata now netbuf=
--- REC2
lwip_recvfrom(1, , 536872532, 0x2, ..)
lwip_recvfrom: top while sock->lastdata=
lwip_recvfrom: buflen=4 len=2 off=0 sock->lastoffset=2
lwip_recvfrom(1): addr=192.168.1.64 port=34736 len=2
lwip_recvfrom: deleting netbuf=
--- SEND
lwip_send(1, data=, size=536872528, flags=0x2)
tcp_output: snd_wnd 65378, cwnd 2680, wnd 2680, effwnd 2, seq 7061, ack 7061
tcp_output: snd_wnd 65378, cwnd 2680, wnd 2680, effwnd 2, seq 7061, ack 7061, i 0
lwip_send(1) err=0 written=2


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

--- REC1
lwip_recvfrom(1, , 536872532, 0x2, ..)
lwip_recvfrom: top while sock->lastdata=
tcp_slowtmr: cwnd 536 ssthresh 1340
tcp_output: snd_wnd 65378, cwnd 536, wnd 536, effwnd 2, seq 7061, ack 7061
tcp_output: snd_wnd 65378, cwnd 536, wnd 536, effwnd 2, seq 7061, ack 7061, i 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+- tcp_input: flags -+-+-+-+-+-+-+-+-+-+-+-+-+-+
tcp_receive: slow start cwnd 1072
tcp_receive: ACK for 7063, unacked->seqno 7061:7063
tcp_receive: removing 7061:7063 from pcb->unacked
tcp_output: snd_wnd 65376, cwnd 1072, wnd 1072, seg == NULL, ack 7063
netconn_recv_data: received , len=536904428
lwip_recvfrom: netconn_recv err=0, netbuf=
lwip_recvfrom: buflen=4 len=2 off=0 sock->lastoffset=0
lwip_recvfrom(1): addr=192.168.1.64 port=34736 len=2
lwip_recvfrom: lastdata now netbuf=
--- REC2
lwip_recvfrom(1, , 536872532, 0x2, ..)
lwip_recvfrom: top while sock->lastdata=
lwip_recvfrom: buflen=4 len=2 off=0 sock->lastoffset=2
lwip_recvfrom(1): addr=192.168.1.64 port=34736 len=2
lwip_recvfrom: deleting netbuf=
--- SEND
lwip_send(1, data=, size=536872528, flags=0x2)
tcp_output: snd_wnd 65376, cwnd 1072, wnd 1072, effwnd 2, seq 7063, ack 7063
tcp_output: snd_wnd 65376, cwnd 1072, wnd 1072, effwnd 2, seq 7063, ack 7063, i 0
lwip_send(1) err=0 written=2


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

--- REC1
lwip_recvfrom(1, , 536872532, 0x2, ..)
lwip_recvfrom: top while sock->lastdata=
+-+-+-+-+-+-+-+-+-+-+-+-+-+- tcp_input: flags -+-+-+-+-+-+-+-+-+-+-+-+-+-+
tcp_receive: duplicate seqno 2719756760
tcp_output: snd_wnd 65376, cwnd 1072, wnd 1072, seg == NULL, ack 7063
+-+-+-+-+-+-+-+-+-+-+-+-+-+- tcp_input: flags -+-+-+-+-+-+-+-+-+-+-+-+-+-+
tcp_receive: duplicate seqno 2719756760
tcp_output: snd_wnd 65376, cwnd 1072, wnd 1072, seg == NULL, ack 7063
tcp_slowtmr: cwnd 536 ssthresh 1072
tcp_output: snd_wnd 65376, cwnd 536, wnd 536, effwnd 2, seq 7063, ack 7063
tcp_output: snd_wnd 65376, cwnd 536, wnd 536, effwnd 2, seq 7063, ack 7063, i 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+- tcp_input: flags -+-+-+-+-+-+-+-+-+-+-+-+-+-+
tcp_receive: slow start cwnd 1072
tcp_receive: ACK for 7065, unacked->seqno 7063:7065
tcp_receive: removing 7063:7065 from pcb->unacked
tcp_output: snd_wnd 65374, cwnd 1072, wnd 1072, seg == NULL, ack 7065
netconn_recv_data: received , len=536904428
lwip_recvfrom: netconn_recv err=0, netbuf=
lwip_recvfrom: buflen=4 len=2 off=0 sock->lastoffset=0
lwip_recvfrom(1): addr=192.168.1.64 port=34736 len=2
lwip_recvfrom: lastdata now netbuf=
--- REC2
lwip_recvfrom(1, , 536872532, 0x2, ..)
lwip_recvfrom: top while sock->lastdata=
lwip_recvfrom: buflen=4 len=2 off=0 sock->lastoffset=2
lwip_recvfrom(1): addr=192.168.1.64 port=34736 len=2
lwip_recvfrom: deleting netbuf=
--- SEND
lwip_send(1, data=, size=536872528, flags=0x2)
tcp_output: snd_wnd 65374, cwnd 1072, wnd 1072, effwnd 2, seq 7065, ack 7065
tcp_output: snd_wnd 65374, cwnd 1072, wnd 1072, effwnd 2, seq 7065, ack 7065, i 0
lwip_send(1) err=0 written=2


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

--- REC1
lwip_recvfrom(1, , 536872532, 0x2, ..)
lwip_recvfrom: top while sock->lastdata=
+-+-+-+-+-+-+-+-+-+-+-+-+-+- tcp_input: flags -+-+-+-+-+-+-+-+-+-+-+-+-+-+
tcp_receive: duplicate seqno 2719756764
tcp_output: snd_wnd 65374, cwnd 1072, wnd 1072, seg == NULL, ack 7065
+-+-+-+-+-+-+-+-+-+-+-+-+-+- tcp_input: flags -+-+-+-+-+-+-+-+-+-+-+-+-+-+
tcp_receive: duplicate seqno 2719756764
tcp_output: snd_wnd 65374, cwnd 1072, wnd 1072, seg == NULL, ack 7065
tcp_slowtmr: cwnd 536 ssthresh 1072
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, effwnd 2, seq 7065, ack 7065
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, effwnd 2, seq 7065, ack 7065, i 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+- tcp_input: flags -+-+-+-+-+-+-+-+-+-+-+-+-+-+
tcp_receive: duplicate seqno 2719756764
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, seg == NULL, ack 7065
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, seg == NULL, ack 7065
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, seg == NULL, ack 7065
+-+-+-+-+-+-+-+-+-+-+-+-+-+- tcp_input: flags -+-+-+-+-+-+-+-+-+-+-+-+-+-+
tcp_receive: duplicate seqno 2719756764
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, seg == NULL, ack 7065
tcp_slowtmr: cwnd 536 ssthresh 1072
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, effwnd 2, seq 7065, ack 7065
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, effwnd 2, seq 7065, ack 7065, i 0
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, seg == NULL, ack 7065
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, seg == NULL, ack 7065
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, seg == NULL, ack 7065
tcp_slowtmr: cwnd 536 ssthresh 1072
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, effwnd 2, seq 7065, ack 7065
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, effwnd 2, seq 7065, ack 7065, i 0
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, seg == NULL, ack 7065
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, seg == NULL, ack 7065
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, seg == NULL, ack 7065
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, seg == NULL, ack 7065
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, seg == NULL, ack 7065
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, seg == NULL, ack 7065
tcp_slowtmr: cwnd 536 ssthresh 1072
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, effwnd 2, seq 7065, ack 7065
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, effwnd 2, seq 7065, ack 7065, i 0
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, seg == NULL, ack 7065
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, seg == NULL, ack 7065
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, seg == NULL, ack 7065
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, seg == NULL, ack 7065
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, seg == NULL, ack 7065
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, seg == NULL, ack 7065
tcp_output: snd_wnd 65374, cwnd 536, wnd 536, seg == NULL, ack 7065

.... ad infinitum ....
_______________________________________________
lwip-users mailing list
lwip-users@...
https://lists.nongnu.org/mailman/listinfo/lwip-users
John, BOOM | 4 Oct 20:41 2014

lwip vs openwrt?

Noob question: what's the difference between LwIP and OpenWRT?
 
-thx!
_______________________________________________
lwip-users mailing list
lwip-users@...
https://lists.nongnu.org/mailman/listinfo/lwip-users
Nikeah Q | 3 Oct 14:59 2014
Picon

Sending large data problem..

Hello,

I'm having a lot of trouble sending large data using TCP.  I read that multiple tcp_writes will be required so as a simple test, i've tried this in my tcp accept method:

int len = tcp_sndbuf(newpcb);

    while(sentSize < 8192)
    {
        err = tcp_write(newpcb, data, len, 0x01);
        err = tcp_output(newpcb);
       
        sentSize += len;
    } // end while

Data is an array with 4096 elements.  len evaluates to 5893.

My receiving application detects only 5893 bytes sent.  This is confirmed using wireshark.  Running the code in the debugger shows that both tcp_write and tcp_output are called twice.

Am I missing anything here?

Thanks in advance,

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

Gmane