VLANs and subnets and SMB1 oh my
-
@johnpoz
Windows 95 computers aren't joined to our domain, there is no FQDN. I can assign them a name in DNS and use that, but it makes absolutely no difference. -
Joining to a "domain" has nothing to do with a fqdn..
Windows 95 machines understand dns just fine ;)
L2 discovery doesn't work when your not on the same L2.. Be it broadcast, multicast, LLDP, WSD.. etc.. If you want to maintain old school OSes like that - then setup WINS ;) for them to resolve netbios names across vlans. Thats how it was done before ;) Getting rid of that crap that was was wins was the best thing ever! Gawd that was a mess to maintain across multiple sites..
Or just use dns to resolve what you want via a fqdn. Or just use the IP ;)
-
@johnpoz
Ok, so I have a workgroup computer named XYZ. What is it's FQDN? It doesn't really have one. Again, I can put an A record on my DNS server and use the name instead of an IP, but it resolves NOTHING. What does the FQDN have to do with the inability to connect to an SMBv1 share from another subnet?"Or just use the IP"
What do you think we're doing? How else would I be accessing it?
-
@dlogan said in VLANs and subnets and SMB1 oh my:
What is it's FQDN?
Whatever you want to be!! Use the same thing your AD is using.
You resolving a name to an IP has zero to do with SMB be it 1, 2 or 3.. But no you can not use discovery across vlans.. your windows 95 box isn't going to be able to broadcast for server, and expect an answer because that doesn't cross L2..
-
@johnpoz
So we've established that I can make an A record and use the name and it doesn't do anything, so I don't think FQDN has anything to do with this issue. -
What issue? You say it works when you use IP.. So your problem is name resolution.. And again old L2 discovery methods do not work across vlans... Look up that up in the old MS docs - they had you run wins.. to resolve the host name to the ip.
-
@johnpoz said in VLANs and subnets and SMB1 oh my:
me to an IP has zero to d
No I did not say it works by IP, I've been using IP since the beginning.
-
Well then open the ports on the firewall.. No old school OSes like windows 95 do not use the 445 port.. They used old school 137-139 ports for file sharing.. ie smb..
TCP 137 - SMB over TCP port (via NetBIOS).
UDP 137 - SMB over UDP port (via NetBIOS).
UDP 138 - SMB over UDP port (via NetBIOS).
TCP 139 - SMB over TCP port (via NetBIOS). -
@johnpoz
Nope. All open. Did you read the part where I put my laptop in vlan 111 and it works? But the 2019 server on my ESXi host doesn't? Then it suddenly works when I put a 2nd interface on the VM in vlan 110 but the SMB traffic isn't going out the 110 inteface, it's going out the 111 interface? -
This comes down to resolving name, and access.. Doesn't matter if smbv1,2 or 3..
Then a SYN on 139, which usually gets a SYN ACK.
If you get a syn ack.. You started the conversation and got an answer.
-
@johnpoz said in VLANs and subnets and SMB1 oh my:
You started the conversation and got an answer.
I agree. But the SMB session is never negotiated. On the 2019 VM there's a FIN ACK and nothing happens. On my 10 machine I see the SMB handshaking and the folder opens.
-
@dlogan said in VLANs and subnets and SMB1 oh my:
FIN ACK and nothing happens
That is closing the conversation.
-
@johnpoz
Again, I agree. But why does the 2019 server close the connection and the Windows 10 machine continues on the the SMB protocol? -
You will have to ask windows why it closes the conversation.. Did you auth? I am on a work call currently - but I could fire up smb1 and show it working.. but if the server sends a FIN, it is closing the conversation..
Can you post your sniff from your client, and then a sniff from the server at the same time will show you if any traffic is not passing the firewall.
-
It looks to me like the client side (the Server 2019 VM) is closing the connection. The FIN is sent from the client to the server.
Where's a good place to upload the captures and link them here.
The server side (Win 95 machine) is going to be difficult. I can't install anything on it. I might have to setup a mirror on my switch and get the packets from there.
-
Ok, 1st capture, after a reboot, only 1 nic is enabled on the Server 2019 VM. I start a capture to host 10.10.10.12 and attempt opening the folder using \\10.10.10.12\002\ it fails: trackhound-to-002-nic1-vlan111-during-fail.pcapng
2nd capture on the same interface, after enabling a 2nd NIC with IP 10.10.10.2 in the same VLAN as the 10.10.10.12 machine. This time the connection to \\10.10.10.12\002\ is successful: trackhound-to-002-nic1-vlan111-during-success-after-enabling-nic2.pcapng
Another capture going on at the same time as the success but capturing all traffic on the 2nd NIC: trackhound-nic2-vlan110-during-success.pcapng
-
Your seeing error called name not present..
Yeah that is going to be problem..
https://osqa-ask.wireshark.org/questions/53776/what-does-called-name-not-present-mean
In the 2nd one your never doing a session request.. I just see NBNS in there - your trying to just get a browse list?
Your problem is the server doesn't know who you are, and says that - so the client says thanks and sends FIN.. Its just sending a generic name SMBSERV as its name..
edit: I haven't played with the limitation of windows 95 in years and years.. Its time for a martini - work call ran way longer than the 30 mins scheduled.. Customer going down the qos rabbit hole ;) If I find some time I might fire up a 95/8 vm.. But a google for that specific error will give you the details of the problem.
-
@johnpoz
I thought you might be interested to hear that some computers work while others do not. As far as I can tell it's based on the NIC / NIC driver installed.After your suggestion here, I started paying more attention to the Netbios messages in Wireshark for both connections that work and those that don't.
It seems they all fail with their initial attempt, always geting the "called name not present" message.
The ones that fail pretty much stop there.
The ones that successfully connect follow up the "called name not present" with an nbtstat.
So I pop open cmd prompt and run nbtstat -A 10.10.10.12. It's successful on machines where it connects.
On machines that won't connect, not only does it "fail" but not one single packet is sent out the network interface when the command is entered. It literally fails without trying.
So far:
-
My MacBook running Windows 10 in Bootcamp with a Broadcom 802.11ac wifi card (2020 Broadcom driver) -- works
-
My Dell laptop with docking station ethernet Realtek USB 2020 Realtek driver -- works
-
Old Dell Precision workstation with onboard Broadcom NetExtreme -- fail
-
Same old Dell Precision workstation with a PCI Intel Pro 1000 GT with 2010 Microsoft driver -- works
-
Dell Optiplex with onboard Realtek - fail
-
Same Dell Optiplex with Intel PCIe CT desktop adapter with 2018 Intel driver -- fail
-
Intel NUC with onboard i219-v network card 2020 Intel drivers -- works
-
HP Elitedesk 600 G1 with onboard Intel i217-LM and 2020 Intel drivers -- fail
I wish I could figure out what kind of PCIe network card I could buy that would work.
-
-
the network nic shouldn't matter at all..
What is the output of the command.. the command runs... What OS are you running that command on..
-
@johnpoz But it does. Same machine, same IP address, same VLAN, different NIC and it starts working.
When it's not working, it says "Host not found"
When it is working it outputs:
Ethernet 2:
Node IpAddress: [10.10.101.101] Scope Id: []NetBIOS Remote Machine Name Table Name Type Status --------------------------------------------- MAZATROL640M <00> UNIQUE Registered WORKGROUP <00> GROUP Registered MAZATROL640M <03> UNIQUE Registered MAZATROL640M <20> UNIQUE Registered WORKGROUP <1E> GROUP Registered MAC Address = 00-E0-98-83-33-26
