[Synce-devel] odccm / connections / multidev / rndis questions

[Mark Ellis]

Morning all

Sorry about the messy subject, I'm on a bit of an information fishing
expedition.

Putting aside for the moment the recently mentioned ideas about *dccm
and hal integration (because that seems to me much better for a long
term goal) I want to get odccm to be all that it can be, before I get
distracted again (I can hear my gnome-ification of kcemirror
calling...). I also don't think it will take that long.

odccm has skeleton support for multiple devices, in that it will
register any device that fully connects. I haven't been able to test any
of this, but from the code I'm guessing that for WM5 this won't work.
Pre WM5 probably would with improved serial scripts (working on that
too). Pre WM5 I can handle, but I've never even seen an rndis interface
live, hence the fishing.

Anyone who knows how any of this works in practice, help appreciated.

Firstly, anyone who can send me the output of odccm in foreground when a
device is connected and disconnected, and an ifconfig of the interface,
that would be great.

DHCP has been mentioned a few times, so ok run a dhcp server on the
linux box, set the device to use dhcp, but what about an ip for the
linux box's end of the connection. Couldn't just get any other dhcp ip
and claculate a netmask, surely there would be routing chaos ! Anybody
have any idea how this is supposed to work ?

I'm sure there was a ton of other stuff, but it escapes my mind at the
moment.

Ta
Mark

[John Carr]

Post by Mark Ellis
Morning all
Sorry about the messy subject, I'm on a bit of an information fishing
expedition.
Putting aside for the moment the recently mentioned ideas about *dccm
and hal integration (because that seems to me much better for a long
term goal) I want to get odccm to be all that it can be, before I get
distracted again (I can hear my gnome-ification of kcemirror
calling...). I also don't think it will take that long.

In synce tradition, what you are describing tastes like "mdccm" :)

What are we talking about with HAL integration? Pushing properties
into HAL is a good goal, but not urgent. Getting everything to "just
work" when you plug in is, IMO, very important and I guess what I
originally meant. I don't really like the idea of having odccm and
sync-engine running all the time though.

Post by Mark Ellis
DHCP has been mentioned a few times, so ok run a dhcp server on the
linux box, set the device to use dhcp, but what about an ip for the
linux box's end of the connection. Couldn't just get any other dhcp ip
and claculate a netmask, surely there would be routing chaos ! Anybody
have any idea how this is supposed to work ?

Isn't the DHCP server on the phone? For the moto q's you had to
dhclient rndis0, so yes I think the device is packing DHCP. And yes, I
fear the utter chaos too.

Your in the UK aren't you? If i can get my old WM5 device working i'd
happily loan it you for testing. On the condition that you are then
more HAL friendly :P

John

[Mark Ellis]

Post by John Carr

Post by Mark Ellis
Morning all
Sorry about the messy subject, I'm on a bit of an information fishing
expedition.
Putting aside for the moment the recently mentioned ideas about *dccm
and hal integration (because that seems to me much better for a long
term goal) I want to get odccm to be all that it can be, before I get
distracted again (I can hear my gnome-ification of kcemirror
calling...). I also don't think it will take that long.

In synce tradition, what you are describing tastes like "mdccm" :)
What are we talking about with HAL integration? Pushing properties
into HAL is a good goal, but not urgent. Getting everything to "just
work" when you plug in is, IMO, very important and I guess what I
originally meant. I don't really like the idea of having odccm and
sync-engine running all the time though.

Fair point, and I can see where you want to go with the HAL idea, but my
brain is unwilling to think about it too much :)

Post by John Carr

Post by Mark Ellis
DHCP has been mentioned a few times, so ok run a dhcp server on the
linux box, set the device to use dhcp, but what about an ip for the
linux box's end of the connection. Couldn't just get any other dhcp ip
and claculate a netmask, surely there would be routing chaos ! Anybody
have any idea how this is supposed to work ?

Isn't the DHCP server on the phone? For the moto q's you had to
dhclient rndis0, so yes I think the device is packing DHCP. And yes, I
fear the utter chaos too.

Really !? My first thought is, How Odd. Actually I remember someone in
the past insinuating something like that, just before I made odccm's ip
setup configurable, but I thought I was misunderstanding.

I suppose that would work though, *dccm would pick up the new interface
and dhclient it rather than assign a static address. But then how does
the device know what addresses it can use to avoid clashes ?

[John Carr]

Hi Mark

Sorry for not replying sooner, been locked in conversation with the
ubuntu guy and opensync peoples about... HAL :-)

Post by Mark Ellis
Really !? My first thought is, How Odd. Actually I remember someone in
the past insinuating something like that, just before I made odccm's ip
setup configurable, but I thought I was misunderstanding.
I suppose that would work though, *dccm would pick up the new interface
and dhclient it rather than assign a static address. But then how does
the device know what addresses it can use to avoid clashes ?

Yes, very odd indeed! I have no idea how it would cope with multiple
addresses at all.

Post by Mark Ellis
Cool, yep I'm in Surrey, I'll definitely consider that. For now could
you send an ifconfig of an interface, and anything else you think may
help my understanding ?

I will get you output from my WM6 device as soon as my brain is awake
- right now i'm falling asleep and I have another 2 emails to write...

Post by Mark Ellis
I'm coming around to the HAL idea actually, but I'm not that aware of
how much you can do. Would it go something like this.
1) Register a device type with HAL, so when a WM is connected it starts
a *dccm.

We provide an FDI that tells HAL to start a script when a device using
the rndis_host or ipaq driver is detected Said script initiates dccm
as below

Post by Mark Ellis
1) How does *dccm know what ip configurations it can use, and which may
already be in use by other devices ? We no longer have centralised data
in a single process.

No idea - even with one *dccm its weird as the device has its own DHCP
server.. We can at least publish the ips and what not in HAL so that
other interested parties know what to connect to?

Post by Mark Ellis
2) How would we send a 'device connected' signal to the likes of
trayicon and raki ? Multiple processes couldn't bind to a single dbus
address, can HAL actively send arbitrary events ?

HAL sends new device events. You can also get a "new capability" event
when you modify the "info.capabilities" property. Any data you
currently get from odccm over dbus i think we would get over HAL
instead.

A HAL device also has a path of its own, not unlike how odccm behaves.

John

[Mark Ellis]

Post by John Carr
Hi Mark
Sorry for not replying sooner, been locked in conversation with the
ubuntu guy and opensync peoples about... HAL :-)

Post by Mark Ellis
Really !? My first thought is, How Odd. Actually I remember someone in
the past insinuating something like that, just before I made odccm's ip
setup configurable, but I thought I was misunderstanding.
I suppose that would work though, *dccm would pick up the new interface
and dhclient it rather than assign a static address. But then how does
the device know what addresses it can use to avoid clashes ?

Yes, very odd indeed! I have no idea how it would cope with multiple
addresses at all.

Ok, we'll pend that thought.....

Post by John Carr

Post by Mark Ellis
Cool, yep I'm in Surrey, I'll definitely consider that. For now could
you send an ifconfig of an interface, and anything else you think may
help my understanding ?

I will get you output from my WM6 device as soon as my brain is awake
- right now i'm falling asleep and I have another 2 emails to write...

Hmm yes, must remember to sleep myself.

Post by John Carr

Post by Mark Ellis
I'm coming around to the HAL idea actually, but I'm not that aware of
how much you can do. Would it go something like this.
1) Register a device type with HAL, so when a WM is connected it starts
a *dccm.

We provide an FDI that tells HAL to start a script when a device using
the rndis_host or ipaq driver is detected Said script initiates dccm
as below

Ok, that's cool, gives me another place for research, thanks.

Post by John Carr

Post by Mark Ellis
1) How does *dccm know what ip configurations it can use, and which may
already be in use by other devices ? We no longer have centralised data
in a single process.

No idea - even with one *dccm its weird as the device has its own DHCP
server.. We can at least publish the ips and what not in HAL so that
other interested parties know what to connect to?

Probably the funkiest thing here would be getting a rapi connection. I
guess the best think would be for *dccm to connect to dbus and provide a
call to obtain a socket, as odccm does now. The dbus address for this
could then be published in hal, cool.

So what do you think of hal-dccm, or dccm-hal ? I know i know, breaking
with synce tradition :)

Post by John Carr

Post by Mark Ellis
2) How would we send a 'device connected' signal to the likes of
trayicon and raki ? Multiple processes couldn't bind to a single dbus
address, can HAL actively send arbitrary events ?

HAL sends new device events. You can also get a "new capability" event
when you modify the "info.capabilities" property. Any data you
currently get from odccm over dbus i think we would get over HAL
instead.
A HAL device also has a path of its own, not unlike how odccm behaves.

Ah yes, of course, just watch hal for connection events with the right
properties, odccm does that, must be getting late. And of course post
all the other device info as properties.

Ok, I'm in for this, just need to figure out the fdi stuff, work out how
to do legacy devices with ppp, and clone myself :)

Mark

[John Carr]

Post by Mark Ellis
Ah yes, of course, just watch hal for connection events with the right
properties, odccm does that, must be getting late. And of course post
all the other device info as properties.
Ok, I'm in for this, just need to figure out the fdi stuff, work out how
to do legacy devices with ppp, and clone myself :)
Mark

Hopefully this will be a starter for 10 - the fruits of all the
discussion with opensync/ubuntu:

https://wiki.ubuntu.com/SyncIntegration/HalDesign

There is a basic wm5/6 FDI, and see the blackberry callout for a
sample of how that might work. But David posted a C callout if you'd
prefer to avoid the python :-)

Publishing the devices serial in HAL would be a big help incidentally...

John

[Mark Ellis]

Post by John Carr

Post by Mark Ellis
Ah yes, of course, just watch hal for connection events with the right
properties, odccm does that, must be getting late. And of course post
all the other device info as properties.
Ok, I'm in for this, just need to figure out the fdi stuff, work out how
to do legacy devices with ppp, and clone myself :)
Mark

Hopefully this will be a starter for 10 - the fruits of all the
https://wiki.ubuntu.com/SyncIntegration/HalDesign
There is a basic wm5/6 FDI, and see the blackberry callout for a
sample of how that might work. But David posted a C callout if you'd
prefer to avoid the python :-)

Ok, yep, makes sense.

Post by John Carr
Publishing the devices serial in HAL would be a big help incidentally...

Hmm, never come across the serial over the wire, have to have a look.

Mark

[Ochal Christophe]

Hi,

Post by John Carr

Post by Mark Ellis
DHCP has been mentioned a few times, so ok run a dhcp server on the
linux box, set the device to use dhcp, but what about an ip for the
linux box's end of the connection. Couldn't just get any other dhcp ip
and claculate a netmask, surely there would be routing chaos ! Anybody
have any idea how this is supposed to work ?

Isn't the DHCP server on the phone? For the moto q's you had to
dhclient rndis0, so yes I think the device is packing DHCP. And yes, I
fear the utter chaos too.

Actually, no.
What you need is a fixed interface on the linux machine (this is the
serial/bluetooth/whatchawantit interface) that listens to connecting
devices. This side *HAS* a fixed ip that's different from your other ip
address (on the interface facing your network), you *will* need to use
iptables for routing if you want your PDA to get to the internet this
way, but if not, all you need to do is run a dhcp server on the linux
machine that's binding to the fixed ip address of the serial/bluetooth
interface.

No WM device i have seen sofar comes with a dhcp-server, only with a dhcp client.

[John Carr]

Post by Ochal Christophe
Hi,

Post by John Carr

Post by Mark Ellis
DHCP has been mentioned a few times, so ok run a dhcp server on the
linux box, set the device to use dhcp, but what about an ip for the
linux box's end of the connection. Couldn't just get any other dhcp ip
and claculate a netmask, surely there would be routing chaos ! Anybody
have any idea how this is supposed to work ?

Isn't the DHCP server on the phone? For the moto q's you had to
dhclient rndis0, so yes I think the device is packing DHCP. And yes, I
fear the utter chaos too.

Actually, no.
What you need is a fixed interface on the linux machine (this is the
serial/bluetooth/whatchawantit interface) that listens to connecting
devices. This side *HAS* a fixed ip that's different from your other ip
address (on the interface facing your network), you *will* need to use
iptables for routing if you want your PDA to get to the internet this
way, but if not, all you need to do is run a dhcp server on the linux
machine that's binding to the fixed ip address of the serial/bluetooth
interface.

Well thats obviously the logical choice. So far we force a device to
use an IP of our choice, however that breaks for at least the Moto Q.
This has an IP that seems to change randomly. Odccm has been modded to
let a user choose an IP, allowing the Moto Q to work.

Its also worth noting that if you want the PDA to get the internet
some apps will work with standard routing. Others need DTPT.py to
supply the Desktop Passthrough Proxy. Joy.

Post by Ochal Christophe
No WM device i have seen sofar comes with a dhcp-server, only with a dhcp client.

Are you absolutely certain?

***@ichigo:~/Projects/synce/usb-rndis-lite$ sudo ifconfig eth3
eth3 Link encap:Ethernet HWaddr 80:00:60:0f:e8:00
UP BROADCAST RUNNING MULTICAST MTU:8050 Metric:1
RX packets:7 errors:6 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:340 (340.0 B) TX bytes:134 (134.0 B)

***@ichigo:~/Projects/synce/usb-rndis-lite$ sudo dhclient eth3
Internet Systems Consortium DHCP Client V3.0.6
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth3/80:00:60:0f:e8:00
Sending on LPF/eth3/80:00:60:0f:e8:00
Sending on Socket/fallback
DHCPDISCOVER on eth3 to 255.255.255.255 port 67 interval 5
DHCPOFFER from 169.254.2.1
DHCPREQUEST on eth3 to 255.255.255.255 port 67
DHCPACK from 169.254.2.1
bound to 169.254.2.2 -- renewal in 1260637 seconds.

***@ichigo:~/Projects/synce/usb-rndis-lite$ sudo ifconfig eth3
eth3 Link encap:Ethernet HWaddr 80:00:60:0f:e8:00
inet addr:169.254.2.2 Bcast:169.254.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:8050 Metric:1
RX packets:9 errors:8 dropped:0 overruns:0 frame:0
TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:944 (944.0 B) TX bytes:3971 (3.8 KiB)

eth3 is the WM6 device i just plugged in. It's the same with my WM5
device. What the hell is responding to the DHCP request???

Normally odccm forces the IP to the very ones that DHCP has offered.
Its always .2.1 and .2.2... But for the moto q it seems to reply with
general weirdness. If you do not comply with its wishes then you will
be beaten down... Or rather, odccm won't work.

One thought I have is that the phone has some kind of fake DHCP thing
going on so that windows can auto configure the device with an IP when
you plug it in - the values it returns might come from the registry,
rather than a traditional DHCP server. (This fits with some keys that
we have been able to change in the past I think).

John

[Ochal Christophe]

Post by John Carr

Post by Ochal Christophe
Actually, no.
What you need is a fixed interface on the linux machine (this is the
serial/bluetooth/whatchawantit interface) that listens to connecting
devices. This side *HAS* a fixed ip that's different from your other ip
address (on the interface facing your network), you *will* need to use
iptables for routing if you want your PDA to get to the internet this
way, but if not, all you need to do is run a dhcp server on the linux
machine that's binding to the fixed ip address of the serial/bluetooth
interface.

Well thats obviously the logical choice. So far we force a device to
use an IP of our choice, however that breaks for at least the Moto Q.
This has an IP that seems to change randomly. Odccm has been modded to
let a user choose an IP, allowing the Moto Q to work.
Its also worth noting that if you want the PDA to get the internet
some apps will work with standard routing. Others need DTPT.py to
supply the Desktop Passthrough Proxy. Joy.

Post by Ochal Christophe
No WM device i have seen sofar comes with a dhcp-server, only with a dhcp client.

Are you absolutely certain?

Well, i haven't seen one yet :P And like you said, it wouldn't be
logical, however, wouldn't these devices be PDA/Phone combo's by change?

I suppose, if they are phones, that they *might* have a dhcp-server
integrated to allow other devices to connect to them to access the
internet, but even in this situation it would strike me as very odd.

Post by John Carr
eth3 Link encap:Ethernet HWaddr 80:00:60:0f:e8:00
UP BROADCAST RUNNING MULTICAST MTU:8050 Metric:1
RX packets:7 errors:6 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:340 (340.0 B) TX bytes:134 (134.0 B)
Internet Systems Consortium DHCP Client V3.0.6
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Listening on LPF/eth3/80:00:60:0f:e8:00
Sending on LPF/eth3/80:00:60:0f:e8:00
Sending on Socket/fallback
DHCPDISCOVER on eth3 to 255.255.255.255 port 67 interval 5
DHCPOFFER from 169.254.2.1
DHCPREQUEST on eth3 to 255.255.255.255 port 67
DHCPACK from 169.254.2.1
bound to 169.254.2.2 -- renewal in 1260637 seconds.
eth3 Link encap:Ethernet HWaddr 80:00:60:0f:e8:00
inet addr:169.254.2.2 Bcast:169.254.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:8050 Metric:1
RX packets:9 errors:8 dropped:0 overruns:0 frame:0
TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:944 (944.0 B) TX bytes:3971 (3.8 KiB)
eth3 is the WM6 device i just plugged in. It's the same with my WM5
device. What the hell is responding to the DHCP request???

What you're witnessing is, i'm guessing, zero-configuration, i say that
because of the IP addresses involved (the 169.254/16 range), i did some
quick checking, this is described in RFC3927.

Also note that Avahi implements a plugin for dhclient to support
RFC3927.

I haven't read the specifics yet of both, but here are the links:
RFC3927: http://www.ietf.org/rfc/rfc3927.txt
Avahi: http://avahi.org/wiki/AvahiAutoipd

Post by John Carr
One thought I have is that the phone has some kind of fake DHCP thing
going on so that windows can auto configure the device with an IP when
you plug it in - the values it returns might come from the registry,
rather than a traditional DHCP server. (This fits with some keys that
we have been able to change in the past I think).

It also fits with the zero-configuration system in that the WM device
caches it's last known good ip address.

[John Carr]

Post by Ochal Christophe

Post by John Carr
Internet Systems Consortium DHCP Client V3.0.6
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Listening on LPF/eth3/80:00:60:0f:e8:00
Sending on LPF/eth3/80:00:60:0f:e8:00
Sending on Socket/fallback
DHCPDISCOVER on eth3 to 255.255.255.255 port 67 interval 5
DHCPOFFER from 169.254.2.1
DHCPREQUEST on eth3 to 255.255.255.255 port 67
DHCPACK from 169.254.2.1
bound to 169.254.2.2 -- renewal in 1260637 seconds.

What you're witnessing is, i'm guessing, zero-configuration, i say that
because of the IP addresses involved (the 169.254/16 range), i did some
quick checking, this is described in RFC3927.
Also note that Avahi implements a plugin for dhclient to support
RFC3927.
RFC3927: http://www.ietf.org/rfc/rfc3927.txt
Avahi: http://avahi.org/wiki/AvahiAutoipd

The reason that I posted that log was not because dhclient "worked",
but rather because it got a DHCPOFFER and a DHCPACK. It also got the
IP on the first request. If I turn DHCP on my router off, the same
command (different eth*) looks like:

***@ichigo:~$ sudo dhclient eth2
Internet Systems Consortium DHCP Client V3.0.6
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth2/00:1b:77:2c:5d:83
Sending on LPF/eth2/00:1b:77:2c:5d:83
Sending on Socket/fallback
DHCPREQUEST on eth2 to 255.255.255.255 port 67
DHCPREQUEST on eth2 to 255.255.255.255 port 67
DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 13
DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 19
DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 19
No DHCPOFFERS received.
Trying recorded lease 192.168.0.3
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.

--- 192.168.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 9.509/9.509/9.509/0.000 ms
bound: renewal in 39118 seconds.

So the DHCPREQUEST is sent because we /did/ know there was a working
DHCP on eth2 (but I just turned it off). It doesnt get any response.
So then it sends a DHCPDISCOVER... Any DHCP servers out there?? HELP
PLZ??! It can't find any and times out - falling back to other methods
to get an IP. In this case, "last known good" got me back on the
network.

After turning DHCP back on I get:

***@ichigo:~$ sudo dhclient eth2
Internet Systems Consortium DHCP Client V3.0.6
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth2/00:1b:77:2c:5d:83
Sending on LPF/eth2/00:1b:77:2c:5d:83
Sending on Socket/fallback
DHCPREQUEST on eth2 to 255.255.255.255 port 67
DHCPACK from 192.168.0.1
bound to 192.168.0.3 -- renewal in 33010 seconds.

As you can see the behaviour with and without a DHCP server is quite
different. If avahi was involved then I would expected my main network
connection to get an IP just as quick as the device did. But no DHCP
causes a series of DHCPDISCOVER requests that time out... This seems
to back up the idea that (at the very least) the device is packing a
pseudo DHCP server so that it is quickly configured on connection to a
host PC.

Post by Ochal Christophe

Post by John Carr
One thought I have is that the phone has some kind of fake DHCP thing
going on so that windows can auto configure the device with an IP when
you plug it in - the values it returns might come from the registry,
rather than a traditional DHCP server. (This fits with some keys that
we have been able to change in the past I think).

It also fits with the zero-configuration system in that the WM device
caches it's last known good ip address.

It is possible that link-local zeroconf is used the very first time
(hence the IP addresses in that range) but then MS cache the IPs in
the devices registry and use them from that point on to answer DHCP
requests - speeding up connection.

I'm not being stubborn here, as we both agree it seems silly to have a
DHCP server. But i'm trying to explain why dhclient is reporting that
it is getting DHCP responses from somewhere, and my experiments with
my router seem to suggest that avahi would behave differently to what
i'm seeing.

John

[Ochal Christophe]

Post by John Carr

Post by Ochal Christophe

Post by John Carr
Internet Systems Consortium DHCP Client V3.0.6
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Listening on LPF/eth3/80:00:60:0f:e8:00
Sending on LPF/eth3/80:00:60:0f:e8:00
Sending on Socket/fallback
DHCPDISCOVER on eth3 to 255.255.255.255 port 67 interval 5
DHCPOFFER from 169.254.2.1
DHCPREQUEST on eth3 to 255.255.255.255 port 67
DHCPACK from 169.254.2.1
bound to 169.254.2.2 -- renewal in 1260637 seconds.

What you're witnessing is, i'm guessing, zero-configuration, i say that
because of the IP addresses involved (the 169.254/16 range), i did some
quick checking, this is described in RFC3927.
Also note that Avahi implements a plugin for dhclient to support
RFC3927.
RFC3927: http://www.ietf.org/rfc/rfc3927.txt
Avahi: http://avahi.org/wiki/AvahiAutoipd

The reason that I posted that log was not because dhclient "worked",
but rather because it got a DHCPOFFER and a DHCPACK. It also got the
IP on the first request. If I turn DHCP on my router off, the same
So the DHCPREQUEST is sent because we /did/ know there was a working
DHCP on eth2 (but I just turned it off). It doesnt get any response.
So then it sends a DHCPDISCOVER... Any DHCP servers out there?? HELP
PLZ??! It can't find any and times out - falling back to other methods
to get an IP. In this case, "last known good" got me back on the
network.

I wasn't trying to discredit your findings, nor deny that you got a
DHCPACK, rather, i was suggesting that zero-conf or local-link
mechanisms might be the ones simulating the dhcp-server, on further
reading of the RFC however, that seems unlikely.

Post by John Carr
As you can see the behaviour with and without a DHCP server is quite
different. If avahi was involved then I would expected my main network
connection to get an IP just as quick as the device did. But no DHCP
causes a series of DHCPDISCOVER requests that time out... This seems
to back up the idea that (at the very least) the device is packing a
pseudo DHCP server so that it is quickly configured on connection to a
host PC.

Correct, i was under the (wrong) impression that local-link or
zero-config might use a (limited) dhcp server, in that the first machine
to be powered gets the first local-link ip address and then responds to
dhcprequests from subsequent machines unless there is another dhcp
server coming onto the lan (dhcpdiscover).

Post by John Carr

Post by Ochal Christophe

Post by John Carr
One thought I have is that the phone has some kind of fake DHCP thing
going on so that windows can auto configure the device with an IP when
you plug it in - the values it returns might come from the registry,
rather than a traditional DHCP server. (This fits with some keys that
we have been able to change in the past I think).

It also fits with the zero-configuration system in that the WM device
caches it's last known good ip address.

It is possible that link-local zeroconf is used the very first time
(hence the IP addresses in that range) but then MS cache the IPs in
the devices registry and use them from that point on to answer DHCP
requests - speeding up connection.
I'm not being stubborn here, as we both agree it seems silly to have a
DHCP server. But i'm trying to explain why dhclient is reporting that
it is getting DHCP responses from somewhere, and my experiments with
my router seem to suggest that avahi would behave differently to what
i'm seeing.

I don't want to be stubborn neighter, i was merely offering a possible
explication why you got dhcp replies, as i had (wrongly) assumed
zeroconf would implement such a feature.

[John Carr]

Post by Ochal Christophe

Post by John Carr
The reason that I posted that log was not because dhclient "worked",
but rather because it got a DHCPOFFER and a DHCPACK. It also got the
IP on the first request. If I turn DHCP on my router off, the same
So the DHCPREQUEST is sent because we /did/ know there was a working
DHCP on eth2 (but I just turned it off). It doesnt get any response.
So then it sends a DHCPDISCOVER... Any DHCP servers out there?? HELP
PLZ??! It can't find any and times out - falling back to other methods
to get an IP. In this case, "last known good" got me back on the
network.

I wasn't trying to discredit your findings, nor deny that you got a
DHCPACK, rather, i was suggesting that zero-conf or local-link
mechanisms might be the ones simulating the dhcp-server, on further
reading of the RFC however, that seems unlikely.

I just wanted to be sure of what was happening, and I was trying to
forcefully get an explanation from you. You said maybe and guess a few
times, I just wanted to be able to categorically say whether the
DHCPACK was coming from the device or some software on my PC.

Post by Ochal Christophe

Post by John Carr

Post by Ochal Christophe

Post by John Carr
One thought I have is that the phone has some kind of fake DHCP thing
going on so that windows can auto configure the device with an IP when
you plug it in - the values it returns might come from the registry,
rather than a traditional DHCP server. (This fits with some keys that
we have been able to change in the past I think).

It also fits with the zero-configuration system in that the WM device
caches it's last known good ip address.

It is possible that link-local zeroconf is used the very first time
(hence the IP addresses in that range) but then MS cache the IPs in
the devices registry and use them from that point on to answer DHCP
requests - speeding up connection.
I'm not being stubborn here, as we both agree it seems silly to have a
DHCP server. But i'm trying to explain why dhclient is reporting that
it is getting DHCP responses from somewhere, and my experiments with
my router seem to suggest that avahi would behave differently to what
i'm seeing.

I don't want to be stubborn neighter, i was merely offering a possible
explication why you got dhcp replies, as i had (wrongly) assumed
zeroconf would implement such a feature.

I've lost track of what we were saying :-) What do we think is
happening here? A (limited) DHCP 'server', perhaps returning a hard
coded value from the devices registry (allowing windows to poke the
device to another IP as needed)?

John

[Mark Ellis]

Post by John Carr
I've lost track of what we were saying :-) What do we think is
happening here? A (limited) DHCP 'server', perhaps returning a hard
coded value from the devices registry (allowing windows to poke the
device to another IP as needed)?
John

Cool guys, at least we have more information than previously, even if we
have no idea what to do with it :(

I don't think it matters what is actually on the device, and it seems
unlikely to be a full blown dhcp server. Something is responding to dhcp
requests.

Anyone else want to try, see if its a common thing ?

At this point, if WM5+ devices are "pseudo-dhcp servers" or statically
configured, I cannot see a reliable way of out-of-the-box multiple
device support for them. You would need to instead individually
configure each device with a different IP, keep a database of this on
the synce box, and cross-ref this information based on something visible
between the device being plugged in and the interface being configured.

Does this sound like where we are ?

Mark

[Guido Diepen]

About the whole thing of allowing multiple connections.

Post by John Carr
I've lost track of what we were saying :-) What do we think is
happening here? A (limited) DHCP 'server', perhaps returning a hard
coded value from the devices registry (allowing windows to poke the
device to another IP as needed)?

I was just wondering what would happen under windows, and I found some
interesting things:

http://www.pdastreet.com/forums/archive/index.php/t-65313.html
http://www.eggheadcafe.com/software/aspnet/30286175/as-w-multiple-devices-s.aspx


There it states that AS (they talk about AS 4.1) requires a maximum of one
device to be connected. Again, unfortunately I don't have windows and I don't
have two devices, so I can't do the actual test under windows. But it would
be nice to see what exactly windows with active sync would do.

Maybe having multiple connected devices at the same time would seam as a nice
idea, but is infeasible due to the design by microsoft?

Guido Diepen

[Scott Gifford]

Guido Diepen <***@jcwodan.nl> writes:

[...]

Post by Guido Diepen
There it states that AS (they talk about AS 4.1) requires a maximum of one
device to be connected. Again, unfortunately I don't have windows and I don't
have two devices, so I can't do the actual test under windows. But it would
be nice to see what exactly windows with active sync would do.

If you plug multiple devices into Windows it just sees the first one.

Post by Guido Diepen
Maybe having multiple connected devices at the same time would seam
as a nice idea, but is infeasible due to the design by microsoft?

At least with WM2003 and vdccm, it was possible, and worked very well
and very reliably. I haven't had to use it in awhile, though.

----Scott.

[Ochal Christophe]

Post by John Carr

Post by Ochal Christophe
I wasn't trying to discredit your findings, nor deny that you got a
DHCPACK, rather, i was suggesting that zero-conf or local-link
mechanisms might be the ones simulating the dhcp-server, on further
reading of the RFC however, that seems unlikely.

I just wanted to be sure of what was happening, and I was trying to
forcefully get an explanation from you. You said maybe and guess a few
times, I just wanted to be able to categorically say whether the
DHCPACK was coming from the device or some software on my PC.

No force needed ;) The DHCPACK is definatly coming from the device
unless magical elves are living in your system ;) What i'm speculating
about is *why* it does that, i'm trying to figure out why there would be
dhcp functionality in the device in the first place.

Post by John Carr
I've lost track of what we were saying :-) What do we think is
happening here? A (limited) DHCP 'server', perhaps returning a hard
coded value from the devices registry (allowing windows to poke the
device to another IP as needed)?

Any way to trace what happens on Windows when you hook it up?

[Guido Diepen]

Post by Ochal Christophe
Any way to trace what happens on Windows when you hook it up?

I can't actually try this due to the lack of another device, but everything I
find on the internet shows that you can only have one device connected, since
they all try to work with the same address.

Guido Diepen

[Scott Gifford]

Mark Ellis <***@ntlworld.com> writes:

[...]

Post by Mark Ellis
Pre WM5 probably would with improved serial scripts (working on that
too). Pre WM5 I can handle, but I've never even seen an rndis interface
live, hence the fishing.

Feel free to borrow from these scripts, which I wrote to get multiple
devices working:

http://whereabouts.eecs.umich.edu/wiki/lib/exe/fetch.php?id=whereabouts_pda_setup&cache=cache&media=synce-serial-0.9.1-sg.tar.gz

----Scott.

[Mark Ellis]

Post by Scott Gifford
[...]

Post by Mark Ellis
Pre WM5 probably would with improved serial scripts (working on that
too). Pre WM5 I can handle, but I've never even seen an rndis interface
live, hence the fishing.

Feel free to borrow from these scripts, which I wrote to get multiple
http://whereabouts.eecs.umich.edu/wiki/lib/exe/fetch.php?id=whereabouts_pda_setup&cache=cache&media=synce-serial-0.9.1-sg.tar.gz
----Scott.

Thanks Scott, beat you to it :) See my other message.

Mark