#1032869 xmppc doesn't seem to work with Prosody

Package:
xmppc
Source:
xmppc
Description:
XMPP Command Line Client
Submitter:
Russell Coker
Date:
2024-02-13 03:09:02 UTC
Severity:
normal
#1032869#5
Date:
2023-03-13 06:12:27 UTC
From:
To:
I am trying to get xmppc to send messages where the from and to addresses are
on the same server which runs Prosody on Bullseye.  Below are some of the
commands I ran with the jid and password in the [default] section of
~/.config/xmppc.conf .  Below are some of the commands I ran, no messages
were delivered and there was no output from the discovery commands:

xmppc -m message $ADDR test
xmppc -m discovery info $ADDR
xmppc -a default -m discovery info $ADDR

I don't know if I made a mistake somewhere, but the program doesn't give an
error message and gives a 0 return code so I expect some result.
#1032869#10
Date:
2023-03-13 12:53:06 UTC
From:
To:
The command should be with "chat" as command:

  xmppc -m message chat $ADDR test

You you check the output with -v?
#1032869#15
Date:
2023-03-14 09:27:24 UTC
From:
To:
# xmppc -m message chat $ADDR test -v
Connecting xev@coker.com.au ... Stopping XMPP!
# echo $?
0

The above is what I get.
#1032869#20
Date:
2023-03-15 01:11:02 UTC
From:
To:
reassign 1032869 libstrophe0
thanks

It turned out that the cause of this was a configuration error on my server
making IPv6 port 5222 unavailable.  The libstrophe code that connects was
always connecting via IPv6 and never trying IPv4.  This algorithm will always
have failure cases as there are more than a few networks without correct IPv6
configuration.  In a general networking situation trying to connect to all
available addresses is the best behaviour.  Also having debugging logs state
which address was attempted and what error was received is good.
#1032869#29
Date:
2024-02-09 11:27:00 UTC
From:
To:
Hi Russell,

could you check, if the behaviour of libstrophe is better in the current
version 0.13.0? Thank you!

Cheers
#1032869#40
Date:
2024-02-12 10:44:02 UTC
From:
To:
Thanks for the update, the functionality seems better but strange.  It
connects to both addresses and closes then, and then makes a third connection
to do the actual work.

I think the correct functionality is to connect to each address in turn and
use the first one that works.  Below is an extract from "strace xmppc -m
message chat $ADDR".

connect(3, {sa_family=AF_INET, sin_port=htons(5222),
sin_addr=inet_addr("144.76.186.21")}, 16) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(57596),
sin_addr=inet_addr("115.64.7.71")}, [28 => 16]) = 0
close(3)                                = 0
socket(AF_INET6, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET6, sin6_port=htons(5222), sin6_flowinfo=htonl(0),
inet_pton(AF_INET6, "2a01:4f8:200:641c::d0d0:c0de", &sin6_addr),
sin6_scope_id=0}, 28) = 0
getsockname(3, {sa_family=AF_INET6, sin6_port=htons(43981),
sin6_flowinfo=htonl(0), inet_pton(AF_INET6,
"2001:4479:6804:6c00:c472:15ff:fe25:e183", &sin6_addr), sin6_scope_id=0},
[28]) = 0
close(3)                                = 0
socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) = 3
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
connect(3, {sa_family=AF_INET6, sin6_port=htons(5222), sin6_flowinfo=htonl(0),
inet_pton(AF_INET6, "2a01:4f8:200:641c::d0d0:c0de", &sin6_addr),
sin6_scope_id=0}, 28) = -1 EINPROGRESS (Operation now in progress)
#1032869#45
Date:
2024-02-13 03:05:57 UTC
From:
To:
Feedback from upstream. The first and second call is because of
resolver routines. The 3. connection is the "libstrophe"
connection.

When I understood well, the reason of the bugs was a wrong IPv6
configuration. After failed IPv6 connection, libstrophe didn't
try IPv4 as fallback. Am I right?

TIL: There are some information in RFC 6724 - Default Address
Selection for Internet Protocol Version 6 (IPv6).