> I think manufacturers do this just to annoy us :)
Anything to make life harder for us ;)
>
> > I remember that for Mark it worked after he supplied these addresses to
> > odccm.
> >
> > Somebody was asking some questions on my website about getting synce to
> > run on his computer with his Moto-Q device. He was also seeing the same
> > problem that his device was using 169.254.2.118. This means that odccm is
> > not able to communicate with the device, meaning all the other things
> > won't work.
> >
> > My question is now why currently we are using the static, hardcoded IP
> > addresses and not making use of the fact that the device contains some
> > elementary DHCP server that will provide the computer with the right
> > address when it queries for one?
> >
> > Would it be possible to change odccm to make use of DHCP instead, and if
> > so, who has some knowledge that is sufficient to implement this?? :) The
> > problem is that is just a bit too high for me to implement ;)
> >
> > Furthermore, I think that the same problem holds for hal-dccm, since I
> > also see hardcoded information in the SVN tree.
> >
> > My guess is that it will cause quite some problems for end-users when
> > they see that their device is not working and it turns out to be because
> > of this.
> >
> > Anybody some further ideas?
>
> Ideas yes, solutions no.
Well.. ideas are always good ;)
>
> Odccm does everything internally, so to use dhcp you'd need to implement
> it in C or call dhclient externally.
I could not resist the urge, and looked into the details of odccm. I think if
a simple dhcp client would be implemented with odccm, it would be very easy
to use this information.
>
> synce-hal currently uses ifconfig in the callout script, so this could
> easily be replaced with dhclient. The problem is then how to pass the
> recovered ip address to dccm so it knows which interface to listen on. I
> seem to remember that there is a dbus controllable dhclient, I'll
> investigate at some point.
I do not fancy the idea of requiring a depency on a dbus contrallable
dhclient.
My current suggestion would be to still keep the possibility of supplying
addresses, but create a very simple DHCP client that won't cope very well
with errors/problematic situations, but only tries one request and if it
succeeds uses that information, otherwise tries the user supplied information
if present.
The only problem is that I don't know how difficult it is to write a simple
dhcp client... I will try to look into this, maybe it won't be that difficult
after all.
I will keep you guys updated about this one ;)
Guido
--
Aviation is proof that given the will, we have the
capacity to achieve the impossible.
--Eddie Rickenbacker
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
SynCE-Devel mailing list
SynCE-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/synce-devel
