[PATCH] net: cdc_ether.c: Add SE J105i to device whitelist

[PATCH] net: cdc_ether.c: Add SE J105i to device whitelist

[Thomas Loo]

This patch adds the Sony Ericsson J105i (Naite)
mobile phone to the cdc_ether device whitelist,
enabling access to the modem.

I would think more SE models of this generation
(2009Q3) with builtin HSDPA modules also needs
to be added to this list.

Signed-off-by: Thomas Loo <tloo@saltstorm.net>
---
 drivers/net/usb/cdc_ether.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 21e183a..833ba5a 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -584,6 +584,11 @@ static const struct usb_device_id	products [] = {
 			USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
 	.driver_info = (unsigned long) &mbm_info,
 }, {
+	/* Sony Ericsson J105i (Naite) */
+	USB_DEVICE_AND_INTERFACE_INFO(0x0fce, 0xd12d, USB_CLASS_COMM,
+			USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
+	.driver_info = (unsigned long) &mbm_info,
+}, {
 	/* Toshiba F3507g */
 	USB_DEVICE_AND_INTERFACE_INFO(0x0930, 0x130b, USB_CLASS_COMM,
 			USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
-- 
1.6.5.5

Re: [PATCH] net: cdc_ether.c: Add SE J105i to device whitelist

[Marcel Holtmann]

Hi Thomas,

> This patch adds the Sony Ericsson J105i (Naite)
> mobile phone to the cdc_ether device whitelist,
> enabling access to the modem.
> 
> I would think more SE models of this generation
> (2009Q3) with builtin HSDPA modules also needs
> to be added to this list.

I do prefer if we NOT use the mbm_info details for this since they are
clearly for mobile broadband cards with FLAG_WWAN.

Since this is a phone where the setup of the connection is done via the
phone. And you just treat this as an Ethernet device and run DHCP, then
please create a se_info or similar with FLAG_ETHER.

Regards

Marcel

Re: [PATCH] net: cdc_ether.c: Add SE J105i to device whitelist

[Bjørn Mork]

Marcel Holtmann <marcel@holtmann.org> writes:

>> This patch adds the Sony Ericsson J105i (Naite)
>> mobile phone to the cdc_ether device whitelist,
>> enabling access to the modem.
>> 
>> I would think more SE models of this generation
>> (2009Q3) with builtin HSDPA modules also needs
>> to be added to this list.
>
> I do prefer if we NOT use the mbm_info details for this since they are
> clearly for mobile broadband cards with FLAG_WWAN.

Assuming that these devices can be configured just like the WWAN cards
by sending commands to the associated ACM* or WDM* interfaces, why would
you treat them differently?  Because they've got a keyboard and a
display?

> Since this is a phone where the setup of the connection is done via the
> phone. And you just treat this as an Ethernet device and run DHCP, then
> please create a se_info or similar with FLAG_ETHER.

Why would anyone want to setup the connection via the phone?  That seems
unnecessary cumbersome. I'd prefer such devices to be auto-configured
just like any other WWAN device.


Bjørn

Re: [PATCH] net: cdc_ether.c: Add SE J105i to device whitelist

[Marcel Holtmann]

Hi Bjorn,

> >> This patch adds the Sony Ericsson J105i (Naite)
> >> mobile phone to the cdc_ether device whitelist,
> >> enabling access to the modem.
> >> 
> >> I would think more SE models of this generation
> >> (2009Q3) with builtin HSDPA modules also needs
> >> to be added to this list.
> >
> > I do prefer if we NOT use the mbm_info details for this since they are
> > clearly for mobile broadband cards with FLAG_WWAN.
> 
> Assuming that these devices can be configured just like the WWAN cards
> by sending commands to the associated ACM* or WDM* interfaces, why would
> you treat them differently?  Because they've got a keyboard and a
> display?

these are not like MBM devices WWAN cards. The MBM cards require to
setup the PDP context before the card will become ready. With an actual
phone you are already set.

So these are Ethernet devices and not WWAN cards.

> > Since this is a phone where the setup of the connection is done via the
> > phone. And you just treat this as an Ethernet device and run DHCP, then
> > please create a se_info or similar with FLAG_ETHER.
> 
> Why would anyone want to setup the connection via the phone?  That seems
> unnecessary cumbersome. I'd prefer such devices to be auto-configured
> just like any other WWAN device.

Are they WWAN devices? What these do is basically tethering via an
Ethernet like device. It does not require a telephony stack to drive
this hardware.

We require a proper DEVTYPE classification and these don't fall into the
category of WWAN devices. They can be treated like every other Ethernet
card and should be classified like this. We have FLAG_ETHER for this, so
please use that one.

Regards

Marcel

Re: [PATCH] net: cdc_ether.c: Add SE J105i to device whitelist

[Bjørn Mork]

Marcel Holtmann <marcel@holtmann.org> writes:

> Hi Bjorn,
>
>> >> This patch adds the Sony Ericsson J105i (Naite)
>> >> mobile phone to the cdc_ether device whitelist,
>> >> enabling access to the modem.
>> >> 
>> >> I would think more SE models of this generation
>> >> (2009Q3) with builtin HSDPA modules also needs
>> >> to be added to this list.
>> >
>> > I do prefer if we NOT use the mbm_info details for this since they are
>> > clearly for mobile broadband cards with FLAG_WWAN.
>> 
>> Assuming that these devices can be configured just like the WWAN cards
>> by sending commands to the associated ACM* or WDM* interfaces, why would
>> you treat them differently?  Because they've got a keyboard and a
>> display?
>
> these are not like MBM devices WWAN cards. The MBM cards require to
> setup the PDP context before the card will become ready. With an actual
> phone you are already set.

You are?  AFAIK, the PDP context *may* be configured using the phone UI
but it still needs to be setup.  And there are good reasons why you'd
like to configure/setup/verify the PDP context from the PC even if one
is setup using the phone UI. You will at least need to verify that a PDP
context actually *is* setup.  And you might want to use a different APN
than the one used when surfing from the phone.  You might even want to
choose different APNs depending on context (for VPN access, e.g)

> So these are Ethernet devices and not WWAN cards.

Well, I argued that the WWAN card were Ethernet devices.  I realise that
they've been defined otherwise now.  What I'm trying to understand are
the finer details of this definition.  Exactly what defines a WWAN card?

>> > Since this is a phone where the setup of the connection is done via the
>> > phone. And you just treat this as an Ethernet device and run DHCP, then
>> > please create a se_info or similar with FLAG_ETHER.
>> 
>> Why would anyone want to setup the connection via the phone?  That seems
>> unnecessary cumbersome. I'd prefer such devices to be auto-configured
>> just like any other WWAN device.
>
> Are they WWAN devices? What these do is basically tethering via an
> Ethernet like device. It does not require a telephony stack to drive
> this hardware.

Do they connect automatically, or do you need to initiate the connection
somehow?

> We require a proper DEVTYPE classification and these don't fall into the
> category of WWAN devices. They can be treated like every other Ethernet
> card and should be classified like this. We have FLAG_ETHER for this, so
> please use that one.

I believe the WWAN cards also can be treated like every other USB
Ethernet device, as far as the kernel is concerned.  Any differences are
easily resolved by userspace applications. 

So I'm still trying to figure out what makes a WWAN device special wrt
the kernel.  Thanks for explaining.


Bjørn

Re: [PATCH] net: cdc_ether.c: Add SE J105i to device whitelist

[Marcel Holtmann]

Hi Bjorn,

> >> >> This patch adds the Sony Ericsson J105i (Naite)
> >> >> mobile phone to the cdc_ether device whitelist,
> >> >> enabling access to the modem.
> >> >> 
> >> >> I would think more SE models of this generation
> >> >> (2009Q3) with builtin HSDPA modules also needs
> >> >> to be added to this list.
> >> >
> >> > I do prefer if we NOT use the mbm_info details for this since they are
> >> > clearly for mobile broadband cards with FLAG_WWAN.
> >> 
> >> Assuming that these devices can be configured just like the WWAN cards
> >> by sending commands to the associated ACM* or WDM* interfaces, why would
> >> you treat them differently?  Because they've got a keyboard and a
> >> display?
> >
> > these are not like MBM devices WWAN cards. The MBM cards require to
> > setup the PDP context before the card will become ready. With an actual
> > phone you are already set.
> 
> You are?  AFAIK, the PDP context *may* be configured using the phone UI
> but it still needs to be setup.  And there are good reasons why you'd
> like to configure/setup/verify the PDP context from the PC even if one
> is setup using the phone UI. You will at least need to verify that a PDP
> context actually *is* setup.  And you might want to use a different APN
> than the one used when surfing from the phone.  You might even want to
> choose different APNs depending on context (for VPN access, e.g)
> 
> > So these are Ethernet devices and not WWAN cards.
> 
> Well, I argued that the WWAN card were Ethernet devices.  I realise that
> they've been defined otherwise now.  What I'm trying to understand are
> the finer details of this definition.  Exactly what defines a WWAN card?
> 
> >> > Since this is a phone where the setup of the connection is done via the
> >> > phone. And you just treat this as an Ethernet device and run DHCP, then
> >> > please create a se_info or similar with FLAG_ETHER.
> >> 
> >> Why would anyone want to setup the connection via the phone?  That seems
> >> unnecessary cumbersome. I'd prefer such devices to be auto-configured
> >> just like any other WWAN device.
> >
> > Are they WWAN devices? What these do is basically tethering via an
> > Ethernet like device. It does not require a telephony stack to drive
> > this hardware.
> 
> Do they connect automatically, or do you need to initiate the connection
> somehow?
> 
> > We require a proper DEVTYPE classification and these don't fall into the
> > category of WWAN devices. They can be treated like every other Ethernet
> > card and should be classified like this. We have FLAG_ETHER for this, so
> > please use that one.
> 
> I believe the WWAN cards also can be treated like every other USB
> Ethernet device, as far as the kernel is concerned.  Any differences are
> easily resolved by userspace applications. 

and this is where you are totally wrong. It is not easy for userspace to
identify the type of an interface and resolve things.

Take WiFi for example. We need to actually connect to a network before
these are useful. Same applies for 3G cards (aka WWAN) devices. You have
to register with the network, attach to GPRS etc. before any of this
becomes really useful. If the the USB network interface does automatic
connect and does tethering then it is not a WWAN device. Then it is an
Ethernet device.

And that you can use your phone via a TTY and configure a second PDP
context and then run PPP has nothing to do with its network device.

> So I'm still trying to figure out what makes a WWAN device special wrt
> the kernel.  Thanks for explaining.

It has nothing to do with the kernel. It classifies the network device
type for userspace. Like you classify /dev/sda as "disk" and /dev/sda1
as "partition".

So please modify your patch as outlined in my first response. It should
take you only like 5 minutes to do so. Then your phone will show up and
gets a proper classification.

Regards

Marcel

Re: [PATCH] net: cdc_ether.c: Add SE J105i to device whitelist

[Bjørn Mork]

Marcel Holtmann <marcel@holtmann.org> writes:

>> I believe the WWAN cards also can be treated like every other USB
>> Ethernet device, as far as the kernel is concerned.  Any differences are
>> easily resolved by userspace applications. 
>
> and this is where you are totally wrong. It is not easy for userspace to
> identify the type of an interface and resolve things.

No?  Well, I probably have a too limited view of this, but I found it
easy enough to create a pre-up/post-down script which checked whether
the network interface being brought up/down belongs to a supported WWAN
card and then do the necessary magic on one of the related cdc-wdm
channels. This was implemented by poking around in the sysfs.  I fail to
see why one needs a special network device name to do that.

But it would have been useful to have the CDC MDLM header exported
somewhere in sysfs.  That's more of a generic usb/cdc thing though, I
guess. 

> Take WiFi for example. We need to actually connect to a network before
> these are useful. Same applies for 3G cards (aka WWAN) devices. You have
> to register with the network, attach to GPRS etc. before any of this
> becomes really useful. If the the USB network interface does automatic
> connect and does tethering then it is not a WWAN device. Then it is an
> Ethernet device.

I can live with that defintion of the difference between a WWAN/3G
device (wwan%d) and a USB Ethernet device (usb%d).

But I still don't see why this doesn't make a phone (supporting the same
commands as a 3G card) a WWAN device.  A phone can't do an automatic
connection any more than a WWAN card can.  Both *must* be configured
with at least one PDP context, register with the network, attach to GPRS
etc.

Yes, some phones can be configured to auto-connect using it's own
UI. But there's really nothing preventing anyone from implementing the
same feature for a WWAN card.  What would that make that card then?

> And that you can use your phone via a TTY and configure a second PDP
> context and then run PPP has nothing to do with its network device.

I was talking about the network device.  

My experience with these devices is limited to the Ericsson F3507g, but
I assume that many of them will behave identically.  It allows you to
define multiple PDP contexts and select which one you connect with,
either you use PPP or the network device.  The list of defined contexts
are in fact shared.

>> So I'm still trying to figure out what makes a WWAN device special wrt
>> the kernel.  Thanks for explaining.
>
> It has nothing to do with the kernel. It classifies the network device
> type for userspace. Like you classify /dev/sda as "disk" and /dev/sda1
> as "partition".
>
> So please modify your patch as outlined in my first response. It should
> take you only like 5 minutes to do so. Then your phone will show up and
> gets a proper classification.

Sorry for the confusion, but the patch was not mine.  I just stumbled
across the discussion and first wondered why the heck the mbm_info stuff
was added (hadn't noticed before) and then why the heck this device
should be treated differenctly if it shows up as a similar one.



Bjørn

Re: [PATCH] net: cdc_ether.c: Add SE J105i to device whitelist

[Marcel Holtmann]

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

Hi Bjorn,

> >> I believe the WWAN cards also can be treated like every other USB
> >> Ethernet device, as far as the kernel is concerned.  Any differences are
> >> easily resolved by userspace applications. 
> >
> > and this is where you are totally wrong. It is not easy for userspace to
> > identify the type of an interface and resolve things.
> 
> No?  Well, I probably have a too limited view of this, but I found it
> easy enough to create a pre-up/post-down script which checked whether
> the network interface being brought up/down belongs to a supported WWAN
> card and then do the necessary magic on one of the related cdc-wdm
> channels. This was implemented by poking around in the sysfs.  I fail to
> see why one needs a special network device name to do that.

this has nothing do with pre-up/post-down scripts.

The kernel already knows the type of the device. Userspace does not. And
detecting if from userspace is more complicated than just having the
kernel export it.

Also connection managers like NetworkManager and ConnMan do needs these
additional information. The actual interfaces names are not guaranteed
to be unique or static.

> > Take WiFi for example. We need to actually connect to a network before
> > these are useful. Same applies for 3G cards (aka WWAN) devices. You have
> > to register with the network, attach to GPRS etc. before any of this
> > becomes really useful. If the the USB network interface does automatic
> > connect and does tethering then it is not a WWAN device. Then it is an
> > Ethernet device.
> 
> I can live with that defintion of the difference between a WWAN/3G
> device (wwan%d) and a USB Ethernet device (usb%d).
> 
> But I still don't see why this doesn't make a phone (supporting the same
> commands as a 3G card) a WWAN device.  A phone can't do an automatic
> connection any more than a WWAN card can.  Both *must* be configured
> with at least one PDP context, register with the network, attach to GPRS
> etc.

Yes, the phone can do that. We call that provision which your provider
normally provides for you. Especially since the telephony stack is
running inside the phone. In case of 3G data cards, the telephony stack
is running on your machine. This is a big difference.

> Yes, some phones can be configured to auto-connect using it's own
> UI. But there's really nothing preventing anyone from implementing the
> same feature for a WWAN card.  What would that make that card then?
> 
> > And that you can use your phone via a TTY and configure a second PDP
> > context and then run PPP has nothing to do with its network device.
> 
> I was talking about the network device.  

You were talking about configuring the PDP context. That can't be done
via the network interface. And also it is not guaranteed that you can
actually modify the PDP context from your host. It might be specific to
the phone itself.

> My experience with these devices is limited to the Ericsson F3507g, but
> I assume that many of them will behave identically.  It allows you to
> define multiple PDP contexts and select which one you connect with,
> either you use PPP or the network device.  The list of defined contexts
> are in fact shared.

That is your assumption. It is not mandatory. You can have dedicated PDP
context for the tethering interface. And that is what the USB Ethernet
device of your phone is. If you can overwrite it or change it via your
host OS, then be happy, but it is not required to make this device work.

A pure MBM data card for example needs a telephony stack to make this
card work.

> >> So I'm still trying to figure out what makes a WWAN device special wrt
> >> the kernel.  Thanks for explaining.
> >
> > It has nothing to do with the kernel. It classifies the network device
> > type for userspace. Like you classify /dev/sda as "disk" and /dev/sda1
> > as "partition".
> >
> > So please modify your patch as outlined in my first response. It should
> > take you only like 5 minutes to do so. Then your phone will show up and
> > gets a proper classification.
> 
> Sorry for the confusion, but the patch was not mine.  I just stumbled
> across the discussion and first wondered why the heck the mbm_info stuff
> was added (hadn't noticed before) and then why the heck this device
> should be treated differenctly if it shows up as a similar one.

The point here clearly is that it is not a MBM device. Like it or not,
it is a phone and not a 3G data card/modem.

See attached patch for what I mean :)

Regards

Marcel


[-- Attachment #2: 0001-net-cdc_ether.c-Add-SE-J105i-to-device-whitelist.patch --]
[-- Type: text/x-patch, Size: 1734 bytes --]

>From f8c35427986bad983f2b321c15cdcbe15cc45a4c Mon Sep 17 00:00:00 2001
From: Marcel Holtmann <marcel@holtmann.org>
Date: Tue, 5 Jan 2010 12:49:47 -0800
Subject: [PATCH] net: cdc_ether.c: Add SE J105i to device whitelist

This patch adds the Sony Ericsson J105i (Naite)
mobile phone to the cdc_ether device whitelist,
enabling access to the modem.

I would think more SE models of this generation
(2009Q3) with builtin HSDPA modules also needs
to be added to this list.

Signed-off-by: Thomas Loo <tloo@saltstorm.net>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
 drivers/net/usb/cdc_ether.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 21e183a..a099d92 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -435,6 +435,14 @@ static const struct driver_info mbm_info = {
 	.status =	cdc_status,
 };
 
+static const struct driver_info mdlm_info = {
+	.description =	"MDLM Ethernet Device",
+	.flags =	FLAG_ETHER,
+	.bind = 	cdc_bind,
+	.unbind =	usbnet_cdc_unbind,
+	.status =	cdc_status,
+};
+
 /*-------------------------------------------------------------------------*/
 
 
@@ -584,6 +592,11 @@ static const struct usb_device_id	products [] = {
 			USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
 	.driver_info = (unsigned long) &mbm_info,
 }, {
+	/* Sony Ericsson J105i (Naite) */
+	USB_DEVICE_AND_INTERFACE_INFO(0x0fce, 0xd12d, USB_CLASS_COMM,
+			USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
+	.driver_info = (unsigned long) &mdlm_info,
+}, {
 	/* Toshiba F3507g */
 	USB_DEVICE_AND_INTERFACE_INFO(0x0930, 0x130b, USB_CLASS_COMM,
 			USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
-- 
1.6.5.2

Re: [PATCH] net: cdc_ether.c: Add SE J105i to device whitelist

[Dan Williams]

On Tue, 2010-01-05 at 13:46 +0100, Bjørn Mork wrote:
> Marcel Holtmann <marcel@holtmann.org> writes:
> 
> >> I believe the WWAN cards also can be treated like every other USB
> >> Ethernet device, as far as the kernel is concerned.  Any differences are
> >> easily resolved by userspace applications. 
> >
> > and this is where you are totally wrong. It is not easy for userspace to
> > identify the type of an interface and resolve things.
> 
> No?  Well, I probably have a too limited view of this, but I found it
> easy enough to create a pre-up/post-down script which checked whether
> the network interface being brought up/down belongs to a supported WWAN
> card and then do the necessary magic on one of the related cdc-wdm
> channels. This was implemented by poking around in the sysfs.  I fail to
> see why one needs a special network device name to do that.
> 
> But it would have been useful to have the CDC MDLM header exported
> somewhere in sysfs.  That's more of a generic usb/cdc thing though, I
> guess. 
> 
> > Take WiFi for example. We need to actually connect to a network before
> > these are useful. Same applies for 3G cards (aka WWAN) devices. You have
> > to register with the network, attach to GPRS etc. before any of this
> > becomes really useful. If the the USB network interface does automatic
> > connect and does tethering then it is not a WWAN device. Then it is an
> > Ethernet device.
> 
> I can live with that defintion of the difference between a WWAN/3G
> device (wwan%d) and a USB Ethernet device (usb%d).
> 
> But I still don't see why this doesn't make a phone (supporting the same
> commands as a 3G card) a WWAN device.  A phone can't do an automatic
> connection any more than a WWAN card can.  Both *must* be configured
> with at least one PDP context, register with the network, attach to GPRS
> etc.
> 
> Yes, some phones can be configured to auto-connect using it's own
> UI. But there's really nothing preventing anyone from implementing the
> same feature for a WWAN card.  What would that make that card then?
> 
> > And that you can use your phone via a TTY and configure a second PDP
> > context and then run PPP has nothing to do with its network device.
> 
> I was talking about the network device.  
> 
> My experience with these devices is limited to the Ericsson F3507g, but
> I assume that many of them will behave identically.  It allows you to

Haha.  No.  Never assume that two WWAN devices (or even two phones) will
behave identically.  It's almost never the case.

> define multiple PDP contexts and select which one you connect with,
> either you use PPP or the network device.  The list of defined contexts
> are in fact shared.

Here's the difference:

F3507g: requires AT command setup before cdc-ether port is usable
SE j105i: does not require AT command setup before port is usable

Same on my TM-506; you can simply run DHCP on the 'usb0' port and it
works, because the phone is pretending to be a usb-ethernet device and
transparently bridge between the ethernet and the cellular network.
That's simply not the case with the F3507g or any other WWAN card.

Phones are fundamentally different than WWAN cards and shouldn't be
treated like one, at least at this time.

Dan

> >> So I'm still trying to figure out what makes a WWAN device special wrt
> >> the kernel.  Thanks for explaining.
> >
> > It has nothing to do with the kernel. It classifies the network device
> > type for userspace. Like you classify /dev/sda as "disk" and /dev/sda1
> > as "partition".
> >
> > So please modify your patch as outlined in my first response. It should
> > take you only like 5 minutes to do so. Then your phone will show up and
> > gets a proper classification.
> 
> Sorry for the confusion, but the patch was not mine.  I just stumbled
> across the discussion and first wondered why the heck the mbm_info stuff
> was added (hadn't noticed before) and then why the heck this device
> should be treated differenctly if it shows up as a similar one.
> 
> 
> 
> Bjørn
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: cdc_ether.c: Add SE J105i to device whitelist

[Bjørn Mork]

Dan Williams <dcbw@redhat.com> writes:

> Here's the difference:
>
> F3507g: requires AT command setup before cdc-ether port is usable
> SE j105i: does not require AT command setup before port is usable
>
> Same on my TM-506; you can simply run DHCP on the 'usb0' port and it
> works, because the phone is pretending to be a usb-ethernet device and
> transparently bridge between the ethernet and the cellular network.
> That's simply not the case with the F3507g or any other WWAN card.
>
> Phones are fundamentally different than WWAN cards and shouldn't be
> treated like one, at least at this time.

OK, then I misunderstood the request.  I thought that this phone behaved
like a WWAN card since it presumably advertised the same CDC "Mobile
Direct Line" class as the Ericsson WWAN cards, maybe even with the same
GUID in the MDLM header?

If it really behaves like you describe (which is what the other Sony
Ericsson phones I've seen does too), then I don't understand why it
doesn't just advertise a CDC Ethernet class device.  That's what the
other phones do, and as you of course know, the reason why we don't have
a gazillion phone VID/PID entries in cdc_ether.c..


Bjørn

Re: [PATCH] net: cdc_ether.c: Add SE J105i to device whitelist

[Dan Williams]

On Thu, 2010-01-07 at 09:50 +0100, Bjørn Mork wrote:
> Dan Williams <dcbw@redhat.com> writes:
> 
> > Here's the difference:
> >
> > F3507g: requires AT command setup before cdc-ether port is usable
> > SE j105i: does not require AT command setup before port is usable
> >
> > Same on my TM-506; you can simply run DHCP on the 'usb0' port and it
> > works, because the phone is pretending to be a usb-ethernet device and
> > transparently bridge between the ethernet and the cellular network.
> > That's simply not the case with the F3507g or any other WWAN card.
> >
> > Phones are fundamentally different than WWAN cards and shouldn't be
> > treated like one, at least at this time.
> 
> OK, then I misunderstood the request.  I thought that this phone behaved
> like a WWAN card since it presumably advertised the same CDC "Mobile
> Direct Line" class as the Ericsson WWAN cards, maybe even with the same
> GUID in the MDLM header?

Interesting.  But I'd be very, very skeptical if the phone really acted
just like an MBM card.  My TM-506 has *some* of the same commands that
the F3507g and the F3607gw do but certainly not all of them.

> If it really behaves like you describe (which is what the other Sony
> Ericsson phones I've seen does too), then I don't understand why it
> doesn't just advertise a CDC Ethernet class device.  That's what the
> other phones do, and as you of course know, the reason why we don't have
> a gazillion phone VID/PID entries in cdc_ether.c..

Good question; though I've seen enough hardware that I'll simply just
assume they did it differently just because they could, not for any
specific reason.  Don't over-estimate the intelligence of firmware
people, they are just as human as the rest of us :)

Dan