I guess what you want to do is publish and receive TLVs using DNCP, and probably get a sense of the topology. To do so, there mostly is a single header to look at: dncp.h <https://github.com/sbyx/hnetd/blob/master/src/dncp.h>
Here is a simple example of Wifi autoconfig we did for one of IETF’s hackathon: https://github.com/Oryon/hnetd/blob/hackathon/src/hncp_wifi.c <https://github.com/Oryon/hnetd/blob/hackathon/src/hncp_wifi.c> As a more advanced example, I think the service discovery part will be relevant to you: https://github.com/sbyx/hnetd/blob/master/src/hncp_sd.c <https://github.com/sbyx/hnetd/blob/master/src/hncp_sd.c> If you want to add configuration parameters available in OpenWrt, I’d recommend you look at platform-openwrt.c <https://github.com/sbyx/hnetd/blob/master/src/platform-openwrt.c> - Pierre > Le 9 nov. 2018 à 08:52, Ted Lemon <mel...@fugue.com> a écrit : > > Made out of LEGO bricks. What you’re describing doesn’t match my experience > last time I looked at it. I will look again. This is why I asked: because I > need help. This is the most information I’ve gotten about it. I’m sorry my > comments come across as saying the software is bad. That’s not what i was > trying to communicate. > > On Fri, Nov 9, 2018 at 4:47 PM Markus Stenberg <markus.stenb...@iki.fi > <mailto:markus.stenb...@iki.fi>> wrote: > First off, hnetd was team effort - me, Pierre Pfister and Steven Barth. > > Secondly, I did not particularly want to promote hnetd but 'existing > implementations are bad, boo hoo' argument gets old and I think e.g. > https://github.com/jech/shncpd <https://github.com/jech/shncpd> is also quite > sufficient. I use even https://github.com/fingon/pysyma > <https://github.com/fingon/pysyma> 'in production' even now (admittedly not > HNCP bits of it, but DNCP + SHSP :->). > > On 09.11.2018, at 2.03, Ted Lemon <mel...@fugue.com > <mailto:mel...@fugue.com>> wrote: > > The issue with the code (IIRC) is that it requires cmake to compile, for no > > obvious reason, and cmake is hard to get working, so e.g. building it on > > MacOS X is a major porting task. And it depends on libraries that I don't > > have. And there's no layering of the configuration system aspect of the > > architecture—it just goes and bashes on interfaces and stuff (this is my > > recollection—I haven't looked at it in a year or so). > > There's some distinct parts that have well defined interfaces (as far as > those 'well defined' go in C anyway) - DNCP (dncp_*), /HNCP code (hncp_*), > prefix assignment code (pa_*), and operating system (platform_*) are all > pretty loosely coupled. > > I have compiled the DNCP(/partial HCNP) bits on OS X with relatively minor > modifications for my hobby project for example. > > > These are not bad things that Markus did. Markus was doing what he needed > > to do to get it running on OpenWRT. But these are real issues, which are > > preventing me from using the code. For someone who is not an HNCP expert > > to hack on the code is difficult, and would require substantial work. I > > could do it, but I have other things I'm working on. If the code were > > more modular, I could experiment with it. This is the problem I was > > trying to express. > > I have used it also unmodified on plain Linux number of times. If you want to > use it on something more esotreic, I could bet on OS X port being doable but > as lots of HNCP value comes from interfacing with system servers, I do not > see anyone writing platform interface for it. > > I am curious about what 'more modular' code looks like. Separate DLLs? Single > function call API between modules? Possibly made out of Lego bricks? > > Cheers, > > -Markus > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
