I’ll try that. I don’t remember if I did last time. My recollection was that the log messages were useful, but not sufficient, pretty much for the reason you’ve stated.
On Fri, Nov 9, 2018 at 5:51 PM <[email protected]> wrote: > 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]> 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 >> 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 >> >> 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]> 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]> >> 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 is also quite sufficient. I use even >>> 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]> 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] >> https://www.ietf.org/mailman/listinfo/homenet >> >> >> >
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
