lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 06 Jan 2010 22:38:41 -0800
From:	Dan Williams <dcbw@...hat.com>
To:	Bjørn Mork <bjorn@...k.no>
Cc:	Marcel Holtmann <marcel@...tmann.org>, netdev@...r.kernel.org
Subject: Re: [PATCH] net: cdc_ether.c: Add SE J105i to device whitelist

On Tue, 2010-01-05 at 13:46 +0100, Bjørn Mork wrote:
> Marcel Holtmann <marcel@...tmann.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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ