[Xymon] IPv6 debugging on xymon 4.4 (was Re: Roadmap/GitHub?/IPv6)

[Japheth Cleaver]

On 4/14/2019 11:53 PM, Christian Herzog wrote:
>> Looking at xymonnet.c and contest.c, I'm actually suspecting here that we're
>> not building NET6 connections at all in xymonnet tests, which means there's
>> more connecting work left to do than expected. I'm not sure if the original
>> plan was to migrate to xymonnet2 before IPv6. The factored-out connectivity
> I guess it was. Rereading my correspondence with Henrik from 6 years ago, it
> seems we had it pretty much working using xymonnet2 at that time:
> https://xymon.xymon.narkive.com/BbXHR8kH/status-of-ipv6-support (see my last
> message in that thread). I have no idea what has happened in the xymon source
> tree during those 6 years, and of course I don't have that config any more,
> but if we could reproduce those results we might be one step closer.

Agreed. I'm a bit torn at the xymonnet v xymonnet2 split here, simply 
due to how some of the code diverges at this point. I suspect adding 
IPv6 branching into xymonnet will be easier (or at least easier to 
validate).

>> For the short term, testing xymonclient messaging
> meaning client reports to IPv6 XYMONSERVERS?
>> and xymond record
>> management (using conn tests as sources) might be the most useful.
> meaning what exactly?
>
Correct. xymonproxy is another component that will need work, but 
client->xymond and anything at all (xymonnet/xymongen, etc) talking to 
an IPv6-only xymond would be very helpful. xymongen needs to download 
full xymondboard copies from xymond, so it's really about catching any 
assumptions out there on IP size or host lookups.

Would be good to disable BFQ too if it's enabled, since local components 
will short-circuit to using that for message submission instead of TCP 
in 4.x

> I'll go right ahead with those tests and stand by for any xymonnet2 trials you
> might come up with.

Thanks! I'll be focusing on 4.3.29 this week, so this will definitely help.

-jc