384.12 - SMB Share name

[adrenalize]

I know I ned to try a full reset too, but coming from 384.11_2 where my SMB shares were fine, with 384.12 I couldn't access them.

Found in the logs that although the device name is RT-AC88U, the share device name seems to get set as RT-AC88U-CF30

Ive tried changing the name to something else and back etc, but it always seems to default to RT-AC88U-CF30. I can access the shares fine at this name however.

Anyone else had issues with this?

 

[ColinTaylor]

You are looking at two different things.

RT-AC88U-CF30.local is the Avahi name and RT-AC88U is the Samba name. But you have selected SMBv2 which means you can no longer browse the network and see that name.

RMerlin added WS-Discovery support in 384.12 which should allow you to see the Samba share names again, but I'm not sure it's working reliably at the moment. You'll probably have to wait for the fix to trickle down.

 

[consorts]

https://www.snbforums.com/threads/giving-router-a-unique-name-for-remote-syslog-server.48892/

 

[adrenalize]

You are looking at two different things.

RT-AC88U-CF30.local is the Avahi name and RT-AC88U is the Samba name. But you have selected SMBv2 which means you can no longer browse the network and see that name.

RMerlin added WS-Discovery support in 384.12 which should allow you to see the Samba share names again, but I'm not sure it's working reliably at the moment. You'll probably have to wait for the fix to trickle down.

OK thanks, used SMBv2 only with 384.11 and earlier also and just manually typed \\RT-AC88U\ worked fine - so would have thought this would work even with 384.12 regardless of WS-Discovery if it wasn't in earlier versions. As manually typing \\RT-AC88U-CF30\ works in Windows Explorer with 384.12 (never tried it in earlier version) is Windows 10 then resolving the avahi name?

Had seen a couple of people have trouble with WS-Discovery but some others saying their shares were fine, so will wait for a fix.

 

[ColinTaylor]

Manually typing \\RT-AC88U\ should still work provided at least one of the name resolution services can resolve that name. So assuming DNS is setup correctly it ought to have worked. From a client that is having the problem try the following command:

nslookup RT-AC88U

Also check the router's Device Name on LAN > LAN IP.

 

[adrenalize]

Yes an nslookup resolves to the routers IP and all bits including the LAN > LAN IP in the GUI say RT-AC88U. So had a delve a bit more. Doing a search across the file system for files with the text RT-AC88U-CF30 I can only find the avahi-daemon.conf (and sys log). So had a quick grab of the network traffic in a few situations.
For the 384.11_2 firmware which works with \\RT-AC88U - Theres just a straight SMB2 Tree Connect Request to \\RT-AC88U\IPC$.
On 384.12 firmware when I directly go to \\RT-AC88U-CF30 (which works fine) Theres a few LLMNR and MDSN queries and a couple of responses, then SMB session negotiation and then the SMB2 Tree connect request to \\RT-AC88U-CF30\IPC$
With the same config when I try and go to \\RT-AC88U - There is a slightly different set of LLMNR and MDNS queries and a couple of responses - the one of interest is the one that responds with a CNAME alias of RT-AC88U-CF30 and also then the router IP for the CF30 name. But then there is no attempt by Windows to start SMB session negotiation, connect request etc.

If I copy the avahi-daemon.conf file to the /jffs/configs and edit the avahi hostname to be RT-AC88U then it occasionally works directly typing \\RT-AC88U, but lot of the time Windows explorer just hangs. I don't know anything about avahi, WS-Discovery etc to know if it needs the different hostname and alias etc so removed the config override.

Happy to provide the pcaps if anyone is interested and will see if any WS-Discovery fixes come along. At least \\RT-AC88U-CF30 works in the meantime.

 

[ColinTaylor]

Just some ideas to try;

Make sure the nmbd process is running:

ps w | grep nmbd

Try killing the avahi process and analysing the traffic again. We're not interested in avahi so we don't want it interfering and confusing matters.

killall avahi-daemon

Instead of using \\RT-AC88U, try using the fully qualified domain name instead. e.g. \\RT-AC88U.home.lan (obviously changing the domain part to your own). I would expect this to work.

 

[kernol]

When having connection issues to Samba server on the AC5300 running 384.12 I have found that simply restarting the Samba service [click "Apply" again in the Webgui or use scMerlin option 6] - restores connectivity?!
Have not discovered what causes Samba to stop at times - nothing in my logs to suggest it has!

 

[adrenalize]

Just some ideas to try;

Make sure the nmbd process is running:

ps w | grep nmbd

Try killing the avahi process and analysing the traffic again. We're not interested in avahi so we don't want it interfering and confusing matters.

killall avahi-daemon

Instead of using \\RT-AC88U, try using the fully qualified domain name instead. e.g. \\RT-AC88U.home.lan (obviously changing the domain part to your own). I would expect this to work.

Aha - so may have sorted it - the FQDN worked. Killing the avahi daemon just stopped being able to reach it at \\RT-AC88U-CF30 as expected.
And probably the main reason was I hadn't bothered to set a domain before (nieve\lazy\well it just worked on previous versions!).
Setting the domain then meant that the \\RT-AC88U worked without the FQDN.

So I guess something in the WS-Discovery or other changes in 384.12 don't like not having a domain set.

Thanks for the hints and tips.

 

[ColinTaylor]

Well that's interesting.

Did you notice whether nmbd was running before you made that change?

Was/is the "netbios name" set correctly in /etc/smb.conf?

 

[adrenalize]

Sorry forgot to say, checked nmbd was running before any other changes and it was.

I'm pretty sure the netbios name in /etc/smb.conf was and still is RT-AC88U (will double check when home later).

I'm mindful that I haven't done a full reset and dirty flashed so may see if I can fit that in at some point when convenient as it's the main router. I've got a spare RT-AC68U to go in as an AP when I've got round to cabling so may have a play with that and see if I can replicate it.

 

[ColinTaylor]

Thanks for the additional info @adrenalize. As you said, it used to work prior to 384.12, so it's still a mystery what exactly has changed that would have this effect. Unfortunately I don't have a spare router I can test this firmware on.

 

[silverspr]

Hello
I can confirm I am also having a problem accessing usb shares since upgrading to 384.12. Issue resolved when rolling back to 384.11_2. I'm using RT-AC86U.

 

[Diamond67]

After installing the latest Windows 10 Cumulative Updates and after "forced" reboot of my Windows 10 Pro computers I had trouble accessing my Samba Shares again. No surprise. I have had these troubles after installing fw 384.12.

However, I have PIA VPN Client software installed into all these computers, and after activating PIA connection using the client app (after computer reboot) it kinda seems to fix the share access problem. Or at least I think so. I am not sure though. Anyway, from PIA Network Preferences I have enabled "Allow LAN Traffic". So, it must have something to do with the LAN traffic anyway, I think. And if you happen to use PIA Client software and have problems accessing your Samba Shares atm as well, you could try toggling PIA connection on/off?

Just my 2 cents or something.