Not logged in. · Lost password · Register
Forum: MatriX and XmppDotNet RSS
Page:  1  2  next
pcharlton@carbonlabs.co.uk #1
Member since Nov 2019 · 12 posts
Group memberships: Members
Show profile · Link to this post
Subject: Matrix vNext in Xamarin.Forms - DotNetty.Transport.Channels.ClosedChannelException
Hi,
I'm not sure how active these forums are but I couldn't find anywhere else of use.

I'm running into issues when trying to use Matrix.vNext in Xamarin forms.  I have a sample (taken from github https://github.com/matrix-xmpp/matrix-vnext/tree/master/ex…) that works perfectly well when running on a windows box.

However, when moving to Xamarin.Forms, in either Android or iOS I'm getting a ClosedChannelException (see below).  It seems to do the initial connect and get the features, but fails when setting up the Tls.

DotNetty.Transport.Channels.ClosedChannelException: I/O error occurred.
at Matrix.Network.Handlers.XmppStanzaHandler.SendAsync (System.String s) [0x0004c] in C:\vs_samples_repos\matrix-vnext\src\Matrix\Network\Handlers\XmppStanzaHandler.cs:114
at Matrix.Network.Handlers.XmppStanzaHandler.SendAsync[T] (System.Func`1[TResult] sendTask, System.Func`2[T,TResult] predicate, System.Int32 timeout, System.Threading.CancellationToken cancellationToken) [0x000b8] in C:\vs_samples_repos\matrix-vnext\src\Matrix\Network\Handlers\XmppStanzaHandler.cs:438
at Matrix.Network.Handlers.XmppStanzaHandler.SendAsync[T1,T2] (System.String s, System.Int32 timeout, System.Threading.CancellationToken cancellationToken) [0x00098] in C:\vs_samples_repos\matrix-vnext\src\Matrix\Network\Handlers\XmppStanzaHandler.cs:169
at Matrix.XmppConnection.SendAsync[T1,T2] (System.String data, System.Int32 timeout, System.Threading.CancellationToken cancellationToken) [0x00037] in C:\vs_samples_repos\matrix-vnext\src\Matrix\XmppConnection.cs:199
at Matrix.XmppConnection.SendStreamHeaderAsync (System.Int32 timeout, System.Threading.CancellationToken cancellationToken) [0x00068] in C:\vs_samples_repos\matrix-vnext\src\Matrix\XmppConnection.cs:480
at Matrix.XmppConnection.SendStreamHeaderAsync (System.Threading.CancellationToken cancellationToken) [0x0002b] in C:\vs_samples_repos\matrix-vnext\src\Matrix\XmppConnection.cs:469
at Matrix.XmppConnection.ResetStreamAsync (System.Threading.CancellationToken cancellationToken) [0x0003c] in C:\vs_samples_repos\matrix-vnext\src\Matrix\XmppConnection.cs:447
at Matrix.XmppClient.DoStartTlsAsync (System.Threading.CancellationToken cancellationToken) [0x0018f] in C:\vs_samples_repos\matrix-vnext\src\Matrix\XmppClient.cs:228
at Matrix.XmppClient.HandleStreamFeaturesAsync (Matrix.Xmpp.Stream.StreamFeatures features, System.Threading.CancellationToken cancellationToken) [0x000c0] in C:\vs_samples_repos\matrix-vnext\src\Matrix\XmppClient.cs:179
at Matrix.XmppClient.ConnectAsync (System.Threading.CancellationToken cancellationToken) [0x0021f] in C:\vs_samples_repos\matrix-vnext\src\Matrix\XmppClient.cs:169
at Matrix.XmppClient.ConnectAsync () [0x00025] in C:\vs_samples_repos\matrix-vnext\src\Matrix\XmppClient.cs:142

Does anyone have any ideas?

Thanks in advance,
Paul.
This post was edited 2 times, last on 2019-11-26, 19:28 by Alex.
Avatar
Alex #2
Member since Feb 2003 · 4449 posts · Location: Germany
Group memberships: Administrators, Members
Show profile · Link to this post
Hello Paul,

do you have the XML log as well to see when this happens in the XML stream?
I have not seen problems on Xamarin Android before, but have not tried for a while myself.

There are knows issues with TLS on Xamarin iOS. Xamarin is still not 100% netstandard compatible. There is netstandard code which still behaves different in Xamarin.

Alex
pcharlton@carbonlabs.co.uk #3
Member since Nov 2019 · 12 posts
Group memberships: Members
Show profile · Link to this post
Thankyou for your quick reply!

I've been debugging this all day so apologies if I'm missing something really obvious.  I'm getting the same errors on both iOS and Xamarin.

The error seems to come after the proceed command has been received (the log output below) and then the Handlers are flushed in the DotNetty AbstractChannelHandlerContext.  It's really hard to follow but it's almost as if the last Handler (Matrix.Network.Handlers.StreamFooterHandler) doesn't exit properly and it starts to loop?


  1. SEND: <stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" to="carbonite" version="1.0" >
  2. RECV: <?xml version='1.0'?><stream:stream id='17333227140417320032' version='1.0' xml:lang='en' xmlns:stream='http://etherx.jabber.org/streams' from='carbonite' xmlns='jabber:client'><stream:features><starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'><required/></starttls></stream:features>
  3. SEND: <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls" />
  4. RECV: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
  5. SEND: <stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" to="carbonite" version="1.0" >

Paul.
This post was edited on 2019-11-26, 21:40 by Alex.
Avatar
Alex #4
Member since Feb 2003 · 4449 posts · Location: Germany
Group memberships: Administrators, Members
Show profile · Link to this post
Can you  try to disable StartTls for a test?

There is a known issue in DotNetty in combination with MONO which I have reported a while ago.
There is also a PR which is addressing it here:
https://github.com/Azure/DotNetty/pull/374

But this PR was never merged, because the problem is in MONO, and not in DotNetty. And it is related to flushing as you have seen as well.

Alex
pcharlton@carbonlabs.co.uk #5
Member since Nov 2019 · 12 posts
Group memberships: Members
Show profile · Link to this post
In reply to post #3
After a bit more digging, it seems I'm getting a "The authentication or decryption has failed." exception in HandleFailure of TlsHandler.

[Edit] - this is a red herring - i'd been playing with TLS settings on Android.
pcharlton@carbonlabs.co.uk #6
Member since Nov 2019 · 12 posts
Group memberships: Members
Show profile · Link to this post
In reply to post #4
Quote by Alex:
Can you  try to disable StartTls for a test?

There is a known issue in DotNetty in combination with MONO which I have reported a while ago.
There is also a PR which is addressing it here:
https://github.com/Azure/DotNetty/pull/374

But this PR was never merged, because the problem is in MONO, and not in DotNetty. And it is related to flushing as you have seen as well.

Alex

I'll have a look in the morning, this is starting to get to me!
pcharlton@carbonlabs.co.uk #7
Member since Nov 2019 · 12 posts
Group memberships: Members
Show profile · Link to this post
Removing StartTLS worked.  Not really a sustainable option though ;)
pcharlton@carbonlabs.co.uk #8
Member since Nov 2019 · 12 posts
Group memberships: Members
Show profile · Link to this post
I've also replaced the TlsHander with the one from that PR and this addresses the problem.

Is there any way Matrix could be adjusted to allow us to pass in our preferred TlsHandler, and we could specify a child version?
Avatar
Alex #9
Member since Feb 2003 · 4449 posts · Location: Germany
Group memberships: Administrators, Members
Show profile · Link to this post
Quote by pcharlton@carbonlabs.co.uk:
Is there any way Matrix could be adjusted to allow us to pass in our preferred TlsHandler, and we could specify a child version?

currently not, but I am considering to add this because quite a lot of users are running into the Mono issue.

Alex
pcharlton@carbonlabs.co.uk #10
Member since Nov 2019 · 12 posts
Group memberships: Members
Show profile · Link to this post
I've modified XmppClient to read:

  1. /// <summary>
  2. /// Initializes a new instance of the <see cref="XmppClient"/> class.
  3. /// </summary>
  4. /// <param name="pipelineInitializerAction">The pipeline initializer action.</param>
  5. public XmppClient(Action<IChannelPipeline, ISession> pipelineInitializerAction)
  6.     : base(pipelineInitializerAction)
  7. {
  8.     TlsHandlerFactory = tlsSettings => new TlsHandler(stream
  9.         => new SslStream(stream,
  10.         true,
  11.         (sender, certificate, chain, errors) => CertificateValidator.RemoteCertificateValidationCallback(sender, certificate, chain, errors)),
  12.         tlsSettings);
  13. }
  14.  
  15. /// <summary>
  16. /// Initializes a new instance of the <see cref="XmppClient"/> class.
  17. /// </summary>
  18. /// <param name="pipelineInitializerAction">The pipeline initializer action.</param>
  19. /// <param name="eventLoopGroup">The event loop group.</param>
  20. public XmppClient(Action<IChannelPipeline, ISession> pipelineInitializerAction, IEventLoopGroup eventLoopGroup)
  21.     : base(pipelineInitializerAction, eventLoopGroup)
  22. {
  23.     TlsHandlerFactory = tlsSettings => new TlsHandler(stream
  24.         => new SslStream(stream,
  25.         true,
  26.         (sender, certificate, chain, errors) => CertificateValidator.RemoteCertificateValidationCallback(sender, certificate, chain, errors)),
  27.         tlsSettings);
  28. }
  29.  
  30. ...
  31.  
  32.  
  33. public Func<TlsSettings, IChannelHandler> TlsHandlerFactory { get; set; }

Then I've locally set the factory to return a MyTlsHandler, which is the one from the PR essentially.  It's smells though as I've had to surface some of the DotNetty internal classes.

Is it worth a PR for the XmppClient changes?

Paul.
This post was edited on 2019-11-27, 10:31 by Alex.
Edit reason: added code formatting tags
Avatar
Alex #11
Member since Feb 2003 · 4449 posts · Location: Germany
Group memberships: Administrators, Members
Show profile · Link to this post
Yes, similar to that.
We just have used Provider naming instead of Factory and worked with interfaces for similar stuff.
I will add it to my TODO list and review as soon as possible. Should be straight forward to get this into the main code base soon.

Alex
pcharlton@carbonlabs.co.uk #12
Member since Nov 2019 · 12 posts
Group memberships: Members
Show profile · Link to this post
Awesome - a knock in here or github would be great, then I can go back to the official release!
Avatar
Alex #13
Member since Feb 2003 · 4449 posts · Location: Germany
Group memberships: Administrators, Members
Show profile · Link to this post
will post an update here for sure.

Alex
Avatar
Alex #14
Member since Feb 2003 · 4449 posts · Location: Germany
Group memberships: Administrators, Members
Show profile · Link to this post
I have pushed a branch to GitHub here:
https://github.com/matrix-xmpp/matrix-vnext/tree/tls-provi…

Feedback is welcome before its getting merged.

Alex
Avatar
Brad #15
Member since Jun 2019 · 7 posts
Group memberships: Members
Show profile · Link to this post
Alex, in the new version of Matrix how do you use this? TlsHandlerProvider wants ITlsHandlerProvider but the handler is a type of ByteToMessageDecoder.

I was expecting just:

  1.   xmppClient.TlsHandlerProvider = new customTlsHandlerFromPR();
This post was edited on 2019-12-22, 11:05 by Alex.
Close Smaller – Larger + Reply to this post:
Verification code: VeriCode Please enter the word from the image into the text field below. (Type the letters only, lower case is okay.)
Smileys: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Special characters:
Page:  1  2  next