Project

General

Profile

Actions

Testing #376

closed

Verify Media Player can see Media Server

Added by Hammel about 10 years ago. Updated about 10 years ago.

Status:
Closed
Priority:
Immediate
Assignee:
Category:
09 - Testing
Target version:
Start date:
14 Aug 2014
Due date:
% Done:

100%

Estimated time:
Severity:
02 - High

Description

After configuring MS as AP, configure MP as client and then make sure that latter automatically sees and mounts the MP's /media directories.

Then try playing from the MP and see what kind of lag there is.

Actions #1

Updated by Hammel about 10 years ago

  • Severity changed from 03 - Medium to 02 - High
Actions #2

Updated by Hammel about 10 years ago

  • % Done changed from 0 to 20

The player doesn't see the server with the default wpa_supplicant.conf. The following lines need to be changed from

  pairwise=TKIP
  group=TKIP

to

  pairwise=CCMP
  group=CCMP

The fix for this is for bui-network-config to set these values. There may be some ways to query for this but the quickest way is to have the UI let the user set these.

Once the connection is made the player doesn't see the server due to some errors in CIFS session setup:

Aug 18 00:26:42 (none) user.err kernel: [160705.153273] CIFS VFS: Send error in SessSetup = -13
Actions #3

Updated by Hammel about 10 years ago

  • % Done changed from 20 to 40

Client mounts were failing (despite that cryptic message) with a "permission denied" error message. After much searching, I found that adding sec=ntlmv2 to the mount options mounted perfectly.

A test of playback is failing, however. videofe sees the video files on the mount point just fine but it takes a while to get a list displayed and then starting the video playback is really slow. Eventually omxplayer dies.

Actions #4

Updated by Hammel about 10 years ago

  • % Done changed from 40 to 60

I found that sec=ntlm (instead of ntlmv2) seems to work a little better, at least when the devices are close together. I was able to play a video on the player streamed from the server just fine

Dom also suggested disabling smb/nmb in the client before trying the mount. That implies a some kind of client-only opkg that disables the Samba server because that server is part of the core platform.

Here is the command to use for mounts:

mount -t cifs //192.168.3.1/media /media/smb/192.168.3.1 -o username=guest,guest,sec=ntlm

Now I just need to update piboxd to use this command and create a client opkg to disable samba and I should be ready for an 0.9 release (I think). I also updated bui-network-config to use CCMP for pairwise and group settings and pushed that upstream already.

Actions #5

Updated by Hammel about 10 years ago

  • % Done changed from 60 to 70

Fresh install failure: player doesn't connect to server again. The problem is that the buildroot build didn't pick up the latest changes to bui-network-config. The changes are pushed upstream. I think the problem is that the build pulled from the local archive which was not up to date.

Also: server mounts its own smb exports on boot.

Everything else seems okay so far. Need to get an updated bui-network-config and try again.

Actions #6

Updated by Hammel about 10 years ago

  • Status changed from New to In Progress
Actions #7

Updated by Hammel about 10 years ago

The problem with connecting seems to be that bui-network-config is writing "WPA" instead of "WPA2" when WPA2 is selected. This is because src/load.c:684: sets "WPA" instead of "WPA2" if wpa_supplicant.conf doesn't exist at load time. It should default to WPA2.

The default for wpa_supplicant "pairwise" and "group" should be CCMP as well. That seems to be the case if wpa_supplicant.conf doesn't exist. If it does exist,but has the wrong values then it messes things up.

Actions #8

Updated by Hammel about 10 years ago

  • % Done changed from 70 to 80

Discovered one last bug with networking: The S40network script starts wpa_supplicant in the background and then immediately performs an ifup -a. The latter doesn't give the former time to complete. So I added an arbirtrary 2 second wait and that seems to help let the client connect cleanly with the server. Change is committed and pushed upstream.

All bugs seem to be cleaned up for this release. Now I need to do another clean build and install on both client and server to verify everything is working for 0.9.0. I also need to do a completely clean build on feynman (CentOS) to make sure the supporting toolchain and rootfs builds still work when I have no local archive.

Actions #9

Updated by Hammel about 10 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 80 to 100

One last issue - the bui-network-config change that fixed the WPA -> WPA2 issue wasn't pushed upstream. Fixed that and rebuilt the rootfs. Everything seems to be working now.

Ready for a release. Closing this issue.

Actions

Also available in: Atom PDF