Muthu Selvi | 18 Nov 07:45 2014
Picon

Iperf test in lwip

Hi,
 I'm really very much struggle with iperf tcp and udp tests in lwip
 Im working in  AT91SAM9263 -FREERTOS and using lwip_v1.3.2 stack by Ethernet driver.
 Getting very low 0.4Mbit/sec rate for iperf tcp downlink and 5Mbits/sec for iperf udp downlink.
 Can u help me to improve performance?..what is the lwip stack  options for improving  throughputs? 



MuthuSelvi.R
_______________________________________________
lwip-users mailing list
lwip-users@...
https://lists.nongnu.org/mailman/listinfo/lwip-users
mjackson | 16 Nov 07:36 2014
Picon

Three-way Handshake (extraneous ACK-SYN)

I'm trying to establish a connection to a remote server with netconn_connect. 
The sequence starts off as it should by following the 3-way handshake in
*SEQUENCE 1.*

*SEQUENCE 1:*
CLIENT (LWIP): SYN
SERVER         : ACK-SYN
CLIENT          : ACK

After the CLIENT sends an "ACK" in SEQUENCE 1, the SERVER sends two
additional ACK-SYN as shown below in SEQUENCE 2 and SEQUENCE 3.  Why did the
server send two additional ACK-SYNs?  Is the behavior typical?

*SEQUENCE 2:*
SERVER         : ACK-SYN
CLIENT          : ACK

*SEQUENCE 3:*
SERVER         : ACK-SYN
CLIENT          : ACK

Maurice

--
View this message in context: http://lwip.100.n7.nabble.com/Three-way-Handshake-extraneous-ACK-SYN-tp23532.html
Sent from the lwip-users mailing list archive at Nabble.com.
aaisha | 14 Nov 07:43 2014

Assertion "pbuf_free: p->ref > 0" failed at line 651 in ../src/lwip/core/pbuf.c


Hi,
I'm trying to send ping and udp packets. But for both packets I'm getting assertion failed like this
Assertion "pbuf_free: p->ref > 0" failed at line 651 in ../src/lwip/core/pbuf.c
Can anyone please help me..

Regards,
Aaisha Ahmed.
_______________________________________________
lwip-users mailing list
lwip-users@...
https://lists.nongnu.org/mailman/listinfo/lwip-users
chrysn | 14 Nov 10:09 2014
Picon

hayes commands popping up in ppp stream

hello lwip users,

i'd like to keep track of my gsm device's position while a ppp data
connection is active. unfortunately, that means that the non-ppp
messages (/\r\n+CENG:[0-9,"a-f]+\r\n/ in my case) arrive in the same
stream as ppp messages. (at least, it appears, they are not fully
interleaved).

does the lwip ppp stack provide a mechanism to feed back rejected
strings somewhere else, or do i need to inspect the ppp stack's internal
state from outside, determine whether it is currenlty inside or outside
of a frame, and divert \r\n... sequences from it if no frame is
currently being received?

for reference, i'm working with lwip master branch, and the modem i'm
using is a simcom sim900d. apart from the CENG messages, occasional
"\r\nUNDER-VOLTAGE WARNNING\r\n" (sic) messages appear, and those can't
be switched off.

best regards
chrysn

--

-- 
This may seem a bit weird, but that's okay, because it is weird.
  -- perldata(1) about perl variables
_______________________________________________
lwip-users mailing list
lwip-users@...
https://lists.nongnu.org/mailman/listinfo/lwip-users
aaisha22 | 14 Nov 07:36 2014

Assertion "pbuf_free: p->ref > 0" failed at line 651 in ../src/lwip/core/pbuf.c

Hi,
I'm trying to send ping and udp packets. But for both packets I'm getting
assertion failed like this
Assertion "pbuf_free: p->ref > 0" failed at line 651 in
../src/lwip/core/pbuf.c
Can anyone please help me..

Regards,
Aaisha Ahmed.

--
View this message in context: http://lwip.100.n7.nabble.com/Assertion-pbuf-free-p-ref-0-failed-at-line-651-in-src-lwip-core-pbuf-c-tp23512.html
Sent from the lwip-users mailing list archive at Nabble.com.
Ivan Delamer | 13 Nov 17:32 2014

Re: oxff==0x60 condition do not match for received IP6 packet in tcipip_thread

These are really useful packet dumps.

They show standard 14-byte Ethernet header followed by IPv6 header.

This packet should be accepted by ethernet_input() and from there it 
would go to ip6_input().

If you debug stepping into your functions, where does it end up?

Cheers
Ivan

> Date: Wed, 12 Nov 2014 00:01:42 -0700 (MST)
> From: mfkexpress <mohsin_kesarani@...>
> To: lwip-users@...
> Subject: Re: [lwip-users] oxff==0x60 condition do not match for
> 	received IP6 packet in tcipip_thread
> Message-ID: <1415775702587-23487.post@...>
> Content-Type: text/plain; charset=us-ascii
> 
> I'm really very much confised with this p->payload.
> 
> Below are the settings and received packets at my device:
> 
>      1) netif->flags= NETIF_FLAG_BROADCAST | NETIF_FLAG_ETHARP |
> NETIF_FLAG_LINKUP
> 
>      2) I printed incoming packets of my device using p->payload which
> appears something like below:
> 
>         p->payload  33 33 00 00 00 02 74 46
>                           A0 9E 85 9B 86 DD 60 00
>                           00 00 00 10 3A FF FE 80
>                           00 00 00 00 00 00 64 E4
>                           E3 51 A0 9D 5B F4 FF 02
>                           00 00 00 00 00 00 00 00
>                           00 00 00 00 00 02 85 00
>                           9C E5 00 00 00 00 01 01
>                           74 46 A0 9E 85 9B AF DD
>                           0E D2
> 
>        p->payload  33 33 00 00 00 01 74 46
>                          A0 9E 85 9B 86 DD 60 00
>                          00 00 00 20 3A FF FE 80
>                          00 00 00 00 00 00 64 E4
>                          E3 51 A0 9D 5B F4 FF 02
>                          00 00 00 00 00 00 00 00
>                          00 00 00 00 00 01 88 00
>                          35 8D 20 00 00 00 FE 80
>                          00 00 00 00 00 00 64 E4
>                          E3 51 A0 9D 5B F4 02 01
>                          74 46 A0 9E 85 9B 6F 23
>                          2A 63
> 
> Now first nibble is not "6' in above packets but 30th byte is "6".
> Than how it will enter into IPV6 case of tcpip_thread()??
> 
> Please any soluton..
> 
> Regards,
> Mohsin
> 
> 
> 
Fabian Koch | 13 Nov 13:28 2014
Picon

lwip_close blocks on non-blocking socket when cable is removed

Hey everyone,

 

I’m using LwIP 1.4.1 and we noticed that on a non-blocking socket, lwip_close() suddenly starts being blocking when the cable is removed.

 

This is because:

lwip_close() -> netconn_delete() -> API_MSG -> do_delconn() -> do_close_internal() -> tcp_close() -> tcp_close_shutdown() -> tcp_send_fin() -> tcp_enqueue_flags()

 

That last function checks the TCP send queue and returns with ERR_MEM when the cable is unplugged because the send queue is full.

Thus, that error is given up to do_close_internal() which does NOT sys_sem_signal() the op_completed semaphore and in turn, the API_MSG is still being waited on.

Do_close_internal() sets poll_tcp and sent_tcp callbacks which re-call do_close_interal() until it works (when the cable is re-plugged and the send queue can be worked on).

 

Is this bug known and maybe even fixed on current master branch?

We need the non-blocking sockets to actually _be_ non-blocking.

 

Kind regards,

Fabian

_______________________________________________
lwip-users mailing list
lwip-users@...
https://lists.nongnu.org/mailman/listinfo/lwip-users
Robert Wood | 13 Nov 10:54 2014
Picon

Pulling data from a server using HTTP with lwIP

I'm getting started with lwIP; I have the SAM7X FreeRTOS demo running 
and it is serving its demo file just fine.

However, what I really need to do is pull a file *from* a server. So, 
I've created a new thread and done the following:

xNetConn = netconn_new ( NETCONN_TCP );

IP4_ADDR(&local_ip,emacIPADDR0,emacIPADDR1,emacIPADDR2,emacIPADDR3);
rc1 = netconn_bind ( xNetConn, &local_ip, 0 );
IP4_ADDR(&remote_ip,192,168,0,87);
rc2 = netconn_connect ( xNetConn, &remote_ip, 80 );

local_ip is the fixed address of my board, 192.168.0.87 is my desktop.

I've hooked up Wireshark to look at what's going on and I get two 
packets (*): the lwIP SAM7X board sending out the initial request for a 
connection with the SYN flag set and my desktop, which is running an 
Apache server, replying with SYN & ACK flags set.

Now, I would expect the lwIP stack to then automatically return the 
third packet in the handshake with just ACK flag set.

When the desktop sends out its SYN/ACK packet, I can see it goes through 
a number of functions. It goes into ip_input(), you can see that the IP 
addresses match and it calls tcp_input() which is happy that the ports 
are correct and match. It clearly sees the flags are set to 0x12, which 
is exactly what Wireshark says it is.

It ends up going into tcp_process(), in the switch statement for 
pcb->state is goes into the SYN_SENT case, seems to increment the 
sequence number correctly (I can see that number in the Wireshark data 
and that gets incremented by one. Eventually, it goes into tcp_ack(), 
which calls tcp_output(). pcb->flags is set to 0x01 which doesn't seem 
right, but what is less right is that no packet gets sent out.

So, what vital step am I missing here? Is this something to do with 
needing to specify a callback function and me sending out the 
appropriate message? It looked to me like there was one set up; maybe it 
was,  just set-up and queued but not sent?

I only have a tenuous grasp callback functions, so it may be that I'm 
missing something vital.

I have plenty of FreeRTOS experience, but this is my first foray into 
lwIP. In truth, a lot of this is new; I talk about these flags like SYN 
and ACK as if I know what I'm on about, but this is all new to me in the 
past few days!

Many thanks. :~)

Rob

* Actually I get a few more - my desktop resending its last packet!
Ivan Delamer | 11 Nov 18:12 2014

Re: oxff==0x60 condition do not match for received IP6 packet in tcipip_thread

You need to check where p->payload is pointing at.

The first nibble of the first byte of an IPv6 packet is "6" which 
specifies that it is an IPv6 (and not IPv4) packet.

If that value is not 6 then there is a problem with the packet format.

Check to see if it is still pointing at the Ethernet header.

In that case, make sure you have defined LWIP_ETHERNET and that your 
netif has either NETIF_FLAG_ETHARP | NETIF_FLAG_ETHERNET or both.

Then it will go through ARP or ND6 protocol first.

Cheers
Ivan

> Date: Tue, 11 Nov 2014 05:40:13 -0700 (MST)
> From: mfkexpress <mohsin_kesarani@...>
> To: lwip-users@...
> Subject: [lwip-users] oxff==0x60 condition do not match for received
> 	IP6 packet in tcipip_thread
> Message-ID: <1415709613468-23481.post@...>
> Content-Type: text/plain; charset=us-ascii
> 
> Hi,
> 
> I'm using lan9221 card in my device and trying to implement IPv6 in 
> it.
> 
> I can see that IPv6 packets are received on my device but ip6_input() 
> is not
> being called in tcpip_thread() because following condition do not 
> satisfy in
> my case:
> 
> #if LWIP_ETHERNET
>       if (msg->msg.inp.netif->flags & (NETIF_FLAG_ETHARP |
> NETIF_FLAG_ETHERNET)) {
>         ethernet_input(msg->msg.inp.p, msg->msg.inp.netif);
>       } else
> #endif /* LWIP_ETHERNET */
> #if LWIP_IPV6
>       if ((*((unsigned char *)(msg->msg.inp.p->payload)) & *0xf0) == 
> 0x60)*
> {
>           ip6_input(msg->msg.inp.p, msg->msg.inp.netif);
>       } else
> #endif /* LWIP_IPV6 */
>       {
>         ip_input(msg->msg.inp.p, msg->msg.inp.netif);
>       }
> 
> Can anyone please tell me why this condition do not match though my 
> input
> packets are IPv6 only and thay contains field "60" also.
> 
> Any help would be greatly appreciated.
> 
> Thanks & regards,
> Mohsin
mfkexpress | 11 Nov 13:40 2014
Picon

oxff==0x60 condition do not match for received IP6 packet in tcipip_thread

Hi,

I'm using lan9221 card in my device and trying to implement IPv6 in it. 

I can see that IPv6 packets are received on my device but ip6_input() is not
being called in tcpip_thread() because following condition do not satisfy in
my case:

#if LWIP_ETHERNET
      if (msg->msg.inp.netif->flags & (NETIF_FLAG_ETHARP |
NETIF_FLAG_ETHERNET)) {
        ethernet_input(msg->msg.inp.p, msg->msg.inp.netif);
      } else
#endif /* LWIP_ETHERNET */
#if LWIP_IPV6
      if ((*((unsigned char *)(msg->msg.inp.p->payload)) & *0xf0) == 0x60)*
{
          ip6_input(msg->msg.inp.p, msg->msg.inp.netif);
      } else
#endif /* LWIP_IPV6 */
      {
        ip_input(msg->msg.inp.p, msg->msg.inp.netif);
      }

Can anyone please tell me why this condition do not match though my input
packets are IPv6 only and thay contains field "60" also.

Any help would be greatly appreciated.

Thanks & regards,
Mohsin

--
View this message in context: http://lwip.100.n7.nabble.com/oxff-0x60-condition-do-not-match-for-received-IP6-packet-in-tcipip-thread-tp23481.html
Sent from the lwip-users mailing list archive at Nabble.com.
Ivan Delamer | 10 Nov 17:46 2014

Re: IPv6 packet not sent or received

> Date: Sun, 9 Nov 2014 22:46:07 -0700 (MST)
> From: mfkexpress <mohsin_kesarani@...>
> To: lwip-users@...
> Subject: Re: [lwip-users] IPv6 packet not sent or received
> Message-ID: <1415598367969-23474.post@...>
> Content-Type: text/plain; charset=us-ascii
> 
> Thank You so much Ivan!!!
> 
> Earlier I added "case ETHTYPE_IPV6" in lan9221_if_input_interrupt() 
> but
> forgot to add it in lan9221_if_input().
> 
> Now my receiption part is ok. Only one problem is that in all received
> packets, I get some additional 4 bytes at the end.

This is not LwIP-related this is due to your lan9221 code, so I can't 
really help you there.

> And still transmission part is not working

Packets may be queued in ND6 code waiting for address resolution. Do 
you see any neighbor discovery messages going out?

I don't have any more advice other than to trace the outgoing packets 
through the debugger...

Ivan

> 
> Thaks & Regards,
> Mohsin
> 

Gmane