buglwIP - A Lightweight TCP/IP stack - Bugs: bug #61653, PPP Netmask Changed

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #61653: PPP Netmask Changed

Submitter:  Ashley Duncan <ashesman>
Submitted:  Thu 09 Dec 2021 10:37:21 PM UTC
   
 
Category:  PPP Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
lwIP version:  2.1.2

Sun 12 Dec 2021 11:56:17 PM UTC, comment #4: 

Hi Sylvain,

Thankyou for taking the time to offer advice.  I am a seasoned embedded software engineer but by no means an expert in IP stacks!

I have actually done as you mentioned and fudged the netmask in this case which allows broadcast packets on the PPP links IP address to be sent to the WiFi module. 

Unfortunately it turns out that the module PPP to WiFi bridging does not bridge broadcast packets in either direction so working with the manufacturer on that one.

Keep up the great work, lwIP is a great resource.

Regards

Ashley

 Ashley Duncan <ashesman>
Sun 12 Dec 2021 11:49:00 PM UTC, comment #3: 

Hi Ashley,

I took the time to dig a bit more about that, there is quite a bit of history and legacy on netmask hacks on PPP links.

https://github.com/ppp-project/ppp/blob/eff574c871822c7e2788aa8a928f2480fa7a6cb3/pppd/sys-linux.c#L2766

This is the final answer, for "recent" Linux kernels (Linux 2.1.16 was released 18-Dec-1996 :-), the netmask is forced to 255.255.255.255, everything else is legacy code that do nothing. So the subnet hack I supposed to still exists was only working in the early '90 era…

And you are right, IPCP never exchange netmask between peers, my bad, I sometimes think there is because I used to see non standard support for that in the wild but that's all.

Anyway, I am not against allowing the user to set any netmask if necessary, bypassing the forced 255.255.255.255 value (that is, only setting the netif netmask at init). After all, the wifi module can still hack around PPP and create a layer 2 bridge between the PPP link and the Wifi "world" in the same way cellular modems currently do.

Sylvain

 Sylvain Rochet <gradator>
Group Member
Sun 12 Dec 2021 09:59:51 PM UTC, comment #2: 

Hi Sylvain,

Quote:  "What do you mean by "the PPP link is configured for netmask 255.255.255.0"" - The Ublox WiFi module I am using is pre-configured by AT commands before entering PPP mode.  These AT commands can set the PPP client/server IP addresses and subnet mask.

It seems there is no IPCP option (in lwIP or the RFC documents) for setting the clients subnet mask from the PPP server.  This makes sense in the fact that it is a one to one connection so a subnet mask of 255.255.255.255 is applicable.

I had made some assumption that I could send broadcast packets to the PPP netif, and they would be relayed on the WiFi link as broadcast packets.

I guess I need to send the broadcast packets to the address range of the WiFi link, not the PPP link.  Not a big deal, but requires some additional code to bipass the use of the netifs IP address.

After some debugging, I found some minor issues with the PPP debugging code which I have listed in a separate issue.

I don't believe lwIP is doing anything wrong, feel free to close this issue, sorry for wasting time.

 Ashley Duncan <ashesman>
Fri 10 Dec 2021 03:01:45 PM UTC, comment #1: 

Hi Ashley,

What do you mean by "the PPP link is configured for netmask 255.255.255.0" ?  For PPP "client mode", netmask can be set by IPCP from the peer if the peer send the netmask option, otherwise 255.255.255.255 is a sane default. Or is it broken ? Could you send the PPP packet trace ?

get_mask() is a leftover from pppd and is for unix-like systems with multiple interfaces and is only useful when IP forwarding is enabled on the client side. It achieves something similar to ARP proxy. This is mostly a hack to offer professional customers a subnet of more than one IP address and it is a very uncommon design today, proper IP routing is preferred.

Sylvain

 Sylvain Rochet <gradator>
Group Member
Thu 09 Dec 2021 10:37:21 PM UTC, original submission:  

Hi,

I am not sure if this is an issue, or my misunderstanding of PPP.  Please forgive me if it is the later...

I am using a PPPoS connection to a Ublox Nina W15 WiFi module.  Has been working great for years.

Today I tried to send UDP broadcast packets on the PPP netif.  I calculate the broadcast IP address by ORing the compliment of the netmask with the netif IP address.  I noticed that even though the PPP link is configured for netmask 255.255.255.0, once connected the netmask is changed to 255.255.255.255 (IPADDR_BROADCAST).  this happens in get_mask, line 1232 of ppp.c.

The above calculation results in the broadcast address being calculated as the netifs IP address.  So any packets sent on that PPP netif are caught by loopback and not actually sent on the PPP link.

I guess that a PPP link is always one to one so the concept of broadcast may not exist on PPP?  Although in most PPPoS cases, the PPP link is a conduit to another network interface so should pass all traffic in both directions?

 Ashley Duncan <ashesman>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gradator (Posted a comment)
  • -email is unavailable- added by ashesman (Submitted the item)

    •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    No changes have been made to this item

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.13-72d9.
    Corresponding source code