Bluetooth obex push is using chunks of 666bytes while N9 is using 32K

Bug Reports
,
1

REPRODUCIBILITY (% or how often): 100%
BUILD ID = OS VERSION (Settings > About product): 3.3.0.16 - 4.3.0.12
HARDWARE (XA2, X10, X10 II, …): X and X 10 II
UI LANGUAGE: English
REGRESSION: (compared to previous public release: Yes, No, ?): ?

DESCRIPTION:

I was playing recently a lot with OBEX PUSH and while running obexd in debug mode I noticed that old Nokia N9 transfers files in chunks of 32K, while Xperia X (3.3.0.16) and X 10 II (4.3.0.12) transfer at 666B.

This is resulting in longer transfer time.

PRECONDITIONS:

obexd running and configure on the linux machine:

/usr/lib/bluetooth/obexd -d -n -l -r Downloads -a

STEPS TO REPRODUCE:

  1. Start the obexd on the target machine
  2. Start bluetooth on the X device
  3. Select image to share
  4. choose Bluetooth
  5. choose the target device
  6. look at the debugging of obexd in the linux console

EXPECTED RESULT:

chunks of 32K

ACTUAL RESULT:

chunks of 666Bytes

ADDITIONAL INFORMATION:

(Please ALWAYS attach relevant data such as logs, screenshots, etc…)

10 Likes
2

I think may be the easiest way is to run strace on the obexd on the target machine?

Xperia:
write(8, "\334\215N\25\230sO\7\r\234\220=(R1\324\37j\27\3\336\246a\21I \365\350{R\253\226"..., 666) = 666

N9 is not booting anymore

See also this issue [BT] slow file transfer - #9 by deloptes

3

Xperia 10 II Sailfish
Debian Bulsseye up to date

 uname -v
#1 SMP Debian 5.10.158-2 (2022-12-13)

I now remember what I did exactly to debug obex:

    /usr/libexec/bluetooth/obexd --debug -n -a -l -r Downloads

then sending one file from the phone gives following

    obexd[2971922]: obexd/src/obex.c:recv_data() name=20230106_173705.jpg type=(null) file=0x8 size=666
    obexd[2971922]: obexd/src/obex.c:driver_write() 666 written
    obexd[2971922]: obexd/src/obex.c:recv_data() name=20230106_173705.jpg type=(null) file=0x8 size=666
    obexd[2971922]: obexd/src/obex.c:driver_write() 666 written
    obexd[2971922]: obexd/src/obex.c:recv_data() name=20230106_173705.jpg type=(null) file=0x8 size=666
    obexd[2971922]: obexd/src/obex.c:driver_write() 666 written
    obexd[2971922]: obexd/src/obex.c:recv_data() name=20230106_173705.jpg type=(null) file=0x8 size=666
    obexd[2971922]: obexd/src/obex.c:driver_write() 666 written
    obexd[2971922]: obexd/src/obex.c:recv_data() name=20230106_173705.jpg type=(null) file=0x8 size=207
    obexd[2971922]: obexd/src/obex.c:driver_write() 207 written
    obexd[2971922]: obexd/src/obex.c:transfer_complete()
    obexd[2971922]: obexd/src/obex.c:cmd_disconnect() session 0x561de27496d0
    obexd[2971922]: DISCONNECT(0x1), (0xff)
    obexd[2971922]: DISCONNECT(0x1), Success(0x20)
    obexd[2971922]: disconnected: Transport got disconnected
    obexd[2971922]: obexd/src/obex.c:obex_session_destroy()

in contrast sending one from the N9, which booted today gives following

obexd[2972806]: obexd/src/obex.c:recv_data() name=19090016.jpg type=(null) file=0x8 size=32567
obexd[2972806]: obexd/src/obex.c:driver_write() 32567 written
obexd[2972806]: obexd/src/obex.c:recv_data() name=19090016.jpg type=(null) file=0x8 size=32567
obexd[2972806]: obexd/src/obex.c:driver_write() 32567 written
obexd[2972806]: obexd/src/obex.c:recv_data() name=19090016.jpg type=(null) file=0x8 size=32567
obexd[2972806]: obexd/src/obex.c:driver_write() 32567 written
obexd[2972806]: obexd/src/obex.c:recv_data() name=19090016.jpg type=(null) file=0x8 size=28886
obexd[2972806]: obexd/src/obex.c:driver_write() 28886 written
obexd[2972806]: obexd/src/obex.c:transfer_complete()
obexd[2972806]: obexd/src/obex.c:cmd_disconnect() session 0x55ede218be30
obexd[2972806]: DISCONNECT(0x1), <unknown>(0xff)
obexd[2972806]: DISCONNECT(0x1), Success(0x20)
obexd[2972806]: disconnected: Transport got disconnected
obexd[2972806]: obexd/src/obex.c:obex_session_destroy()

so my guess is that the sending part is responsible for the packet size, thus there must be something in the sending side.

4

Added to internal tracker

4 Likes
5

Summer time - so I could allocate few hours on this matter and I’m looking again into this. I am wondering, if the size was deliberately reduced, because it is going through D-Bus now.

However as Christian I am offended by the number 666 … it’s like 13. why?!

In D-Bus it is exactly 666 bytes … and this is how the conspiracies start.

signal time=1688970851.908238 sender=:1.90 -> destination=(null destination) serial=10079 path=/org/bluez/obex/server/session5/transfer4; interface=org.fre
edesktop.DBus.Properties; member=PropertiesChanged
   string "org.bluez.obex.Transfer1"
   array [
      dict entry(
         string "Transferred"
         variant             uint64 1943
      )
   ]
   array [
   ]
signal time=1688970851.915463 sender=:1.90 -> destination=(null destination) serial=10080 path=/org/bluez/obex/server/session5/transfer4; interface=org.fre
edesktop.DBus.Properties; member=PropertiesChanged
   string "org.bluez.obex.Transfer1"
   array [
      dict entry(
         string "Transferred"
         variant             uint64 2609
      )
   ]
   array [
   ]
6

Oh, come on! If you are that easily offended, you probably should recalibrate your sensitivities.
To the average programmer, it is just another funny number like 42 and 1337.

2 Likes
7

They should make it 69 to make funny outside programming circles.

2 Likes
8

@attah I’m not making that much noise. I understand it could be a joke.
There are so many numbers <> 666, so why exactly this one … where is the code and the change log on that. I really want to know … because so many conspiracies turn out to be true after some time.
You can not drop any hypothesis until proving one to be true. Except respecting Christianity I own also a real university degree, obtained at the time when universities still had true education and professors. So to the average scientist this number has specific meaning.
I always knew programmers are ignorant, but you just proved it, by your statement. And I do not think I offend someone - it is what it is. Obviously it was not an avg. programmer doing this.

9

Well, this is funny, gut even with 666bytes transfer is much slower than it was in N9 with 32K packets.

I wish I knew where exactly it is coded.

10

You cannot possibly be serious. Literal satanists wanting to limit your transfer speed - that’s about as absurd as 5G giving people COVID.

I will remind you to criticize ideas, not people.

1 Like
11

The original number (in Revelation, not the code) is 616 anyway.

Be that as it may, I guess the relevant part of the code from the logging output is here and/or here.

1 Like
12

I think if you leave the theological and linguistic discussion aside you know exactly what I mean. It is commonly accepted to be 666

Regarding the references, I thank you, but it is not sufficient as it does not explain why it uses 666bytes at a time. I agree this is the place where it does the copy, but it is not clear why. I know I have to look into the size definitions, but you could have referred to the corresponding definition as well. It would be nice if you would do this next.

thank you

13

you are right, of course I am making fun of it. But we hardly have evidence for everything and what I learned at the university is that we should not stop asking why.

I am sure you have no proof regarding 5G and COVID, so do not make propositions that you can not prove. If everybody were following this rule, the internet and the world would be much better place. Think about it!

Where are the people, when referring to programmers? just joking.
It was a reply to your statement - “the average programmer”
And my statement is true not only for the average programmer but also the average person. Very unfortunately for the mankind. If NetFlix and youtube were promoting educational content, instead of BS, the situation could improve.
But we are getting OT here.
I really want to know where this is defined. Unfortunately I do not have the time to search in the code.