Re: Accepted presence subscription never signaled to the subscriber

[Tomasz Sterna]

W dniu 01.04.2016, pią o godzinie 15∶06 +0200, użytkownik Philipp Jacob
napisał:
>  from='localhost' to='localhost'>
>  type='subscribed' to='gloox@localhost'/>
> 
> sx (io.c:301) encoding 210 bytes for writing:  sx (io.c:255) decoded read data (210 bytes):
>  to='localhost' from='localhost'>
>    type='subscribed' from='user1@localhost/testclient'/>
> 
> (io.c:96) completed nad: https://github.com/jabberd2/jabberd2/issues/new


-- 
 /o__  A verbal contract isn't worth the paper it's written on. Include
(_<^'  me out. -Samuel Goldwyn



signature.asc
Description: This is a digitally signed message part

Re: Accepted presence subscription never signaled to the subscriber

[Philipp Jacob]

2016-04-01 14:38 GMT+02:00 Tomasz Sterna :

> W dniu 01.04.2016, pią o godzinie 11∶04 +0200, użytkownik Philipp Jacob
> napisał:
> > In the router's debug output I can see the incoming subscribed
> > presence stanza from the contact:
> > sx (io.c:255) decoded read data (323 bytes):  > to='localhost'> > sc:sm='621b457a7181f454ca07bb4326e73e67096ed383' sc:c2s='10'
> > from='user1@localhost/testclient' type='subscribed'
> > to='gloox@localhost'/>
>
> I'm pretty sure the router routed it from 'c2s' to 'localhost' as
> requested.
>
> Take a look at sm debug log of 'localhost' to see what happened with
> that stanza there.
>
> According to RFC6121 3.1.5. server should:
> Replace from='user1@localhost/testclient' with from='user1@localhost';
> Then push roster item to all user1 (interested) resources;
> And finally send presence to gloox.
>
>
>
> --
>  /o__  "I always avoid prophesying beforehand because it is much better
> (_<^'  to prophesy after the event has already taken place. " - Winston
>
>
The final presence stanza arrives at gloox.
But not the 'subscribed' presence stanza with edited 'from' attribute.

The following messages are the only one mentioning "subscribed" in the sm
debug log during the process of requesting the subscription from
user1@localhost:

sx (io.c:255) decoded read data (323 bytes):



(io.c:96) completed nad: 


sx (io.c:301) encoding 210 bytes for writing: 
  

(io.c:96) completed nad: 

Re: Accepted presence subscription never signaled to the subscriber

[Tomasz Sterna]

W dniu 01.04.2016, pią o godzinie 11∶04 +0200, użytkownik Philipp Jacob
napisał:
> In the router's debug output I can see the incoming subscribed
> presence stanza from the contact:
> sx (io.c:255) decoded read data (323 bytes):  to='localhost'> sc:sm='621b457a7181f454ca07bb4326e73e67096ed383' sc:c2s='10'
> from='user1@localhost/testclient' type='subscribed'
> to='gloox@localhost'/>

I'm pretty sure the router routed it from 'c2s' to 'localhost' as
requested.

Take a look at sm debug log of 'localhost' to see what happened with
that stanza there.

According to RFC6121 3.1.5. server should:
Replace from='user1@localhost/testclient' with from='user1@localhost';
Then push roster item to all user1 (interested) resources;
And finally send presence to gloox.



-- 
 /o__  "I always avoid prophesying beforehand because it is much better
(_<^'  to prophesy after the event has already taken place. " - Winston

Accepted presence subscription never signaled to the subscriber

[Philipp Jacob]

Hi,
currently I'm writing an XMPP test client and I'm using jabberd2 v2.3.6 as
XMPP server (built from source).

I recognized a problem when subscribing to a user's presence. The
subscription itself seems to work, i.e. the subscriber receives presence
updates. However, the presence stanza of type "subscribed" never arrives at
the subscriber. That means on subscriber's side the subscription remains in
unanswered state while already receiving presence updates.

In the router's debug output I can see the incoming subscribed presence
stanza from the contact:
sx (io.c:255) decoded read data (323 bytes): 

I'm not very familiar with reading the debug output, but I cannot see an
error. And I don't see the subscribed presence stanza going out to the
subscriber. I confirmed this with a Wireshark trace.

Am I missing something? Please, can someone shed some light on this? I
didn't add the whole debug output, because it's quite lenghty, but of
course I can provide it when requested.

Regards,
Philipp