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

[Sylvain Rochet]

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