WANTED: Someone with Share problems after 2.01.86 that can run Wireshark

WD Legacy Products WD TV Live Streaming
1

I admit there seems to be an unusually high number of people with this issue. If anyone out there has problems with windows file shares after the 2.01.86 upgrade that wants to experiment, and:

1- Has their PC as the master browser
2- can install and run Wireshark packet captures on that PC
3- is willing to spend an hour or so doing some upgrades / rollbacks (and knows how to do them) and take multiple packet captures at several intervals
4- has the issue ONLY on 2.01.86 and then it works fine on prior firmware

… Please PM me. I want to see if I can figure out what has changed.

I have 9 servers on my network, and have no issues, so I can’t troubleshoot what isn’t broken in my environment.

1 Like
2

Some people in the other threads hinted at this being a wireless issue?

3

I can’t help, as I had zero issues with my two SMPs.  Updated them both without doing anything at all special (no resets, reboots, nothing!).  SMB network shares function exactly as before, as does Netflix, etc.  Very very odd that the same update breaks things for a few people.  Seems like reset to clear all settings should fix anything that differs from my two boxes.  I do note that my two are using Ethernet connections, not Wifi.  It does seem like many of the people reporting problems are using Wifi, and that the problems being encountered sound like they could be caused by network connectivity problems.  Would hardly be unknown to have a network device be “broken” with certain brands of Wifi routers.

4

For testing reasons I switched from wired to wireless. No problems with network shares or DLNA. Signal strength was at the usual level, too.

I also haven’t changed anything regarding network-settings anywhere (router, other cliens, fileservers, …) before or after the update…

So, I have no idea where the problems for others after the update may come from.

5

yep, reviving an old thread

@tony, I don’t have any problems here, and I’m not sure how to test this idea without custom fw

but I was reminded of this today

WD’s smb.conf on 2.01.86

uses this

name resolve order      = bcast host lmhosts wins

prior gen devices used   bcast lmhosts wins host

it was well documented for prior devices that proper correct order, solves a lot of smb related problems

proper correct order should be

lmhosts host wins bcast

so yeah, not sure how to test without custom fw

but just an idea,

or maybe you know of tweaks to the windows side, that can help with possible name resolve order issues

or of coarse, maybe this relates to the server function and not the client function

6

KAD79 wrote:

yep, reviving an old thread

 

@tony, I don’t have any problems here, and I’m not sure how to test this idea without custom fw

 

but I was reminded of this today

 

WD’s smb.conf on 2.1.86

uses this

name resolve order      = bcast host lmhosts wins

prior gen devices used   bcast lmhosts wins host

 

it was well documented for prior devices that proper correct order, solves a lot of smb related problems

proper correct order should be

 

lmhosts host wins bcast

 

so yeah, not sure how to test without custom fw

but just an idea,

or maybe you know of tweaks to the windows side, that can help with possible name resolve order issues

 

KAD, can you explain how some of these options would even work. I am little confused on how some of those can even be used on an SMP, but Ive been out of the network business for a while now so that;s not al that surprising. :dizzy_face:

How does the SMP use an LMHOSTS file or a HOST file, and where would you put them if you wrote one? These are pretty old school static way of mapping machine names to IPs and would cause real problems with DHCP if you did use one. Also is the SMP a WINS client and who would be running a WINS server at there house?

My understanding is that the windows machines use the below order by default to find another machine over netbios for SAMBA connections. For direct IP apps using winsock they are supposed to hit DNS first instead.

NetBIOS name cache
WINS server
B-node broadcast
LMHOSTS file
HOSTS file
DNS server

Seems like if not resolved via cache, all machines on a home net are going to default to broadcast mode to find each other from the MB, unless you have multiple subnets (unlikely for most home nets)

Im fascinated by this but a bit out of my depth as far as understanding how the WD boxes can use some of these methods, so you want to post a few lines of a crash course for us half-wit dangerous home networkers?

I guess to me, understanding or not, the fact that the order of name resolution has changed and now people are having SAMBA problems totally makes you think there is some type of correlation.

-P

7

I’ll have to admit,

I dont have much expertise here, was hoping yourself or tony, and some others would know better

I’m sure quite a few of you have much more networking knowledge than I do, my niche seems to be linux related sh, bash scripting, etc …

it’s just something I was reminded of, and once discovered and implemented in WDLXTV for old Live and Live Plus

solved a lot of smb related problems

not that it will help, but smb.conf

# cat ./smb.conf
[global]
   Workgroup = WORKGROUP
   NetBIOS Name = SMPdev
   security = share
   guest account = root
   server string = WD TV Live
   disable spoolss = yes
   name resolve order = bcast host lmhosts wins
   socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536 SO_KEEPALIVE
   pid directory = /tmp
   lock directory = /tmp/locks
   max log size = 50
   log level = 0
   domain master = no
   local master = yes
   preferred master = no
   os level = 20
   veto files = /.DS_Store/.AppleDB/.AppleDouble/.AppleDesktop/Network Trash Folder/TheFindByContentFolder/TheVolumeSettingsFolder/Temporary Items/.TemporaryItems/.VolumeIcon.icns/Icon/.FBCIndex/.FBCLockFolder/
   delete veto files = yes

[BIG_DOG]
   comment = BIG_DOG
   path = /tmp/media/usb/USB1140/3F65-3AF5
   use sendfile = yes
   read only = no
   guest ok = yes

also in win7 the default adaptor settings for NetBios

“Use NetBios settings from DHCP Server. If Static IP address is used or the DHCP Server does not provide NetBios setting, enable Netbios over TCP/IP.”

also by default LMHOST and WINS is enabled - in my case they are both blank in win7, but still enabled

so my thought was we’ve got the WD, with changing resolve order

and then default in win7 is to accept and use whatever setting the DHCP server tells windows to use

and next thing you know, I can completely see it total network mess

so yeah dns should be tried first, but if there’s any dns related issues the

it should follow whatever order is set to try to find/resolve smb

and so why is “lmhosts host wins bcast” considered a correct order

lmhost = local machine host

host = already resolved shares/servers from other machines

wins

bcast = finally last try broadcast resolution

makes sense to me.

  1. check the local machine before everything else

  2. check any already resolved info

  3. check for wins server

  4. if all else fails try broadcast

on a side note, something we’ve discussed in the past in the master browser issue, note the OS Level = 20

8

Certainly interesting. Hopefully someone with deeper networking skills than I can explain some of this. The HOST and LMHOSTS should be text files, the former being the original TCP/IP name resolution file, and the other (LanMan hosts) was used for MS’s networking protocol, and I think possibly for Novell as well back in the day. I cannot imagine why you would need these anymore unless you have a very small network with subnets and need name resolution between the networks.

WINS makes sense I guess, but how many home media streaming boxes are running on large corporate networks that need name services across subnets? You usually even have to have  a secondary WINS server as well that replicates the name database.

Most of this would seem like real legacy stuff, and unnecessary for a media player. Since you are on a single small peer network where you can broadcast and find the other machines. Broadcast would be the only option I assume.

You need NB over TCP to map drives. Without that you could still use IP based apps like FTP or even a browser as long as you have the default gateway and DNS. No idea though what NB settings the DHCP server could give you since DHCP is from a RFC and MS had nothing to do with it. They just needed to find a way to continue with drive mapping and using their naming convention once IP replaced their LanManager and  Novells IPX/SPX.

Ahhh, like a random walk down memory lane. Much MUCH better now that we are all using the same protocol. Routing between subnets was a real pain in the early 90s.

But back to real life:

Hopefully Tony can jump in here, but B-node broadcast should be the best choice, and possibly the only one. Interesting that there is the option for preferred master (at least its set to no) and incredible that you could even have the ability to set for Domain Master. I doubt that would work. Having your WD be the Domain Controller would be a disaster! There is no way it could do login validation for a Windows Domain. It doesn’t have the user database.

Can you alter the OS level to 5 and hopefully prevent the SMP from ever becoming the Master Browser? 20 is really high.

You are definitely into some wild stuff on these boxes my friend

-P

9

KAD79 wrote:

WD’s smb.conf on 2.01.86

uses this

name resolve order      = bcast host lmhosts wins

prior gen devices used   bcast lmhosts wins host

Yeah, that CAN be an important difference – and they changed it for a reason, presumably, but I can’t imagine why.   Did they, perhaps, change the version of Samba that’s on the box now?

bcast:   That means the NetBIOS client (the WDTV) will just send a broadcast out to the network when trying to do NetBIOS name resolution.    This should be very reliable on a local network (Samba doesn’t recommend it in situations where hosts are on another subnet, but that’s not possible with WDTV’s anyway.).

host:  That means it will look in a local host file for the name, usually in /etc/hosts

lmhosts:  That means it will look in a local “LanMan” hosts file, usually in /etc/lmhosts

WINS means it will try a local WINS server, but since no WINS server is defined in the configuration file (or any includes that might have it) that method is disregarded.

So, do these files exist?

/etc/hosts

/etc/lmhosts  (or perhaps /etc/samba/lmhosts or some other path defined by the Samba defaults)

and if so, what’s in them?

Also, might there be an /etc/nsswitch.conf? 

10

Techflaws wrote:

Some people in the other threads hinted at this being a wireless issue?

TechFlaws: 

It isn’t just a wireless issue - I run my WDTV Live boxes on wired 1gb connections and I still lost network shares wth 2.01.86.  

I reset my firmware back to 1.6.x (can’t remember the exact version) and that has fixed  the problem.

11

so, I haven’t looked at all smb config files, and haven’t looked at the start up files at all

smb.conf is actually located at /tmp.smb.conf

so it’s recreated on every boot, so any options selected, will be in a startup script (which I haven’t looked at)

possibly in primary sys init file  /init that has some network stuff defined

or /etc/init.d/Sxx

side note, and yes, once I identify the start up script, I can change the os level, or any other item in smb.conf

/tmp/host does exist, in my case last night it was blank, but that’s probably because I haven’t attempted to connect to any smb shares

nsswitch.conf , I think this was in /tmp as well, but didn’t look at it

of coarse, I’m just getting into work for the day, so I’ll check for additional files, tonight and over the weekend

something else I should probably do as well

is flash official 1.16.xx and confirm that is changed not just with the newer device but between these 2 firmwares

12

TechFlaws: 

It isn’t just a wireless issue - I run my WDTV Live boxes on wired 1gb connections and I still lost network shares wth 2.01.86. 

Yeah, I know. That posting of mine if quite old from the beginning of this mess. I’d be really interested to see what turns out to be the cause in the end.

13

I don’t know if it can help, but I can detail how I got the “windows share not working” problem :

. I received this new box 3 days ago.

. I connected it to a USB disc, no ethernet cable.

. I configured the wifi.

. As the auto update was configured by default, it opened the new firmware menu.

. I accepted the firmware update and noted that fw previous version was 1.16.13.

. The update to  2.01.86 firmware ran without errors (2 steps) through WIFI (no ethernet).

.  I checked the web access ok on the box (Youtube, TVPluzz,…)

.  I configured the share of the USB local disk of the box.

. I then tried to get access to the shared USB disk from my PC. Its a windows 8.1 with accesses to shares on others PCs.

. I could not find the share of the box on the PC. There was an icon wdtv that gives access to the web remote interface of the box.

. rebooting several times the box and the PC, reconfiguring the wifi and the share, I could see the icon of the share. Most of the time I had a windows error 0x80070035 and no access to the share. 2 times (only) I could see the files on the shared disk.

. I configured a fixed dhcp ip address for the box in my router (my PC already has a fixed address) : same problem.

. I found the problem was documented on the forum and downgraded to the 1.16.13 firmware.

. Now shares work OK, I also have access to the shared directories of my PC from the box, the windows streaming from the PC (“Play to” feature) works OK.

. The result of my experiment is that a lot of new users of this box should fall into this problem, as the update to  2.01.86 firmware is proposed by default. A fix to this problem is needed urgently. As I retrofited the firmware, I lost the TVPluzz access (French TV  yessssss).

14

Thought the Samba info was interesting, so looked at some Samba documentation:

http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/NetworkBrowsing.html#id2584634

I assume that Samba params are relevant only if your SMP is using Samba to share out a local drive.  My SMPs are not doing such sharing, and they don’t show any SMB-related ports open.  Seems pretty clearl that Samba is not running on them.  Since connecting to (remote) SMB shares is presumably done with the Linux kernel CIFS support, Samba parameters are irrelevant for me as far as I can see.

15

I Set the firmware back to 1.6.  I was at 2.01.86 and the Network Shares work just fine.  I am not updating firmware until I’m sure that it has been fully regression tested> Also I use the Media Shares workaround with DLNA software - I have Serviio installed as my DLNA server and I can also play my media (FLAC, mp3, MKV, AVI, Mp4) with the Serviio Media Shares. 

16

ncarver wrote:

I assume that Samba params are relevant only if your SMP is using Samba to share out a local drive.  My SMPs are not doing such sharing, and they don’t show any SMB-related ports open.  Seems pretty clearl that Samba is not running on them.  Since connecting to (remote) SMB shares is presumably done with the Linux kernel CIFS support, Samba parameters are irrelevant for me as far as I can see.

Not really.  The smb.conf contains both server and client configuration.

Samba is CIFS.

17

regarding cifs

cifs.ko is only used to mount the file system once it’s located

from the link above

“Samba facilitates browsing. The browsing is supported by nmbd and is also controlled by options in the smb.conf file”

anways, I roled back to 1.16.xx

while it was an idea, I guess it still don’t amount to much, as i’m finding very few changes

resolve order did not change between firmware version, it only changed between the old gen devices and the new

here’s a run down of some of the items I checked

Firmware 1.16.13
Kernel Linux SMPDEV 2.6.22.19-49-4 #4 PREEMPT Tue Jul 16 11:03:01 CST 2013 mips unknown
nmbd -V 3.5.6
smbd -V 3.5.6
smbclient -V 3.5.6
/tmp/hosts <empty>
lmhost does not exist
nsswitch.conf does not exist
smb.conf no changes
modprobe cifs CIFSMaxBufSize=64512
cat /proc/mounts \134\134192.168.1.123\134Action /tmp/media/samba/SERVER/Action cifs rw,mand,unc=\\192.168.1.123\Action,username=anonymous,posixpaths,rsize=64512,wsize=130048 0 0
cat /proc/modules cifs 317824 9 - Live 0xc017c000

Firmware 2.01.86
Kernel Linux SMPDEV 2.6.35.9-22-sigma #11 PREEMPT Thu Dec 5 16:02:07 CST 2013 mips unknown
nmbd -V 3.5.6
smbd -V 3.5.6
smbclient -V 3.5.6
/tmp/hosts <empty>
lmhost does not exist
nsswitch.conf does not exist
smb.conf no changes
modprobe cifs CIFSMaxBufSize=64512
cat /proc/mounts \134\134192.168.1.123\134Action /tmp/media/samba/SERVER/Action cifs rw,mand,relatime,unc=\\192.168.1.123\Action,username=anonymous,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.123,posixpaths,serverino,directio,nobrl,acl,rsize=64512,wsize=57344 0 0
cat /proc/modules cifs 291693 10 - Live 0xc062c000

only changes, I’m finding is a different kernel version

and different mount parameters after the smb share has been found

if anybody has other idea’s on items needing to be checked, just let me know

18

Are they still using SMBTREE binary?

If so, check to see if there’s any differences there…  

smbtree will output the discovered servers and the shares available on those servers.

19

no smbtree is does not exist on the system

smbclient does exist

smbclient -L 192.168.1.123
creating lame upcase table
creating lame lowcase table
params.c:OpenConfFile() - Unable to open configuration file "/home/release2/ARSE NAL/Arsenal_Palace_2.01.84/src/libs/../../build/binary/third_party_build/lib/smb .conf":
        No such file or directory
smbclient: Can't load /home/release2/ARSENAL/Arsenal_Palace_2.01.84/src/libs/../ ../build/binary/third_party_build/lib/smb.conf - run testparm to debug it
Enter root's password:
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.6.9]

        Sharename Type Comment
        --------- ---- -------
        print$ Disk Printer Drivers
        Action Disk Action
        Drama Disk Drama
        Scifi Disk Scifi
        Music Disk Music
        Photos Disk Photos
        Action2 Disk Action2
        Mini Disk Mini
        TVSeries Disk TVSeries
        Family Disk Family
        IPC$ IPC IPC Service (SERVER server (Samba, Ubuntu))
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.6.9]

        Server Comment
        --------- -------
        SERVER SERVER server (Samba, Ubuntu)
        RT-AC66U RT-AC66U

        Workgroup Master
        --------- -------
        WORKGROUP RT-AC66U
20

TonyPh12345 wrote:

Not really.  The smb.conf contains both server and client configuration.

 

Samba is CIFS.

smb.conf contains config info for Samba’s server and client software, such as smbclient.  The Linux kernel does not require Samba packages be installed to mount a CIFS share.  It uses cifs-utils (cifs.ko), which is technically separate from Samba and does not require Samba or smb.conf.  Here is the cifs-utils documentation:

“Unlike smbfs and smbclient, configuration for the cifs vfs does not depend on smb.conf. CIFS configuration is done using /proc (modifying pseudofiles in /proc/fs/cifs) and by specifying module install parameters (module options passed to /sbin/insmod or modprobe).”