Verify Media Player can see Media Server
|Status:||Closed||Start date:||14 Aug 2014|
|Category:||09 - Testing|
|Severity:||02 - High|
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.
RM #376: If SMBMOUNT is specified in config file, use that. Otherwise use the default mount command.
#2 Updated by Hammel over 5 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
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
#3 Updated by Hammel about 5 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.
#4 Updated by Hammel about 5 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.
#5 Updated by Hammel about 5 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.
#7 Updated by Hammel about 5 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.
#8 Updated by Hammel about 5 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.
#9 Updated by Hammel about 5 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.