Connection by hostname disappears

[normtown]

I'm noticing that I can connect to my server by its hostname ("tower.local") when the server is started, but after "a while" (usually no longer than 30 minutes) the hostname is no longer resolvable. I can still connect by IP.

 

Has anyone else seen this behaviour?

 

I'd like to continue to used DHCP for IP assignment and not resort to hacking my hosts file. This should be something that works without resorting to those kind shenanigans

 

This is my first unRAID build. I'm running 5.0 rc-16.

[Bitz69]

I'm noticing that I can connect to my server by its hostname ("tower.local") when the server is started, but after "a while" (usually no longer than 30 minutes) the hostname is no longer resolvable. I can still connect by IP.

 

Has anyone else seen this behaviour?

 

I'd like to continue to used DHCP for IP assignment and not resort to hacking my hosts file. This should be something that works without resorting to those kind shenanigans

 

This is my first unRAID build. I'm running 5.0 rc-16.

 

Pretty typical here.. happens daily. I've just accepted it.

[trurl]

Have you tried Settings - SMB - Local master - Yes?

 

After setting this you may have to wait a while, or just try rebooting all the other machines on the network.

[Bitz69]

Have you tried Settings - SMB - Local master - Yes?

 

After setting this you may have to wait a while, or just try rebooting all the other machines on the network.

yes, been through all of that, it's just never reliable. it'll work sometimes but usually stops working on it's own.

[EGOvoruhk]

Pretty typical here.. happens daily. I've just accepted it.

 

Is this pretty much the answer so far? To just accept it for now? I've been looking around to see if there's a solution, but most threads kind of dead end with nothing, or someone saying to edit the host file. I haven't seen anyone solve it

 

I thought I was going mad when it all of a sudden stopped working. I'm (oddly) glad to see that I'm not the only one. I do hope it's looked into though

[normtown]

My guess is that there's something funny going on with the NetBIOS integration. I'm guessing that because I'm just running a simple LAN with a few machines connected to a router. For my unRAID server to disappear after a little while it would have to stop broadcasting its name to the other hosts on the LAN.

 

Was this happening in 4.x? Have there been any changes in this area?

[unevent]

I've been getting this since 16c with avahi loaded.  I don't use AFP or anything apple, yet avahi is running and creating tower-smb and tower.local crap.

[normtown]

I do use AFP. Creating the Tower and Tower-SMB crap is exactly what I want it to do 

 

This is affecting more than just the creation of Tower and Tower-SMB. As I said before, it seems as though the unRAID server is not broadcasting its NetBIOS hostname to the LAN. I can't even ping the server with its hostname. The only thing that seems to make it broadcast again is restarting my router. I'm guessing that the process of getting a new IP address from my router's DHCP server causes the unRAID server to broadcast its hostname. I'm guessing there's a TTL on that?

[unevent]

I started experiencing the same problem you describe in both my Windows and Linux system over SMB when avahi was included in 16c.  Those that don't have AFP enabled should not suffer from having avahi enabled by default.

[dgaschk]

tower.local is an ahavi name. SMB clients should connect to the shares with \\tower and to the management GUI with //tower

[unevent]

tower.local is an ahavi name. SMB clients should connect to the shares with \\tower and to the management GUI with //tower

 

Yes, I know.  My point was I have been experiencing th same problems as the OP (host name not working at times), but also included the comment that since I do not use AFP I should not see 'Tower-SMB' and 'Tower.local' in my network views because I the wife and kids that access unRAID from computers and having extra stuff to click tot he Tower does not go over well.  If it is for AFP only then if AFP is not enabled it should not be there.

[normtown]

I understand your frustration regarding the advertised services from avahi. However, that is not really what this thread is about. If you have any solutions or clues about the root cause of the original issue I reported, please feel free to contribute.

 

It sounds like the integration with avahi coincides with this hostname behavior. Are there any unRAID devs that can speak about the integration?

[EGOvoruhk]

It sounds like the integration with avahi coincides with this hostname behavior.

 

I just tried running a fresh install of 5.0-rc15a, which according to the changelogs is the release before AVAHI runs regardless of AFP status, but it's still getting the hostname issues 

[dgaschk]

Avahi is not the issue. SMB clients are not effected by Avahi.

[sureguy]

Can you try booting from a bootable Linux CD/DVD/USB and then try again?  I can ping my server name from all my workstations (win xp, win 8, ubuntu, etc) without issue.  This would either eliminate or implicate Windows as the cause of the problem.

 

I'm using SimpleFeatures with the following SMB settings:

 

Enable SMB:  Yes(workgroup)

Workgroup: workgroup

Local Master: Yes

 

 

[dgaschk]

I do use AFP. Creating the Tower and Tower-SMB crap is exactly what I want it to do 

 

This is affecting more than just the creation of Tower and Tower-SMB. As I said before, it seems as though the unRAID server is not broadcasting its NetBIOS hostname to the LAN. I can't even ping the server with its hostname. The only thing that seems to make it broadcast again is restarting my router. I'm guessing that the process of getting a new IP address from my router's DHCP server causes the unRAID server to broadcast its hostname. I'm guessing there's a TTL on that?

 

Sounds like a router issue.

[EGOvoruhk]

This would either eliminate or implicate Windows as the cause of the problem.

 

It's not Windows. I can't ping from any device. Windows, OS X, Android, etc. It's also not the UnRAID hardware, since I could ping the Server 2012 install that was on it days before

 

I did a little more testing today, and I think it's a problem with whatever scripts run when setting a static IP in the web GUI. I did another fresh install of rc16c, and after boot, I can ping Tower just fine. I did nothing but change the IP from DHCP to Static, reboot, and as soon as it comes up, I can't ping Tower anymore. I also don't see the hostname in the device list on my router (running Tomato). So I change the IP back to DHCP, reboot, and as soon as it finishes booting, the device pops up in Tomato's device list, and I can ping Tower again

 

Just for a little confidence, I used a 2nd flash drive, installed UnRAID rc16c on it, and then plugged it into an older Thinkpad I've got. I then performed the exact same steps as above, and got the same results. Upon initial boot, I could see and ping Tower. I then changed the IP to Static (a different IP than the 1st UnRAID machine), rebooted, and when it came back up, it was again no longer in Tomato's device list and no longer pingable. Changed IP back to DHCP, rebooted, and it's back in the device list and pingable again

 

normtown, no doubt if you performed the same steps, you would see the same results I'm seeing

 

Since I need a static IP, and I also want to use unMENU (which only works by browsing via the hostname), the best course of action is to use IP reservations in my router, which isn't the worst thing in the world, but this is still a problem that needs addressing

[normtown]

I can't ping tower from any host in my network either.

 

@EGOvorhuk

 

I'm a little confused by your test. My networking knowledge is admittedly limited. If you set a static IP in the web GUI but don't reserve that IP in your DHCP server, should your router know about it? It's not clear to me that the behavior you're seeing is unexpected. Can anyone educate me on this?

 

Also, when I reboot (using DHCP for IP assignment) I see Tower in my device list and it is pingable via tower.local at first. After a little while (not sure how long exactly--5 to 30 minutes, maybe?) tower.local becomes unpingable.

 

 

[normtown]

I just verified that I get the same behavior when using a static IP address. Tower appears at first and is pingable as tower.local, then it disappears after a little while and is no longer pingable by the hostname.

[dgaschk]

Attach a syslog that includes a disconnect period.

[normtown]

Attached!

syslog.txt

[dgaschk]

What does "ethtool eth0" and "ifconfig" show?

 

[unevent]

Attached!

 

Problem looks to be in AFP configuration and how it handles clients going to sleep.  It is something Tom will most likely need to look into and is probably already on his list for after 5 is released.  Something to chew on in the meantime http://osdir.com/ml/network.netatalk.devel/2003-03/msg00023.html

[drawz]

What happens if you go to a command line (on your PC, not the unRAID box) and type in "nslookup tower" (replace tower with the name of your unraid machine). If it can't find the IP address, this could be a problem with your routers handling of hostnames. You can try this right when your box boots and the webgui works and then try again when it goes down.

 

What router are you using?

[normtown]

Firstly, on the unRAID server, I ran ethtool and ifconfig:

 

~# ethtool eth0

Settings for eth0:

Supported ports: [ TP ]

Supported link modes:  10baseT/Half 10baseT/Full

                        100baseT/Half 100baseT/Full

                        1000baseT/Full

Supports auto-negotiation: Yes

Advertised link modes:  10baseT/Half 10baseT/Full

                        100baseT/Half 100baseT/Full

                        1000baseT/Full

Advertised pause frame use: Symmetric Receive-only

Advertised auto-negotiation: Yes

Speed: 1000Mb/s

Duplex: Full

Port: Twisted Pair

PHYAD: 0

Transceiver: internal

Auto-negotiation: on

MDI-X: Unknown

Supports Wake-on: pumbg

Wake-on: g

Current message level: 0x00000033 (51)

Link detected: yes

 

~# ifconfig

eth0      Link encap:Ethernet  HWaddr bc:5f:f4:83:ef:71

          inet addr:192.168.0.100  Bcast:192.168.0.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:2467498 errors:0 dropped:198 overruns:0 frame:0

          TX packets:923886 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:3280671312 (3.0 GiB)  TX bytes:64237367 (61.2 MiB)

          Interrupt:46 Base address:0x2000

 

lo        Link encap:Local Loopback

          inet addr:127.0.0.1  Mask:255.0.0.0

          UP LOOPBACK RUNNING  MTU:65536  Metric:1

          RX packets:917 errors:0 dropped:0 overruns:0 frame:0

          TX packets:917 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:76862 (75.0 KiB)  TX bytes:76862 (75.0 KiB)