No connection between MBC <--> MBS

[StAlex 0]

Hello.

 

My OS Environment:

OS with the MBC: Win7 Maximum

OS with the MBS: FreeNAS-9.2.1.3-RELEASE-x64 (dc0c46b)

 

Versions (you can see it on screenshots):

MBC: 3.0.238.0

MBS: 3.0.5445.6

[admin@storage] /mnt/VOL1/home/admin# uname -a
FreeBSD storage.satan 9.2-RELEASE-p3 FreeBSD 9.2-RELEASE-p3 #0 r262572+38751c8: Thu Mar 20 21:13:02 PDT 2014     root@build.ixsystems.com:/tan
k/home/jkh/9.2.1-BRANCH/freenas/os-base/amd64/tank/home/jkh/9.2.1-BRANCH/freenas/FreeBSD/src/sys/FREENAS.amd64  amd64
[admin@storage] /mnt/VOL1/home/admin#

Network configurations.

MBC:

ipconfig.txt

MBS:

ifconfig.txt

ifconfig.ToolJail.txt

 

MBS itself installed under the Jail named as "ToolJail" (appears inside the logfiles). MBS's install performed as package (pkg install, ...), ffmpeg reassembled from ports (due to your manual recomendations). Also, I tried to install MBS onto the same computer with the MBC - and no difference I seen. 

 

Now, I explain a problem I faced.

 

When I am start the Media Browser Classic Configurator, I see next screen:

 

When I click "OK" I see the next screen:

 

After click "OK" again, I see the main window of Configurator app.

You can see empty fields for server address and port, and also empty Userlist:

 

When I try to push button "Validate and Save" I see the next screen:

and catch the next network communication (using tcpdump utility on the MBS side):

13:32:22.061364 IP MCE.Dlink.49448 > 255.255.255.255.7359: UDP, length 26
E..6T.....%
.........(..."<Ewho is MediaBrowserServer?
13:32:22.061953 IP ToolJail.7359 > MCE.Dlink.49448: UDP, length 37
E..AF...@..............(.-.@MediaBrowserServer|192.168.0.129:8096

With that dump I uderstand that no firewall issues affected on the on-topic problem.

Also, please look on the screen at the server address and port fields - it fills from the received UDP message.

 

But - unfortunately, MBC cannot connect to the MBS with this message:

2014-12-14 12:22:15.5428,Error,,Error requesting http://192.168.0.129:8096/mediabrowser/System/Info/Public?format=Json ( Exception.  Type=System.ArgumentException Msg=Указанное значение содержит недопустимые знаки управления. [n] Имя параметра: value Src=System Method=CheckBadChars Line=0 Col=0 [n] StackTrace= [n]    в System.Net.WebHeaderCollection.CheckBadChars(String name,, Boolean isHeaderValue) [n]    в System.Net.WebHeaderCollection.Add(String name,, String value) [n]    в System.Net.WebHeaderCollection.Add(HttpRequestHeader header,, String value) [n]    в MediaBrowser.ApiInteraction.MbHttpClient.Get(String url) ),1,

I see the same error on this forum, but in my case - I do not have russian letters in the hostname of computer with MBC (it just "MCE" - three latin letters).

I try to look in the sourcecode on github (in MbHttpClient.Get function), but I not see in it nothing special except adding one authorisation header. The error message from the log - pointing to the problems with the HTTP-header value. But no value is logged (of cource, due to security things). 

How I can do more detailed debug of this issue? In my case I do not have the MS VS C# for build the project and do manual debug...

 

Now, the complette LOG-files.

MBC:

Configurator-14122014eab576ba20064ac8a3a942e17148bb5b.log

MBS:

server-full.zip

 

And finally, couple scrrens from the MBS, observed via the WEB-interface:

 

PS.

As the side question - 

what is the messy mesages I see in the server logs?

2014-12-14 00:01:22.5151 Error - Dlna: Error sending Datagram to 239.255.255.250:1900 from 127.0.0.1:0: NOTIFY * HTTP/1.1
. HOST: 239.255.255.250:1900
. CACHE-CONTROL: max-age = 600
. LOCATION: http://127.0.0.1:8096/mediabrowser/dlna/a88351a89d11084d89af5baef10ce1d7/description.xml
. SERVER: Unix64/9.2 UPnP/1.0 DLNADOC/1.5 MediaBrowser/3.0.5445.6
. NTS: ssdp:alive
. NT: urn:schemas-upnp-org:service:ContentDirectory:1
. USN: uuid:a88351a89d11084d89af5baef10ce1d7::urn:schemas-upnp-org:service:ContentDirectory:1
. 
. 
	The requested address is not valid in this context
	System.Net.Sockets.SocketException
	  at System.Net.Sockets.Socket.EndSend (IAsyncResult result) [0x00000] in <filename unknown>:0 
	  at MediaBrowser.Dlna.Ssdp.Datagram+<Send>c__AnonStorey0.<>m__0 (IAsyncResult result) [0x00000] in <filename unknown>:0 
	

[ebr 14905]

What is the name of the Windows User on the MBC machine?

[StAlex 0]

What is the name of the Windows User on the MBC machine?

Default administrator user from clean install of localized RUSSIAN win7:

 

If I feel the situation right, the workaround is - rename the administrator account. But more efficient job - teach the code to work with the i18n names (like i18n websites) ...

At least, put the attention in the FAQ - which requisites is strightly should be in latin-1 charset.

[StAlex 0]

After rename the user account to latin "Administrator", connection is established.

Issue may be marked as "Answered"

[ebr 14905]

@@Luke - is there anything I can do about this on the MBC side?  The headers are basically barfing on those types of characters.

[Luke 37029]

what's the exact issue?

[ebr 14905]

His Windows User name was formed with Cyrillic characters (I think that's right for Russian) and, when I attempted to add them to the headers on the http request, the system said those characters were not supported in a header. 

[Luke 37029]

what header is that?

[ebr 14905]

The Authorization Header.  I comprise the Devicename as the machine name + windows user because, otherwise, you couldn't tell extenders from each other or host machines.

[StAlex 0]

I think you should convert all values (hostname && UserName) into UTF-8.

May be C# Api has the possibility to obtain mentioned values forced in UTF-8.

 

I think it may be affected for all non-english OS. For German or Scandinavian countries for example, which languages contain non-latin letters.

Edited December 14, 2014 by StAlex

[Luke 37029]

ok, yea i would make sure it's encoded and stripped of special chars

[StAlex 0]

I comprise the Devicename as the machine name + windows user

 

ok, yea i would make sure it's encoded and stripped of special chars

Let's make the whole world better

 

In my opinion, there are two ways to get it works.

#1 best way, permanent. The document rfc5987 contains an explanation how to deal with the chars which is outside the ASCII, when composing the values for embedding them into HTTP-messages.

#2 minor way, workaround. Just encode the values in Base64 before put into the HTTP-message. But it heavily depends on what to do with the value from the header on the server side. If just identification (no matter what is inside, just as some unique byte array) - it may solve the issue.