Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Hello Charles, On Fri, Apr 11, 2014 at 06:21:09PM +, l...@moog.com wrote: Sylvain, Great, the latest patch works. Thank you very much. Maybe you missed that, but the patch was actually broken by design, please see bug #43173 [1]. Please also note that ppp-new branch has been merged meanwhile to master, so you should now checkout the master branch. Sylvain [1] https://savannah.nongnu.org/bugs/?43173 signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Sylvain, I observed similar messages. I think VJ is in effect in my test. Charles -Original Message- From: lwip-users-bounces+cmao=moog@nongnu.org [mailto:lwip-users-bounces+cmao=moog@nongnu.org] On Behalf Of Sylvain Rochet Sent: Monday, April 14, 2014 10:19 AM To: Mailing list for lwIP users Subject: Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP) Hello Charles, On Mon, Apr 14, 2014 at 01:05:07PM +, l...@moog.com wrote: Hi Sylvain, I applied the patch and it seems everything is working. However, I don't know much about VJ support, so I don't know if the PPP server and my gateway device have actually negotiated to use VJ at all. Please tell me how to check VJ is in effect. Is there any specific debug options for VJ ? pppd negotiate VJ by default unless novj option is set. pppd debug display the VJ negotiation, for example: Apr 12 01:55:14 ornithopter pppd[990]: rcvd [IPCP ConfAck id=0x1 compress VJ 0f 01 addr 192.168.2.1] Apr 12 01:55:14 ornithopter pppd[990]: sent [IPCP ConfAck id=0x2 compress VJ 0f 01 addr 192.168.2.2 ms-dns1 198.168.100.7 ms-dns2 198.168.100.7] I did set VJ_SUPPORT to 1 in lwipopts.h, is there anything else need be set up? That should be enough, as long as your PPP server accept VJ. Sylvain ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Hello Charles, On Tue, Apr 15, 2014 at 06:03:40PM +, l...@moog.com wrote: Sylvain, I observed similar messages. I think VJ is in effect in my test. Great ! :) Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Hi Sylvain, I applied the patch and it seems everything is working. However, I don't know much about VJ support, so I don't know if the PPP server and my gateway device have actually negotiated to use VJ at all. Please tell me how to check VJ is in effect. Is there any specific debug options for VJ? I did set VJ_SUPPORT to 1 in lwipopts.h, is there anything else need be set up? Charles -Original Message- From: lwip-users-bounces+cmao=moog@nongnu.org [mailto:lwip-users-bounces+cmao=moog@nongnu.org] On Behalf Of Sylvain Rochet Sent: Saturday, April 12, 2014 3:03 PM To: Mailing list for lwIP users Subject: Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP) Hello Charles, On Sat, Apr 12, 2014 at 01:29:33AM +0200, Sylvain Rochet wrote: Finally, here we are… Hey!, since you have the setup to check IP forwarding could you check IP forwarding with VJ support enabled ? :) Humm, I should have added that you must update your Git repository before testing. Sylvain ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Hello Charles, On Mon, Apr 14, 2014 at 01:05:07PM +, l...@moog.com wrote: Hi Sylvain, I applied the patch and it seems everything is working. However, I don't know much about VJ support, so I don't know if the PPP server and my gateway device have actually negotiated to use VJ at all. Please tell me how to check VJ is in effect. Is there any specific debug options for VJ ? pppd negotiate VJ by default unless novj option is set. pppd debug display the VJ negotiation, for example: Apr 12 01:55:14 ornithopter pppd[990]: rcvd [IPCP ConfAck id=0x1 compress VJ 0f 01 addr 192.168.2.1] Apr 12 01:55:14 ornithopter pppd[990]: sent [IPCP ConfAck id=0x2 compress VJ 0f 01 addr 192.168.2.2 ms-dns1 198.168.100.7 ms-dns2 198.168.100.7] I did set VJ_SUPPORT to 1 in lwipopts.h, is there anything else need be set up? That should be enough, as long as your PPP server accept VJ. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Hello Charles, On Sat, Apr 12, 2014 at 01:29:33AM +0200, Sylvain Rochet wrote: Finally, here we are… Hey!, since you have the setup to check IP forwarding could you check IP forwarding with VJ support enabled ? :) Humm, I should have added that you must update your Git repository before testing. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Sylvain, I applied the new patch, but the following statement always cause Data Abort exception run-time error. No matter I set ETH_PAD_SIZE to 0 or 2. The good thing is my compiler doesn't generate any error message for the new patch. *((ppp_pcb**)payload) = pcb; Another thing I am not so sure is the macro PPP_USE_PBUF_RAM. I always set it to 1 in lwipopts.h, but I think the default is set to 0 in opt.h. Am I doing the right thing? Thanks, Charles -Original Message- From: lwip-users-bounces+cmao=moog@nongnu.org [mailto:lwip-users-bounces+cmao=moog@nongnu.org] On Behalf Of Sylvain Rochet Sent: Thursday, April 10, 2014 6:15 PM To: Mailing list for lwIP users Subject: Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP) Hello Charles, On Thu, Apr 10, 2014 at 08:03:13PM +, l...@moog.com wrote: Hi Sylvain, Good news, I got it work with your patch Yeah, happy to hear that. Here is another patch, which should fix the issue in a way that can be pushed to the repository, would you test it ? plus the replacement of (PBUF_LINK_HLEN +2), however, set ETH_PAD_SIZE to 2 actually doesn't work. It seems fail at ARP and infinitely repeat with the following debug messages: Humm, this is strange, using ETH_PAD_SIZE should work. Sylvain ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Hello Charles,
On Fri, Apr 11, 2014 at 12:13:02PM +, l...@moog.com wrote:
Sylvain,
I applied the new patch, but the following statement always cause Data
Abort exception run-time error. No matter I set ETH_PAD_SIZE to 0 or
2. The good thing is my compiler doesn't generate any error message
for the new patch.
*((ppp_pcb**)payload) = pcb;
Yeah, of course, there is an alignment problem here, pbuf-payload might
be unaligned, here is a new patch with an helper packed struct which
should fix the issue.
It was fine with a PBUF_RAW because the pointer was put deliberately in
front of the buffer, buffer which was allocated on alignment by lwIP.
You don't need to set ETH_PAD_SIZE, this is not necessary.
Another thing I am not so sure is the macro PPP_USE_PBUF_RAM. I always
set it to 1 in lwipopts.h, but I think the default is set to 0 in
opt.h. Am I doing the right thing?
Yes!, if you have a heap PPP_USE_PBUF_RAM is the option you should use,
it allows you to use a smaller PBUF_POOL_BUFSIZE.
Sylvain
diff --git a/src/netif/ppp/ppp.c b/src/netif/ppp/ppp.c
index 594d18c..7e4f632 100644
--- a/src/netif/ppp/ppp.c
+++ b/src/netif/ppp/ppp.c
@@ -1529,6 +1529,22 @@ ppp_drop(ppp_pcb_rx *pcrx)
snmp_inc_ifindiscards(pcb-netif);
}
+/** PPPoS input helper struct, must be packed since it is stored
+ * to pbuf-payload, which might be unaligned. */
+#if PPP_INPROC_MULTITHREADED
+#ifdef PACK_STRUCT_USE_INCLUDES
+# include arch/bpstruct.h
+#endif
+PACK_STRUCT_BEGIN
+struct pppos_input_header {
+ PACK_STRUCT_FIELD(ppp_pcb *pcb);
+} PACK_STRUCT_STRUCT;
+PACK_STRUCT_END
+#ifdef PACK_STRUCT_USE_INCLUDES
+# include arch/epstruct.h
+#endif
+#endif /* PPP_INPROC_MULTITHREADED */
+
/** Pass received raw characters to PPPoS to be decoded. This function is
* thread-safe and can be called from a dedicated RX-thread or from a main-loop.
*
@@ -1704,7 +1720,15 @@ pppos_input(ppp_pcb *pcb, u_char *s, int l)
}
}
/* If we haven't started a packet, we need a packet header. */
+#if IP_FORWARD || LWIP_IPV6_FORWARD
+/* If IP forwarding is enabled we are using a PBUF_LINK packet type so
+ * the packet is being allocated with enough header space to be
+ * forwarded (to Ethernet for example).
+ */
+next_pbuf = pbuf_alloc(PBUF_LINK, 0, PBUF_POOL);
+#else /* IP_FORWARD || LWIP_IPV6_FORWARD */
next_pbuf = pbuf_alloc(PBUF_RAW, 0, PBUF_POOL);
+#endif /* IP_FORWARD || LWIP_IPV6_FORWARD */
if (next_pbuf == NULL) {
/* No free buffers. Drop the input packet and let the
* higher layers deal with it. Continue processing
@@ -1716,15 +1740,27 @@ pppos_input(ppp_pcb *pcb, u_char *s, int l)
break;
}
if (pcrx-in_head == NULL) {
- u8_t *payload = next_pbuf-payload;
+ u8_t *payload;
+ /* pbuf_header() used below is only trying to put PPP headers
+ * before the current payload pointer if there is enough space
+ * in the pbuf to do so. Therefore we don't care if it fails,
+ * but if it fail we have to set len to the size used by PPP headers.
+ */
#if PPP_INPROC_MULTITHREADED
- *((ppp_pcb**)payload) = pcb;
- payload += sizeof(ppp_pcb*);
- next_pbuf-len += sizeof(ppp_pcb*);
+ if (pbuf_header(next_pbuf, +sizeof(struct pppos_input_header) +sizeof(pcrx-in_protocol))) {
+next_pbuf-len += sizeof(struct pppos_input_header) + sizeof(pcrx-in_protocol);
+ }
+ payload = next_pbuf-payload;
+ ((struct pppos_input_header*)payload)-pcb = pcb;
+ payload += sizeof(struct pppos_input_header);
+#else /* PPP_INPROC_MULTITHREADED */
+ if (pbuf_header(next_pbuf, +sizeof(pcrx-in_protocol))) {
+next_pbuf-len += sizeof(pcrx-in_protocol);
+ }
+ payload = next_pbuf-payload;
#endif /* PPP_INPROC_MULTITHREADED */
*(payload++) = pcrx-in_protocol 8;
*(payload) = pcrx-in_protocol 0xFF;
- next_pbuf-len += sizeof(pcrx-in_protocol);
pcrx-in_head = next_pbuf;
}
pcrx-in_tail = next_pbuf;
@@ -1749,8 +1785,8 @@ static void pppos_input_callback(void *arg) {
struct pbuf *pb = (struct pbuf*)arg;
ppp_pcb *pcb;
- pcb = *((ppp_pcb**)pb-payload);
- if(pbuf_header(pb, -(s16_t)sizeof(ppp_pcb*))) {
+ pcb = ((struct pppos_input_header*)pb-payload)-pcb;
+ if(pbuf_header(pb, -(s16_t)sizeof(struct pppos_input_header))) {
LWIP_ASSERT(pbuf_header failed\n, 0);
goto drop;
}
signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Hi Sylvain, Sylvain Rochet wrote: I put the PPP header into the allocated space for PBUF_LINK if there is enough space to do so, for a 14 byte PBUF_LINK_HEADER this is 12 bytes of RAM wasted for NO_SYS=1, and 8 bytes for NO_SYS=0 with 32 bits pointers, for me this is an acceptable outcome. Yes, you're right. The patch also looks good. Although I can't really test it myself... What about other sources of pbuf allocation? I think there are now more than in the 'old' ppp code. Are there more allocations we need to take care of (e.g. VJ decompression)? BTW: what do you think about making ppp_new the default for 1.5.0? Can it handle IPv6 correctly or are there additions needed? I think it might be bigger than the old code, but also more buggy. And it's kind of meaningless keeping the old code when everyone starting with a PPP device takes the ppp_new branch... Having upgrading instructions for applications using the 'old' pop code would be nice, of course. Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Sylvain, Great, the latest patch works. Thank you very much. Charles -Original Message- From: lwip-users-bounces+cmao=moog@nongnu.org [mailto:lwip-users-bounces+cmao=moog@nongnu.org] On Behalf Of Sylvain Rochet Sent: Friday, April 11, 2014 2:01 PM To: Mailing list for lwIP users Subject: Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP) Hello Charles, On Fri, Apr 11, 2014 at 12:13:02PM +, l...@moog.com wrote: Sylvain, I applied the new patch, but the following statement always cause Data Abort exception run-time error. No matter I set ETH_PAD_SIZE to 0 or 2. The good thing is my compiler doesn't generate any error message for the new patch. *((ppp_pcb**)payload) = pcb; Yeah, of course, there is an alignment problem here, pbuf-payload might be unaligned, here is a new patch with an helper packed struct which should fix the issue. It was fine with a PBUF_RAW because the pointer was put deliberately in front of the buffer, buffer which was allocated on alignment by lwIP. You don't need to set ETH_PAD_SIZE, this is not necessary. Another thing I am not so sure is the macro PPP_USE_PBUF_RAM. I always set it to 1 in lwipopts.h, but I think the default is set to 0 in opt.h. Am I doing the right thing? Yes!, if you have a heap PPP_USE_PBUF_RAM is the option you should use, it allows you to use a smaller PBUF_POOL_BUFSIZE. Sylvain ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Hello Charles, On Fri, Apr 11, 2014 at 06:21:09PM +, l...@moog.com wrote: Sylvain, Great, the latest patch works. Thank you very much. Finally, here we are… Hey!, since you have the setup to check IP forwarding could you check IP forwarding with VJ support enabled ? :) Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Hi Simon, On Fri, Apr 11, 2014 at 07:45:25PM +0200, Simon Goldschmidt wrote: Sylvain Rochet wrote: I put the PPP header into the allocated space for PBUF_LINK if there is enough space to do so, for a 14 byte PBUF_LINK_HEADER this is 12 bytes of RAM wasted for NO_SYS=1, and 8 bytes for NO_SYS=0 with 32 bits pointers, for me this is an acceptable outcome. Yes, you're right. The patch also looks good. Although I can't really test it myself... I slightly improved it, we only allocate a PBUF_LINK if IP forwarding is enabled, so we are not wasting RAM for rx-only devices. What about other sources of pbuf allocation? I think there are now more than in the 'old' ppp code. All other allocation in PPP (except VJ) is for output buffers, we only care about input buffers for IP forwarding, and more specifically, we only care about IP and IPv6 PPP packets, all others PPP packets (LCP, IPCP, IP6CP, PAP, CHAP, EAP, …) are obviously out of the IP forwarding scope. Are there more allocations we need to take care of (e.g. VJ decompression)? Yup, VJ support required some work because it prepends a pbuf to realign the buffer, I hope it works :-) BTW: what do you think about making ppp_new the default for 1.5.0? That would be great. I am currently using it in production for some time and it works nicely, at least for me ;-), with PPPoL2TP (VPN link) over PPPoE (ADSL Modem) and over PPPoS (GPRS Modem). Can it handle IPv6 correctly or are there additions needed? It can, but, well, PPP IP6CP is somewhat limited, it only negotiate a random link-local address for each side, maybe IPv6 ”autoip” works over a PPP link, I just don't know :) So, it works, at least, the PPP simple job for IPv6 works: ppp_link_status_cb: PPPERR_NONE … our6_ipaddr = FE80::1C66:89CD:2A6B:FEA3 his6_ipaddr = FE80::9C58:704B:C4A6:8542 $ ping6 -I ppp0 FE80::1C66:89CD:2A6B:FEA3 PING FE80::1C66:89CD:2A6B:FEA3(fe80::1c66:89cd:2a6b:fea3) from fe80::9c58:704b:c4a6:8542 ppp0: 56 data bytes 64 bytes from fe80::1c66:89cd:2a6b:fea3: icmp_seq=1 ttl=255 time=0.278 ms 64 bytes from fe80::1c66:89cd:2a6b:fea3: icmp_seq=2 ttl=255 time=0.309 ms I think it might be bigger than the old code, but also more buggy. And it's kind of meaningless keeping the old code when everyone starting with a PPP device takes the ppp_new branch... Yup, it is bigger in code size, but not that much, however it uses less memory (about 3 or 4 times less per PPP session IIRC), mainly due to static tx buffer removal and cleaned structs. Having upgrading instructions for applications using the 'old' pop code would be nice, of course. I fully agree, will do. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Hello Charles, On Wed, Apr 09, 2014 at 06:47:43PM +, l...@moog.com wrote: 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? First, thank you, I trimed most but everything was really helpful, I enjoy getting such well-written investigation pattern :) Well, ip_forward() should call netif-output(), which in our case is ppp_netif_output_ip4(), could you first check that ? You can also enable PPP_DEBUG in your lwipopts.h, this will display discarded frames in ppp_netif_output_ip4() if any. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Hi Sylvain,
Thank you for your reply. I really appreciate your help. The below are a few
comments and more observations.
Well, ip_forward() should call netif-output(), which in our case is
ppp_netif_output_ip4(), could you first check that ?
Sorry, I may confuse you about which direction the problem is. Actually, the
problem is it doesn't output the corresponding Ethernet packets based on the
incoming PPP packets.
You can also enable PPP_DEBUG in your lwipopts.h, this will display discarded
frames in ppp_netif_output_ip4() if any.
The following logging messages are captured with PPP_DEBUG enabled. I also
enabled ETHARP_DEBUG NETIF_DEBUG.
From the newly captured messages below(last line), it seems there's a memory
issue.
etharp_timer
etharp_timer
ethernet_input: dest:00:bd:33:06:68:22, src:c8:d7:19:ee:1f:fc, type:800
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
etharp_output: could not allocate room for header.
I looked at the code of etharp_output function, it seems pbuf_header function
cannot find room for Ethernet header (code snippet is shown below).
/* make room for Ethernet header - should not fail */
#if ETHARP_SUPPORT_VLAN defined(LWIP_HOOK_VLAN_SET)
if (pbuf_header(q, sizeof(struct eth_hdr) + SIZEOF_VLAN_HDR) != 0) {
#else /* ETHARP_SUPPORT_VLAN defined(LWIP_HOOK_VLAN_SET) */
if (pbuf_header(q, sizeof(struct eth_hdr)) != 0) {
#endif /* ETHARP_SUPPORT_VLAN defined(LWIP_HOOK_VLAN_SET) */
/* bail out */
LWIP_DEBUGF(ETHARP_DEBUG | LWIP_DBG_TRACE | LWIP_DBG_LEVEL_SERIOUS,
(etharp_output: could not allocate room for header.\n));
LINK_STATS_INC(link.lenerr);
return ERR_BUF;
However, the non-forwarded IP packets have no problem to be sent out. For
example, if I ping 192.168.1.105 which is the PPP interface on the gateway
device, we can IP packet is sent out without problem (log messages are shown
below).
etharp_timer
etharp_timer
ethernet_input: dest:ff:ff:ff:ff:ff:ff, src:c8:d7:19:ee:1f:fc, type:806
etharp_update_arp_entry: 192.168.0.211 - c8:d7:19:ee:1f:fc
etharp_find_entry: found matching entry 0
etharp_update_arp_entry: updating stable entry 0
etharp_arp_input: incoming ARP request
etharp_arp_input: replying to ARP request for our IP address
ethernet_input: dest:00:bd:33:06:68:22, src:c8:d7:19:ee:1f:fc, type:800
ip_input: iphdr-dest 0x6901a8c0 netif-ip_addr 0x3200a8c0 (0x1a8c0, 0xa8c0,
0x6900)
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)
+---+
| 3005 |000| 0 | (id, flags, offset)
+---+
| 128 |1 |0xab77 | (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)
+---+
| 3005 |000| 0 | (id, flags, offset)
+---+
| 255 |1 |0x2c77 | (ttl, proto, chksum)
+---+
| 192 | 168 |1 | 105 | (src)
+---+
| 192 | 168 |0 | 211 | (dest)
+---+
netif-output()
etharp_send_ip: sending packet 0020cf34
etharp_timer
etharp_timer
Now, what I really don't understand is the forwarded and non-forwarded IP
packets both need room for Ethernet header before sending out, why one
succeeded in making room for Ethernet header and the other failed. Is it
because these two type packets use different types of PBUF?
Charles
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Sylvain, It seems the patch makes things worse - PPP connection couldn’t build-up anymore. Below is the complete log message after applying the patch. It seems the code stalled at very early stage. *** FreeRTOS Demo Started! *** netif_set_ipaddr: netif addrnetif: IP address of interface set to 0.0.0.0 netif: netmask of interface set to 0.0.0.0 eteif: GW sasd dbreeissn go fc hinatnegrefdace snete ttiof 0.0.0.0: nIePti fa:d darddeesds iontfe rifnatcee pp IP addr 0.0.0.r0 netfmask 0.0.0.0 gw 0.0.0.0 ace set to 192.168.0.50 netif: netif: setting default interface pp netmask of interface set to 255.255.255.0 netif: GW address of interface set to 192.168.0.1 etharp_timer etharp_timer etharp_timer etharp_timer etharp_timer netif: added interface em IP addr 192.168.0.50 netmask 255.255.255.0 gw 192.168.0.1 ethernet_input: dest:ff:ff:ff:ff:ff:ff, src:c8:d7:19:ee:1f:fc, type:806 etharp_update_arp_entry: 0.0.0.0 - c8:d7:19:ee:1f:fc etharp_update_arp_entry: will not add non-unicast IP address to ARP cache etharp_arp_input: incoming ARP request etharp_arp_input: ARP request was not for us. etharp_timer etharp_timer Regarding the patch, my compiler complains the following statement u8_t *payload = next_pbuf-payload + PBUF_LINK_HLEN; so I made a small change to make it work with my compiler u8_t *payload = (u8_t*)next_pbuf-payload + PBUF_LINK_HLEN; Thanks again, Charels Oh dear, now I see what is happening. PPP header is smaller than Ethernet header, plus PPPoS needs to reallocate a new PPP to do HDLC encoding, so Ethernet to PPPoS forwarding will always works. But, PPPoS to Ethernet will not work, because there is not enough header space in the pbuf to put Ethernet header in place of the PPP header. This is actually a lwIP design issue, the only way we can fix that is by adding a configuration option so pbuf from PPP are allocated with enough extra space so a Ethernet header will fit in place of a PPP header. So, let's try that with a stupid patch, at least it will confirm what I thought is happening. ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Sylvain Rochet wrote: Oh dear, now I see what is happening. PPP header is smaller than Ethernet header [..] This is actually a lwIP design issue, the only way we can fix that is by adding a configuration option so pbuf from PPP are allocated with enough extra space so a Ethernet header will fit in place of a PPP header. The lwIP way to solve this is to defin PBUF_LINK_HLEN to be big enough for both sides. We do waste some bytes that way, but it should work. However, I just saw that PPP (new?) seems to allocate many pbufs as PBUF_RAW, which kind of breaks the link-header size calculation and thus might make my suggestion not work... Anyway, we might want to fix this in a generic way... Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Hello Simon, On Thu, Apr 10, 2014 at 08:12:00PM +0200, Simon Goldschmidt wrote: Sylvain Rochet wrote: Oh dear, now I see what is happening. PPP header is smaller than Ethernet header [..] This is actually a lwIP design issue, the only way we can fix that is by adding a configuration option so pbuf from PPP are allocated with enough extra space so a Ethernet header will fit in place of a PPP header. The lwIP way to solve this is to defin PBUF_LINK_HLEN to be big enough for both sides. We do waste some bytes that way, but it should work. However, I just saw that PPP (new?) seems to allocate many pbufs as PBUF_RAW, which kind of breaks the link-header size calculation and thus might make my suggestion not work... Anyway, we might want to fix this in a generic way... PPPoE use PBUF_LINK, PPPoL2TP use PBUF_TRANSPORT, PPPoS use PBUF_RAW, it all makes sense at first sight and IP forwarding should work for PPPoE and PPPoL2TP. Maybe we should allocate a PBUF_LINK for PPPoS as well. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Below is more debug information and hope it's helpful for fixing the problem. Regarding the code stalled at early stage, that's hardware related. I am using ARM7 (AT91SAM7 to be specific), so the data alignment is 4 and PBUF_LINK_HLEN is 14 by default, so I replaced all PBUF_LINK_HLEN in the patch with (PBUF_LINK_HLEN + 2). It fixed the run-time problem which keep the code running fine. Now I can build-up the PPP connection. However, the patch seems fix the pbuf issue but it actually breaks the traffic from Ethernet to PPP side which was fine before the patch. If you need me do any test, please let me know. etharp_timer etharp_timer ethernet_input: dest:00:bd:33:06:68:22, src:c8:d7:19:ee:1f:fc, type:800 ip_input: iphdr-dest 0x6901a8c0 netif-ip_addr 0x3200a8c0 (0x1a8c0, 0xa8c0, 0x6900) 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) +---+ | 3897 |000| 0 | (id, flags, offset) +---+ | 128 |1 |0xa7fb | (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) +---+ | 3897 |000| 0 | (id, flags, offset) +---+ | 255 |1 |0x28fb | (ttl, proto, chksum) +---+ | 192 | 168 |1 | 105 | (src) +---+ | 192 | 168 |0 | 211 | (dest) +---+ netif-output() etharp_send_ip: sending packet 0020d520 etharp_timer etharp_timer etharp_timer etharp_timer etharp_timer etharp_timer ethernet_input: dest:00:bd:33:06:68:22, src:c8:d7:19:ee:1f:fc, type:800 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 etharp_timer etharp_timer etharp_timer etharp_timer etharp_timer etharp_timer etharp_timer etharp_timer ethernet_input: dest:00:bd:33:06:68:22, src:c8:d7:19:ee:1f:fc, type:800 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 etharp_timer etharp_timer Thanks, Charles -Original Message- From: lwip-users-bounces+cmao=moog@nongnu.org [mailto:lwip-users-bounces+cmao=moog@nongnu.org] On Behalf Of l...@moog.com Sent: Thursday, April 10, 2014 2:30 PM To: lwip-users@nongnu.org Subject: Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP) Sylvain, It seems the patch makes things worse - PPP connection couldn’t build-up anymore. Below is the complete log message after applying the patch. It seems the code stalled at very early stage. *** FreeRTOS Demo Started! *** netif_set_ipaddr: netif addrnetif: IP address of interface set to 0.0.0.0 netif: netmask of interface set to 0.0.0.0 eteif: GW sasd dbreeissn go fc hinatnegrefdace snete ttiof 0.0.0.0: nIePti fa:d darddeesds iontfe rifnatcee pp IP addr 0.0.0.r0 netfmask 0.0.0.0 gw 0.0.0.0 ace set to 192.168.0.50 netif: netif: setting default interface pp netmask of interface set to 255.255.255.0 netif: GW address of interface set to 192.168.0.1 etharp_timer etharp_timer etharp_timer etharp_timer etharp_timer netif: added interface em IP addr 192.168.0.50 netmask 255.255.255.0 gw 192.168.0.1 ethernet_input: dest:ff:ff:ff:ff:ff:ff, src:c8:d7:19:ee:1f:fc, type:806 etharp_update_arp_entry: 0.0.0.0 - c8:d7:19:ee:1f:fc etharp_update_arp_entry: will not add non-unicast IP address to ARP cache etharp_arp_input: incoming ARP request etharp_arp_input: ARP request was not for us. etharp_timer etharp_timer Regarding the patch, my compiler complains the following statement u8_t *payload = next_pbuf-payload + PBUF_LINK_HLEN; so I made a small change to make it work with my compiler u8_t *payload = (u8_t*)next_pbuf-payload + PBUF_LINK_HLEN; Thanks again, Charels Oh dear, now I see what is happening. PPP header is smaller than Ethernet header, plus PPPoS needs to reallocate a new PPP to do HDLC encoding, so Ethernet to PPPoS forwarding will always works. But, PPPoS to Ethernet will not work, because there is not enough header space in the pbuf to put Ethernet header in place of the PPP
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Hello Charles, On Thu, Apr 10, 2014 at 05:30:12PM +, l...@moog.com wrote: Sylvain, It seems the patch makes things worse - PPP connection couldn’t build-up anymore. Below is the complete log message after applying the patch. It seems the code stalled at very early stage. Hummm, this is a quick'n'dirty check patch, but I checked it still works. *** FreeRTOS Demo Started! *** netif_set_ipaddr: netif addrnetif: IP address of interface set to 0.0.0.0 netif: netmask of interface set to 0.0.0.0 eteif: GW sasd dbreeissn go fc hinatnegrefdace snete ttiof 0.0.0.0: nIePti fa:d darddeesds iontfe rifnatcee pp IP addr 0.0.0.r0 netfmask 0.0.0.0 gw 0.0.0.0 ace set to 192.168.0.50 This is not the point, but this garbage implies you are breaking lwIP threading rules. Regarding the patch, my compiler complains the following statement u8_t *payload = next_pbuf-payload + PBUF_LINK_HLEN; so I made a small change to make it work with my compiler u8_t *payload = (u8_t*)next_pbuf-payload + PBUF_LINK_HLEN; Could you try with the following instead: u8_t *payload = next_pbuf-payload; payload += PBUF_LINK_HLEN; Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Sylvain Rochet wrote: PPPoE use PBUF_LINK, PPPoL2TP use PBUF_TRANSPORT, PPPoS use PBUF_RAW, it all makes sense at first sight and IP forwarding should work for PPPoE and PPPoL2TP. Maybe we should allocate a PBUF_LINK for PPPoS as well. That would be a good idea for the forwarding case, I guess. However, for ppp rx only, RAM would be wasted. But it should probably fix the current issue. Simon ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Hello Charles, On Thu, Apr 10, 2014 at 06:37:02PM +, l...@moog.com wrote: Below is more debug information and hope it's helpful for fixing the problem. Regarding the code stalled at early stage, that's hardware related. I am using ARM7 (AT91SAM7 to be specific), so the data alignment is 4 and PBUF_LINK_HLEN is 14 by default, so I replaced all PBUF_LINK_HLEN in the patch with (PBUF_LINK_HLEN + 2). It fixed the run-time problem which keep the code running fine. Now I can build-up the PPP connection. However, the patch seems fix the pbuf issue but it actually breaks the traffic from Ethernet to PPP side which was fine before the patch. If you need me do any test, please let me know. Humm, you should set ETH_PAD_SIZE to 2 in your lwipopts.h instead of doing that. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Hi Sylvain, Good news, I got it work with your patch plus the replacement of (PBUF_LINK_HLEN +2), however, set ETH_PAD_SIZE to 2 actually doesn't work. It seems fail at ARP and infinitely repeat with the following debug messages: ethernet_input: dest:ff:ff:ff:ff:ff:ff, src:c8:d7:19:ee:1f:fc, type:806 etharp_update_arp_entry: 192.168.0.211 - c8:d7:19:ee:1f:fc etharp_find_entry: found empty entry 0 etharp_find_entry: no empty entry found and not allowed to recycle etharp_arp_input: incoming ARP request etharp_arp_input: ARP request was not for us. ethernet_input: dest:ff:ff:ff:ff:ff:ff, src:c8:d7:19:ee:1f:fc, type:806 etharp_update_arp_entry: 192.168.0.211 - c8:d7:19:ee:1f:fc etharp_find_entry: found empty entry 0 etharp_find_entry: no empty entry found and not allowed to recycle etharp_arp_input: incoming ARP request etharp_arp_input: ARP request was not for us. ethernet_input: dest:ff:ff:ff:ff:ff:ff, src:c8:d7:19:ee:1f:fc, type:806 etharp_update_arp_entry: 192.168.0.211 - c8:d7:19:ee:1f:fc etharp_find_entry: found empty entry 0 etharp_find_entry: no empty entry found and not allowed to recycle etharp_arp_input: incoming ARP request etharp_arp_input: ARP request was not for us. The reason I originally found it didn't work because I forgot to set the default route in my Linux PPP server. Now we need a more elegant way to fix the problem. Thanks, Charles -Original Message- From: lwip-users-bounces+cmao=moog@nongnu.org [mailto:lwip-users-bounces+cmao=moog@nongnu.org] On Behalf Of Sylvain Rochet Sent: Thursday, April 10, 2014 3:49 PM To: Mailing list for lwIP users Subject: Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP) Hello Charles, On Thu, Apr 10, 2014 at 06:37:02PM +, l...@moog.com wrote: Below is more debug information and hope it's helpful for fixing the problem. Regarding the code stalled at early stage, that's hardware related. I am using ARM7 (AT91SAM7 to be specific), so the data alignment is 4 and PBUF_LINK_HLEN is 14 by default, so I replaced all PBUF_LINK_HLEN in the patch with (PBUF_LINK_HLEN + 2). It fixed the run-time problem which keep the code running fine. Now I can build-up the PPP connection. However, the patch seems fix the pbuf issue but it actually breaks the traffic from Ethernet to PPP side which was fine before the patch. If you need me do any test, please let me know. Humm, you should set ETH_PAD_SIZE to 2 in your lwipopts.h instead of doing that. Sylvain ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Hello Charles,
On Thu, Apr 10, 2014 at 08:03:13PM +, l...@moog.com wrote:
Hi Sylvain,
Good news, I got it work with your patch
Yeah, happy to hear that.
Here is another patch, which should fix the issue in a way that can be
pushed to the repository, would you test it ?
plus the replacement of (PBUF_LINK_HLEN +2), however, set ETH_PAD_SIZE
to 2 actually doesn't work. It seems fail at ARP and infinitely repeat
with the following debug messages:
Humm, this is strange, using ETH_PAD_SIZE should work.
Sylvain
diff --git a/src/netif/ppp/ppp.c b/src/netif/ppp/ppp.c
index 594d18c..ccb4bcb 100644
--- a/src/netif/ppp/ppp.c
+++ b/src/netif/ppp/ppp.c
@@ -1704,7 +1704,7 @@ pppos_input(ppp_pcb *pcb, u_char *s, int l)
}
}
/* If we haven't started a packet, we need a packet header. */
-next_pbuf = pbuf_alloc(PBUF_RAW, 0, PBUF_POOL);
+next_pbuf = pbuf_alloc(PBUF_LINK, 0, PBUF_POOL);
if (next_pbuf == NULL) {
/* No free buffers. Drop the input packet and let the
* higher layers deal with it. Continue processing
@@ -1716,15 +1716,27 @@ pppos_input(ppp_pcb *pcb, u_char *s, int l)
break;
}
if (pcrx-in_head == NULL) {
- u8_t *payload = next_pbuf-payload;
+ u8_t *payload;
+ /* pbuf_header() used below is only trying to put PPP headers
+ * before the current payload pointer if there is enought space
+ * in the pbuf to allow that. Therefore we don't care if it fails,
+ * but if it fail we have to set len to the size used by PPP headers.
+ */
#if PPP_INPROC_MULTITHREADED
+ if (pbuf_header(next_pbuf, +sizeof(ppp_pcb*) +sizeof(pcrx-in_protocol))) {
+next_pbuf-len += sizeof(ppp_pcb*) + sizeof(pcrx-in_protocol);
+ }
+ payload = next_pbuf-payload;
*((ppp_pcb**)payload) = pcb;
payload += sizeof(ppp_pcb*);
- next_pbuf-len += sizeof(ppp_pcb*);
+#else /* PPP_INPROC_MULTITHREADED */
+ if (pbuf_header(next_pbuf, +sizeof(pcrx-in_protocol))) {
+next_pbuf-len += sizeof(pcrx-in_protocol);
+ }
+ payload = next_pbuf-payload;
#endif /* PPP_INPROC_MULTITHREADED */
*(payload++) = pcrx-in_protocol 8;
*(payload) = pcrx-in_protocol 0xFF;
- next_pbuf-len += sizeof(pcrx-in_protocol);
pcrx-in_head = next_pbuf;
}
pcrx-in_tail = next_pbuf;
signature.asc
Description: Digital signature
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Hello, On Thu, Apr 10, 2014 at 08:44:43PM +0200, S G wrote: Sylvain Rochet wrote: PPPoE use PBUF_LINK, PPPoL2TP use PBUF_TRANSPORT, PPPoS use PBUF_RAW, it all makes sense at first sight and IP forwarding should work for PPPoE and PPPoL2TP. Maybe we should allocate a PBUF_LINK for PPPoS as well. That would be a good idea for the forwarding case, I guess. However, for ppp rx only, RAM would be wasted. But it should probably fix the current issue. I put the PPP header into the allocated space for PBUF_LINK if there is enough space to do so, for a 14 byte PBUF_LINK_HEADER this is 12 bytes of RAM wasted for NO_SYS=1, and 8 bytes for NO_SYS=0 with 32 bits pointers, for me this is an acceptable outcome. Sylvain signature.asc Description: Digital signature ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
