<div dir="ltr"><div>Hello!</div><div><br></div>I need a way to override how the OSPF protocol sees a device interface. I had an interface which had a peer address (/32) but I needed it to be able to communicate with an upstream OSPF router which was set as (/24) communicating via broadcast and expecting a larger mask. While it is of course possible to modify the upstream OSPF router to act as PTP this was not possible in my situation.<div><br></div><div>So essentially I needed to override the /32 on an interface to behave as /24 and for it to communicate in the broadcast type. In my case the interface had to remain /32 so changing it to /24 manually was not a viable option.  I looked at <b>ptp netmask</b> but all that did was send up /32 instead of /0 as part of the hello packets.</div><div><br></div><div>Has this ever come up as a request? If not then this is how I got around this issue.  Let me know your thoughts. I added a configuration option into the device protocol to support a list of interface patterns which if matched will override the prefix to what is passed in. The sysdep/linux/netlink.c then looks for an interface match and modifies the pxlen to be the real prefix that is configured. This resulted in the OSPF protocol seeing the device as broadcast and /24 instead of p2p.</div><div><br></div><div>I also have some basic questions:</div><div><ul><li>Where are your bugs/issues maintained? Bugzilla? Mantis? ...</li><ul><li>I say this because there is a TODO in the code but would expect this in a issue tracking system.</li></ul><li>Is there a list of tests that your team goes through before you release a version and if so where are they defined so that I can run through them before I push up a patch. I've done basic OSPF tests with the associated patch as well as valgrind leak checks.</li></ul><div>Thank you very much!</div><div><br></div></div></div>