Bug 2758

Comment 1 Andrew Flegg 2008-01-12 16:37:04 UTC

Obviously spaces and other invalid characters would need stripping out, but the
result should also be fed into the DHCP requests.

*** This bug has been confirmed by popular vote. ***

ACK w/o a proper hostname the telepathy*-software has problems when announcing
"presence" in local networks 

when all devices have the same hostname (Nokia-810-50-2) it doesn't work

Setting the hostname in the startup should probably also set the Bluetooth ID
as well.

I think this is higher priority then 'low'.

I want to ssh to my NIT by name, not IP.

Since it's not clear from other comments and I stumbled on this looking for a
fix for the dhcp problem:

* in Diablo at least, udhcpc does send the hostname with the DHCP request but
the standard ps line trimming hides this from casual observation.
* setting /etc/hostname and rebooting allows future DHCP requests to send the
correct name. (It may be sufficient to run hostname)
* /etc/hosts also contains the hostname and needs setting

Comment 7 Patrik Flykt 2008-08-26 09:07:11 UTC

(In reply to comment #0)
> Enter a name while setting up a device for the first time.

This is actually defined to set only the Bluetooth device name. The host name
is in /etc/hosts is not touched.

Comment 8 Andrew Flegg 2008-08-26 10:42:34 UTC

> This is actually defined to set only the Bluetooth device name. The host name
> is in /etc/hosts is not touched.

Isn't that the point of this bug? The "My device's name" prompt may be under
Control Panel > Bluetooth; however during initial device setup after a reflash
I *think* there's no reference to Bluetooth.

The argument is, therefore, that setting the device name (of it via Bluetooth)
should also update the name (e.g. via DHCP). Since the specification is closed,
there's no way we can know if this is a bug in the implementation. a bug in the
specification or an enhancement request.

I'm not sure I'd call this "easy fix". and realistically, if you expect an easy
fix for chinook/diablo, the only one i can imagine is to fix the text (and
that'd require localization which makes it "hard").

----

I think this leads to a couple of questions:
1. what is the expected result if someone changes their bluetooth name directly
via gconf, should /etc/hosts and /etc/hostname change?
2. if someone changes /etc/hostname, should the others change?
3. if dhcp responds and assigns the device a hostname, should the bluetooth
name change?
4. exactly what character mapping do you expect, consider the following
characters highlighted by the changeset between bluez-utils 2.18 and 2.19:

$ ' " \ `

and for:
~ - _ # : @ / ^ . <space> 

but also, for Chinese, Japanese, Korean, Cyrillic and other "interesting"
characters.

Do you expect a punycode hostname?

5. If a dhcp server reports a conflict on the name, what do you want to have
happen?
6. If bluetooth detects another device by the same name (Nokia N800), should
the device randomly change its name? :)
7. Where do you expect a device name feature to live? should it move out of
control panel/bluetooth?

For comparison, could someone survey other devices and indicate whether they
use the same widget to set hostname and bluetooth name?

Comment 10 Andrew Flegg 2009-01-08 12:49:53 UTC

(In reply to comment #7)
> (In reply to comment #0)
> > Enter a name while setting up a device for the first time.
> 
> This is actually defined to set only the Bluetooth device name. The host name
> is in /etc/hosts is not touched.

Actually, that's not entirely true. The device name entered during initial
setup is *not* solely used for Bluetooth, it's also used in the File Manager
and file operation dialogues as the name for $MYDOCSDIR (typically
/home/user/MyDocs)

Comment 11 Quim Gil 2009-01-16 08:32:25 UTC

Reading (In reply to comment #7)
> (In reply to comment #0)
> > Enter a name while setting up a device for the first time.
> 
> This is actually defined to set only the Bluetooth device name. The host name
> is in /etc/hosts is not touched.

Therefore this is an enhancement request.

From a conceptual point of view seems to make sense: the user wants to have the
same name for the device/system no matter who asks for it.

If the implementation is easyfix or not, that I don't know. Comment #9 has some
good arguments for potential complexity.

Changing summary and removing easyfix.

I think the WINS/SMB hostname is part of all this

> 1. what is the expected result if someone changes their bluetooth name directly via gconf, should /etc/hosts and /etc/hostname change?
> 2. if someone changes /etc/hostname, should the others change?

No, and it should revert one specific way (one file should be dominant and be
set by some settings applet and a namesync rerun) the next bootup.  Something
in /etc/init.d should synchronize the hostnames.

> 3. if dhcp responds and assigns the device a hostname, should the bluetooth
name change?

No, for the same reason that DHCP doesn't change "localhost".  The "hostname"
shouldn't have a domain, and a device can have several names mapped.  I would
map any local hostname to be an alias for 127.0.0.1 primarily.  If other
services like an nslookup (wins/smb) I would use the same name.  Windows does
this and gets away with it (the hostname is the same for SMB and bluetooth). 
If Bonjour would need a name, it would use the same one.

Most of these requests are logically separate.  The protocols are not asking
for an FQDN, but more "What do you think your own name is?".  DHCP assigned
names are for the local or central DNS server and the question as to what name
a particular device is (or it's IP address) will be answered by THAT server,
not the device itself.

> 4. exactly what character mapping do you expect, consider the following
characters highlighted by the changeset between bluez-utils 2.18 and 2.19:
> ...
> Do you expect a punycode hostname?

Yes. I can't use "interesting" characters in DNS lookups, just ascii letters,
numbers and the hyphen to my knowledge.

> 5. If a dhcp server reports a conflict on the name, what do you want to have
happen?

The DHCP server's assigned name would apply to the single IP address
corresponding to the interface.  You might have to go FQDN - but the same thing
if a host happened to be called "localhost" - an external server would be
"localhost.yoyodyne.com" or something similar.

If the DHCP/DNS/naming configuration is not set up to avoid collisions (e.g. if
the IP ends in .107, it is not xyzclient-107 but something like "workstation")
there are going to be worse problems.

I would note every linux system I've tried bluetooth on (laptop/desktop) has a
unified hostname and manages not to have huge sets of bug reports about
conflicts.  Or for that matter, Windows that does the same thing (the hostname
is used for BT).

I don't think any device or computer can or should be made workable with every
pathological case you or I or anyone else can come up with.  You need to assume
at least a sane network, and that if something is large enough to have problems
there will be someway of solving it locally.  Huge networks assigning hostnames
without any IT person?  They will have worse problems.

Right now, every tablet of the same model and firmware has the same hostname. 
What if that hostname was assigned?

> 6. If bluetooth detects another device by the same name (Nokia N800), should
the device randomly change its name? :)

No, the Mac addresses would be different, and the duplicated names are already
annoying and present everywhere and nothing can be done about that (other than
using the application to create an alias name, i.e. my two GPS units are
G-Rays-A and G-Rays-B so I can tell it which one to attach to and I have many
devices where I have multiples, all with the same name including my new
Jawbone2 that comes up "Jawbone", same as my old one).  The "friendly name" is
not designed to guarantee uniqueness.  If the problem arises with two tablet of
the same name, I would expect it to be handled like my two headsets, or GPS
units.

> 7. Where do you expect a device name feature to live? should it move out of
control panel/bluetooth?

It would be there in bluetooth, but could also be a new applet or extension to
another existing applet, but it would affect the name globally, not just for an
instance.

> Yes. I can't use "interesting" characters in DNS lookups, just ascii letters,
> numbers and the hyphen to my knowledge.

err, you can. that's punicode.

your other answers are all fine w/ me, and should be a reasonable starting
point.

and you can also have interesting characters in bluetooth names.

personally i'd suggest moving the name out of bluetooth.

Comment 14 Quim Gil 2009-05-19 00:19:36 UTC

Setting high visibility to see if that helps reaching to a conclusion.

Comment 15 Quim Gil 2009-09-14 08:14:15 UTC

Same situation in Fremantle.

For a product based on connectivity I can't understand why this bug hasn't been
addressed in the last 20+ months.

Comment 17 Ryan Abel 2009-10-13 01:32:09 UTC

Hey, with Nokia it means we're only about 4 months from a fix!

My ${CURRENCY}.02, mostly summarising previous comments:

- The device name UI should be moved out of the bluetooth control panel (maybe
to about product, or an entirely new one), and set the unix hostname according
to RFC1034 3.5 (1-63 alphanumeric or "-" characters, beginning with a letter
and ending with a letter or number).  POSIX allows up to 255 characters, but
anything longer than 63 would be invalid for DNS-related usage and typing or
even displaying a name that long on this kind of device would be silly anyway.

- The bluetooth user-friendly name can be set to be the same as the unix
hostname.  A correctly constructed hostname is always a valid bluetooth name,
and users who need and manage to connect additional bluetooth adapters should
be able to figure out how to name them distinctly.  This does mean no
international characters, I don't see this as a big issue but others' mileage
may vary.

- Since samba support has been dropped there's no need to worry about those
pesky little NetBIOS names :-)

Comment 19 Andre Klapper 2012-03-24 11:42:32 UTC

The Maemo 5 User Interface and Maemo 5 platform components (e.g. libraries)
used for the N900 are considered stable by Nokia and it seems that there are no
plans for official updates currently, hence nobody plans to work on this
enhancement/wishlist request. 
(And in case you feel like discussing this situation: Nokia Customer Care or
http://talk.maemo.org would be the place to do so as you will not reach Nokia
officials in this community bugtracker - though all of this is really no news.)

Reflecting this status by setting RESOLVED WONTFIX for this
enhancement/wishlist request (see
https://bugs.maemo.org/page.cgi?id=fields.html#status for status explanations).

There is a small chance for issues in those Maemo components that are open
source: Contributed patches could be included and made available in the Maemo 5
Community CSSU updates. 
The Maemo CSSU project is run by a small team of volunteers; see
http://wiki.maemo.org/CSSU for more information.
So in case that you can provide a patch that fixes the reported problem, please
feel encouraged to file a request under
https://bugs.maemo.org/enter_bug.cgi?product=Maemo%205%20Community%20SSU .
Please note: The Maemo CSSU project is not related in any way to Nokia.


( Tag for mass-deleting bugmail: [cleanup20120324] )