Uploaded image for project: 'FreeNAS / TrueNAS'
  1. FreeNAS / TrueNAS
  2. NAS-107293

nmbd service possible race condition

    XMLWordPrintable

    Details

      Description

      Greetings -

      Recently upgraded to 11.3-RELEASE-p11 from 11

      It appears as if nmbd service has a race condition where a network discovery packet is set before networking is available.
      As a result, SMB is available via direct IP, however the "Windows Discovery" system doesnt work, or if clients refernce the netbios name, it doesnt resolve/register.

      Within /var/log/samba4/log.nmbd

      # cat /var/log/samba4/log.nmbd
      [2020/08/19 20:39:53.637177,  0] ../../source3/nmbd/nmbd.c:906(main)
        nmbd version 4.10.16 started.
        Copyright Andrew Tridgell and the Samba Team 1992-2019
      [2020/08/19 20:39:53.643770,  0] ../../source3/libsmb/nmblib.c:924(send_udp)
        Packet send failed to 192.168.1.255(137) ERRNO=No route to host
      [2020/08/19 20:39:53.643800,  0] ../../source3/nmbd/nmbd_packets.c:180(send_netbios_packet)
        send_netbios_packet: send_packet() to IP 192.168.1.255 port 137 failed
      [2020/08/19 20:39:53.643809,  0] ../../source3/nmbd/nmbd_nameregister.c:582(register_name)
        register_name: Failed to send packet trying to register name NASSERVER<20>
      [2020/08/19 20:39:53.643821,  0] ../../source3/libsmb/nmblib.c:924(send_udp)
        Packet send failed to 192.168.1.255(137) ERRNO=No route to host
      [2020/08/19 20:39:53.643830,  0] ../../source3/nmbd/nmbd_packets.c:180(send_netbios_packet)
        send_netbios_packet: send_packet() to IP 192.168.1.255 port 137 failed
      [2020/08/19 20:39:53.643837,  0] ../../source3/nmbd/nmbd_nameregister.c:582(register_name)
        register_name: Failed to send packet trying to register name NASSERVER<03>
      [2020/08/19 20:39:53.643848,  0] ../../source3/libsmb/nmblib.c:924(send_udp)
        Packet send failed to 192.168.1.255(137) ERRNO=No route to host
      [2020/08/19 20:39:53.643854,  0] ../../source3/nmbd/nmbd_packets.c:180(send_netbios_packet)
        send_netbios_packet: send_packet() to IP 192.168.1.255 port 137 failed
      [2020/08/19 20:39:53.643861,  0] ../../source3/nmbd/nmbd_nameregister.c:582(register_name)
        register_name: Failed to send packet trying to register name NASSERVER<00>
      [2020/08/19 20:39:53.643872,  0] ../../source3/libsmb/nmblib.c:924(send_udp)
        Packet send failed to 192.168.1.255(137) ERRNO=No route to host
      [2020/08/19 20:39:53.643879,  0] ../../source3/nmbd/nmbd_packets.c:180(send_netbios_packet)
        send_netbios_packet: send_packet() to IP 192.168.1.255 port 137 failed
      [2020/08/19 20:39:53.643886,  0] ../../source3/nmbd/nmbd_nameregister.c:582(register_name)
        register_name: Failed to send packet trying to register name WORKGROUP<00>
      [2020/08/19 20:39:53.643896,  0] ../../source3/libsmb/nmblib.c:924(send_udp)
        Packet send failed to 192.168.1.255(137) ERRNO=No route to host
      [2020/08/19 20:39:53.643903,  0] ../../source3/nmbd/nmbd_packets.c:180(send_netbios_packet)
        send_netbios_packet: send_packet() to IP 192.168.1.255 port 137 failed
      [2020/08/19 20:39:53.643909,  0] ../../source3/nmbd/nmbd_nameregister.c:582(register_name)
        register_name: Failed to send packet trying to register name WORKGROUP<1e>
      [2020/08/19 20:39:53.644116,  0] ../../lib/util/become_daemon.c:136(daemon_ready)
        daemon_ready: daemon 'nmbd' finished starting up and ready to serve connections

      Here it appears as if something in the networking stack prevents the server from sending out the broadcast packets to the network. From what I could see, there is no firewall or anything blocking such traffic.

      If I turn my attention to the /var/log/messages file, I note this :

      Aug 19 20:39:54 tvseries kernel: bge0: link state changed to UP
      Aug 19 20:39:54 tvseries kernel: bge0: link state changed to UP

      If we note the difference in time stamps, the nmbd service started at 20:39:53 when we notice the networking service only broadcasted it was ready a second later at 20:39:54.

      Restarting the nmbd service totaly resolved the issue:

      service nmbd stop
      service nmbd start

      Returning to check /var/log/samba4/log.nmbd

      [2020/08/19 21:00:50.407137,  0] ../../source3/nmbd/nmbd.c:59(terminate)
        Got SIGTERM: going down...
      [2020/08/19 21:00:52.646719,  0] ../../source3/nmbd/nmbd.c:906(main)
        nmbd version 4.10.16 started.
        Copyright Andrew Tridgell and the Samba Team 1992-2019
      [2020/08/19 21:00:52.651016,  0] ../../lib/util/become_daemon.c:136(daemon_ready)
        daemon_ready: daemon 'nmbd' finished starting up and ready to serve connections
      [2020/08/19 21:00:52.651517,  0] ../../source3/nmbd/nmbd_namequery.c:109(query_name_response)
        query_name_response: Multiple (2) responses received for a query on subnet 192.168.1.198 for name WORKGROUP<1d>.
        This response was from IP 192.168.1.190, reporting an IP address of 192.168.1.190.
      [2020/08/19 21:06:05.770560,  0] ../../source3/nmbd/nmbd_namequery.c:109(query_name_response)
        query_name_response: Multiple (2) responses received for a query on subnet 192.168.1.198 for name WORKGROUP<1d>.
        This response was from IP 192.168.1.190, reporting an IP address of 192.168.1.190.

      It should be noted that host .190 has a configueration of preferred master = yes, and I would expect it to act as the master in this deloyment.

      I am rubbish at FreeBSD, so I am unsure where I can check this kind of service dependancy. :)

      Thanks!

        Attachments

          Attachments

            JEditor

              Activity

                People

                Assignee:
                releng Release Council
                Reporter:
                BSD-Newb MattyB
                Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved: