VLC player sees two SMB servers

I don't know if this was mentioned before on the forums and my search didn't turn up anything.

This is for 3 routers; Slate AX, Beryl AX and Flint 2. Firmware 4.8.6.
Flint 2, firmware 4.6.6 op24.

I have a VLC player running on Apple TV 4K and it sees 2 SMB servers, each one is exact copy of each other. Only Samba is enabled under File Services.



have same, slate ax

Without investigating it further, I would say it is either Hostname and IP or 2,4GHz/5GHz.
The service (smb) is per default bind to 0.0.0.0 (or any), so it will listen to all available ports.
If the router provides the connection to the services over multiple ways or routes, the client sees two ways for the same endpoint.

I don't think this is an issue in functionality.

1 Like

I don't know how GL SDK and Apple TV communicate, but maybe due to redundant discovery protocols or so. Many protocols and multiple ports are involved for "Samba" sharing. e.g., mDNS, SSDP, WINS, SMB, CIFS, etc... So several scenarios are possible.

Whatever the cause, both will connect to the same destination. Just consider them as two identical shortcuts.

Probably you won't get some clear response from either GL.iNet or Apple, but if you're curious, try investigate with Wireshark or so.

Its none of the above. When using Asus router it only shows "one" samba server in a VLC player.

It is an issue that is being caused by GL routers, 3 GL routers in this case. Even when Apple TV is connected via LAN cable directly to GL router, it still shows 2 SMB servers. So yes, its a GLinet problem.

Could be mDNS or IPv4 + IPv6

But it's not any problem at all, just some inconvenience.

I don't use ipv6. Im not aware of using mDNS, settings in the router are as vanilla as it gets. Adguard is enabled, but even if I disable it two Sambas still show up.

Only 4 settings that are enabled:

Adguard.
Samba with a hard drive attached to USB.
HD idle.
Transmission for torrening.

Its not causing any issues, just my OCD annoying me. Would be great if it could be fixed in the next firmware update.

So yes, its a GLinet problem.

There's possibility that some GL.iNet part causing it, but I don't agree that it is or could be a "problem" in any way. Moreover I can't find any reasonable technical reason even if assume that everything you said is true.

Im not aware of using mDNS,

It's not a kind of thing that used only when you explicitly try to use it. So since you don't know what the mDNS is, I think your assumptions may likely meaningless.

just my OCD annoying me.

That's exactly why I said like the above. You will find exactly what the cause is, even if you can't solve the problem yourself. Then if you ask more specifically, you'll have more chances to get some help.

Personally I empathize with you as I too sometimes care about minor annoyances that not harmful at all. But please do note that you usually won't get any closer answer you want, especially when there's no realistic problem and ask technically vague issue.

Nice discussion of whose fault it is. But would we go back to the technical part?

The Samba service is provided at the router. I have only a Slate Plus at hand, but lets narrow it down.

at first we need to log in into the router via ssh:

ssh root@192.168.8.1

And type in the admin panel login password.

From the samba documentation we know the configuration is placed in /etc/samba/smb.conf and we know the multiplying factor is anything with interface, so we search what is the regarding configuration:

root@GL-A1300:~# grep interface /etc/samba/smb.conf
        interfaces = lo br-lan 
        ## This global parameter allows the Samba admin to limit what interfaces on a machine will serve SMB requests.
        #bind interfaces only = yes
root@GL-A1300:~# 

lo won't be routed outside the device, so lets focus on br-lan.

root@GL-A1300:~# brctl show br-lan
bridge name     bridge id               STP enabled     interfaces
br-lan          7fff.<some number>       no              eth0
                                                        wlan0-1
                                                        wlan1

We try to understand. The samba service is started, and listening on the network bridge br-lan. br-lan is split to 3 physical devices, eth0, wlan0-1 and wlan1.
eth0 is the LAN port, wlan0-1 and wlan1 are 2,4GHz and 5GHz WLAN.

We go back to the very beginning of your question:

I think, if your NAS router is connected to a main router, within your home network, the IP 192.168.8.1 is reachable from LAN (eth0) and WLAN (wlan0-1 and wlan1).

In my test setup with only the Slate Plus, I don't see two devices. But the laptop is connected via LAN and the Internet is in repeater mode via 2,4GHz WLAN. It is a typical travel setup, not a home setup.
Even with IPv6 I have only one reachable device. I know this was not the case here, but I wanted to have this tested, because of:

root@GL-A1300:~# netstat -tulpen | grep -i smb
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      31295/smbd
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      31295/smbd
tcp        0      0 :::139                  :::*                    LISTEN      31295/smbd
tcp        0      0 :::445                  :::*                    LISTEN      31295/smbd

A possible OCD friendly solution would be to change the /etc/samba/smb.conf to interface = eth0. But this will be overwritten by next firmware update. And this is definitely a very particular change, not recommended to set up in general for all users by GL-iNet.
When I have a free which, I would like to change the workgroup = WORKGROUP setting via Admin Panel and persistent.

By reading your netstat I would assume that the reason is that port 139 (SMB1, NETBIOS) and port 445 (SMB2+3) is used. So setting the interface shouldn't fix it.

1 Like

Okay, I have not seen this. But that's the reason why one should always add the details.

I thought a Mac VLC is the same intelligent as my Linux VLC and ignores the insecure SMBv1. But it sounds reasonable.

Short answer is: NO.

No, there was no nice discussion, and again, no, your suggestion don't help at all.

I guarantee that just set /etc/samba/smb.conf to interface = eth0 will cause problem.

If it were that easy, I would already gave the answer.

The whole samba config should be rewritten to ensure that the newest standards are used.
I am pretty sure that a good samba config (no, the one out of the box isn't good) will solve all issues.

Could you explain to me why you'll give this guarantee?
I am fully aware, that in this specific setup this maybe can help to bind the routing, in other setups it could make the service unavailable over WLAN.
Just roll the change back, and everything is as before, no harm no problem. Just a wrong assumption and dead end testing.

But I like the approach from @admon:
We could test a turn off SMBv1 and after confirming, make a qualified feature request to GL.iNet.
I am on the road now and could not read the smb config to give further instructions right now. Depending on the traffic, maybe in 5 hours.

The issue has nothing to do with NAS, because I do not use NAS and I don't have a NAS.

If you guarantee issues with my idea, I want to know what I have not considered. I think this is a valid request after such a hard statement. Just accuse others of writing nonsense is easy.

In fact, I tried my solution, and it does not do anything. Because the service needs to be restarted and the /etc/samba/smb.conf is rewritten, see /etc/init.d/samba4 line 49.
Lets put this together: My idea caused no problem as you guaranteed. Your result was at least as wrong as my assumptions.

Back to topic:

I've played a little around, and still don't see where the device is split in two.

โ””โ”€$ nmap -sV --script=banner 192.168.8.1
[...]
139/tcp  open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp  open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
[...]
โ””โ”€$ nbtscan 192.168.8.1     
Doing NBT name scan for addresses from 192.168.8.1

IP address       NetBIOS Name     Server    User             MAC address      
------------------------------------------------------------------------------
192.168.8.1      GL-A1300         <server>  GL-A1300         00:00:00:00:00:00
โ””โ”€$ nmblookup -S WORKGROUP
192.168.8.1 WORKGROUP<00>
Looking up status of 192.168.8.1
        GL-A1300        <00> -         B <ACTIVE> 
        GL-A1300        <03> -         B <ACTIVE> 
        GL-A1300        <20> -         B <ACTIVE> 
        ..__MSBROWSE__. <01> - <GROUP> B <ACTIVE> 
        WORKGROUP       <00> - <GROUP> B <ACTIVE> 
        WORKGROUP       <1b> -         B <ACTIVE> 
        WORKGROUP       <1d> -         B <ACTIVE> 
        WORKGROUP       <1e> - <GROUP> B <ACTIVE> 

        MAC Address = 00-00-00-00-00-00

I am done here, and I would say the behavior is caused by the network management of the AppleTV, not at the GL.iNet side.

NAS is short for 'Network Attached Storage'.
The Samba service is providing a locally attached storage the the connected network.

For GL.iNet the configuration for samba is partially found under /etc/gl_nas/nas_samba4.
Even if you don't use a local NAS device in your network, this is totally fitting as wording, discussing your question.

I am not an expert in VLC, but since it is an open development, I peeked.

This is an older issue and related to VLC-iOS. But because in this issue is mentioned, that described behavior should be fixed in VLC-core and there is no hint of anything has done, I have two theories:

  1. You need to update your VLC client. I don't know the version, so it is just an assumption.
  2. The issue is not fixed from VLC. But it is written that it is a known issue, and caused by lack of filtering, not caused by the smb server.

If the Asus router shows at one device, it may or may not does not provide the same compatibility as GL.iNet. We can't say.

Again, this is a firmware issue. If I have to type in commands in to SSH, then it should be resolved in the firmware from the get-go. I have two Asus routers and I even test drove a new Asus EBR63 router and it doesn't show 2 Samba servers, but it does with GL routers.

It's fine for me.
I've tried to analyse it remote, because I can't reproduce this firmware issue at my side.

But as everyone here knows more than me, my thoughts are not needed.
Sorry to bother you. Good luck with solving the issue.

1 Like