gnome-vfs-obexftp 0.4

It hasn’t been long since the last gnome-vfs-obexftp release, but I thought it’d be good to get these fixes out before undertaking more invasive development. The new version is available from:

http://download.gnome.org/sources/gnome-vfs-obexftp/0.4/

The highlights of this release are:

  • If the phone does not provide free space values in the OBEX capability object, do not report this as zero free space. This fixes Nautilus file copy behaviour on a number of Sony Ericsson phones.
  • Fix date parsing when the phone returns UTC timestamps in the folder listings.
  • Add some tests for the capability object and folder listing XML parsers. Currently has sample data for Nokia 6230, Motorola KRZR K1, and Sony K800i, Z530i and Z710i phones.

These fixes should improve the user experience for owners of some Sony Ericsson phones by letting them copy files to the phone, rather than Nautilus just telling them that there is no free space. Unfortunately, if there isn’t enough free space you’ll get an error part way through the copy. This is the best that can be done with the information provided by the phone.

Test Suite

As noted in the third point, I’ve started to build up a collection of capability and folder listing XML documents produced by various phone models. This serves a dual purpose:

  1. Ensure that the capability object and folder listing XML parsers don’t regress between releases. It is impractical for me to test gnome-vfs-obexftp against all these phone models since I don’t have the hardware or time.
  2. Give an idea of what information the different phone models provide, which should be useful when planning new features.

If you have an OBEX FTP capable phone that is not already in the test suite, it’d be useful if you could collect the data and file a bug. The information can be collected using the command line “obexftp” program (part of the “obexftp” package on Ubuntu). The following commands will give the capability object and root folder listing:

obexftp --bluetooth $BDADDR --capability
obexftp --bluetooth $BDADDR --list

It’d also be useful to get a listing for one or two other directories. If there is a memory card, it’d be useful to get that folder. For example:

obexftp --bluetooth $BDADDR --list "Memory card/"

It’d be most useful if the transcript of the various commands were included as an attachment. Feel free to censor personal information if you want (e.g. the phone serial number in the capability object, some non-default file names).

In particular, I wouldn’t mind getting information on phones with brands other than than Nokia or Sony to see what info they provide.

Investigating OBEX over USB

I’ve had a number of requests for USB support in gnome-vfs-obexftp. At first I didn’t have much luck talking to my phone via USB. Running the obex_test utility from OpenOBEX gave the following results:

$ obex_test -u
Using USB transport, querying available interfaces
Interface 0:   (null)
Interface 1:   (null)
Interface 2:   (null)
Use 'obex_test -u interface_number' to run interactive OBEX test client

Trying to talk via any of these interface numbers failed. After reading up a bit, it turned out that I needed to add a udev rule to give permissions on my phone. After doing so, I got a better result:

$ obex_test -u
Using USB transport, querying available interfaces
Interface 0: Nokia Nokia 6230 (null)
Interface 1: Nokia Nokia 6230 (null)
Interface 2: Nokia Nokia 6230 (null)
Use 'obex_test -u interface_number' to run interactive OBEX test client

With the change, I was also able to access the phone using the obexftp command line client. This seemed enough to start investigating a bit further. The OpenOBEX API for setting up USB connections goes something like this:

  1. The app calls OBEX_FindInterfaces(), which returns a list of obex_interface_t structures that represent the different discovered interfaces.
  2. The app picks one of the discovered interfaces (based on the manufacturer, product and serial number strings), then connects to it using OBEX_InterfaceConnect().

There are a number of issues with this interface though.

  • If the phone doesn’t provide a serial number via its USB interface (like my 6230 doesn’t), the obex_interface_t structure is not enough to identify a particular phone.
  • If the phone exposes multiple OBEX USB interfaces for some reason, OpenOBEX lists it multiple times. In the obex_test output shown above, there was a single phone attached – not three.
  • There is no way to tell when phones are connected or disconnected. While HAL can do that job for us, there is no way to map from the device information provided by HAL to one of the discovered interfaces provided by OpenOBEX.

To sum up, it shouldn’t be difficult to hack support for USB connections into gnome-vfs-obexftp with URLs like obex://usb-N/ (where N is the number of the discovered interface), but there are a number of features I’d need to provide a good user experience:

  1. The ability to ask OpenOBEX to connect to a particular USB device, rather than having to deal with its discovery interface.
  2. A good set of udev rules to grant the needed permissions on common phones so they don’t need to find out why things only work as root.

TXT records in mDNS

Havoc: for a lot of services advertised via mDNS, the client doesn’t have the option of ignoring TXT records if it wants to behave correctly.

For example, the Bonjour Printing Specification puts the underlying print queue name in a TXT record (as multiple printers might be advertised by a single print server). While it says that the server can omit the queue name (in which case the default queue name “auto” is used), a client is not going to be able to do what the user asked without checking for the presence of the record.

Rather than thinking of TXT records as optional data, it is better to think of them as “stuff that is can not be used to perform searches”. In the printer example above, the fact that you can’t search by print queue name is not a problem because users instead pick a printer based on the human readable service name which is exposed as a DNS name.

In your example of including session and machine identifiers in TXT data, it would be enough to tell a client that two services belonged to the same machine or session, but it wouldn’t let you do searches like “find all the card game servers belonging to the same session as the guy I’m chatting with”.  For that you’d also need to advertise DNS names that include the machine identifier or session identifier.

gnome-vfs-obexftp 0.3

I’ve just released a new version of gnome-vfs-obexftp, which includes the features discussed previously. It can be downloaded from:

http://download.gnome.org/sources/gnome-vfs-obexftp/0.3/

The highlights of the release include:

  • Sync osso-gwobex and osso-gnome-vfs-extras changes from Maemo Subversion.
  • Instead of asking hcid to set up the RFCOMM device for communication, use an RFCOMM socket directly. This is both faster and doesn’t require enabling experimental hcid interfaces. Based on work from Bastien Nocera.
  • Improve free space calculation for Nokia phones with multiple memory types (e.g. phone memory and a memory card). Now the free space for the correct memory type for a given directory should be returned. This fixes various free-space dependent operations in Nautilus such as copying files.

Any bug reports should be filed in Launchpad at:

https://bugs.launchpad.net/gnome-vfs-obexftp/

New stuff in gnome-vfs-obexftp

Recently, Bastien has been doing a bit of hacking on gnome-vfs-obexftp. The changes remove the use of the org.bluez.RFCOMM interface to hcid, instead doing SDP and createing RFCOMM sockets directly. This removes the need to run hcid with its experimental interfaces enabled. This is also good because the org.bluez.RFCOMM interface has been removed in newer releases (replaced by org.bluez.serial.Manager).

I’ve now integrated that patch and made a number of further clean ups so that we don’t need any D-Bus requests to establish the connection to the remote device. Now the only D-Bus requests being made are for device enumeration used for the “obex:///” virtual folder. Should make it easier to switch over to HAL if/when it supports scanning for Bluetooth devices.

I also had a go at fixing bug #116912. Using the memory type information provided in folder listings on Nokia phones, I’ve now got the get_volume_free_space() routine to return the free space of the appropriate memory type for the folder. While this works fine in the GNOME-VFS API, unfortunately it hasn’t improved matters in Nautilus. It seems to always request the free space for the root directory, so I still see an incorrect free space value for e.g. obex://[...]/Memory%20card/ on my phone. I’m not sure how I’ll go about fixing that.

There does appear to be some problems with some Sony phones, but I don’t have any hardware to test this. Perhaps this is something to work on in the next release if I can get some help debugging the problem.

Update: looks like I spoke too soon about Nautilus not getting the correct free space value.  After restarting Nautilus again, it started showing the free space correctly, and I can copy large files to my memory card.