mjackson | 27 Oct 18:53 2014
Picon

TCIP Support Flow for PPPos

I have couple of high level flow questions regarding TCPIP support  for
PPPos.
I using LWIP 1.4.1

	1. After PPP has completed negotiations (LCP, AUTH and IPCP), 
	   which api should I call to connect to a remote server?	
	   
	2. After connecting to a remote server, should I used the following
	   api's to send and receive data.
	   
		- ppp_netif_output_ip4(...) or ppp_write(...)
		- pppos_input(...)

Thank you,
Maurice

--
View this message in context: http://lwip.100.n7.nabble.com/TCIP-Support-Flow-for-PPPos-tp23430.html
Sent from the lwip-users mailing list archive at Nabble.com.
Matthias Dübon | 27 Oct 12:01 2014
Picon

tcp_tmr and timers.c

Hello everyone,

I am diving into lwip and I have "found" the timers.c module. This
module seems to be  a nice possibility to setup the different timer
(e.g. for arp, DHCP, ...). But I am wondering why is the call to
tcp_tmr not included in timers.c? Are there any architectural reasons
or do I understand something wrong? BTW. I am working without an OS,
NO_SYS = 1

best,
Matthias
ᐧ

_______________________________________________
lwip-users mailing list
lwip-users <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Michael Tharp | 23 Oct 19:42 2014

ARP lookups and UDP servers

Hi all,

I have an embedded application that is a NTP server (UDP based). Due to 
the timing sensitivity of the application I want to avoid doing an ARP 
lookup just to reply to a single query packet. I see there is an 
ETHARP_TRUST_IP_MAC option that will automatically save the MAC from 
incoming packets into the ARP table, however there are two things that 
keep it from helping much.  Firstly it calls etharp_update_arp_entry 
with the ETHARP_FLAG_FIND_ONLY option which gives up if there isn't 
already a free entry. This means that if there are more clients than ARP 
table slots, the table fills up and it starts making ARP queries again. 
Secondly, even if I change that to ETHARP_FLAG_TRY_HARD which will 
displace the oldest entry, it only works for on-subnet clients. Distant 
clients will force a lookup of the gateway's IP each time. Of course a 
bigger ARP table will help, but I can only increase it so much and I 
want to be able to support subnets with arbitrarily many hosts on them, 
so relying on that is not practical.

Ideally I think I would simply like to take the original packet and flip 
it around so both layer 2 and layer 3 source and destination addresses 
are exchanged, and no lookup is needed. Is there any existing facility 
that can help with this? I can figure out how to manually munge the IP 
headers and send the reply as a raw layer 2 frame but it would be great 
if a function already existed to do this. Maybe a udp_reply() function 
that takes a pbuf as input.

Also this optimization needs to eventually happen for IPv6 as well. I 
haven't looked yet to see whether IPv6 has the same issue but I assume 
it has to, but in ND rather than ARP of course.

(Continue reading)

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

Gmane