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
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
