[asterisk-dev] Configured IPv6 transport in endpoint being overwritten by IPv4

[Joshua C. Colp]

On Wed, May 13, 2020 at 6:55 AM Roger James <roger at beardandsandals.co.uk>
wrote:

> I have an endpoint defined in the conf that has the 'transport' field set
> to a named ipv6 transport. I had this working on a test system. This
> required the application of the gerrit patch 14404 (currently in code
> review). I have moved this on to a more realistic test setup. This setup
> also has active ipv4 connections. As soon as one of these was successful
> it
> seems to have 'locked' the system into a persistent ipv4 only mode. I am
> afraid that is the best way I can describe it. I apologise in advance for
> the lack of precision. Even if the system is fully rebooted, very early on
> in the config process the transport field in the endpoint is changed to
> point at an ipv4 transport. I have spent a number of hours in gdb trying
> to
> pinpoint where this is happening, to no avail. The depths of sorcery have
> addled my ancient brain. Any assistance or pointers would be extremely
> gratefully received! In particular about where to put a breakpoint to trap
> this.
>
> As an aside. It is educational to put a break point on the code in
> config.c
> that reads the config files. I have isolated the transport=my-ipv6 line
> into its own file, and made the break point conditional on that file name.
> It is triggered an unbelievable number of times. I cannot see the wood for
> the trees. It also seems very wasteful as somewhere way back up the stack
> it is going to be thrown away as "file unchanged". Isn't that what last
> modification times are for?
>

And to further clarify - you state in your message that the transport is
changed to an ipv4 transport early in the config process, but before that
you state that it's locked into ipv4 after one of these was successful.
That's what I'm finding confusing in understanding.

If the case is indeed actually that after configuration loads the endpoint
has an explicitly configured ipv4 transport and not ipv6, and that it
doesn't depend on actual traffic flowing then it's likely in your
configuration files. Have you taken parts of them away and gradually added
them back? One of the things that people can find problematic is using the
same name for adding to an existing context, as in PJSIP you can end up
using the same name for different logical contexts. In this case you have
to use a filter[1] to ensure it gets added to the right thing.

[1] https://wiki.asterisk.org/wiki/display/AST/Adding+to+an+existing+section

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20200513/9aed9c86/attachment.html>