PPP proxy arp support

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

PPP proxy arp support

Bob Jones
Hello,

I'm trying to resolve an issue with regards to PPP and ARP requests. My network topology is as follows,

Laptop (192.168.1.3, ethernet) <-> MCU #1 (192.168.1.4, ethernet) <-> MCU #1 (192.168.1.126, PPP serial [server]) <-> MCU #2 (192.168.1.127 PPP serial [client])

The issue I'm running into is that when I try to send a packet to MCU #2 (192.168.1.127) from the laptop, the ARP request the laptop sends is never satisfied. This makes sense to me, as the instance of lwip running on MCU #1 can't respond to this ARP request as it doesn't have MCU #2's IP address in its routing table (and shouldn't). In this case, one solution is to add a static route to the laptop's routing table to send all requests destined for 192.168.1.127 out of the interface corresponding to 192.168.1.4. Voila, no ARP request for 192.168.1.127, no problem.

Unfortunately, however, our team is working with some antiquated hardware in place of the "laptop" in the above example that doesn't support adding static routes.

So, in doing some Googling around and reading of past posts on this forum, it seems like layer 2 forwarding is one possible solution here (MCU #1 would be responsible for this). I was thinking of using PPP proxy arp support on MCU #1, but noticed that it was commented out of the lwip ppp implementation in 2015 (commit hash 99bcce78...). The commit message simply reads "PPP, IPCP, removed proxy ARP support". Was curious to know if this is something that, if the surrounding `#define`s were removed, would likely just work, or if there was some underlying implementation issue that led to its removal. Also, any other ideas about how this problem might be resolved otherwise, given the constraints on network topology?

Thanks!

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: PPP proxy arp support

Patrick Klos-2
On 10/9/2018 8:24 PM, Bob Jones wrote:

> Hello,
>
> I'm trying to resolve an issue with regards to PPP and ARP requests.
> My network topology is as follows,
>
> Laptop (192.168.1.3, ethernet) <-> MCU #1 (192.168.1.4, ethernet) <->
> MCU #1 (192.168.1.126, PPP serial [server]) <-> MCU #2 (192.168.1.127
> PPP serial [client])
>
> The issue I'm running into is that when I try to send a packet to MCU
> #2 (192.168.1.127) from the laptop, the ARP request the laptop sends
> is never satisfied. This makes sense to me, as the instance of lwip
> running on MCU #1 can't respond to this ARP request as it doesn't have
> MCU #2's IP address in its routing table (and shouldn't). In this
> case, one solution is to add a static route to the laptop's routing
> table to send all requests destined for 192.168.1.127 out of the
> interface corresponding to 192.168.1.4. Voila, no ARP request for
> 192.168.1.127, no problem.
>
> Unfortunately, however, our team is working with some antiquated
> hardware in place of the "laptop" in the above example that doesn't
> support adding static routes.
>
> So, in doing some Googling around and reading of past posts on this
> forum, it seems like layer 2 forwarding is one possible solution here
> (MCU #1 would be responsible for this). I was thinking of using PPP
> proxy arp support on MCU #1, but noticed that it was commented out of
> the lwip ppp implementation in 2015 (commit hash 99bcce78...). The
> commit message simply reads "PPP, IPCP, removed proxy ARP support".
> Was curious to know if this is something that, if the surrounding
> `#define`s were removed, would likely just work, or if there was some
> underlying implementation issue that led to its removal. Also, any
> other ideas about how this problem might be resolved otherwise, given
> the constraints on network topology?

Hello Bob,

What version of LwIP are you using?  What are your subnet masks on the
various devices?

Scenario #1:
     The subnet mask includes all the devices in question (i.e.
192.168.1.0/24).  In this case, MCU#1 will have to answer ARP requests
for MCU#2.

Scenario #2:
     The subnets are truly broken up (i.e. ethernet is 192.168.1.0/22
and PPP is 192.168.1.64/22) and MCU#1 is acting as a router between the
2 subnets.  In this case, the laptop would have MCU#1's IP address in
it's route table to 192.168.1.64/22 (or it's default route if necessary).

I'm guessing you're using scenario #1?  If that's the case, when the
laptop sends an ARP request for MCU#2's IP address, MCU#1 will need to
respond with it's own MAC address (and MCU#2's IP address) in the ARP
response.  Maybe that's what the PPP proxy ARP code on MCU#1 is supposed
to do - I haven't looked at that code?  If the code is commented out
because it doesn't currently work, that doesn't mean it can't be made to
work.

You say the "antiquated hardware" has limited configuration
capabilities.  What are they?  Can you set it's IP address, subnet mask,
and default gateway?  Does it support DHCP or is it manually
configured?  Does that "antiquated hardware" just need to talk to MCU#2
or does it need to communicate with other devices on the network (or on
the Internet) as well?

Good luck,

Patrick Klos
Klos Technologies, Inc.

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: PPP proxy arp support

goldsimon@gmx.de
In reply to this post by Bob Jones
On 10.10.2018 02:24, Bob Jones wrote:
> [..] I was thinking of using PPP proxy arp support on MCU #1, but
> noticed that it was commented out of the lwip ppp implementation in
> 2015 (commit hash 99bcce78...). The commit message simply reads "PPP,
> IPCP, removed proxy ARP support".

Isn't proxy ARP support only really valid when we are a PPP server? That
wasn't working at that time.

> Was curious to know if this is something that, if the surrounding
> `#define`s were removed, would likely just work,

No, the ARP layer does not have support for this. You'd have to add at
least that to make it work.

> or if there was some underlying implementation issue that led to its
> removal.

If I remember correctly, Sylvain started to make things work that he
needed when porting the updated PPP sources. It doesn't necessarily mean
there was an issue, but I guess he didn't want to implement proxy ARP
support in the lwIP ARP layer unless he needed it...


Simon

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: PPP proxy arp support [fixed typo]

Patrick Klos-2
In reply to this post by Patrick Klos-2
On 10/10/2018 8:59 AM, Patrick Klos wrote:

> On 10/9/2018 8:24 PM, Bob Jones wrote:
>> Hello,
>>
>> I'm trying to resolve an issue with regards to PPP and ARP requests.
>> My network topology is as follows,
>>
>> Laptop (192.168.1.3, ethernet) <-> MCU #1 (192.168.1.4, ethernet) <->
>> MCU #1 (192.168.1.126, PPP serial [server]) <-> MCU #2 (192.168.1.127
>> PPP serial [client])
>>
>> The issue I'm running into is that when I try to send a packet to MCU
>> #2 (192.168.1.127) from the laptop, the ARP request the laptop sends
>> is never satisfied. This makes sense to me, as the instance of lwip
>> running on MCU #1 can't respond to this ARP request as it doesn't
>> have MCU #2's IP address in its routing table (and shouldn't). In
>> this case, one solution is to add a static route to the laptop's
>> routing table to send all requests destined for 192.168.1.127 out of
>> the interface corresponding to 192.168.1.4. Voila, no ARP request for
>> 192.168.1.127, no problem.
>>
>> Unfortunately, however, our team is working with some antiquated
>> hardware in place of the "laptop" in the above example that doesn't
>> support adding static routes.
>>
>> So, in doing some Googling around and reading of past posts on this
>> forum, it seems like layer 2 forwarding is one possible solution here
>> (MCU #1 would be responsible for this). I was thinking of using PPP
>> proxy arp support on MCU #1, but noticed that it was commented out of
>> the lwip ppp implementation in 2015 (commit hash 99bcce78...). The
>> commit message simply reads "PPP, IPCP, removed proxy ARP support".
>> Was curious to know if this is something that, if the surrounding
>> `#define`s were removed, would likely just work, or if there was some
>> underlying implementation issue that led to its removal. Also, any
>> other ideas about how this problem might be resolved otherwise, given
>> the constraints on network topology?
>
> Hello Bob,
>
> What version of LwIP are you using?  What are your subnet masks on the
> various devices?
>
> Scenario #1:
>     The subnet mask includes all the devices in question (i.e.
> 192.168.1.0/24).  In this case, MCU#1 will have to answer ARP requests
> for MCU#2.
>
> Scenario #2:
>     The subnets are truly broken up (i.e. ethernet is 192.168.1.0/22
> and PPP is 192.168.1.64/22) and MCU#1 is acting as a router

Ooops... my mistake.  Subnets would 192.168.1.0/26 and 192.168.1.64/26
(26 bits instead of 22 bits).

> between the 2 subnets.  In this case, the laptop would have MCU#1's IP
> address in it's route table to 192.168.1.64/22 (or it's default route
> if necessary).
>
> I'm guessing you're using scenario #1?  If that's the case, when the
> laptop sends an ARP request for MCU#2's IP address, MCU#1 will need to
> respond with it's own MAC address (and MCU#2's IP address) in the ARP
> response.  Maybe that's what the PPP proxy ARP code on MCU#1 is
> supposed to do - I haven't looked at that code?  If the code is
> commented out because it doesn't currently work, that doesn't mean it
> can't be made to work.
>
> You say the "antiquated hardware" has limited configuration
> capabilities.  What are they?  Can you set it's IP address, subnet
> mask, and default gateway?  Does it support DHCP or is it manually
> configured?  Does that "antiquated hardware" just need to talk to
> MCU#2 or does it need to communicate with other devices on the network
> (or on the Internet) as well?

Patrick


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: PPP proxy arp support

Sylvain Rochet
In reply to this post by goldsimon@gmx.de
Hi,

On Wed, Oct 10, 2018 at 03:13:56PM +0200, [hidden email] wrote:
>
> Isn't proxy ARP support only really valid when we are a PPP server? That
> wasn't working at that time.

We use to call that client and server but in the end it is just an IP
tunnel and both ends are equal, PPP protocol is mostly (fully if no
corner cases are to be found :>) symmetric regarding which one is the
initiator (e.g. IP addresses are not necessarily given by the initiator,
both ends can even choose their own if remote side allow to do so). So
technically speaking there is no reason for a PPP "client" or I would
rather say non-initiator to never need ARP proxy. However I agree that's
an option for IP routers so it makes more sense in the real world on
what we call PPP "servers".


> >Was curious to know if this is something that, if the surrounding
> >`#define`s were removed, would likely just work,
>
> No, the ARP layer does not have support for this. You'd have to add at least
> that to make it work.
>
> >or if there was some underlying implementation issue that led to its
> >removal.
>
> If I remember correctly, Sylvain started to make things work that he needed
> when porting the updated PPP sources. It doesn't necessarily mean there was
> an issue, but I guess he didn't want to implement proxy ARP support in the
> lwIP ARP layer unless he needed it...
Indeed. If it would be implemented proxy ARP control plane should live
in the netif core code and data plane in the ARP layer. There is no ARP
proxy support per se on the PPP protocol, PPP layer do no more than
setting a few internal flags and asking the system to set/remove an ARP
proxy entry.

Anyway, ARP proxies seem to be a mostly dead thing nowadays, and I
consider that a good thing because it's a huge layer violation. However,
if some day ARP proxy support materialize in the ARP layer I will of
course make it works for PPP since it is just a couple of flags and
functions calls.


Sylvain

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PPP proxy arp support

goldsimon@gmx.de
On 19.10.2018 12:07, Sylvain Rochet wrote:

> [..]
>> If I remember correctly, Sylvain started to make things work that he needed
>> when porting the updated PPP sources. It doesn't necessarily mean there was
>> an issue, but I guess he didn't want to implement proxy ARP support in the
>> lwIP ARP layer unless he needed it...
> Indeed. If it would be implemented proxy ARP control plane should live
> in the netif core code and data plane in the ARP layer. There is no ARP
> proxy support per se on the PPP protocol, PPP layer do no more than
> setting a few internal flags and asking the system to set/remove an ARP
> proxy entry.
>
> Anyway, ARP proxies seem to be a mostly dead thing nowadays, and I
> consider that a good thing because it's a huge layer violation. However,
> if some day ARP proxy support materialize in the ARP layer I will of
> course make it works for PPP since it is just a couple of flags and
> functions calls.

I see that the other way round: if some day, someone really does need
ARP proxy support, adding it to etherp.c should not be too difficult and
I'd gladly accept a patch for it :-)
I don't think this is needed outside of PPP support. But you're right
that re-adding the flags and calls in PPP is probably far less work than
the rest...
Thanks for clarifying this.


Simon

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users