nbtscan - is strictly client side ( ubuntu / debian etc. )
nmblookup - is.... samba36-client
yeah, if -H is compiled in that would work.... lmhosts ( /etc/hosts ) should be the default first option unless it is explicitly excluded in a resolve order directive or nsswitch.conf ( low level file disregard )
i've just dug a bit further into the binary.... and it does seem a little non-standard.....
/etc/init.d/samba
procd_add_mdns "smb" "tcp" "445"???
/usr/sbin/samba_multicall
saw no logs too....
me thinks she could be stripped... sadly..... 
a saw a 4 floating around.... ? 
kinda just leaves you with a L2-tap/SNAT-DNAT hack to get it working but as you mentioned, if it's production, you could buy replacement hardware for the time you'd put into that.... cool to learn from tho'
@anon50098793: You were looking at a "samba36-server" package binary, I presume? If so, then this thing might be hopeless. But another possibility might be to 'forward-port' (as opposed to back-port) a Samba2 package and build it to work with OpenWRT18. BTW, the multi-call build (with attendant symlinks for smbd and nmbd) has been the case for awhile now, so that doesn't immediately get me concerned.
1 Like
@anon50098793: One other thing: I have run netstat -an to see what ports are getting connected, and I do see ports 137-139 and 445 connected, so it can't be all that stripped unless its just dropping packets in ports 137-139.
Also, I don't see the "procd_add_mdns" line you mention as being in /etc/init.d/samba on my installation -- are you looking at a snapshot? I'm using the 18.06.1 release build, not a snapshot.
So.......................
[SLAPS-FOREHEAD-OF-SELF] 
I think we need to redefine your question......
I pull down the sources today..... thinking I will take a quick peek into what was and was not included.... how it's compiled etc..... Didn't take very long and my old days cam rushing back to me 
When I was in college, one of my "triumph's" was running our "domain" file services in a linux box running samba.... i think i ended up using mandrake.... or redhat 8.... man linux was prettier back then.... less bufferbloat 
Anyways the final result was cool, when you walked up to the linux box, you'd get a graphical login screen listing the DOMAIN\usernames ......
Soooooo....... what i'm getting at is that all of a sudden a huge piece of this equation comes rushing back to me.....
PAM, nss, winbind............ NETLOGON???
hint hint -
@anon50098793: I'm wondering if I should apologize for putting you through that! Unfortunately, we're not running a Windows Domain here (so no PDC, and we don't want to configure Samba to do that, either) -- just a geographically distributed Windows Workgroup. Strictly speaking, this is something Microsoft frowns upon, but it is facilitated by using Samba, just without configuring Samba to be an AD PDC.
Packet capture with Tcpdump will have to wait for the weekend, but today I collected another morsel of information: I configured a tired old Netgear WNR3500L with DD-WRT (SVN 15508M running Samba 2), and I was able to get a browse list from the DMB (Linksys WRT1200AC running OpenWRT 18) using substantially the same smb.conf on my remote LMB side. So that disparity in behavior is pointing to a possible problem in how the Samba3 remote LMBs are operating in OpenWRT.
Let me be more specific,
In order for samba to "step-up" from a "LOCAL NETBIOS BROWSE LIST" integrator, to a "DISTRIBUTED WINS" player.... it is going to need authorization / authentication.
In a typical environment, pre AD/DNS, NETLOGON / IPC are a necessity to support the RPC calls that authenticate the machine to machine record exchange.
In samba winbindd does that.... it looks like it's not compiled in.....
You could try.....
./feeds/base/package/network/services/samba36/Makefile
But for the pain that it would cause, using mdns relay, or other hacks seem much simpler....
@anon50098793: Ah, dangit, now you've done it: I'm going to have to put together a build system! I was hoping to avoid doing that. But it sounds like the function you've honed in on might well be the missing piece. Are you peering right into the binaries here (i.e. you don't also need the run-time environment for your sleuthing)? If so, would you be willing to take a peek into the binary for the Samba server from DD-WRT that I've been using to see if it has that function? I have a setup where I can use PuTTy/WinSCP to get into the router and I can pull any file out of it that I want.
Windbindd is a build option for the samba4 package.
1 Like
I wonder if this isn't the way to go, using something like smcroute on the routers you could join all the locations together as far as MDNS and WSD goes. This might have benefits beyond browsing. I think it's probably just a few lines of config on smcroute.
It's good that it's a compile option, but why was it removed in the first place? We know what Microsoft has planned, but until the legacy form of network discovery is impossible on Windows platforms, doesn't it make sense to keep all the functionality in place to make it work? And if you don't want it, you simply don't enable it in your smb.conf? I'd like to hear the rationale for removing winbindd from the build, if there is one. Andy, you're not maintaining the samba36-server package, are you?
That's correct, i maintain the samba4 package.
You have to keep in mind that the goal for samba in openWRT was to get a stable and small fileserver to work on as many devices as possible. This was possible by basically disabling all other functions except the fileserver. The big problem is size here, samba36 is around 1.8 MB, while the smallest samba4 config is around 4 MB. Many of the extra samba build option's add extra dependencies that in turn also increase size, so until most routers have 32-64 MB flash size, doing a full default build is problematic.
3 Likes
I figured package size might have something to do with it. But available flash isn't a problem on the WRT1200AC, which has 128 Mbytes. So maybe the thing to do is create a "sambaXX-server-full-legacy" package that builds in the kitchen sink in the compile options, and make it available as a package that can be optionally installed but is not bundled into the install images... A similar thing was done on dnsmasq, where dnsmasq-full includes DNSSEC but the smaller build that gets included in install images does not include that function.
Aside from "tactical" package build options, I wonder if the time hasn't come for Samba to be "strategically" split into two packages -- network-wide browsing discovery support vs. on-device share discovery and access support. Samba4's build direction presently seems to support only the on-device functions while completely omitting the other piece.
It seems like network wide discovery is moving to a multicast WSD mode and this isn't actually specific to SMB/shares, so it makes sense that in a WSD world the discovery is taken care of by something entirely else like wsdd.
The devices / services you're advertising, are they running samba, or are they running windows. I'm not clear on which case you're in:
- Samba servers on several subnets need to all be visible in network neighborhood
- Windows devices are advertising themselves and need to be available on all subnets
- A mix of samba servers and windows devices are advertising themselves and all need to be available on all subnets
Can you clarify? Because if it's only windows devices that are advertising, it seems like you can multicast forward their advertisements and voila everyone's browsable. If its samba services, then it seems you can install wsdd (https://github.com/christgau/wsdd) on the servers and do multicast forwarding and voila browseable.
The only issue is if you're doing something like having ancient Windows XP devices still doing SMB1 mixed in.
1 Like
@dlakelan: The "Samba servers" are not advertising anything that network users need -- other than the browse list functionality that is now broken. Their job is to function as Local Master Browsers (in the case of the remote network subnets) and a Domain Master Browser and WINS server (in the case of the main local network subnet). Since Microsoft is on a path to completely deprecate SMBv1/NetBIOS/WINS, we'll migrate away from that in due course. The problem is that network browsing using Samba in this fashion was available in the old router infrastructure and it's not now, and that's annoying.
Yes I understand this, but wasn't clear if there were any additional samba services say running on PCs at each site.
As I see it, with only Windows devices actually offering services at each site, you should already have each subnet being advertised by the WSD method, and in addition they may be talking to your samba local master browser on each router.
So you have two options, one is to continue to bang on Samba to support this legacy discovery mechanism, and the other is to install the very tiny smcroute daemon on the routers and route the existing multicast WSD advertisements between your sites, uninstall samba on the routers and rejoice.
The only issue would be that any samba PCs at each site are not advertising by WSD because samba doesn't do that yet. But it seems you don't have that case
@dlakelan: I did fail to mention that there are two NAS servers running NAS4free (the rest are Windows PCs), and right now those are well-integrated into the Windows Network Browsing infrastructure.
FOSS is a wonderful thing, but it's not so wonderful when decisions are made to deprecate features that people are presently using, even if it's a Microsoft direction. The right thing to do is make the function available, even if it has to be in a separate package that must be installed (in the case of executable size bloat). As things stand, we're going to be scrambling to restore the function either way.
So for those NAS devices it seems wsdd would advertise them for you.
I recognize this is a different direction and has some risks involved but it doesn't seem like it would be hard to try the WSD routing and advertising and roll it back if it caused problems. Wsdd can be started up without changing any samba settings on your NAS and smcroute can be spun up for testing and taken back down pretty easily.
@dlakelan: It's not so much a different direction -- we know Microsoft will force the issue at some point -- it's just not something we expected to have to immediately tackle at the same time as this migration of router hardware and firmware (from Netgear WNR3500L's running DD-WRT to Linksys WRT1200AC's running OpenWRT 18).
Well, if you want to give it a spin and can provide a simple high level network diagram, I'd be willing to try to suggest settings for smcroute.