Denon AVR-4311CI Recognized But Not Authorized

Discuss media renderers like Xbox 360, TVs, smartphones, etc.
holografik
Posts: 23
Joined: Tue Feb 11, 2020 8:55 am

Re: Denon AVR-4311CI Recognized But Not Authorized

Post by holografik »

Nadahar wrote: Mon Feb 17, 2020 6:51 pm I don't thin there should be any HTTP/2 traffic there, I certainly know that UMS doesn't support it. I don't even know if it has been added to UPnP AV, but the "original" UPnP AV was written for HTTP/1.1.
Ah! I misinterpreted the one of the log messages. It includes the string HTTPv2:
TRACE 2020-02-16 13:07:54.185 [HTTPv2 Request Worker 7] Received a request from avr4311 [Unknown renderer] (192.168.1.72:117
0):
Of course, had I thought about one of the lines which follows:
SUBSCRIBE /upnp/event/content_directory HTTP/1.1
I've added more logging, and I've run the connection sequence 3 times. The 4311 never inquires about it's authorization status. Further, I've determined that all the empty responses produced by UMS occur when the 4311 sends a SUBSCRIBE without any uri. Something might be off with the header parsing too, because for these SUBSCRIBEs, the CALLBACK header value is interpreted as the soapaction. Of course, UMS is being asked to parse what is probably an invalid SUBSCRIBE message.
Nadahar
Posts: 1990
Joined: Tue Jun 09, 2015 5:57 pm

Re: Denon AVR-4311CI Recognized But Not Authorized

Post by Nadahar »

The HTTPv2 is just "UMS internal", because it has two HTTP server implementations, "v1" and "v2". "v1" uses Java's embedded HttpServer, while "v2" uses Netty.
Nadahar
Posts: 1990
Joined: Tue Jun 09, 2015 5:57 pm

Re: Denon AVR-4311CI Recognized But Not Authorized

Post by Nadahar »

I would focus on the "description" request for now. Once devices discover each other, they will usually query for the other's description. All services must be listed there, and I suspect that the renderer never asks for the authorization because the service isn't listed as it should.

The easiest way is probably to use WireShark and compare the "description" response from UMS with one that works with the renderer, and chances are that you will get a hint of what's missing or wrong.
holografik
Posts: 23
Joined: Tue Feb 11, 2020 8:55 am

Re: Denon AVR-4311CI Recognized But Not Authorized

Post by holografik »

Nadahar wrote: Tue Feb 18, 2020 11:56 am I would focus on the "description" request for now. Once devices discover each other, they will usually query for the other's description. All services must be listed there, and I suspect that the renderer never asks for the authorization because the service isn't listed as it should.

The easiest way is probably to use WireShark and compare the "description" response from UMS with one that works with the renderer, and chances are that you will get a hint of what's missing or wrong.
Good, because that is what I'm doing. :) I got what I think is the 'standard' service description for MRR, and I added it to the server. Still analyzing the result.
holografik wrote: Tue Feb 18, 2020 10:44 am ... Further, I've determined that all the empty responses produced by UMS occur when the 4311 sends a SUBSCRIBE without any uri.
This claim of mine was incorrect. Actually, the 4311 is providing a root URI (i.e. '/') for the SUBSCRIBE. I don't know what this means or implies ... yet.
holografik
Posts: 23
Joined: Tue Feb 11, 2020 8:55 am

Re: Denon AVR-4311CI Recognized But Not Authorized

Post by holografik »

Nadahar wrote: Mon Feb 17, 2020 6:51 pm
holografik wrote: Mon Feb 17, 2020 6:21 pm I gave up on trying to use wireshark to understand the upnp conversations. I got stuck on the http2 traffic.
I don't thin there should be any HTTP/2 traffic there, I certainly know that UMS doesn't support it. I don't even know if it has been added to UPnP AV, but the "original" UPnP AV was written for HTTP/1.1.
I figured out my missing-http-traffic problem. One shouldn't blame one's tools, but it's OK to question the configuration. :)

I neglected to consider that my local network employs a switch. Pretty difficult to sniff packets in that context unless some special settings are enabled...

That's what I get for working for the last 4 years almost exclusively at the top of the stack with Ruby/Rails.

I also determined that the mysterious requests to subscribe to '/' were attempts to subscribe to MRR events. I added <eventSubUrl> for the MRR service, and all those mysterious subscription requests now have a uri: /upnp/event/mrr. I reordered the path to mrr control and events in order to leverage the code which handles eventing for ContentDirectory.
Nadahar
Posts: 1990
Joined: Tue Jun 09, 2015 5:57 pm

Re: Denon AVR-4311CI Recognized But Not Authorized

Post by Nadahar »

I'm not sure I understand the details (I haven't read the service spec in a loong time), but I take it that <eventSubUrl> was added to the service in the "UPnP description"? If the renderer requires more functionality (if it needs to actually be notified of events, whatever they would contain) than the Xbox, this could be significant work to implement. If you can just "fake" the event subscription as well (return ok, but never send any events), it probably shouldn't be too bad.
holografik
Posts: 23
Joined: Tue Feb 11, 2020 8:55 am

Re: Denon AVR-4311CI Recognized But Not Authorized

Post by holografik »

Nadahar wrote: Wed Feb 19, 2020 7:23 am I'm not sure I understand the details (I haven't read the service spec in a loong time), but I take it that <eventSubUrl> was added to the service in the "UPnP description"? If the renderer requires more functionality (if it needs to actually be notified of events, whatever they would contain) than the Xbox, this could be significant work to implement. If you can just "fake" the event subscription as well (return ok, but never send any events), it probably shouldn't be too bad.
That is what I did. It was very simple to add the the SUBSCRIBE processing. Annnnnd ... drum roll ... it worked.

I'm going to test this on another 'vintage' Denon: 3808CI. If I can get my hands on an Xbox 360 or One, I'll test it on that, too.

I'd like to submit a PR in order to get a fix into the official releases (eventually). I created a local branch off of master at ceb7ec312fed15f95a5db8ceafc4e852b39106f7. Is there any more to the process for this? I haven't yet looked for dev process doc.

In the 4311 descriptor document, there's an attribute at the device node. It's ms:X_MS_SupportsWMDRM, and it's set to true. I suspect that this attribute indicates whether the device will require the presence of an MediaReceiverRegistrar service. I looked into the possibility of detection of this attribute, but the parsing of descriptor xml is buried deeply in cling. Modification of cling document parsing doesn't appear to be easy. I'm sure the code base custodians would regard such a change more warily. And the change would be for something which kind of breaks the schema of the descriptor document.

I -do- want to avoid the hack of having to include the phrase 'XBOX 360' in the rendererName, so I'm going to look into the addition of a configuration variable. Perhaps something like, 'emulateWMDRM', or 'provideWMDRMAuth', or ... ?

Any suggestions on how to proceed would be greatly appreciated. The goal is to get the solution incorporated into master in a timely fashion.
holografik
Posts: 23
Joined: Tue Feb 11, 2020 8:55 am

Re: Denon AVR-4311CI Recognized But Not Authorized

Post by holografik »

Explanation for anyone whom is investigating the problem with their 'vintage' Denon receiver such that certain DLNA media servers are listed as 'Not Authorized':
  1. Some Denon receivers such as the AVR-4311CI require certain parts of the WMDRM protocol (Windows Media Digital Rights Management) to be implemented by a media server. (see Item 4 below)
  2. WMDRM shackled receivers expect to be able to subscribe to events on a service called, X_AV_MS_MediaReceiverRegistrar (MRR).
  3. Other renderers require less interaction with the MRR service. For example, The Xbox 360 does not subscribe to MRR events. It only requests authorization via the actions, IsAuthorized, and IsValidated. The 4311CI uses these actions as well, but it will make these requests only if it can successfully subscribe to MRR events.
  4. If the event-subscription protocol cannot be successfully consummated with such a receiver, that receiver will consider itself to be not authorized to access content on the media server
  5. I have not read the MS-DRMND protocol spec in enough detail to know whether the media server which serves content must be the provider of authorization. It may be that only such a service be present on the local netwok.
  6. For the Denon AVR-4311CI, a special attribute is present in the device node of the receiver's DLNA device description document. This attribute is ms:X_MS_SupportsWMDRM. The use of this tag is not exclusive to equipment made by Denon. If any device which acts as a DLNA MediaRenderer includes this attribute in its description xml, and the attribute has been assigned the value of true, then it is likely that the device expects to interact in some manner with an MRR server.
    Note: The MS-DRMND protocol document does not reference this attribute. Go figure.
  7. Keep in mind that there may be other causes which lead to the same symptom.
Nadahar
Posts: 1990
Joined: Tue Jun 09, 2015 5:57 pm

Re: Denon AVR-4311CI Recognized But Not Authorized

Post by Nadahar »

holografik wrote: Wed Feb 19, 2020 8:02 pm That is what I did. It was very simple to add the the SUBSCRIBE processing. Annnnnd ... drum roll ... it worked.
That's great news, very well done :D
holografik wrote: Wed Feb 19, 2020 8:02 pm I'd like to submit a PR in order to get a fix into the official releases (eventually). I created a local branch off of master at ceb7ec312fed15f95a5db8ceafc4e852b39106f7. Is there any more to the process for this? I haven't yet looked for dev process doc.
I'm not sure exactly how much documentation exists, but I fear not very much. That said, the "standard GitHub" process is used. That means: Fork UMS to your own GitHub account (do you have one?), create a branch in your fork (or just push the one you've made locally to your fork), then create a PR from your fork to the "master" repo/UMS. Others can then comment, request changes and/or approve the PR. You can push new commits to this branch, and the PR will be updated - you can even rebase and force-push to replace the entire PR/clean up commits. There's really not more to it than that. Try to make sensible commits and sensible commit messages, so that it will make sense to someone looking at the history in.. 5 years ;)

I feel a bit stupid trying to explain things you might already know perfectly well, so it's better if you tell me what you do and don't know, and I can try to fill in.
holografik wrote: Wed Feb 19, 2020 8:02 pm In the 4311 descriptor document, there's an attribute at the device node. It's ms:X_MS_SupportsWMDRM, and it's set to true. I suspect that this attribute indicates whether the device will require the presence of an MediaReceiverRegistrar service. I looked into the possibility of detection of this attribute, but the parsing of descriptor xml is buried deeply in cling. Modification of cling document parsing doesn't appear to be easy. I'm sure the code base custodians would regard such a change more warily. And the change would be for something which kind of breaks the schema of the descriptor document.
Cling is currently unmaintained/looking for a new maintainer, so it's extremely unlikely to be able to modify it at this point. That said, it's often possible to use some creative subclassing and possibly reflection to "modify" library behavior, but it gets messy pretty fast. Any changes that breaks standard UPnP compliance probably wouldn't be accepted anyway.

That said, it might be more ways to do this - like getting a "hook" in somewhere to get hold of the raw document and parse it for this purpose outside of Cling for example. But, I'm wondering if this is at all a viable approach. It's a bit of a "the chicken and the egg" situation, in that we have to assume that we get the renderer's description before it gets ours (because we need to modify ours based on its). This isn't the way UPnP is supposed to work, the whole idea of modifying the description based on the recipient that UMS already does, is a hack. But, to "get away" with such a hack, you need to be able to decide to apply the hack with just very basic information about the other party.

UMS will often get the first HTTP request (usually for the description) before "Cling has disovered" the renderer, which is why UMS has a "dual detection" based either on HTTP headers or UPnP details. It's a flawed logic in any ways, but it's still tricky to get out of because the order of events is unpredictable.
holografik wrote: Wed Feb 19, 2020 8:02 pm I -do- want to avoid the hack of having to include the phrase 'XBOX 360' in the rendererName, so I'm going to look into the addition of a configuration variable. Perhaps something like, 'emulateWMDRM', or 'provideWMDRMAuth', or ... ?
The usual way to handle this in UMS is to add another option in RendererConfiguration. This option could then be set in any renderer configuration that would need it, and the existing "XBOX 360" hardcoded logic could probably also be migrated to this, making sure that the option is set in the Xbox 360 configuration.

The question that comes to my mind is why one would need to hide the "service" at all. I would assume that renderers that's not interested in a particular service simply disregards it, so that it could be exposed to all renderers. But, there are so many strange renderer implementations out there, that chances are that some will try to subscribe even to services they don't know or simply be confused by services they don't expect. I don't know, but it must be a reason why other servers have chosen to make this configurable. To me the natural thing, and I think the idea behind UPnP, is that the server simply lists all the services is supports, and then the clients make use of those that are of interest to it.
holografik wrote: Wed Feb 19, 2020 8:02 pm Any suggestions on how to proceed would be greatly appreciated. The goal is to get the solution incorporated into master in a timely fashion.
I've tried to give my inputs above, if you ask specific questions about what you want to know, I will try to give specific answers.
holografik
Posts: 23
Joined: Tue Feb 11, 2020 8:55 am

Re: Denon AVR-4311CI Recognized But Not Authorized

Post by holografik »

PR Submitted

I didn't include the 4311 config file in the PR. I suspect that the code custodians would prefer to seperate renderer config certification from code base changes. I attach my most recent version to this post.

I hope this helps a lot of receiver owners. I think there might be potential for newfound access by a number of circa 2010-2015 receivers.

UMS is such an excellent DLNA server implementation. Few other servers (if any?) offer the degree of control over individual interaction with a renderer.
Attachments
Denon-4311CI.conf
(5.66 KiB) Downloaded 415 times
Post Reply