ryan.jin | 23 Apr 12:42 2014

Multicast on lwip

Hi all,

I'm new to lwip, and I want to create a multicast receiver with lwip. My steps are as follow:
1. Enable LWIP_IGMP;
2. Set NETIF_FLAG_IGMP in low_level_init();
3. Join multicast group, create and bind pcb;
4. udp_connect to remote_ip (or multicast IP address? Both are tried but failed)

Joining group returns success, and everything looks fine when program executing this. However the multicast doesn't work. Does any one know what I'm missing? 

I found "netif->igmp_mac_filter != NULL" in igmp_joingroup(), but it is set as NULL and not implemented. Do I need to implement it by myself to set the filter or it is OK just leave it as NULL?

Thanks a lot for your help!
Best regards,
Ryan Jin
_______________________________________________
lwip-users mailing list
lwip-users@...
https://lists.nongnu.org/mailman/listinfo/lwip-users
Kalneus Leonid | 11 Apr 14:15 2014
Picon

Non-blocking I/O in lwip - need example

Hi all!
 
I'm newbie in lwip. 
I want to implement remote logging using non-blocking I/O api. But there is not enough information in wiki about it.
 
Could someone share an example with using non-blocking I/O api. 
 
Leonid
_______________________________________________
lwip-users mailing list
lwip-users@...
https://lists.nongnu.org/mailman/listinfo/lwip-users
Sergio R. Caprile | 11 Apr 03:09 2014
Picon

Re: need help building netio server

If you arrive here looking for something on the netio server, yes, the
one in contrib (at least upto 1.4.1) is incomplete.

There's one guy who submitted patch #7026 with a full server; however,
that server reacts with one write to each ACK it gets, and so its output
throughput is very low.
I re-wrote the tx part on that one, so we all can have something (far
from ideal) but probably good enough to catch some flaws when developing
link-layer drivers.
And yes, I've added it to that patch, found here:
http://savannah.nongnu.org/patch/?7026

--

-- 
Guy Eschemann | 10 Apr 14:08 2014
Picon

MEM TCPIP_MSG_INPKT

Hello,

while trying to track down the performance bottlenecks of my lwIP instance, the following section in the stats display caught my attention:

MEM TCPIP_MSG_INPKT
        avail: 8
        used: 0
        max: 8
        err: 2

What parameter do I have to change to increase the number of "TCPIP_MSG_INPKT"?

Thanks,
Guy.

Guy Eschemann
noasic e.K.
Sundheimer Feld 6
77694 Kehl, Germany

Tel.: +49 (0) 7851 63 66 305
Mobile: +49 (0) 173 72 51 886
guy <at> noasic.com
Follow me on Twitter: <at> geschema
Skype: guy.eschemann
USt-IdNr.: DE266749532
HRA 703582, Amtsgericht Freiburg i. Br.

Visit us at ALL PROGRAMMABLE PLC2 Days 2014
20 - 22.05.2014, Stuttgart, Germany
_______________________________________________
lwip-users mailing list
lwip-users@...
https://lists.nongnu.org/mailman/listinfo/lwip-users
Sergio R. Caprile | 10 Apr 02:52 2014
Picon

raw api tcp_write()ing small chunks fills snd_queue

Hi, I need help here.
I have this raw api application which tcp_write()s 5 small (~20 bytes)
messages and then checks tcp_sndbuf() to send the biggest possible
chunk, but it ends up having to send a smaller chunk because an internal
queue gets full.

My settings are (almost) standard:
TCP_MSS = 536
TCP_SND_BUF = 2*TCP_MSS
TCP_SND_QUEUELEN = (4*TCP_SND_BUF + TCP_MSS -1)/TCP_MSS
TCP_OVERSIZE = TCP_MSS
MEMP_NUM_PBUF = 30
MEMP_NUM_TCP_SEG = 16
PBUF_POOL_SIZE = 32
PBUF_POOL_BUFSIZE = TCP_MSS+overhead (default)

My operation:
Get a request
tcp_write() with apiflags=0; 5 times, with ~20-byte messages
len = tcp_sndbuf(pcb);
len = LWIP_MIN(len, 2*tcp_mss(pcb));
tcp_write(,len,0)
    900-bytes fails, 450 fails, 225 succeeds

debug log is: "tcp_write: queue too long 9 (8)", that is, line 581 of
tcp_output.c (in 1.4.1 release), Phase 3: Create new segments.

As I understand, those small nocopy tcp_writes generate a queue of type
PBUF_REF, which added to something (? there is no prior traffic in this
pcb, only a just recently closed connection for a prior request)  leads
to a queue that is too big for this segment.

Instead of just increasing TCP_SND_QUEUELEN, or avoiding those small
writes (which I can't right now), I'd like to understand what is going
on and don't have the same problem later.

I've tried inserting a tcp_output() call between the small writes and
the big one, with no difference. I guess this is because tcp can't get
rid of the chain until the remote end acknowledges this segment and I'm
still holding the CPU.
I've set TCP_WRITE_FLAG_COPY for the small writes and it works OK (and
this is what I would do if there is no other option to try)

I'd like to hear suggestions, explanations, criticism, pointers to
documentation I overlooked, whatever. Everything is welcomed.

Regards

--

-- 
LMao | 9 Apr 20:47 2014

ppp-new IP forwarding only works one direction (Ethernet to PPP)

Hi Sylvain,

I try to get IP forwarding work between two interfaces - Ethernet and PPP. So far, I can see it works in one
direction, i.e., Packets from Ethernet can be forward to PPP, but it seems lwIP stack silently drop the
packets in the opposite direction, i.e., from PPP to Ethernet. Can you think of any reason causing the problem?

In order to forward packets between two interfaces, I slightly modified ip_forward function in ip4.c. As
shown in the following code snippet, I eliminate the call to ip_route function. Instead, I just route
traffic from one interface to the other interface and also print out debug message showing which
interface is used for forwarding (either Ethernet interface "em" or PPP interface "pp" as shown in the log
at the bottom.)

// -----------------------------------------------------
// !!! Really bad action !!! Hacking lwIP stack for experiement only
// -----------------------------------------------------
#if 0
  /* Find network interface where to forward this IP packet to. */
  netif = ip_route(ip_current_dest_addr());
  if (netif == NULL) {
    LWIP_DEBUGF(IP_DEBUG, ("ip_forward: no forwarding route for %"U16_F".%"U16_F".%"U16_F".%"U16_F" found\n",
      ip4_addr1_16(ip_current_dest_addr()), ip4_addr2_16(ip_current_dest_addr()),
      ip4_addr3_16(ip_current_dest_addr()), ip4_addr4_16(ip_current_dest_addr())));
    /*  <at> todo: send ICMP_DUR_NET? */
    goto return_noroute;
  }
#endif

  for (netif = netif_list; netif != NULL; netif = netif->next) 
  {
    if (netif != inp)
    {
      LWIP_DEBUGF(IP_DEBUG, ("ip_forward: forward packets to interface.%c%c\n",
        netif->name[0], netif->name[1]));
      break;
    }
  }
// -----------------------------------------------------
// !!! Really bad action !!! Hacking lwIP stack for experiement only
// -----------------------------------------------------

My test setup is like this:

                        Ethernet                                                PPP
             PC   -------------  My gateway device  --------  Linux PPP server
192.168.0.211       192.168.0.50        192.168.1.105       192.168.1.106

I ping from my PC to the PPP server. Here's some logging messages showing the modified ip_forward function
works as expected.

ip_input: iphdr->dest 0x6a01a8c0 netif->ip_addr 0x3200a8c0 (0x1a8c0, 0xa8c0, 0x6a000000)
ip_input: iphdr->dest 0x6a01a8c0 netif->ip_addr 0x6901a8c0 (0x6a01a8c0, 0x6901a8c0, 0x0)
ip_input: packet not for us.
ip_forward: forward packets to interface.pp
ip_forward: forwarding packet to 192.168.1.106
ip_input: iphdr->dest 0xd300a8c0 netif->ip_addr 0x6901a8c0 (0xd300a8c0, 0x6901a8c0, 0x0)
ip_input: iphdr->dest 0xd300a8c0 netif->ip_addr 0x3200a8c0 (0xa8c0, 0xa8c0, 0xd3000000)
ip_input: packet not for us.
ip_forward: forward packets to interface.em
ip_forward: forwarding packet to 192.168.0.211

I captured PPP traffic on the serial port and also captured Ethernet traffic using Wireshark. I can clearly
see PPP traffic on both directions(into and out from the PPP server) and they are correct frames as
expected. However, the traffic from PPP server to my PC NEVER showed up in Wireshark. It seems lwIP
silently drop those packets. What should I do to find out the cause of the problem?

Thanks,

Charles
Alain Mouette | 9 Apr 18:25 2014
Picon

Where is poll_driver() ?

I am writing the driver from scratch for ENC424J600, using Microchip's 
low-level drivers

I checkd the wiki and the file ethernetif.c and I have one (first) question:

Where is the prototype for  poll_driver() ??

Will it be called from LWIP in multi-threaded systems?

It is mentioned in the chapter about single threaded system, but I am 
using FreeRTOS.

I can see no polling or status functions in ethernetif.c, how is this 
implemented?

thanks,
Alain
LMao | 8 Apr 17:55 2014

I cannot get PPP-new IP forwarding and pppapi_set_default() work

Hi Sylvain,

Here's my scenario: 
I am developing a gateway between Ethernet and PPP using ppp-new branch. The gateway device has one
Ethernet port(IP 192.168.0.50, i.e., 0x3200a8c0) and one PPP port (IP 192.168.1.105, i.e.,
0x6901a8c0). For testing purpose, I connected the Ethernet port to a PC (IP 192.168.0.211, i.e.,
0xd300a8c0) and connected the PPP port to a Linux PPP server's PPP port(IP 192.168.1.106, i.e.,
0x6a01a8c0). PPP connection has been successfully built up. From my PC, I can ping my gateway's PPP port
(192.168.1.105) but I couldn't ping PPP server (192.168.0.106). I am sure I have set PC routing correctly
because the ping packet can reach my gateway's serial port as the debug message shows below. Here are the
debug messages, the first part shows the success of ping my gateway's PPP port while the second par
 t shows the failure of ping PPP server.

First log - success of ping my gateway's PPP port
----------------------------------------------------------
ip_input: iphdr->dest 0x6901a8c0 netif->ip_addr 0x3200a8c0 (0x1a8c0, 0xa8c0, 0x69000000)
ip_input: iphdr->dest 0x6901a8c0 netif->ip_addr 0x6901a8c0 (0x6901a8c0, 0x6901a8c0, 0x0)
ip_input: packet accepted on interface pp
ip_input: 
IP header:
+-------------------------------+
| 4 | 5 |  0x00 |        60     | (v, hl, tos, len)
+-------------------------------+
|      736      |000|       0   | (id, flags, offset)
+-------------------------------+
|  128  |    1  |    0xb454     | (ttl, proto, chksum)
+-------------------------------+
|  192  |  168  |    0  |  211  | (src)
+-------------------------------+
|  192  |  168  |    1  |  105  | (dest)
+-------------------------------+
ip_input: p->len 60 p->tot_len 60
ip_output_if: em0
IP header:
+-------------------------------+
| 4 | 5 |  0x00 |        60     | (v, hl, tos, len)
+-------------------------------+
|      736      |000|       0   | (id, flags, offset)
+-------------------------------+
|  255  |    1  |    0x3554     | (ttl, proto, chksum)
+-------------------------------+
|  192  |  168  |    1  |  105  | (src)
+-------------------------------+
|  192  |  168  |    0  |  211  | (dest)
+-------------------------------+
netif->output()

Second log - Fail to ping PPP server
----------------------------------------------------------
ip_input: iphdr->dest 0x6a01a8c0 netif->ip_addr 0x3200a8c0 (0x1a8c0, 0xa8c0, 0x6a000000)
ip_input: iphdr->dest 0x6a01a8c0 netif->ip_addr 0x6901a8c0 (0x6a01a8c0, 0x6901a8c0, 0x0)
ip_input: packet not for us.
ip_forward: not bouncing packets back on incoming interface.

I enabled IP_FORWARDING and also called pppapi_set_default() function. Should I expect the above
scenario working? Or I have to implement my own static routing?

Another thing I noticed is ip_forward function seems give false debugging information " ip_forward: not
bouncing packets back on incoming interface". The packet was coming from Ethernet interface (from my PC)
and its destination should be PPP interface, so there's not bouncing back packet.

Thanks,

Charles
Yafei Yan | 8 Apr 10:33 2014
Picon

Does the API "lwip_shutdown()" work fine?

Hi All,
LwIP Version in my board: LwIP1.4.0
Network way: GPRS modem dial via PPPoS.

I am facing a problem that there are a lot of FIN_WAIT_1 state TCP connections, because I broke network connection when my program called lwip_close() to close a socket descriptor. FIN_WAIT_1 state indicates that the client sends TCP FIN packet but not receive the TCP ACK packet. In my scenario, when the program has sent tcp data, it needs to shutdown the GPRS modem(so network connection is broke) due to low power consumption. It may not receive the TCP ACK packet actually. As far as I know, API "lwip_shutdown()" can shutdown a TCP connection, but it seems that it doesn't work. 

Waiting for guys' help.
Thanks!

Yafei
_______________________________________________
lwip-users mailing list
lwip-users@...
https://lists.nongnu.org/mailman/listinfo/lwip-users
Alain Mouette | 7 Apr 23:00 2014
Picon

Please Help with ENC424J600

In need desperatly to make my ENC424J600 work this week :(

I already have SPI working and tested comunicating with it on my STM32F101 with FreeRTOS, but I cannot find anything to start with.

I had a previous version of LWIP on a different processor/Phy, now I just need to make it work with this new setup...

Any kind of help would be appreciated ;-)
Thanks,
Alain
_______________________________________________
lwip-users mailing list
lwip-users@...
https://lists.nongnu.org/mailman/listinfo/lwip-users
LMao | 7 Apr 22:05 2014

PPP-new threaded vs non-threaded application

Hi Sylvain,

I think in your post http://lists.nongnu.org/archive/html/lwip-users/2013-06/msg00011.html, you
gave some code snippet  showing how to use ppp-new in user's application. I believe that snippet is used in a
non-threaded application, am I right?

Can you give an example application code snippet for threaded environment? I have problem to get my
threaded application work with PPP-new. Basically, I followed your example for non-threaded
environment, but use functions with pre-fix pppapi_ instead of ppp_ as you suggested in that post. The
following code snippet is my task(freeRTOS is used) function handling PPP. 

void vPPPApplication(void)
{
  ppp_pcb *ppps;
  char *username = "test";
  char *password = "test";

  int connected = 0;
  int pd;

  ppps = pppapi_new();

  /* set the method of authentication. Use PPPAUTHTYPE_PAP, or
   * PPPAUTHTYPE_CHAP for more security .
   * If this is not called, the default is PPPAUTHTYPE_NONE. 
   */
  pppapi_set_auth(ppps, PPPAUTHTYPE_PAP, username, password);

  pppapi_over_serial_create(ppps, 0, ppp_link_status_cb, NULL);

  pppapi_open(ppps, 0);
  while(1) 
  {
    u8_t buffer[128];
    int len;
    len = sio_read(0, buffer, 20);
    if(len <= 0) {
      vTaskDelay( 10 );
    } else {
      pppos_input(ppps, buffer, len);
    }
  }
}

Thanks,

Charles

Gmane