On Tue, 2009-03-24 at 12:57 +0100, John Carr wrote:
> On Tue, Mar 24, 2009 at 10:01 AM, Mark Ellis <m...@mpellis.org.uk> wrote:
> > On Mon, 2009-03-23 at 22:22 +0100, Adam Williamson wrote:
> >> I've just been talking to Dan Williams about how to make NetworkManager
> >> play nice with Windows Mobile devices, both in ActiveSync and ICS modes.
> >
> > Yay !
> >
> >> We've come up with one big concrete issue.
> >>
> >> The networking side of things needs to be handled differently in ICS and
> >> ActiveSync modes. 10-synce.fdi is written to set up the network
> >> interface for synchronization. It should therefore only kick in when the
> >> device is in sync mode. However, it doesn't.
> >>
> >
> > You're almost right.
> >
> >> In ICS mode, the network interface needs to be set up differently (it
> >> needs what you get via DHCP, which is usually an address of
> >> 192.168.0.102). But as things stand, if you try to use ICS mode on a
> >> system with synce-hal installed, it won't work, because the synce-hal
> >> scripts will keep on kicking in and adding the 'pda' and 'sync'
> >> capabilities and setting the IP address to 169.154.2.2 and so on.
> >>
> >
> > Actually synce-hal will set up the interface fine in ICS, with a DHCP
> > address in just the way it does in sync mode. It won't of course set up
> > any routing information.
> >
> >> This is because 10-synce.fdi is overbroad in its matching. It just does:
> >>
> >> <match key="@info.parent:info.linux.driver" string="rndis_host">
> >>
> >> this isn't good enough, because the driver will be rndis_host even when
> >> the device is in ICS mode.
> >>
> >> Dan got me to compare some lsusb output in ActiveSync and ICS modes, and
> >> he also found some documentation. His conclusion was:
> >>
> >> <dcbw> looks like Class 239, SubClass 1, Protocol 1 identifies sync
> >> devices according to rndis_host.c
> >> <dcbw> but synce *certainly* should update their HAL fdi file to only
> >> match 239/1/1 devices before tagging them with sync - just using
> >> rndis_host isn't sufficient
> >>
> >> What Dan's planning to do is have NM handle the device as a regular
> >> network interface if the device is in ICS mode,
> >
> > I guess that's pretty easy, it probably already does it if synce-hal
> > isn't around.
> >
> >> and handle it specially
> >> so that synchronization still works if it's in ActiveSync mode.
> >
> > How exactly does he propose to 'handle it' ? I'm quite happy to ignore
> > the device in ICS mode, since it's just a glorified modem, but I would
> > be exceedingly dubious about making allowances for NM in sync-mode, just
> > because there will be people who don't use NM. I would actually like to
> > be able to get NM to completely ignore the interface in sync mode. Is
> > that possible.
> >
> > This has been a bugbear for some time, if we can get it sorted out that
> > would be great.
> >
> >> But for
> >> this to happen, we need synce-hal to do things properly.
> >>
> >
> > From this point of view it's often trying to get NM to do it properly :)
> >
> >> Dan also noticed a typo in hal-synce-rndis line 215:
> >>
> >> if config.has_option('rndis', 'statis_local_ip'):
> >>
> >> 'statis' should be 'static'.
> >
> > Thank him for a nice catch on that.
> >
> >
>
> There is something to be said for NetworkManager bringing up PPP and
> rndis connections to the point where they are ready for TCP/IP then
> handing off to us. There are other devices that need a PPP connection
> before they can do anything useful, like the good old SE P900. While
> it would be unfortunate if NM and some other project both duplicated
> connection handling, i dont know if i could forgive the ecosystem that
> led each device group, or even each device, to have its own set of
> custom scripts..
> I would agree if we were doing any proper networking in that area, but all we are really doing is firing up pppd or dhclient. For that simple exercise I'd rather not get involved in the complexities of NM. > This brings up the question of what to do with DeviceKit looming. The > approach favored seems to be having a dbus activated service that is > activated by DeviceKit via a rule file. Know any good docs for this kind of thing under DeviceKit ? I've only come across general vagueness so far. > > Perhaps synce-hal => DeviceKit-mobiles and support establishing > connections for other devices we can find? > > Just brain dumping, > John
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________ SynCE-Devel mailing list SynCE-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synce-devel
