Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 6 subscribers
  • Views 3235 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Annoying NetBios from latest Windows 10 build

SalishSwede

Microsoft tries to hide it's persistent use of antiquated technologies.  In this instance I'm talking about NetBios.

Using Microsoft tools: Resource Monitor, there appears to be no use of NetBios port 137

Using any other tool, it's clear it's in use.  That's annoying.

As far as I know, the use of this port was deprecated since Windows 2000.  I thought they started using 443 for this.

I'm still showing this traffic coming from my main workstation despite turning off all forms of network discovery and sharing at the network driver level.

 

This is trivial, but can anyone help me kill this traffic from within Windows?

 

Thanks,

Doug



This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to Keyur

    Hi

    Just a quick note (in case this is of interest to anybody reading this thread) and relating to the last link (the Microsoft one; see the note that Microsoft have included about DHCP configuration) I use DHCP option 43 to configure all my Windows machines to disable NetBIOS over TCP/IP, so the Windows machines are now showing the below configuration:

    ipconfig /all

    ---cut---
       DNS Servers . . . . . . . . . . . : 10.11.11.1
       NetBIOS over Tcpip. . . . . . . . : Disabled

    As can be seen below, the required hex string is 01:04:00:00:00:02 (just typed that so it can be swiftly copied and pasted).

    Kind regards to all,

    Briain

    PS An amusing footnote:

    Or course, I must also confess that when I initially created the rule, all seemed to be working just as expected until one day, a Ubiquiti WAP firmware update resulted in my WAPs no longer being discoverable by the UniFi 'server' package (the Ubiquiti management software). After SSH-ing into the WAP and looking at its [now bizarre] configuration, I eventually figured out that the WAP must have been responding to that DHCP option 43 and misinterpreting its hex string (it was overriding the default setting on where it should 'look' for the wireless server). After digging into the Ubiquiti web site, I found that one can indeed also use vendor specific DHCP option 43 to define the address at which the wireless server resides (I believe that you can also do that with Cisco WAPs) and after looking once again at my option, I realised that I foolishly hadn't configured the vendor ID aspect of it (it should be set as MSFT 5.0 - just as is shown in the above image - to ensure that only the Windows machines attempt to interpret the hex string). With my initial misconfiguration, everything on my network was capable of being configured by my 'global' option 43 (but fortunately, only the WAP - and that only after an update - and Windows boxes were actually 'listening' for it) and once it was all set up as is shown in the above image, all was then well again (oops; oh well, I've always reckoned that the best way to learn is to break things and then figure out how to fix them). :-)

  • 0 in reply to Briain

     Thanks Brian,

    I'll give that a try.

Unfiltered HTML