NBNS Protocol overloading a vlan

asked 2020-03-09 13:46:15 +0000

updated 2020-03-10 18:05:54 +0000

Guy Harris
19890 ●3 ●659 ●207

Hello, First time posting here, I apologize if I screw it up.

We are seeing random 'NetBIOS Name Service' (WINs) broadcasts (1-3 times a day at random times) going across a vlan. This traffic overloads the vlan and our phone system goes down as a result due to heartbeat timers expiring between devices.

Here is an example:

15641   2020-03-09 08:01:12.435091  169.254.175.195 169.254.255.255 NBNS    110 Registration NB OH101289<20>

Frame 15641: 110 bytes on wire (880 bits), 110 bytes captured (880 bits) on interface \Device\NPF_{4CB19F40-9878-4814-8D24-F2CF192BBA0D}, id 0
    Interface id: 0 (\Device\NPF_{4CB19F40-9878-4814-8D24-F2CF192BBA0D})
    Encapsulation type: Ethernet (1)
    Arrival Time: Mar  9, 2020 08:01:12.435091000 Eastern Daylight Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1583755272.435091000 seconds
    [Time delta from previous captured frame: 0.000080000 seconds]
    [Time delta from previous displayed frame: 0.000080000 seconds]
    [Time since reference or first frame: 2226.259421000 seconds]
    Frame Number: 15641
    Frame Length: 110 bytes (880 bits)
    Capture Length: 110 bytes (880 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:udp:nbns]
    [Coloring Rule Name: SMB]
    [Coloring Rule String: smb || nbss || nbns || netbios]

Ethernet II, Src: Watlow_00:2a:0f (00:03:aa:00:2a:0f), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
    Source: Watlow_00:2a:0f (00:03:aa:00:2a:0f)
    Type: IPv4 (0x0800)

Internet Protocol Version 4, Src: 169.254.175.195, Dst: 169.254.255.255
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 96
    Identification: 0xc40d (50189)
    Flags: 0x0000
    ...0 0000 0000 0000 = Fragment offset: 0
    Time to live: 48
    Protocol: UDP (17)
    Header checksum: 0xc2bf [validation disabled]
    [Header checksum status: Unverified]
    Source: 169.254.175.195
    Destination: 169.254.255.255

User Datagram Protocol, Src Port: 137, Dst Port: 137
    Source Port: 137
    Destination Port: 137
    Length: 76
    Checksum: 0x8e6e [unverified]
    [Checksum Status: Unverified]
    [Stream index: 335]
    [Timestamps]

NetBIOS Name Service
    Transaction ID: 0xd4c8
    Flags: 0x2910, Opcode: Registration, Recursion desired, Broadcast
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 1
    Queries
        OH101289<20>: type NB, class IN
    Additional records

It looks like the source device is in Ethernet II field and is named "Watlow_MAC Address" and the target being Queried is a workstation on our network named "OH101289".

Does this sound correct in my source/destination assumption? I am unsure as to why the source device would be targeting the destination workstation as I assumed this was a UDP broadcast?

Any help would be appreciated.

Thanks

edit retag flag offensive close merge delete

Comments

Do you have these devices in your network: https://www.watlow.com/Home
Is the owner/user of OH101289 testing a new device?

The Packet List line at the top shows a 169.254 like the device didn't get a good config at startup:
https://packetlife.net/blog/2008/sep/...

Chuckc ( 2020-03-09 14:03:00 +0000 )edit

Hi, Thanks for your response.

Yes, that manufacturer is correct.

No, we are unaware of anyone testing this type of device as it has been installed into the production network for quite some time. I will double check if I can find the owner.

Yea, the 169.###.###.### addresses are confusing me as I thought the www.watlow.com devices are just manufacturing PLC devices that are not running a Windows OS? The source has a static internal IP address on the vlan in question e.g. 172.21.8.### and then the source IP seems to change to the 169.### addressing?

Thanks

NoNotTheSquirrelsAgain ( 2020-03-09 14:30:42 +0000 )edit

[Protocols in frame: eth:ethertype:ip:udp:nbns]

The frame section says IP and UDP were present but that data not in the copy/paste of the packet data.
Can you share a pcap of the packet or a screen shot showing the packet details area in Wireshark?

Chuckc ( 2020-03-09 20:03:06 +0000 )edit

Do you mean the field at the bottom of the three windows?

0000 ff ff ff ff ff ff 00 03 aa 00 2a 0f 08 00 45 00 ..........*...E. 0010 00 60 c4 0d 00 00 30 11 c2 bf a9 fe af c3 a9 fe .....0......... 0020 ff ff 00 89 00 89 00 4c 8e 6e d4 c8 29 10 00 01 .......L.n..)... 0030 00 00 00 00 00 01 20 45 50 45 49 44 42 44 41 44 ...... EPEIDBDAD 0040 42 44 43 44 49 44 4a 43 41 43 41 43 41 43 41 43 BDCDIDJCACACACAC 0050 41 43 41 43 41 43 41 00 00 20 00 01 c0 0c 00 20 ACACACA.. ..... 0060 00 01 00 04 93 e0 00 06 60 00 a9 fe af c3 .............

NoNotTheSquirrelsAgain ( 2020-03-09 20:13:12 +0000 )edit

The packet details are the center section in this screen example:
https://www.wireshark.org/docs/wsug_h...

Chuckc ( 2020-03-09 20:39:08 +0000 )edit

see more comments

2 Answers

Sort by » oldest newest most voted

answered 2020-03-09 18:31:33 +0000

Eddi

2379 ●8 ●48 ●59

Hello NoNotTheSquirrelsAgain - And welcome to ask.wireshark.org

My answer is based on the assumption, that the packet was delivered through UDP port 137. This is a somewhat educated guess, since your question did not include the IP or UDP headers.

The message is a NetBIOS registration. To me, this packet indicates a number of problems:

Missing IP configuration or missing DHCP server

IP addresses are either configured by the administrator or dynamically assigned through a DHCP server. If the host does not receive an address through DHCP it will revert to an APIPA address (= Automatic Private IP Address). This address is randomly chosen from the address block 169.254.x.x. This network block is usually not routed.

Use of SMB v1

The message shown in your post only makes sense in the world of SMB v1. This protocol is now deprecated. Microsoft recommends for a number of years to deactivate the old version. One of many web pages listing that recommendation is on TechNet

Please stop using SMB v1.

What the message is about

SMB v1 is based on NetBIOS and uses very old mechanisms to translate a hostname like OH101289 to a network address. Back in the days this could even be a MAC address, since NetBIOS could (and did) run without IP support. Today only the oldest of printers still support NetBIOS over Ethernet or IPX.

In the world of NetBIOS each host has to register it's name on the network. This is done through host announcements, like the one quoted in your question. Typically a host would call out it's name 3 times, often with a 1 second interval. If no other host objects the sender can safely assume that this name is unique and available and continue normal operations. Other hosts can use the NetBIOS Name Resolution, running on UDP port 137 to translate this hostname into an IP address.

Please note, that the broadcast messages will continue, even if you assign an IP address to your Watlow devices. The broadcasts are part of SMB v1.

Fixing the broadcasts

I highly recommend turning off SMB v1. Use SMB v2 or v3 if possible. Or switch to a completely different protocol to exchange files.

Depending on the number of nodes and the size of your network you might want to consider isolating all Watlow devices into a separate VLAN.

Or - considering that the lack of a DHCP assigned address - unplug them. Please remember, that your regular hosts cannot communicate with the 169.254.x.x addresses anyway.

Good luck!

Eddi

edit flag offensive delete link

Comments

Many thanks. SMB v1 is hurting us elsewhere by some legacy app that we are trying to get rid of.

NoNotTheSquirrelsAgain ( 2020-03-09 18:52:11 +0000 )edit

add a comment

answered 2020-03-09 19:10:45 +0000

Guy Harris
19890 ●3 ●659 ●207

I thought the www.watlow.com devices are just manufacturing PLC devices that are not running a Windows OS?

1) Not everything that does SMB is running Windows. It was originally for DOS, OS/2, and Unix, and there are both SMB clients (various flavors of smbfs/cifsfs) and servers (Samba, Apple's SMBX, etc.) that run on various flavors of UN*X.

2) Watlow's F4T Setup and Operations User's Guide says, on page 31, "Samba, also known as Server Message Block (SMB)/Common Internet File System (CIFS), is fully supported by Windows File Sharing. Within this document, SMB/CIFS will be referred to as Samba." and discusses the F4T's support for SMB. ("Samba" isn't another name for SMB; "Samba" is the name of a free-software SMB server program.)

So those devices may well be doing SMB1 and using NetBIOS-over-TCP.

edit flag offensive delete link

add a comment