[lwip-users] Where is poll_driver() ?

[Alain Mouette]

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

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

[lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)

[LMao]

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(;
/* @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.50192.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, 
0x6a00)
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, 
0xd300)
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


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

[lwip-users] raw api tcp_write()ing small chunks fills snd_queue

[Sergio R. Caprile]

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

-- 


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