hnetd is actually able to produce quite an insane amount of debug logs (e.g. about anything happening on DNCP). Those are meant for developers (like trying to debug DNCP protocol). I don’t think this is what you want to do, since DNCP is actually fairly reliable… But since you ask, here is how to sink under DNCP debug messages. - Enable ‘debug’ log level in hnetd.h (HNETD_DEFAULT_L_LEVEL). - And then set hnetd runtime log level to debug with --loglevel option (As you probably tried already).
- Pierre > Le 9 nov. 2018 à 09:32, Ted Lemon <[email protected]> a écrit : > > Yes, this is exactly the sort of information I am looking for—thanks. I > just did a pass through the code to refresh my memory, and the issue I have > with it is that there's no architecture document, so you kind of have to > figure that out by reverse engineering it, and there aren't a lot of > comments. hncp_sd.c is actually pretty good—I don't think I'd looked at it > before. E.g., one of the modules I looked at before I got this mail from > you was pa_core.c. Actually it looks like there are some useful comments in > the header files. But an introduction that explains how the code basically > works would really help. Not the protocol—just what the concepts are and > how they fit together. And debugging messages aimed at users would help as > well—one of the easiest ways to learn how something works is to just run it > with debugging maxed and see what it logs. But the log messages appear to > be more about hncp than about what has been learned through hncp. > > Anyway, I'll give it another look—you've already helped me quite a bit. > > On Fri, Nov 9, 2018 at 5:21 PM <[email protected] > <mailto:[email protected]>> wrote: > 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/homenet >> <https://www.ietf.org/mailman/listinfo/homenet> >
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
