[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] ppp-new IP forwarding only works one direction (Etherne
Re: [lwip-users] ppp-new IP forwarding only works one direction (Ethernet to PPP)
Sat, 12 Apr 2014 02:01:01 +0200
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
> Are there more allocations we need to take care of (e.g. VJ
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:
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.
Description: Digital signature