15 Dec
2011
15 Dec
'11
3:41 p.m.
Hello,
On 12/15/11 1:18 PM, marius zbihlei wrote:
On 12/14/2011 07:28 PM, Andreas Granig wrote:
have you checked if inet_pton() doesn't break the internal ip_addr
structure and the use of it? If all is ok, I guess inet_pton() is
portable enough through most unix/linux distro's to make use of it.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
Hey Daniel,
On 12/14/2011 06:00 PM, Daniel-Constantin Mierla wrote:
Hello,
Actually, looking at the code I've observed some weird behavior : for
example to fix the force_send_socket IPv6 address, a call to str2ip6()
(from resolve.h) is done (via resolvehost()). The function tries to
manually parse the IP address, so it makes me wonder why not use a
library function like inet_pton(AF_INET6... to get the correct structure.
A possible bug is that with the current code, IPv4 mapped to IPv6
(x:x:x:x:x:x:d.d.d.d) will not be parsed correctly.
Why don't we use inet_pton(AF_INET6 ... . Any reasons? is the ipv6 address in between square brackets
(can you give exact
usage
of the foce_send_socket())? It should work as the bridging ipv4-ipv6 is
using the same mechanism -- may be an issue with the exported function
to config, though. Can you try to set $fs as alternative to
force_send_socket()?
I tried both ways, like force_send_socket(x::x:5060); and
force_send_socket([x::x]:5060); - both resulting in the same error.
However, doing $fs="[x::x]:5060"; works perfectly fine, thanks for
the hint!
A fix for force_send_socket would maybe still be good to not confuse
people.
Thanks,
Andreas