Re: synce-hal: 10-synce.fdi is too enthusiastic

[Mark E. <ma...@mp...>]

On Tue, 2009-03-24 at 16:56 +0100, Adam Williamson wrote:
> On Tue, 2009-03-24 at 10:01 +0000, Mark Ellis wrote:
> 
> > > 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.
> 
> I was actually going to send a follow-up mail, because now I've read the
> script, I see that's what should happen. Only, for me at least, it
> doesn't. :)
> 
> If I plug my phone into my desktop - Rawhide with synce-hal 0.13.1 - and
> then enable ICS, what happens is quite interesting. Briefly, it gets the
> correct 192.168.0.2 address (without manual intervention). Then it
> reverts to 169.254.2.2. In /var/log/messages, there's a message from
> dhclient saying it bound to 192.168.0.2 and no message below which would
> seem to contradict that - but ifconfig says 169.254.2.2. I'm not sure
> exactly what's going on there. I'll re-do the experiment and paste up
> the relevant section of /var/log/messages later.
> 

I'll admit I very rarely use ICS, so I just tried it.

It doesn't seem to want to do it if the device is plugged in and no data
connection is active on the phone. However, if I first get the data
connection up, then trigger ICS, synce-hal drops off, gets restarted by
the ICS mode device, fires dhcp and gets an address of 192.168.0.102,
which is stable. I can then turn off ICS, and synce-hal again resets
with the mode change to the 169.254.2.2 address.

By all means send logs if yours insn't behaving.

> > > 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.
> 
> Actually, no, it just entirely ignores the phone at present, does
> nothing with it. It doesn't show up in a left-click on nm-applet. This
> is expected, I believe.
> 

Again, freely admit I've never tried it, but I wouldn't expect it to
work for me because I have an interface rule to prevent NM messing with
that interface. That's why I assumed NM would already work with ICS,
without that type of rule we used to get problems. I guess they changed
something ?

> > >  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.
> 
> That's what I suggested. Here's the log:
> 
> <dcbw> there's two ways to handle this with NM
>  1) ignore sync devices
>  2) handle sync devices, and only accept zeroconf connection types for
> them
> 
> I didn't ask for any clarification beyond that. WDYT?
> 

My only real problem with NM doing anything with a sync mode device is
that as soon as it does it we have to accept that is going to happen,
and not try to configure the interface. At that point if a user decides
they don't want NM, we have a much more complex situation.

We also need to know our IP, obviously, but also the 'dhcp server' IP,
ie the device, which currently we can get easily from dhclient output.

I just checked out my wifi NIC in hal and it doesn't have any of that
information, so I guess NM doesn't publish it.

> > 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 :)
> 
> As I said, at least in current Fedora Rawhide, NM seems mostly to ignore
> it...
> 

That's definitely not what I was expecting......

> > > 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.
> 
> Will do.
> -- 
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
> http://www.happyassassin.net
>