Open Source Telephony
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: [PATCH v1 7/8] hfp_hf_bluez5: Add rejecting SCO connection
Date: Tue, 29 Jan 2013 10:25:18 -0600	[thread overview]
Message-ID: <5107F7EE.6080500@gmail.com> (raw)
In-Reply-To: <CAKT1EBdEp1eBuhphdzeFo=PuMwJiWasumtp4Ywz3wcTrhWqREw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6884 bytes --]

Hi Claudio,

>>> This patch rejects the SCO incoming connection if there isn't a modem
>>> (service level connection) associated with the address.
>>
>>
>> Why service level connection is in parenthesis?
>
> I thought this additional information could be useful.
> No problem, I gonna remove it.
>

Actually the service level connection is important, the modem part is 
not.  Hence why I'm lost why it is in parenthesis.

<snip>

>>> +       bdaddr_t src;
>>> +       bdaddr_t dst;
>>> +};
>>
>>
>> What is src and what is dst? This is completely context dependent and
>> confusing.  Also, we are already storing the device address on the modem
>> object, why do we need this yet again?
>
> We use this standard in BlueZ for source and destination. It could be
> also sba and dba.
> Do you have another suggestion?

Then BlueZ is just plain weird.  Local and Remote would be way better names.

>
> Indeed, we already have the address stored in the modem, but it is the
> opposite thing of what Marcel is asking: avoid BT address stored using
> string format.
> If I use string to store the BT source address I will be blamed also,
> I did this for the PATCH v0. Please define how you want to store this
> data.
>

Whenever we store duplicate information, a question will be raised.  I 
see no point in doing it twice.

>>
>>
>>> +
>>> +struct sock_bdaddr {
>>> +       bdaddr_t src;
>>> +       bdaddr_t dst;
>>>    };
>>
>>
>> I'd really like to avoid this structure.  At the very least change the name
>> into something that conveys its purpose.  e.g. bdaddr_pair, or something.
>> The way it is now is just silly.
>
> If we get the Device address from the modem string this struct will
> not be necessary.
>
>>
>>>
>>>    static GHashTable *modem_hash = NULL;
>>> @@ -68,6 +75,21 @@ static GHashTable *devices_proxies = NULL;
>>>    static GDBusClient *bluez = NULL;
>>>    static guint sco_watch = 0;
>>>
>>> +static gboolean modem_bacmp(gpointer key, gpointer value,
>>> +                                               gpointer user_data)
>>> +{
>>> +       const struct sock_bdaddr *bda = user_data;
>>> +       struct ofono_modem *modem = value;
>>> +       struct hfp *hfp = ofono_modem_get_data(modem);
>>> +       int ret;
>>> +
>>> +       ret = bt_bacmp(&bda->dst,&hfp->dst);
>>>
>>> +       if (ret != 0)
>>> +               return FALSE;
>>> +
>>> +       return bt_bacmp(&bda->src,&hfp->src) != 0 ? FALSE : TRUE;
>>>
>>> +}
>>> +
>>>    static void hfp_debug(const char *str, void *user_data)
>>>    {
>>>          const char *prefix = user_data;
>>> @@ -275,14 +297,15 @@ static DBusMessage
>>> *profile_new_connection(DBusConnection *conn,
>>>    {
>>>          struct hfp *hfp;
>>>          struct ofono_modem *modem;
>>> +       struct sockaddr_rc src, dst;
>>> +       socklen_t alen;
>>>          DBusMessageIter iter;
>>>          GDBusProxy *proxy;
>>>          DBusMessageIter entry;
>>> -       const char *device, *alias, *address;
>>> +       const char *device, *alias;
>>> +       char device_address[18];
>>>          int fd, err;
>>>
>>> -       DBG("Profile handler NewConnection");
>>> -
>>>          if (dbus_message_iter_init(msg,&entry) == FALSE)
>>>
>>>                  goto invalid;
>>>
>>> @@ -301,11 +324,6 @@ static DBusMessage
>>> *profile_new_connection(DBusConnection *conn,
>>>
>>>          dbus_message_iter_get_basic(&iter,&alias);
>>>
>>> -       if (g_dbus_proxy_get_property(proxy, "Address",&iter) == FALSE)
>>>
>>> -               goto invalid;
>>> -
>>> -       dbus_message_iter_get_basic(&iter,&address);
>>> -
>>>          dbus_message_iter_next(&entry);
>>>          if (dbus_message_iter_get_arg_type(&entry) != DBUS_TYPE_UNIX_FD)
>>>                  goto invalid;
>>> @@ -314,7 +332,24 @@ static DBusMessage
>>> *profile_new_connection(DBusConnection *conn,
>>>          if (fd<   0)
>>>                  goto invalid;
>>>
>>> -       modem = modem_register(device, address, alias);
>>> +       memset(&src, 0, sizeof(src));
>>> +       alen = sizeof(src);
>>> +       if (getsockname(fd, (struct sockaddr *)&src,&alen)<   0) {
>>>
>>> +               close(fd);
>>> +               goto invalid;
>>> +       }
>>> +
>>> +       memset(&dst, 0, sizeof(dst));
>>> +       alen = sizeof(dst);
>>> +       if (getpeername(fd, (struct sockaddr *)&dst,&alen)<   0) {
>>>
>>> +               close(fd);
>>> +               goto invalid;
>>> +       }
>>> +
>>> +       bt_ba2str(&dst.rc_bdaddr, device_address);
>>> +       DBG("Profile handler NewConnection: %s", device_address);
>>> +
>>> +       modem = modem_register(device, device_address, alias);
>>>          if (modem == NULL) {
>>>                  close(fd);
>>>                  return g_dbus_create_error(msg, BLUEZ_ERROR_INTERFACE
>>> @@ -329,6 +364,8 @@ static DBusMessage
>>> *profile_new_connection(DBusConnection *conn,
>>>                                          "Not enough resources");
>>>
>>>          hfp = ofono_modem_get_data(modem);
>>> +       bt_bacpy(&hfp->src,&src.rc_bdaddr);
>>> +       bt_bacpy(&hfp->dst,&dst.rc_bdaddr);
>>>          hfp->msg = dbus_message_ref(msg);
>>>
>>
>> Fair enough, but this chunk really belongs in a separate patch.
>
> IMO it belongs to this patch since it is initializing a value that
> will be used to compare the addresses when the sco connection is
> accepted.
> But no problem, I can split it.
>

I'd like to see the profile_new_connection changes as a separate patch, 
this part can be there as well, not a biggie.

>>
>>
>>>          return NULL;
>>> @@ -384,7 +421,9 @@ static const GDBusMethodTable profile_methods[] = {
>>>    static gboolean sco_accept(GIOChannel *io, GIOCondition cond,
>>>                                                          gpointer
>>> user_data)
>>>    {
>>> -       struct sockaddr_sco saddr;
>>> +       struct ofono_modem *modem;
>>> +       struct sockaddr_sco src, dst;
>>> +       struct sock_bdaddr bda;
>>>          socklen_t alen;
>>>          int sk, nsk;
>>>
>>> @@ -393,14 +432,29 @@ static gboolean sco_accept(GIOChannel *io,
>>> GIOCondition cond,
>>>
>>>          sk = g_io_channel_unix_get_fd(io);
>>>
>>> -       memset(&saddr, 0, sizeof(saddr));
>>> -       alen = sizeof(saddr);
>>> +       memset(&dst, 0, sizeof(dst));
>>> +       alen = sizeof(dst);
>>>
>>> -       nsk = accept(sk, (struct sockaddr *)&saddr,&alen);
>>> +       nsk = accept(sk, (struct sockaddr *)&dst,&alen);
>>
>>
>> When reading this patch I go 'what the...'
>
> I am renaming it to follow a standard: src for source and dst for destination.
> But I can revert it, no problem.
>

This is a dual-initiator profile, src and dst are really bad names for this.

Regards,
-Denis

  reply	other threads:[~2013-01-29 16:25 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-28 14:44 [PATCH v0 0/9] External HFP: Add SCO Claudio Takahasi
2013-01-28 14:44 ` [PATCH v0 1/9] bluez5: Add SCO socket declarations Claudio Takahasi
2013-01-28 14:44 ` [PATCH v0 2/9] bluez5: Add bt_bacpy() Claudio Takahasi
2013-01-28 14:44 ` [PATCH v0 3/9] hfp_hf_bluez5: Add SCO listen socket Claudio Takahasi
2013-01-28 15:59   ` Marcel Holtmann
2013-01-28 16:43     ` Claudio Takahasi
2013-01-28 14:44 ` [PATCH v0 4/9] bluez5: Add bt_ba2str() Claudio Takahasi
2013-01-28 14:44 ` [PATCH v0 5/9] bluez5: Add bt_getsockpeers() Claudio Takahasi
2013-01-28 15:32   ` Marcel Holtmann
2013-01-28 16:34     ` Claudio Takahasi
2013-01-28 14:44 ` [PATCH v0 6/9] bluez5: Add RFCOMM socket address declaration Claudio Takahasi
2013-01-28 14:44 ` [PATCH v0 7/9] hfp_hf_bluez5: Add rejecting SCO connection Claudio Takahasi
2013-01-28 14:44 ` [PATCH v0 8/9] hfp_hf_bluez5: Reject SCO if source doesn't match Claudio Takahasi
2013-01-28 16:04   ` Marcel Holtmann
2013-01-28 16:56     ` Claudio Takahasi
2013-01-28 14:44 ` [PATCH v0 9/9] hfp_hf_bluez5: Fix missing fd close Claudio Takahasi
2013-01-28 21:11 ` [PATCH v1 0/8] External HFP: Add SCO Claudio Takahasi
2013-01-28 21:11   ` [PATCH v1 1/8] bluez5: Add SCO socket declarations Claudio Takahasi
2013-01-29 14:55     ` Denis Kenzior
2013-01-28 21:11   ` [PATCH v1 2/8] bluez5: Add bt_bacpy() Claudio Takahasi
2013-01-29 14:55     ` Denis Kenzior
2013-01-28 21:11   ` [PATCH v1 3/8] hfp_hf_bluez5: Add SCO listen socket Claudio Takahasi
2013-01-29 15:02     ` Denis Kenzior
2013-01-28 21:11   ` [PATCH v1 4/8] bluez5: Add bt_ba2str() Claudio Takahasi
2013-01-29 15:03     ` Denis Kenzior
2013-01-28 21:11   ` [PATCH v1 5/8] bluez5: Add bt_bacmp() Claudio Takahasi
2013-01-29 15:03     ` Denis Kenzior
2013-01-28 21:11   ` [PATCH v1 6/8] bluez5: Add RFCOMM socket address declaration Claudio Takahasi
2013-01-29 15:04     ` Denis Kenzior
2013-01-28 21:11   ` [PATCH v1 7/8] hfp_hf_bluez5: Add rejecting SCO connection Claudio Takahasi
2013-01-29 15:27     ` Denis Kenzior
2013-01-29 16:17       ` Claudio Takahasi
2013-01-29 16:25         ` Denis Kenzior [this message]
2013-01-28 21:11   ` [PATCH v1 8/8] hfp_hf_bluez5: Fix missing fd close Claudio Takahasi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5107F7EE.6080500@gmail.com \
    --to=denkenz@gmail.com \
    --cc=ofono@ofono.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox