Bug 389668

This is not a gnome nor a bluetooth problem.
You probably have a DHCP setup where you get your hostname from, but this is only set late during boot.

I'd guess this is a basesystem problem.

"This is not a gnome nor a bluetooth problem." 

that's why I set component to "Network" to begin with...

well, who sets the adapter name? some daemon/service has to do it - and it most likely needs to listen to network changes.

The name is set during the first boot - it defaults to the hostname (this is the configuration in hcid.conf). If the hostname later changes, bluetooth does not notice nor care. You can change the adapter name via dbus-send, kbluetooth or bluetooth-applet (or however the bluez-gnome thingie is named), this is remembered by hcid in its persistent data store. You can give every adapter a different name, so if you have three different dongles, hcid will remember the given name for each of those.

Again: I filed this as Network issue, Bluetooth and the hostname reflected in the terminal are just symptoms. 

So, instead of using the proper hostname ( workstation6l ) set up with yast2 lan, these two instances ( and maybe others ) get a clobbered hostname ( reached, noname, etc ), from where ?

but bluetooth and the hostname in the terminal are two different things ;-)
As the bluetooth adapter name is just a default that is designed to be changed by the user anyway, so it - on purpose - does not change when the hostname changes. Usually it is just "linux" since it gets set long before the hostname is set for the first time ;)

Closing as invalid according to Comment #4.

Why are you chaps not just read what's reported ?

I am filing a Network Bug about the hostname not being propagated to bluetooth and gnome-terminal properly ( maybe propagated false to other apps too )

Instead of workstation6l which is in /etc/hosts I get "reached", "noname" etc.

What is invalid about that ?

I consider the bluetooth part of the bug report invalid - it is just a wrong assumption that hcid will / should update the adapter names with every hostname change. The rest of the bugreport is IMVHO perfectly valid (and i have no idea how to fix it, nor where the problem might be).

Did this occurs also in xterm or konsole?

Not sure about Konsole, as I use GNOME, but xterm has it too. Also noticed during yet another install from scatch, that changing /etc/hosts manually isn't reflected in the yast2 lan hostname settings later. 

To me it looks as though there are multiple places where this information is kept and they are not properly synced.

It appears as though this is depending on the status of eth0.

I have two network interfaces eth0 ( Intel PRO/100 VE Network Connection ) and wlan0 ( Intel PRO/Wireless 3945ABG Network Connection ) which is actively used, During install these are both configured with startmode auto.

When changing this for eth0 to ifplugd, everything seems normal. Changing it back to onboot and rebooting network connection isn't made automatically but a dhclient wlan0 has to be issued ( See Bug 383320 ), after that BT as well as terminal show "reached" as hostname.

The name of my bluetooth devices should be configured acc. to the
hcid.conf setting as:

  name "BlueZ %h (%d)";

This would mean, %h should be replaced with "xanthos" as configured
in /etc/HOSTNAME and available in $HOSTNAME variable. My hostname
never changes.

The KBluetooth applet shows the adapter as "BlueZ (none) (0)", same
to the "hciconfig -a" output:

xanthos:~ # hciconfig -a
hci0:   Type: USB
        UP RUNNING PSCAN ISCAN 
        Name: 'BlueZ (none) (0)'

Sorry, but I don't see here anything that would be network related.

Well, maybe I confuse things here, my impression was that setting and propagating hostname was network related. Please correct me if I'm wrong.

Setting the hostname for me is done via yast2 lan, what happens from there...

So if you don't think it's network related, please stop proving what the issue _not_is_ but rather state properly what the issue _really_is_ so it can eventually be fixed.

Bluetooth only configures the name from hcid.conf at the first start, then never again looks at that file. At least not for the hostname.

I cannot do anything about this.

But the fact that Casual's hostname in the Xterm and gnome-terminal and whereever is wrong is the real error here.

So back to you, Marius ;-)

Just forget everything said about bluetooth in this bug and look at the rest.

The hostname is changed by dhcp when DHCLIENT_SET_HOSTNAME=yes in
/etc/sysconfig/network/dhcp.

The sysconfig default is "no", the yast2 default in installation
dialogs is AFAIK "yes".

The ifup-dhcp script passes this setting to the dhcp client (-H),
dhcpcd client makes a sethostname call, when dhcp provided one.

Reassigning to dhcpcd maintainer.

Can you provide the following [dhcpcd] logs?

  grep "setting hostname to" /var/log/messages

Or are you using dhclient?

You are using dhclient. And this also explains your bug #393801.

$ host 192.168.110.12
;; connection timed out; no servers could be reached
                                             ^^^^^^^

Going to fix it...

Increasing severity, because the host call in dhclient-script
may cause much troublee.

Created attachment 217807 [details]
proposed patch for dhclient-script

Works fine for me - in success "host" case the hostname is set:

++ DHCLIENT_SET_HOSTNAME=yes
+ '[' yes = yes ']'
++ hostname
+ current_hostname=xanthos
+ '[' xxanthos = x ']'
+ '[' xxanthos '!=' x ']'
+ '[' x '!=' x ']'
+ '[' -x /usr/bin/host ']'
++ host -W 2 192.168.110.1
+ out='1.110.168.192.in-addr.arpa domain name pointer xanthos.example.net.'
++ echo '1.110.168.192.in-addr.arpa domain name pointer xanthos.example.net.'
++ sed 's:^.* ::; s:\..*::'
+ hostname xanthos

in error cases (when I disable modifying of resolv.conf) not:

++ DHCLIENT_SET_HOSTNAME=yes
+ '[' yes = yes ']'
++ hostname
+ current_hostname=xanthos
+ '[' xxanthos = x ']'
+ '[' xxanthos '!=' x ']'
+ '[' x '!=' x ']'
+ '[' -x /usr/bin/host ']'
++ host -W 2 192.168.110.1
+ out=';; connection timed out; no servers could be reached'
+ exit_with_hooks 0

CJP: can you apply the patch to /sbin/dhclient-script and test?

Stephan, I already submitted the fix to STABLE. OK?

Marius, seems to work as expected now, thanks.

it's in