Mantis Bugtracker

Простой вид комментарии ] расширенный вид ] история ] печать ]
Номер Категория Серьезность Воспроизводимость Создан Изменен
0000053 [obex-data-server] General малая неприменима 2008-02-27 13:13 2008-10-17 19:59
Инициатор RobertRawlins Видимость общая  
Ответственный skirsdeda
Приоритет обычный Решение решен  
Состояние закрыт   Версия продукта 0.3
Суть 0000053: Additional signals for ConnectError() and ConnectRefused()
Подробности At present the Session service produces signals for Connected() and Disconnected() along with many others. I can see a benefit to be able to determine when a connection attempt has an error or is refused by the server. Is this plausable?
Дополнительные сведения
Tэги Нет прикрепленных тэгов.
Вложенные файлы ? file icon rfcomm_reports.patch [^] (7,309 bytes) 2008-04-21 19:43
? file icon [^] (6,121 bytes) 2008-04-21 19:44
? file icon second_attempt.patch [^] (11,373 bytes) 2008-05-15 11:49

- Связи
блокирует 0000058закрытskirsdeda 0.4 tracker 

-  Комментарии
skirsdeda (администратор)
2008-03-01 01:55

If session fails to connect, it's object is never created. CreateBluetoothSession simply returns particular error instead of new session object.
RobertRawlins (инициатор)
2008-03-03 13:38

Hey Skirsdeda,

I wasn't sure if I should reopen this or not, however, I need a little more information from you on the behaviour of CreateBluetoothSession. I see what you mean about it returning an error if one occurs, I see that if my Nokia phone times out on the connection request a dbus error is returned stating the timeout.

However, when I refused the connection request on somthing like a Nokia or a Samsung then it appears a Session path is returned from CreateBluetoothSession anyway, this path can the be used to create a Session object and interface without throwing an exception, however, the resulting object is just dead in the water as it doesnt throw any signals or exceptions.

I'm quite happy with the idea of having CreateBluetoothSession return the error if one exists, but at the moment it doesnt seem to recognise when a connection is refused by the server.

Am I missing somthing? It may just be somthing I'm doing wrong but CreateBluetoothSession is definatly returning a session path when I refuse the connection request and I end up with a dead Session object which doesnt do anything.

Cheers Skirsdeda,

skirsdeda (администратор)
2008-03-03 16:27

That's wrong. If connection is refused, session object should not be created and error should be returned.
RobertRawlins (инициатор)
2008-03-03 16:41

Hi Skirsdeda,

At which point should the error be returned? should it be an error returned by CreateBluetoothSession instead of an object path? or should it be when I try to create the Session object using the returned path?

Thanks mate,

skirsdeda (администратор)
2008-03-04 01:24

should be an error returned by CreateBluetoothSession instead of an object path
RobertRawlins (инициатор)
2008-03-04 10:36

Hey Skirsdeda,

I thought that is what should be happening, however, I seem to be getting a different result. When I attempt to connect to a Nokia or a Samsung (possibly other manufacturers too) I get a prompt on the phone screen asking me to accept the connection, if I choose 'no' then an object path is still returned by CreateBluetoothSession and not an error.

Do you have any ideas why I'm getting this unusual behaviour? is there anything I can post here to help debug the issue?


skirsdeda (администратор)
2008-03-05 21:19

Try sending some file with ods-dbus-test program in test directory and send me the output.
Use it like this:

./ods-dbus-test 01:23:45:67:89:01 opp /path/to/some/file
RobertRawlins (инициатор)
2008-03-06 13:10

Hi Skirsdeda,

I've tried running the example code and when refusing the connection from my Nokia and Samsung handsets I get the following output:

** Message: CreateBluetoothSession ("00:13:70:D9:71:45", "opp")
** Message: Object path: /org/openobex/session2
** Message: Session object created: /org/openobex/session2

As you can see, it returns the object path and not an error message. I've also copied below the output from ods itself:

** Message: Parsed[0]: opp, Parsed[1]: (null)
** Message: Connecting to 00:1B:98:16:21:E4 using channel 7
** Message: Connect in progress
** Message: Connect complete
** Message: Session created by: :1.9
** Message: io callback

Thanks Skirsdede, Hopefully this will give a little insight into the problem.


skirsdeda (администратор)
2008-03-06 22:50

Get newest obex-data-server from subversion repository and try it again. Send obex-data-server output.
RobertRawlins (инициатор)
2008-03-07 12:57

Hi Skirsdeda,

OK, well I checked out the latest build from the SVN, however it still appears to be producing pretty much the same results:

** Message: CreateBluetoothSession ("00:13:70:D9:71:45", "00:0F:EA:99:AC:CE", "opp")
** Message: Object path: /org/openobex/session0
** Message: Session object created: /org/openobex/session0

and obex-data-server is spitting out the following:

** Message: obex-data-server 0.3
** Message: Using System bus
** Message: Parsed[0]: opp, Parsed[1]: (null)
** Message: Connecting to 00:13:70:D9:71:45 using channel 9
** Message: Connect in progress
** Message: Connect complete
** Message: Session created by: :1.10
** Message: io callback

Thanks mate,

RobertRawlins (инициатор)
2008-03-09 16:24

Hey Skirsdeda,

I hope you're having a good weekend mate. What are your thoughts on this issue at the moment? is this a bug which others have been able to replicate? or is this just somthing with my configuration?


darwish (инициатор)
2008-03-11 14:22

I confirm. This also appears to me though I asked not to receive the message on my mobile (Nokia N73):

** Message: Adapter found: /org/bluez/hci3
** Message: Adapter addresss: 42:7E:00:01:FD:50
** Message: CreateBluetoothSession ("00:19:79:D2:C7:B8", "42:7E:00:01:FD:50", "opp")
** Message: Connecting Signals
** Message: Session object created: /org/openobex/session5

Problem is 100% produceable, with 0.3 and with latest svn
RobertRawlins (инициатор)
2008-03-11 16:45

Great, I'm glad its not just me doing somthing wrong :0)

Skirsdeda, I've noticed a few other strange behaviours this morning all around this same concept here, perhaps they may be all related.

This morning when playing around with the manager object, it seems that when making a CreateBluetoothSession to my nokia device and allowing the connection to time out I get an error returned from CreateBluetoothSession for the connection attempt, which is normal and expect, however, I also notice that the SessionCreated() signal is broadcast from the manager object, is that meant to happen?

Another strange occurance I have noticed is that the SessionCreated() signal is broadcast from the manager several times at once, seemingly once for every connection that has every been made by CreateBluetoothSession, this one may just be somthing going on with my code but it seems quite odd.

The third issue I'm experiancing with this is that after having made several timed out attempts to connect to the device it starts throwing org.openobex.Error.ConnectionAttemptFailed: Binding to local device (adapter) failed. from CreateBluetoothSession.

I get a strange feeling that some of these problems may be related? what do you think? I'm wondering if perhaps CreateBluetoothSession is creating lots of dead sessions when we refuse the connection or leave it to time out, does that sound possible?

Darwish, perhaps you're able to see if you are experiancing the same issues?

Thanks Skirsdeda,

darwish (инициатор)
2008-03-11 17:26


Yes, I experienced similar issues when a session is not established cause of timeouts or pressing no.

The binding issue is the most occuring one and is a bit reproduceable too. Possibly ods didn't close the socket when the session establishment failed leading to PF_BLUETOOTH address already in use system error.

It's the first day for me to play with those bluetoothstuff. I began reading the OBEX standard and openobex api today, hopefully after I finish, I'll try to solve this ods bug.
skirsdeda (администратор)
2008-03-11 18:40
изменен: 2008-03-11 18:41

The normal behaviour for devices when rejecting file is to send RSP_FORBIDDEN response after getting CMD_PUT request. Apparently, in case of devices you use, this doesn't happen. I need obex-data-server (svn version) debug output to understand what happens.

The timeout problem is described in 0000019.

RobertRawlins (инициатор)
2008-03-11 20:11

Hi Skirs,

I'm trying to get this to run with debug output, how do I do it? at the moment I'm running ./configure --enable-debug but the output from obex-data-server --no-daemon still appears to be the same? is that correct?

I'm also trying to do some testing with the ObexFTP application and its lanuage bindings as from memory these seem to detect refusal on the nokia handsets just fine, perhaps its worth having a snoop around thier source to if they're handling anything differently.

Let me know about the debug output and I can sort somthing out for you.

darwish (инициатор)
2008-03-11 20:28


Here's the output of ods daemon:

** Message: obex-data-server 0.3
** Message: Using System bus
** Message: Parsed[0]: opp, Parsed[1]: (null)
** Message: Connecting to 00:0E:6D:64:E2:B0 using channel 9
** Message: Connect in progress
** Message: Connect complete
** Message: Session created by: :1.76
** Message: io callback

Again, although I hit _no_ on my mobile, a session object is created. session completed signal is never emitted though. Here's the output from client side:

** Message: Adapter found: /org/bluez/hci0
** Message: Adapter addresss: 42:7E:00:01:FD:50
** Message: CreateBluetoothSession ("00:0E:6D:64:E2:B0", "42:7E:00:01:FD:50", "opp")
** Message: Connecting Signals
** Message: Session object created: /org/openobex/session0

skirsdeda (администратор)
2008-03-11 22:30

ok, what is the output of obexftp when refusing connection?
RobertRawlins (инициатор)
2008-03-11 23:13

Hi Skirs,

I'm out of the office this evening so dont have a system to hand to be able to test it, usualy with ObexFtp you just get a '1' returned when each stage that completes successfully and another response code if some form of error occurs.

I'll be able to test that properly in the morning, its been a little while since I looked at it, I'll give you the details as soon as possible, unless darwish is able to test that before I do, [^]

nbransby (инициатор)
2008-03-12 00:06
изменен: 2008-03-12 01:42

Hi everyone,

Just thought i would pass on my experience with OPP if it helps with this bug...

> The normal behaviour for devices when rejecting file is to send RSP_FORBIDDEN
> response after getting CMD_PUT request

This is not strictly true - the behavior differs depending on the device.

For example it holds true for sony ericsson phones as the obex server waits for the put request so it can display the name of the file being sent to the user (or in the case of files such as vCard, accept them without a prompt.

Meanwhile Nokia phones prompt the user with only the sending device's name and therefore blocks on the connect request. So if the user refuses the request the error is returned from the connect request and not the put request.

I think this is causing your problems - of course I could be completely wrong (just started looking into linux bluetooth development today - im a symbian developer) but thought i'd mention it.

RobertRawlins (инициатор)
2008-03-12 11:33

nbransby, you're totaly correct about this.

Sony and a couple of the other manufactuters always accept the connection request, and then display you a prompt on whether to commence the file transfer, if you refuse the file transfer then the RSP_FORBIDDEN is returned, in obex-data-server this means we get the '' signal invoked and it provides the forbidden error.

The problem we are having here is detecting when the connection request is refused.

I'm just going to do some testing with ObexFTP and check the behaviour on that. I'll get back to you with my results shortly.

RobertRawlins (инициатор)
2008-03-12 14:27

Hi Everyone,

Ok, I've installed ObexFTP on my system this morning and run it from the command line tool, and as suspected it does detect when the connection is refused by the Nokia:

Suppressing FBS.
Browsing 00:13:70:D9:71:45 ...
Channel: 10
Connecting...failed: connect
Still trying to connect
Connecting...failed: connect
Still trying to connect
Connecting...failed: connect
Still trying to connect

That is me refusing the connection three times. I'm not sure how to get access to the debug output on ObexFTP so cant give you any more detail than that right now.

However, Skirs, if you're unable to get your hands on a Nokia device to test first hand then I can offer you remote SSH access to my system here, you can then run all the tests you like and I can continualy refuse on my Nokia handset here so you can get a better idea of the response returned, let me know if that would be of interest to you.

skirsdeda (администратор)
2008-03-12 19:15

Please check with ods svn version once again. Now, if connection is refused, ErrorOccurred signal with org.openobex.Error.ConnectionRefused error should be emitted.
RobertRawlins (инициатор)
2008-03-12 19:20

skirs, should this signal be emmited from the manager object? or the session?

skirsdeda (администратор)
2008-03-12 19:20

session object
hadess (инициатор)
2008-03-12 19:44

> > skirs, should this signal be emmited from the manager object? or the session?
> session object

What happens if we can't connect to the signal early enough to see the signal? We get a new session created, are a bit slow, connection refused is emitted, we connect to the signal. We'll never see the session.

Should have an accessor to check if we've been disconnected, or move the signal to the manager, otherwise we have a race.
RobertRawlins (инициатор)
2008-03-12 20:05

Ok, well it may just be me doing somthing incorrectly here, but it doesnt appear to work any differently for me, I dont get the ErrorOccurred() signal emmited from the session object.

Hadess, I have had similar thoughts to this in the past, not just about moving this refused signal, but also perhaps the Connected() too, and perhaps create a new TimedOut() signal, all of which should be placed in the manager object.

Anyway, I've tested this with the latest SVN build and the signal is not called on my session object, what about you Hadess?

skirsdeda (администратор)
2008-03-12 20:26

Basically, I see two approaches:
1) Return from CreateBluetoothSession only after connecting socket, sending CMD_CONNECT and receiving reply. This would be no-nonsense solution, but it has D-Bus timeout problem. Timeout can occur while connecting socket as well as while waiting for reply after sending CMD_CONNECT.
2) Return from CreateBluetoothSession immediately (even before connecting socket). Either Session.Connected or Session.ErrorOccurred signal informs about success. No timeout problem and races are very unlikely, but the code becomes very complicated and benefits only Bluetooth transport. Also, Session object is created every time which is not good.

Feel free to suggest better solution :)
RobertRawlins (инициатор)
2008-03-12 20:35

Hey Skirs,

Well, my personal thoughts are that the second of those two options makes more sense. I appreciate that you're trying to keep the API as simple as possible but for me it adds to the asynchronous feeling of the API if CreateBluetoothSession returns False immediatly and then we get signals for when the connection is created, refused or timedout.

I mean, we can always use the return_handler and error_handler on the current setup but you're still running that risk of the race when connecting to the signals.

I think the second option makes more sense.

RobertRawlins (инициатор)
2008-03-17 14:02

Good morning Everyone,

I hope you all had a good weekend. I just thought I'd check in for the day and see whats been going on with all the bugs.

Has there been any progress on any of the issues?

nbransby (инициатор)
2008-03-18 16:52

Hi Guys,

Not sure if i should file this as a bug (might not be to with obex-data-server) so i thought i would post here first as it is related to this thread.

When calling org.openobex.Manager.CreateBluetoothSession asynchronously (with the reply_handler argument) my reply handler is called post connecting to the device.

This behavior is fine for my purposes except when connecting to a Nokia handset (which blocks on Connect to display a user prompt). In this case my bluez periodic discovery does not fire any RemoteDeviceFound signals while the remote device is blocking the connect request.

I know the hardware is capable of continuing the discovery while attempting a connection to a remote device so why it is not working? Any ideas?

Could obex-data-server be responsible (blocking the gobject main loop possibly?). I guess one way to find out would be to bypass obex-data-server and use the openobex libs directly but i hoping this thread will hold the answer!

RobertRawlins (инициатор)
2008-03-19 16:49

Hi Nick,

I've not been able to replicate that behaviour here, it seems to work just fine for me so I would guess its an unrelated issue.

Although, untill this bug, and the current timeout issues with the dbus connection are properly resolved then its hard to test it properly, its going to be worth placing that on the back burner untill a these issues are worked out, then we'll be able to test it more cleanly I think.

skirsdeda (администратор)
2008-03-19 18:42

nbrasby, your problem is irrelevant neither to obex-data-server nor to openobex.
RobertRawlins (инициатор)
2008-03-20 15:21

Skirs, you need to get yourself an Amazon wish list sorted out, once we've got these bugs fixed I would love to buy you something as a thank you for all the hard work you've been putting into this project. [^]

nbransby (инициатор)
2008-03-25 15:29

Hi guys,

How is this issue coming along? Ive noticed revision 1429 'a proof for 0000053' in the SVN this morning!

Just to clarify will CreateBluetoothSession raise signals for the 4 possible outcomes of the connection attempt...

Connected (success),
Timeout (failed),
Refused by user (failed),
Error occurred (failed)

This would be an improvement on ObexFTP which does not seem to know the difference between timeout, error or refusal (just returns success or failure).
skirsdeda (администратор)
2008-03-25 16:21

I have finally nailed this bug. It is caused by a race condition: ods emits ErrorOccurred just before client app starts listening for signals. ods from svn (r1429) shows when exactly ErrorOccurred is emited and ods-dbus-test shows when exactly it starts litening for signals (when I tested it, ods-dbus-test started listening 1 msec after signal was emitted).

This is gonna be fixed by removing auto-connect from Session. Every client will have to call Connect() after Session object is created. The fix will be available in ods 0.4.
nbransby (инициатор)
2008-03-25 17:26

This makes sense to me.

As I mentioned earlier will ods distinguish between the different types of connection errors...

Refused by user
Error occurred

...and emit the corresponding signal?
RobertRawlins (инициатор)
2008-03-25 17:28

This is excelent Skirs, I'm glad you managed to track it down.

I agree with Nick that being able to distringuise between these would certainly be a real benefit.

skirsdeda (администратор)
2008-03-25 17:29

We can distinguish only Timeout and Error occurred. Some devices (e.g. Nokia) just close the connection when file is refused so there is no way to know whether it was refused or connection simply broke.
nbransby (инициатор)
2008-03-25 18:05

We could just take Error occcured to mean Refused because if the connection breaks (from a out of range condition or taking out the battery of the phone) nothing seems to happen until the a timeout anyway.

BTW Who sets that timeout? Is it set on the client or server side? If you try to connect to a Nokia the on screen prompt is shown for 30 seconds and then times out. Is it device-specific thing?
RobertRawlins (инициатор)
2008-03-25 23:03

Nick: I'm pretty sure this is a manufacturer specific thing, from my experiance with obex this isnt something that can be specified from the client, if it can be it would be great :-)

Skirs: These changes all sound great, are they just proposed ideas at the moment have has the SVN been updated to contain the fixes ready for testing?

Thanks guys,

skirsdeda (администратор)
2008-03-26 01:08

Not yet. This requires a slight redesign so... Not so soon :)
RobertRawlins (инициатор)
2008-03-26 12:05

O.k. Skirs, I really look forward to seeing it :-)

RobertRawlins (инициатор)
2008-03-26 15:53


I notice you've been quite active over on the OpenObex-Users list the past couple of days working on this similar principle of being able to detect refused, timeouts and hostdowns. Are the changes you're making to OpenObex likely to effect this bug at all?

Thanks mate,

nbransby (инициатор)
2008-03-26 16:21


The changes are being made to the BtOBEX_TransportConnect function which ods doesnt use - I think ods reimplements this bluez-openobex interface using a file transport as a buffer between the two (maybe to use the bluez dbus api instead of the deprecated lower-level hci api?)

Interestingly, I seem to be getting different errors via openobex for refusals and broken connections (ECONNREFUSED & EHOSTDOWN)

RobertRawlins (инициатор)
2008-03-26 16:32

Hmm, that is interesting.

In the past I've used ussp-push and that gives a whole load of scrambled output but from memory it also gave varied output if the host was down compared to if it was refused, I dont know that for sure though.

Its a real shame that we dont have a SIG in the industry which could enforce standard behaviour for these kind of things, it would make life a million times simpler of all the manufacturers of handsets and other server devices would conform to a standard.

heston_james (инициатор)
2008-04-04 16:54

Morning All!

I just started using Obex-Data-Server this morning for the first time, really excelent stuff! A D-bus implementation makes a great deal of sense and really seems quite intuetive.

I had noticed this bug myself and just came on to report it and notice you have pipped me to the post and the proposed solution sounds excelent. :-D

How is the progress on a solution for this comming along? anything you would like me to take a look at for you? I'm keen to get this nailed out as soon as possible as it'll no doubt prove a real benefit.


skirsdeda (администратор)
2008-04-04 19:57

Expect 0.4 release by May/June. I have a good idea how to fix this and other issues, except 0000046. So if you want to help, you can try nailing that one down :)
heston_james (инициатор)
2008-04-14 12:42

Hey Skirsdeda,

I've been looking at this stuff over the weekend and think I've managed to find a few key factors in implementing this. It would seem that in ods_bluez_client_socket_connect_cb() there is a argument called 'cond' which is passed in. This argument defines the result of the RFCOMM connection request to the remote device, and it appears as if the following values are returned.

cond = 4 when the RFCOMM socket was connected successfully.
cond = 20 when the RFCOMM socket connection times out.
cond = 28 when the FRCOMM socket connection is refused by the remote device.

In addition to this, I've also noticed the issue we have discussed in the past about dbus throwing a timeout just before the RFCOMM connection times out. I think this is because at present CreateBluetoothSession() is set to return a value _and_ broadcast a signal ‘SessionCreated’ when the session is created.

In my mind, CreateBluetoothSession() should only do one or the other. In this case I would think it should not be set to return a value, this would mean that DBUS would not throw a timeout error when trying to connect to the RFCOMM socket takes a while. Developer will then have to listen for the SessionCreated signal from the manager before they create a connection to the session object.

In my mind, ods_bluez_client_socket_connect_cb() should, instead of calculating FD and passing that into ods_manager_client_socket_connect_cb() should just pass ‘cond’ instead.

Then, ods_manager_client_socket_connect_cb() should have a switch/case statement which looks at cond and does one of three things:

1) If cond = 4 then it creates a session object and emits the SessionCreated signal with the path to the session object.
2) If cond = 20 then no session object is created and SocketConnectTimeout signal is emitted.
3) If cond = 28 then no session object is created and SocketConnectRefused signal is emitted.
4) If cond = anything else then no session object is created and SocketConnectError signal is emitted.

This, in theory I would think would be much simpler to implement than placing all this into the session object. It means that a session is only every created if an RFCOMM connection is successfully established with the remote device, if one is not, then no session object is created and we are given a signal to let us know why.

What do you think?

skirsdeda (администратор)
2008-04-14 15:00

Heston, thanks for you effort. I promise to look into this as soon as I have some spare time.
heston_james (инициатор)
2008-04-14 15:21

You're more than welcome Skirsdeda. I'll spend some time this evening looking a little deeper into this to see what I can find, If I produce anything interesting I'll be sure to attach a patch.

heston_james (инициатор)
2008-04-21 15:37

I now have a working and tested solution for both this and bug 19.

I'll post a patch for them both later this afternoon when I have chance to generate it.

heston_james (инициатор)
2008-04-21 19:42

Ok, here we go, lets see if this brings us any good luck.

I've attached 2 files, the first of which is a PATCH which should be run against the current SVN checkout. This makes some substantial changes to the ods_manager class. It adds 3 new signals to the class which can be listened for.

SocketConnectRefused(string remote_device_address)
SocketConnectTimeout(string remote_device_address)
SocketConnectError(string remote_device_address)

also, CreateBluetoothSession no longer returns the session path which is created. It now returns immediatly with VOID, this is to solve the timeout problems which are documented in bug report 19.

The session path for the session object, if one is indeed created is given in the SessionCreated(string session_path) signal, in your connecting applications you should use this signal to connect to the session object.

I've attached a python script which shows how this new API implementation should be used. I've used this scripts to test the code changes pretty well and not seen any problems thrown by ods.

This is by no means a final solution however does work as a proof of concept, I look forward to getting your feedback on it.

skirsdeda (администратор)
2008-04-21 20:13
изменен: 2008-04-21 20:14

Some thoughts about patch:
1) It is theoretically possible to have concurrent connections being established to the same device so your signals (SocketCOnnectRefused, etc.) might make it impossible to distinguish to which CreateBluetoothSession call they correspond (asuming that you have concurrent applications calling using ods and calling CreateBluetoothSession)

2) These signals are only related to session creation so why they are called "SocketConnect..." and not smth like "Session..."

3) I don't see why you need 3 separate signals when you could simply have ConnectError which would return different errors (org.openobex.Error.ConnectionRefused, org.openobex.Error.Timeout, etc.)

4) This patch doesn't solve the problem where we have race condition (described in note 180 of this bug)

5) Use macros like G_IO_OUT instead of numbers in socket_connect_cb (ods-bluez)

How this should be fixed:
1) CreateBluetoothSession should return Session object (note that session object can be created with fd=-1 and it will do nothing until you set it's "fd" property to real socket (>=0))

2) use one signal instead of 3 (e.g. SessionCreateError). Signal should return session object path instead of device address.

3) SessionCreated signal should be emitted only after socket is successfully connected and Connected signal on Session object is emitted.

heston_james (инициатор)
2008-04-22 12:17

Hi Skirsdeda,

Those are all very valid points. I like the idea about consolidating the 3 signals into one and then changing then passing different error, this makes a great deal of sense and would be simple enough to do.

I'll play around with these concepts this afternoon and work on implementing some of your suggestions.

nbransby (инициатор)
2008-04-23 14:33

My two cents...

Detecting a timeout or a refusal it not as easy as it seems because different phones use different methods.

For example, a Nokia will reply with ETIMEDOUT after 30 seconds when timing out, so far so good. But a samsung will reply with ECONNREFUSED after 15 seconds when timing out. So if a samsung returns with ECONNREFUSED after 15 seconds you can presume it was a timeout and not a refusal.

These are also two examples of phones that block (to display a prompt) on connection. Different phones (such as sony and lg) let you connect to the OPP service and then block on the obex PUT request. You have to account for this too when deciding between timeouts and refusals.

So unless you are able to test every model of handset out there its hard to tell the difference.

I would say the best way to implement this would be to throw a org.openobex.Error.Timeout on receiving a ETIMEDOUT or OBEX_RSP_REQUEST_TIME_OUT and throw a org.openobex.Error.ConnectionRefused on receiving a ECONNREFUSED or OBEX_RSP_FORBIDDEN.

This wouldn't work on all models of phone but its how it should work (and maybe the manafacturer will fix their phones one day!!)

heston_james (инициатор)
2008-04-23 16:08


You're quite right on this. As none of the manufacturers seem to conform to a standard set of rules we'll have to base all this work on the assumtion that we're going to catch the widest audience possible.

I think we should work on that principle of to throw a org.openobex.Error.Timeout on receiving a ETIMEDOUT or OBEX_RSP_REQUEST_TIME_OUT and throw a org.openobex.Error.ConnectionRefused on receiving a ECONNREFUSED or OBEX_RSP_FORBIDDEN.

Cheers Nick,

heston_james (инициатор)
2008-05-04 14:27

Good morning all,

I've been looking at this issue again this morning and trying to work things out in my head. As part of my more thorough testing on this I applied the patch for bug 52 which allows us to select the HCI device we're sending with.

I've noticed some strange behaviour that when refusing RFCOMM connections on the remote device that every successive connection attempt keeps on throwing the 'Binding to local device (adapter) failed'. Would this suggest that we're not freeing something up?

Skirs, with regards to the race condition issue, I did some simple testing yesterday after removing the auto connect code from the session, its quite a simple mod and I think is definitly the best way to solve the race condition.

Any thoughts on the binding to the local device would be greatly appreciated.

heston_james (инициатор)
2008-05-04 15:16


Another thing I wanted to try and clarify with you before I start moving things around is where the signals should be emited from. This ConnectError() signal that we're talking about, should this be in the Session object?

I see that what we need to do is have ods_manager_create_bluetooth_session() just create a session object and return it straight away so we dont have any timeout issues, then the RFCOMM socket connection should be done in the Session object from the Connect() method, then we're iether emmit one of two signals from the Session object, iether the Connected() signal, or the ConnectError(Error Details) if the socket connect doesnt work out.

Is that what you were thinking? or did you have a different plan?

skirsdeda (администратор)
2008-05-04 17:35

No, ConnectError() signal should be in Manager object. Although Session object would be returned straight away, it wouldn't be used until it's connected and _Manager_ object emits SessionConnected() signal.
heston_james (инициатор)
2008-05-12 14:58

Morning Gang,

Another question regarding your thoughts on a solution to this Skirs. Were should the RFCOMM connection process be initiated from? at the moment it is called by the manager, however, if we're having the session object emmit signals as to the result of the connection attempt whould the RFCOMM be established by the session in its connect() method? is that how you see it?

One more. Lets suppose that we successfully connect to the server and send the first file transfer request but then the server moves out of range, will the sesison be able to detect this and close itself and free up the RFCOMM socket? I'm just trying to understand how that will work.

skirsdeda (администратор)
2008-05-12 17:13

RFCOMM connection should be initiated from Manager object. Session is already able to detect when server goes out of range (LinkError).
heston_james (инициатор)
2008-05-12 17:17

Ok, Thanks Skirs, I think I have this clear in my head now.

I'm in the process of making these changes now, the only thing I'm a little unsure about at the moment is how to use the macros as you have suggested but I'll give you a shout when I get to that point and get your thoughts.

heston_james (инициатор)
2008-05-12 18:27

Whilst working on this code another question has come to mind:

In my last patch I made the addition of broadcasting the remote device's address in the ConnectFailed() and ConnectTimeout() signals so that we could determine which device the connection attempt failed on.

How do you think this should be handled? I know my own personal requirements for ods means it is nececary for me to track which connection attempts file and which were successfull so I can reattempt if it fails.

Got any ideas or thoughts on how to handle this?

skirsdeda (администратор)
2008-05-12 18:28

since Session object is created early on, ConnectFailed, ConnectTimeout should return Session object dbus path.
heston_james (инициатор)
2008-05-12 18:31

I see, and presumably in our higher level applications we can simply use GetSessionInfo() to get the address and any other details we may require.

Makes sense.

heston_james (инициатор)
2008-05-14 11:50


This might seem like a silly question but I'm struggling to find an answer to it. When creating the ConnectError() signal which will be emited if the RFCOMM cannot be established the place was to have:

ConnectError(SessionPath, ErrorName, ErrorMessage)

However, when working on creating the signal for this it seems that thier isnt any dbus signature available for STRING_STRING_STRING.

How would you like me to approach this?

skirsdeda (администратор)
2008-05-14 12:41

there is ods-marshal.list where you define custom signatures. In code you use sigs from auto-generated ods-marshal.h
heston_james (инициатор)
2008-05-14 12:56

Oh Neat! that's very simple. I've added the custom STRING_STRING_STRING into the ods-marsgal.list file so with any luck that should work for me.

Next quick question, just to ensure we're thinking in the same way. In ods manager I was thinking about adding a new method called session_connected_cb() which will be attached to the connected() signal of the session objects. This method when called adds the session to the managers session list and emmits the SESSION_CREATED signal. Does that sound like the best way to handle that?
skirsdeda (администратор)
2008-05-14 12:57

yes, the way to go
heston_james (инициатор)
2008-05-14 14:54

Ok, this fix is now slowly starting to take shape I think, with any luck we'll have something working by the end of the day.

I'm stuck on a couple of issues at the moment that I would appreciate your thoughts on.

In the session_connected_cb (OdsSession *session, OdsManager *manager) that we talked about above we are provided with two arguments. Within this function I am looking to call ods_manager_session_list_add (OdsManager *manager, OdsSession *session, const gchar *bluetooth_address, const gchar *dbus_owner, const gchar *dbus_path) in order to add the newly connected session to the managers list.

How can I gain access to the bluetooth_address, dbus_owner and dbus_path for the session object from the two (OdsSession *session, OdsManager *manager) arguments? At the moment I cant figure it out. Am I missing somthing?

The second challenge comes with changing the fd of the session object from client_socket_connected_cb(). At the moment I cant see any obvious ways to change the fd. Do we need to create a new function on the session object to allow us to do so? or can we work something out by making ods_session_set_property() public so the other objects can call it? The session object should then autoconnect when the fd is changed to a figure greater than 0, correct?

I'd appreciate your input and I can then make some more progress.

Cheers Skirs,

heston_james (инициатор)
2008-05-14 17:59

As an additional note. Something in our current plan doesnt work quite right. We have talked about having the session path returned in the ConnectError() method like so.

ConnectError(session_path, error_name, error_message)

This would then enable developers using ODS to tell which device the connection attempt failed for by using the GetSessionInfo() function on the manager.

Unfortunatly, we've also planned that we wont add the session to the managers internal list untill it is connected successfully. This means that when the connection encounters an error we will not be able to use GetSessionInfo() to aquire the sessions address.

We need to rethink how this works a little.

skirsdeda (администратор)
2008-05-14 18:32

bluetooth_address and dbus_owner should be available in Manager when connecting. You can get dbus_path and set fd by using Session properties (use g_object_get and g_object_set). About ConnectError, think of smth :)
heston_james (инициатор)
2008-05-14 18:39

Ok, that makes good sense. I'm new to C so I wasnt aware of the g_object_get and g_object_set methods, I'm sure they will work fine for setting the FD and getting the session path.

Just out of interest, is there any reason why we dont make bluetooth_address and dbus_owner properties of the SessionObject? It would make sense and also simplify quite a few things.

Another quicky, at which point can we free the session objects when a connection fails? presumably we need to keep them alive long enough to be able to retrieve information from then but will also need to destroy them at some point?.

skirsdeda (администратор)
2008-05-14 18:41

Session object is transport agnostic. That is, session doesn't know anything about bluetooth, infrared or any other transport stuff.
heston_james (инициатор)
2008-05-14 19:25

Oh of course, I sometimes forget that its a multi-transport platform. :-)
heston_james (инициатор)
2008-05-15 11:48

Morning Skirs,

I spent an hour or so last night working with some of the advice you gave me and I've managed to implement a few of the changes that we have discussed, however, I've now become a little lost. I'm just building my changes into the latest SVN checkout so I can attach a patch.

1) I've added the new custom error classes for ODS_ERROR_CONNECTION_REFUSED and ODS_ERROR_CONNECTION_TIMEOUT which we will use to post the appropriate error to ConnectError()

2) I've added the ConnectError() signal to the manager object so that it can be emmited.

3) I've modified CreateBluetoothSession() so that it creates a session object and returns its path immediatly. OdsManagerCreateBluetoothSessionData has also been modified as we no longer need much of the information which was contained within it.

4) I've made some minor changes to ods_bluez_socket_connect_cb() which evaluates the connection condition and sets the appropriate error, this still uses numbers though, I know you wanted to use macros like G_IO_OUT but unfortunatly I've not much experiance with that stuff, perhaps you can show me?. :-)

5) In ods-manager.c we now have a method called session_connected_cb() which is called when a session object emmits its 'connected' signal, this then broadcasts the SessionCreated() signal from the manager.

6) Finally, ods_manager_socket_connect_cb() has now been changed so that it evaluates to see if an error was set during the connection process, if one was then it emmits the ConnectError() signal with the session path and the error details. If no error was found during the connection attempt then it connects to the sessions signals and sets the FD property to a real channel and the session then auto connects itself.

It will likely be rough code but I really need some more thoughts from you to go any further with it. I've also not yet worked on how and when the session should be added to the managers list, at the moment its added as soon as CreateBluetoothSession creates the session object.

Please find attached a patch for the work so far, give them a once over and we can have a little review session.


heston_james (инициатор)
2008-05-19 11:02

Good morning everyone!

I hope you've all had a pleasant weekend. It's nice to see a bunch more developers active on the list, could become very productive.

Has anyone had chance to look through this patch/bug over the weekend? I'm working towards the completion of a project for a client this comming thursday and could really do with solving this issue in time to give them the BETA build of my app.

Cheers everyone,

heston_james (инициатор)
2008-05-27 11:51

Morning chaps,

Sorry to poke again at this issue again but I could really use a little help on it. I know its listed a 'minor' but this is actualy quite an important issue for those looking to use ODS as an opp client.

Does anyone have any thoughts?
skirsdeda (администратор)
2008-05-27 15:38
изменен: 2008-05-27 15:39

I think it is better to concentrate on fixing bugs now and release 0.3.2. Then we can look at this issue and decide on all API changes for 0.4 release. This bug (as well as 0000019 and maybe 0000084) will be the most important when we start working on 0.4.

heston_james (инициатор)
2008-05-27 15:52

Hi Skirs,

Thank you for getting back to me, I appreciate it. Do we have any idea of a timescale for when this work will go ahead? I only ask as this is an essential part of an application we've been developing for a client and its currently holding up the project.

Cheers mate,

skirsdeda (администратор)
2008-06-29 00:40

I'm picking this up. Should be done in a few days.
heston_james (инициатор)
2008-06-29 12:58

I've got a big wet kiss waiting here for you when its working.

skirsdeda (администратор)
2008-07-01 10:45

This is almost done with one small problem remaining to be fixed. Not yet in svn though..

So Manager will now have these signals: SessionCreated, SessionRemoved, SessionConnectError. Not sure if naming is good, maybe SessionCreated should be renamed to SessionConnected. CreateBluetoothSession will return Session object at once (before connecting begins). Session object will no longer have Connect(), IsConnected() methods. Session.Connected() signal removed too. When creating Session you'll have to listen for SessionCreated and SessionConnectError signals. SessionCreated gets signaled only after socket and OBEX connection is fully established, if not successful SessionConnectError is emitted instead.
heston_james (инициатор)
2008-07-01 11:19

That sounds good to me Skirs,

I'm thinking that SessionConnected() is likely to be a better name for the signal which is emmited when the session is connected.

Presumably the session object will dispose of itself if a connection error occurs and we wont have to call anything on it manualy?

All sounds great though. I've been trying to sign into IRC this morning but freenode wont let me on, I'll keep trying and we'll no doubt catch up shortly.

Cheers Skirs,

skirsdeda (администратор)
2008-07-01 11:22

Yes, session will be disposed when connection error occurs.
heston_james (инициатор)
2008-07-01 11:22

skirsdeda (администратор)
2008-07-02 03:28

It's finally in subversion. not fixed yet. dbus-api.txt updated.

Manager signals:

Session no longer has Connect(), IsConnected(), Connected signal!

I'm thinking about removing Session.Close() as well and consider Session non-valid as soon as it is disconnected.

Please test ! :D
heston_james (инициатор)
2008-07-02 11:44

Hi Skirs,

I made the changes to my test scripts yesterday to reflect the new API changes so Im pretty much ready to go. I'll be testing this in a few environments today, I'll report back with my findings when I have some information.


heston_james (инициатор)
2008-07-02 12:28

Hi Skirs,

The implementation looks very nice. I've got one 'bug' which I've found and also a question regarding this change.

1) I need to access the session info struct for the bluetooth addresses after a connection attempt has failed. However, when trying to use GetSessionInfo() with the session path returned in the SessionConnectError() signal I just get an empty structure, I can only assume the session has been dispoed of before I attempt to access that information?

2) What are the available error_name's which are returned in the SessionConnectError() signal? Do you have a list of them? what do they represent?

Cheers Skirs,

heston_james (инициатор)
2008-07-03 17:07


After doing some more testing with this solution this morning it appears that whilst we are now catching failed connection attempts it doesnt correctly report if they are refused or just timeouts

When testing here with Nokia handsets, regardless of whether we physicaly refuse the connection or it times out we get the same generic error message returned:

org.openobex.Error.ConnectionAttemptFailed, Connection failed

Is this what we should expect? I know the code implementation I worked on would return:

org.openobex.Error.ConnectionAttemptFailed - When a generic error occured.
org.openobex.Error.ConnectionRefused - When the connection was declined by the user.
org.openobex.Error.ConnectionTimeout - when the remote device, such as a nokia times out the connection after 20-30 seconds.


skirsdeda (администратор)
2008-07-03 17:15

do svn up and try all the conditions again. There should be a line in ods output in form of "cond=%d, checking for %d, %d, %d". Post it here.
heston_james (инициатор)
2008-07-03 18:08

Hi Skirs,

Here is the output from ods for the diferent conditions:

Timeout - ** Message: cond=20, checking for 4, 0, 0
Refused - ** Message: cond=28, checking for 4, 0, 0
Accepted - ** Message: cond=4, checking for 4, 0, 0


skirsdeda (администратор)
2008-07-03 18:10

Commited a fix, should work now
heston_james (инициатор)
2008-07-03 18:27

Excelent, that now appears to return the appropriate errors for timeouts and refused.

Excelent work Tadas,

manuel (инициатор)
2008-07-12 18:44

Hello guys,

We have been discussing this with Tadas, I've been investigating on ways to add information to the error signal, and I'm afraid to say we can't.

Only suggestion I can think of is adding the error number to the error description, besides that there's no way to add extra data so you can retrieve the SessionInfo.

In case user code wants to trace what's going on, and tell who failed, then user code (not ODS) should have a dictionary with session ids, status, and some extra information (like bluetooth address for example), so then when the connection attempt is rejected you can tell what happened.

Manuel Naranjo
Wireless Cables Inc.
heston_james (инициатор)
2008-07-12 19:02

Hi Manuel,

I agree with you, I was trying to figure out how to do this in ods but couldnt come up with any ideas that would'nt ultimatly become a memory leak :-) Albiet a slow one, or one that would require a tricky API which allows the user to dispose of the session data once they'd finished with it.

I have been working on your exact suggested principle that I create my own session list in my higher level application which tracks the remote device details against the session path, then when the session fails I can use the session path passed back in the error signal to pull the remote decvies details from my own internal list.

It works a charm, just means a few lines of extra code in my app, nothing that scares me.

heston_james (инициатор)
2008-07-21 18:25


This can probably be closed off now as it appears to work nicely.


- история
Дата изменения Пользователь Поле Изменение
2008-02-27 13:13 RobertRawlins Новый вопрос
2008-02-27 16:31 hadess Отслеживать: hadess
2008-03-01 01:55 skirsdeda Состояние новый => отработан
2008-03-01 01:55 skirsdeda Решение открыт => решению не подлежит
2008-03-01 01:55 skirsdeda Ответственный => skirsdeda
2008-03-01 01:55 skirsdeda Комментарий добавлен: 0000090
2008-03-03 13:38 RobertRawlins Состояние отработан => нужен отклик
2008-03-03 13:38 RobertRawlins Решение решению не подлежит => повторно открыт
2008-03-03 13:38 RobertRawlins Комментарий добавлен: 0000117
2008-03-03 13:48 RobertRawlins Отслеживать: RobertRawlins
2008-03-03 16:27 skirsdeda Комментарий добавлен: 0000118
2008-03-03 16:41 RobertRawlins Комментарий добавлен: 0000119
2008-03-04 01:24 skirsdeda Комментарий добавлен: 0000123
2008-03-04 10:36 RobertRawlins Комментарий добавлен: 0000125
2008-03-05 21:19 skirsdeda Комментарий добавлен: 0000126
2008-03-06 13:10 RobertRawlins Комментарий добавлен: 0000131
2008-03-06 22:50 skirsdeda Комментарий добавлен: 0000141
2008-03-07 12:57 RobertRawlins Комментарий добавлен: 0000145
2008-03-09 16:24 RobertRawlins Комментарий добавлен: 0000152
2008-03-11 14:22 darwish Комментарий добавлен: 0000153
2008-03-11 16:45 RobertRawlins Комментарий добавлен: 0000154
2008-03-11 17:26 darwish Комментарий добавлен: 0000155
2008-03-11 18:20 skirsdeda Связь добавлена блокирует 0000058
2008-03-11 18:40 skirsdeda Комментарий добавлен: 0000157
2008-03-11 18:40 skirsdeda Состояние нужен отклик => назначен
2008-03-11 18:41 skirsdeda Комментарий изменен: 0000157
2008-03-11 20:11 RobertRawlins Комментарий добавлен: 0000159
2008-03-11 20:28 darwish Комментарий добавлен: 0000160
2008-03-11 22:30 skirsdeda Комментарий добавлен: 0000161
2008-03-11 22:32 skirsdeda Серьезность нововведение => малая
2008-03-11 23:13 RobertRawlins Комментарий добавлен: 0000162
2008-03-12 00:06 nbransby Комментарий добавлен: 0000163
2008-03-12 01:42 nbransby Комментарий изменен: 0000163
2008-03-12 11:33 RobertRawlins Комментарий добавлен: 0000164
2008-03-12 14:27 RobertRawlins Комментарий добавлен: 0000165
2008-03-12 19:15 skirsdeda Комментарий добавлен: 0000166
2008-03-12 19:20 RobertRawlins Комментарий добавлен: 0000167
2008-03-12 19:20 skirsdeda Комментарий добавлен: 0000168
2008-03-12 19:44 hadess Комментарий добавлен: 0000169
2008-03-12 20:05 RobertRawlins Комментарий добавлен: 0000170
2008-03-12 20:26 skirsdeda Комментарий добавлен: 0000171
2008-03-12 20:35 RobertRawlins Комментарий добавлен: 0000172
2008-03-17 14:02 RobertRawlins Комментарий добавлен: 0000174
2008-03-18 16:52 nbransby Комментарий добавлен: 0000175
2008-03-19 16:49 RobertRawlins Комментарий добавлен: 0000176
2008-03-19 18:42 skirsdeda Комментарий добавлен: 0000177
2008-03-20 15:21 RobertRawlins Комментарий добавлен: 0000178
2008-03-25 15:29 nbransby Комментарий добавлен: 0000179
2008-03-25 16:21 skirsdeda Комментарий добавлен: 0000180
2008-03-25 17:26 nbransby Комментарий добавлен: 0000182
2008-03-25 17:28 RobertRawlins Комментарий добавлен: 0000184
2008-03-25 17:29 skirsdeda Комментарий добавлен: 0000185
2008-03-25 18:05 nbransby Комментарий добавлен: 0000187
2008-03-25 23:03 RobertRawlins Комментарий добавлен: 0000188
2008-03-26 01:08 skirsdeda Комментарий добавлен: 0000189
2008-03-26 12:05 RobertRawlins Комментарий добавлен: 0000190
2008-03-26 15:53 RobertRawlins Комментарий добавлен: 0000196
2008-03-26 16:21 nbransby Комментарий добавлен: 0000197
2008-03-26 16:32 RobertRawlins Комментарий добавлен: 0000198
2008-04-04 16:54 heston_james Комментарий добавлен: 0000200
2008-04-04 19:57 skirsdeda Комментарий добавлен: 0000201
2008-04-14 12:42 heston_james Комментарий добавлен: 0000217
2008-04-14 15:00 skirsdeda Комментарий добавлен: 0000218
2008-04-14 15:21 heston_james Комментарий добавлен: 0000219
2008-04-21 15:37 heston_james Комментарий добавлен: 0000220
2008-04-21 19:42 heston_james Комментарий добавлен: 0000221
2008-04-21 19:43 heston_james Файл добавлен: rfcomm_reports.patch
2008-04-21 19:44 heston_james Файл добавлен:
2008-04-21 20:13 skirsdeda Комментарий добавлен: 0000222
2008-04-21 20:14 skirsdeda Комментарий изменен: 0000222
2008-04-21 20:14 skirsdeda Комментарий изменен: 0000222
2008-04-22 12:17 heston_james Комментарий добавлен: 0000223
2008-04-23 14:33 nbransby Комментарий добавлен: 0000224
2008-04-23 16:08 heston_james Комментарий добавлен: 0000225
2008-05-04 14:27 heston_james Комментарий добавлен: 0000226
2008-05-04 15:16 heston_james Комментарий добавлен: 0000227
2008-05-04 17:35 skirsdeda Комментарий добавлен: 0000228
2008-05-12 14:58 heston_james Комментарий добавлен: 0000231
2008-05-12 17:13 skirsdeda Комментарий добавлен: 0000233
2008-05-12 17:17 heston_james Комментарий добавлен: 0000234
2008-05-12 18:27 heston_james Комментарий добавлен: 0000235
2008-05-12 18:28 skirsdeda Комментарий добавлен: 0000236
2008-05-12 18:31 heston_james Комментарий добавлен: 0000237
2008-05-14 11:50 heston_james Комментарий добавлен: 0000245
2008-05-14 12:41 skirsdeda Комментарий добавлен: 0000246
2008-05-14 12:56 heston_james Комментарий добавлен: 0000247
2008-05-14 12:57 skirsdeda Комментарий добавлен: 0000248
2008-05-14 14:54 heston_james Комментарий добавлен: 0000249
2008-05-14 17:59 heston_james Комментарий добавлен: 0000250
2008-05-14 18:32 skirsdeda Комментарий добавлен: 0000251
2008-05-14 18:39 heston_james Комментарий добавлен: 0000252
2008-05-14 18:41 skirsdeda Комментарий добавлен: 0000253
2008-05-14 19:25 heston_james Комментарий добавлен: 0000254
2008-05-15 11:48 heston_james Комментарий добавлен: 0000255
2008-05-15 11:49 heston_james Файл добавлен: second_attempt.patch
2008-05-19 11:02 heston_james Комментарий добавлен: 0000260
2008-05-27 11:51 heston_james Комментарий добавлен: 0000282
2008-05-27 15:38 skirsdeda Комментарий добавлен: 0000283
2008-05-27 15:39 skirsdeda Комментарий изменен: 0000283
2008-05-27 15:52 heston_james Комментарий добавлен: 0000284
2008-06-29 00:40 skirsdeda Комментарий добавлен: 0000326
2008-06-29 12:58 heston_james Комментарий добавлен: 0000328
2008-07-01 10:45 skirsdeda Комментарий добавлен: 0000330
2008-07-01 11:19 heston_james Комментарий добавлен: 0000331
2008-07-01 11:22 skirsdeda Комментарий добавлен: 0000332
2008-07-01 11:22 heston_james Комментарий добавлен: 0000333
2008-07-02 03:28 skirsdeda Комментарий добавлен: 0000334
2008-07-02 11:44 heston_james Комментарий добавлен: 0000335
2008-07-02 12:28 heston_james Комментарий добавлен: 0000336
2008-07-03 17:07 heston_james Комментарий добавлен: 0000340
2008-07-03 17:15 skirsdeda Комментарий добавлен: 0000341
2008-07-03 18:08 heston_james Комментарий добавлен: 0000343
2008-07-03 18:10 skirsdeda Комментарий добавлен: 0000345
2008-07-03 18:27 heston_james Комментарий добавлен: 0000347
2008-07-12 18:44 manuel Комментарий добавлен: 0000359
2008-07-12 19:02 heston_james Комментарий добавлен: 0000360
2008-07-21 18:25 heston_james Комментарий добавлен: 0000378
2008-07-24 15:00 skirsdeda Целевая версия => 0.4
2008-07-25 03:53 skirsdeda Состояние назначен => отработан
2008-07-25 03:53 skirsdeda Решение повторно открыт => решен
2008-07-25 03:53 skirsdeda Решен в версии => 0.4
2008-10-17 19:59 skirsdeda Состояние отработан => закрыт

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker