[Synce-devel] multiple devices at one time

[Patrick Shirkey]

Hi,

I am working with several thousand usb devices. After researching my
options for several months I believe SynCe in conjunction with the Linux
usb drivers is the most advanced system available to enable me to work with
these devices on mass. I have found that a powerful PC with 4 GB memory and
a PCI-USB card on the same irq as the internal usb is able to support upto
200 devices at one time. I am quite probably the only person using Linux
for this purpose and have been working with the usb system for the past 6
months with excellent results. It's quite possible I am the only person in
the world with this many usb devices at my disposal and the specific
requirements to transfer data to them all at the same time on a regular
basis. Yes I work for a big company but we are in a niche market and we are
solely concerned with enabling people to get the most out of the worlds art
and history so I'm not completely sold out.


Currently I am attempting to work with synce-kde to allow these devices to
be syncronised at the same time.


I have made some progress in terms of getting the system to automatically
recognise a device when it is connected but I have been unable to get more
than one device to be accessible at the same time.


The devices that I am working with all have the same device name and
product name. I believe this is a major obstacle. I am reading the source
to find out more about how devices are enumerated and pushed onto the
stack. It would be extreemely helpful if someone was able to find some time
to give me a few hints about how the system is designed to handle multiple
devices.


If neccessary I will be modifying the code to make it work for my setup and
I will be passing back any modifications I make to the list.


I am very glad to be able to work with SynCe on Linux for this task and
hope to be able to contribute robust code back to the community.



Cheers.

--
Patrick Shirkey
Boost Hardware Ltd.

[Scott Gifford]

"Patrick Shirkey" <***@boosthardware.com> writes:

[...]

Post by Patrick Shirkey
I have made some progress in terms of getting the system to automatically
recognise a device when it is connected but I have been unable to get more
than one device to be accessible at the same time.

Hi Patrick,

I did some similar work, with about 20 devices. I used these patches
to the startup scripts to get the devices to come up automatically,
which I found essential to everything working smoothly:

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

They will only work with 128 devices right now, but some simple fixes
to IP address calculations should fix that.

I also had to upgrade to Linux kernel 2.6.15 (which was new at the
time); earlier versions would lock up if I plugged in 20 devices at
once.

I connected everything through a series of USB hubs, resulting on one
cable to plug into my laptop.

Beyond that, a standard vdccm did the trick.

Post by Patrick Shirkey
The devices that I am working with all have the same device name and
product name. I believe this is a major obstacle.

Yes, that's likely to be a problem. IIRC, the main problem is just in
the way that vdccm names files; if the devices all have the same name,
their configuration files will conflict.

If you can think of something else to name the files based on, it
would be fairly straightforward to fix this. You could probably even
use the IP address (which should always be unique), and create a
symlink from the device name to the address for backwards
compatibility.

Good luck!

----ScottG.

[Volker Christian]

I forgot to send it to the list too ... sorry

---------- Forwarded Message ----------

Subject: Re: [Synce-devel] multiple devices at one time
Date: Tuesday 25 September 2007
From: Volker Christian <***@users.sourceforge.net>
To: ***@boosthardware.com

Hi Patrick,

you can force vdccm to use the assigned device ip-addresses as their name
instead of their device-name by starting vdccm with the switch -i.
SynCE-KDE should work with that switch to vdccm as expected.

This should solve at least one of your problems.

regards
voc

Post by Scott Gifford
[...]

Post by Patrick Shirkey
I have made some progress in terms of getting the system to automatically
recognise a device when it is connected but I have been unable to get
more than one device to be accessible at the same time.

Hi Patrick,
I did some similar work, with about 20 devices. I used these patches
to the startup scripts to get the devices to come up automatically,
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
They will only work with 128 devices right now, but some simple fixes
to IP address calculations should fix that.
I also had to upgrade to Linux kernel 2.6.15 (which was new at the
time); earlier versions would lock up if I plugged in 20 devices at
once.
I connected everything through a series of USB hubs, resulting on one
cable to plug into my laptop.
Beyond that, a standard vdccm did the trick.

Post by Patrick Shirkey
The devices that I am working with all have the same device name and
product name. I believe this is a major obstacle.

Yes, that's likely to be a problem. IIRC, the main problem is just in
the way that vdccm names files; if the devices all have the same name,
their configuration files will conflict.
If you can think of something else to name the files based on, it
would be fairly straightforward to fix this. You could probably even
use the IP address (which should always be unique), and create a
symlink from the device name to the address for backwards
compatibility.
Good luck!
----ScottG.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
SynCE-Devel mailing list
https://lists.sourceforge.net/lists/listinfo/synce-devel

[Patrick Shirkey]

Post by Patrick Shirkey
[...]

Post by Patrick Shirkey
I have made some progress in terms of getting the system to
automatically recognise a device when it is connected but I have
been unable to get more than one device to be accessible at the

same time.
Hi Patrick,
I did some similar work, with about 20 devices. I used these patches
to the startup scripts to get the devices to come up automatically,
http://whereabouts.eecs.umich.edu/wiki/lib/exe/fetch.php?id=wherea
bouts_pda_setup&cache=cache&media=synce-serial-0.9.1-sg.tar.gz
They will only work with 128 devices right now, but some simple fixes
to IP address calculations should fix that.

Hi,

Thanks for the link to the patches. I installed them but they are
incompatible with my setup. I'm running most of the latest svn code now. If
I install synce-serial-0.10.0 I can get access to the device again but now
when I run synce-kde I get a message on the device saying:


"Cannot start communications with the desktop computer. Winsock services
could not start due to a critical error (Error %d)."



Cheers.

--
Patrick Shirkey
Boost Hardware Ltd

[Patrick Shirkey]

Post by Patrick Shirkey

Post by Patrick Shirkey
[...]

Post by Patrick Shirkey
I have made some progress in terms of getting the system to
automatically recognise a device when it is connected but I have
been unable to get more than one device to be accessible at the

same time.
Hi Patrick,
I did some similar work, with about 20 devices. I used these
patches to the startup scripts to get the devices to come up
automatically, which I found essential to everything working
http://whereabouts.eecs.umich.edu/wiki/lib/exe/fetch.php?id=whe
rea
bouts_pda_setup&cache=cache&media=synce-serial-0.9.1-sg.tar.gz
They will only work with 128 devices right now, but some simple
fixes to IP address calculations should fix that.

Hi,
Thanks for the link to the patches. I installed them but they are
incompatible with my setup. I'm running most of the latest svn code
now. If I install synce-serial-0.10.0 I can get access to the device
again but now when I run synce-kde I get a message on the device
"Cannot start communications with the desktop computer. Winsock
services could not start due to a critical error (Error %d)."

Ok,

I have rolled back to a pure fedora package install using raki 0.9.1 and I
can get the device to register again with it's ip address while using vdccm
-i


But still no luck with multiple devices.

I'm running gkrellm and the ppp0 device pops up when I run
synce-serial-start and raki is happy to provide a menu for the device with
it's ip address as the name id.


I'll look at those patches in more detail tomorrow. If you have any
suggestions for other things I should be looking for I will be very
greatful.


Cheers.

--
Patrick Shirkey
Boost Hardware Ltd.

[Patrick Shirkey]

On 9:30:45 am 09/25/07 Scott Gifford

Post by Scott Gifford
I did some similar work, with about 20 devices. I used these patches
to the startup scripts to get the devices to come up automatically,
http://whereabouts.eecs.umich.edu/wiki/lib/exe/fetch.php?id=wherea
bouts_pda_setup&cache=cache&media=synce-serial-0.9.1-sg.tar.gz
They will only work with 128 devices right now, but some simple fixes
to IP address calculations should fix that.

Hi Scott,

I have been looking at the code and I cannot see any specific differences
relating to multiple devices. Can you give me a bit of background on what
you had to modify please?


Cheers.

--
Patrick Shirkey
Boost Hardware Ltd.

[Patrick Shirkey]

Post by Patrick Shirkey
On 9:30:45 am 09/25/07 Scott Gifford

Post by Scott Gifford
I did some similar work, with about 20 devices. I used these
patches to the startup scripts to get the devices to come up
automatically, which I found essential to everything working
http://whereabouts.eecs.umich.edu/wiki/lib/exe/fetch.php?id=whe
rea
bouts_pda_setup&cache=cache&media=synce-serial-0.9.1-sg.tar.gz
They will only work with 128 devices right now, but some simple
fixes to IP address calculations should fix that.

Hi Scott,
I have been looking at the code and I cannot see any specific
differences relating to multiple devices. Can you give me a bit of
background on what you had to modify please?

Sorry spoke too soon. Should have read the README and I found these pages:

http://whereabouts.eecs.umich.edu/wiki/doku.php?id=whereabouts_pda_setup

http://sourceforge.net/mailarchive/forum.php?thread_name=qszhcx3ndcr.fsf%40goldenaxe.gpcc.itd.umich.edu&forum_name=synce-devel


It seems sourceforge can't search html attachments on archive mail so that
thread doesn't show up in a standard search of the archive.



Cheers.

--
Patrick Shirkey
Boost Hardware Ltd.

[Patrick Shirkey]

Hi,

I can get multiple devices to show up now after running


synce-serial-start /dev/ttyUSB0
synce-serial-start /dev/ttyUSB1

After this I get two new devices on ppp0 and ppp1. However ppp1 only stays
up for about 3 seconds. I have tried swapping the devices and starting them
in opposite order and it doesn't make any difference.


Do you have any ideas on what would cause this issue?

Cheers.

--
Patrick Shirkey
Boost Hardware Ltd.

[Scott Gifford]

Post by Patrick Shirkey

Post by Patrick Shirkey
On 9:30:45 am 09/25/07 Scott Gifford

[...]

Post by Patrick Shirkey

Post by Patrick Shirkey
I have been looking at the code and I cannot see any specific
differences relating to multiple devices. Can you give me a bit of
background on what you had to modify please?

http://whereabouts.eecs.umich.edu/wiki/doku.php?id=whereabouts_pda_setup
http://sourceforge.net/mailarchive/forum.php?thread_name=qszhcx3ndcr.fsf%40goldenaxe.gpcc.itd.umich.edu&forum_name=synce-devel
It seems sourceforge can't search html attachments on archive mail so that
thread doesn't show up in a standard search of the archive.

That's odd, it shouldn't have been in any kind of attachment; my mail
reader doesn't even support composing HTML email.

Post by Patrick Shirkey
Hi,
I can get multiple devices to show up now after running
synce-serial-start /dev/ttyUSB0
synce-serial-start /dev/ttyUSB1
After this I get two new devices on ppp0 and ppp1. However ppp1 only stays
up for about 3 seconds. I have tried swapping the devices and starting them
in opposite order and it doesn't make any difference.
Do you have any ideas on what would cause this issue?

Look in the logs for clues. You would see this behavior running dccm
instead of vdccm. If you're already running vdccm, turn up debugging
and you should be able to see what's going on.

Also, if the devices have the same name, you'll need to use the option
that Volker suggested to name them by their IP address instead of the
device name. To see if that's the problem, you could try giving them
different names and see if it works then.

Good luck!

----Scott.

[Patrick Shirkey]

Post by Scott Gifford

Post by Patrick Shirkey
It seems sourceforge can't search html attachments on archive mail
so that thread doesn't show up in a standard search of the archive.

That's odd, it shouldn't have been in any kind of attachment; my mail
reader doesn't even support composing HTML email.

It looks like sf.net archives some emails in strange ways.

Post by Scott Gifford

Post by Patrick Shirkey
I can get multiple devices to show up now after running
synce-serial-start /dev/ttyUSB0
synce-serial-start /dev/ttyUSB1
After this I get two new devices on ppp0 and ppp1. However ppp1
only stays up for about 3 seconds. I have tried swapping the
devices and starting them in opposite order and it doesn't make
any difference.
Do you have any ideas on what would cause this issue?

Look in the logs for clues. You would see this behavior running dccm
instead of vdccm. If you're already running vdccm, turn up debugging
and you should be able to see what's going on.
Also, if the devices have the same name, you'll need to use the option
that Volker suggested to name them by their IP address instead of the
device name. To see if that's the problem, you could try giving them
different names and see if it works then.

I also tried that option but it I was not using your scripts at the time
and vdccm appeared to enumerate the address based on the hardcoded product
name as returned by lsusb. Changing the device name via the control panel
did not allow multiple devices to connect with standard 0.9.3 scripts
although the device did show up with a different name in the raki panel.


Anyhow I am happy to use vdccm -i as I don't want to have to deal with
changing all the device names manually anyway.




Cheers.

--
Patrick Shirkey
Boost Hardware Ltd.



--
Patrick Shirkey
Boost Hardware Ltd.

[Patrick Shirkey]

Post by Patrick Shirkey

Post by Patrick Shirkey

Post by Patrick Shirkey
It seems sourceforge can't search html attachments on archive
mail so that thread doesn't show up in a standard search of the

archive.
That's odd, it shouldn't have been in any kind of attachment; my
mail reader doesn't even support composing HTML email.

It looks like sf.net archives some emails in strange ways.

Post by Patrick Shirkey

Post by Patrick Shirkey
I can get multiple devices to show up now after running
synce-serial-start /dev/ttyUSB0
synce-serial-start /dev/ttyUSB1
After this I get two new devices on ppp0 and ppp1. However ppp1
only stays up for about 3 seconds. I have tried swapping the
devices and starting them in opposite order and it doesn't make
any difference.
Do you have any ideas on what would cause this issue?

Look in the logs for clues. You would see this behavior running
dccm instead of vdccm. If you're already running vdccm, turn up
debugging and you should be able to see what's going on.

Hi,

I definitely don't have dccm installed. I have checked the logs and the
relevant message is below. What it says is that the ppp0 device is
registered and stays connected but het ppp1 device is registered and then
disconnected quickly.


I have found some info on this page but it doesn't make sense as I can get
the same device to register and stay connected as ppp0


http://synce.sourceforge.net/synce/qa.php

***********************

PPP error: "LCP terminated by peer"

Q: My PPP session was terminated with the message with "LCP terminated by
peer" after a very short connection time. I see something like this in my
logs:


pppd[21318]: pppd 2.4.2 started by root, uid 0
pppd[21318]: Serial connection established.
pppd[21318]: Using interface ppp0
pppd[21318]: Connect: ppp0 <--> /dev/ttyUSB0
kernel: PPP BSD Compression module registered
kernel: PPP Deflate Compression module registered
pppd[21318]: local IP address 192.168.131.102
pppd[21318]: remote IP address 192.168.131.201
pppd[21318]: LCP terminated by peer
pppd[21318]: Connection terminated.
pppd[21318]: Connect time 0.1 minutes.
pppd[21318]: Sent 579 bytes, received 857 bytes.
pppd[21318]: Connect time 0.1 minutes.
pppd[21318]: Sent 579 bytes, received 857 bytes.
pppd[21318]: Exit.

A: The device password provided to dccm is either wrong or missing. See
Connect for more information.



***************
Here's the message:

Sep 26 16:05:06 localhost kernel: usb 7-6.3.4: new full speed USB device
using ehci_hcd and address 25

Sep 26 16:05:06 localhost kernel: usb 7-6.3.4: device descriptor read/64,
error -32

Sep 26 16:05:07 localhost kernel: usb 7-6.3.4: configuration #1 chosen from
1 choice

Sep 26 16:05:07 localhost kernel: ipaq 7-6.3.4:1.0: PocketPC PDA converter
detected

Sep 26 16:05:07 localhost kernel: usb 7-6.3.4: PocketPC PDA converter now
attached to ttyUSB0

Sep 26 16:05:26 localhost pppd[6212]: pppd 2.4.4 started by patrick, uid 0
Sep 26 16:05:26 localhost pppd[6212]: Serial connection established.
Sep 26 16:05:26 localhost pppd[6212]: Using interface ppp0
Sep 26 16:05:26 localhost pppd[6212]: Connect: ppp0 <--> /dev/ttyUSB0
Sep 26 16:05:26 localhost pppd[6212]: local IP address 192.168.131.1
Sep 26 16:05:26 localhost pppd[6212]: remote IP address 192.168.131.129
Sep 26 16:05:38 localhost kernel: usb 7-6.4: USB disconnect, address 24
Sep 26 16:05:38 localhost kernel: ipaq ttyUSB1: PocketPC PDA converter now
disconnected from ttyUSB1

Sep 26 16:05:38 localhost kernel: ipaq 7-6.4:1.0: device disconnected
Sep 26 16:05:39 localhost kernel: usb 7-6.4: new full speed USB device
using ehci_hcd and address 26

Sep 26 16:05:39 localhost kernel: usb 7-6.4: configuration #1 chosen from 1
choice

Sep 26 16:05:39 localhost kernel: ipaq 7-6.4:1.0: PocketPC PDA converter
detected

Sep 26 16:05:39 localhost kernel: usb 7-6.4: PocketPC PDA converter now
attached to ttyUSB1

Sep 26 16:05:44 localhost pppd[6299]: pppd 2.4.4 started by patrick, uid 0
Sep 26 16:05:44 localhost pppd[6299]: Serial connection established.
Sep 26 16:05:44 localhost pppd[6299]: Using interface ppp1
Sep 26 16:05:44 localhost pppd[6299]: Connect: ppp1 <--> /dev/ttyUSB1
Sep 26 16:05:44 localhost pppd[6299]: local IP address 192.168.131.2
Sep 26 16:05:44 localhost pppd[6299]: remote IP address 192.168.131.130
Sep 26 16:05:47 localhost pppd[6314]: LCP terminated by peer
Sep 26 16:05:47 localhost pppd[6314]: Connect time 0.1 minutes.
Sep 26 16:05:47 localhost pppd[6314]: Sent 368 bytes, received 1514 bytes.
Sep 26 16:05:50 localhost pppd[6314]: Connection terminated.
Sep 26 16:05:50 localhost pppd[6314]: Modem hangup
Sep 26 16:05:50 localhost pppd[6314]: Exit.
**************************



Cheers.

--
Patrick Shirkey
Boost Hardware Ltd.

[Scott Gifford]

[...]

Post by Patrick Shirkey
I definitely don't have dccm installed. I have checked the logs and the
relevant message is below. What it says is that the ppp0 device is
registered and stays connected but het ppp1 device is registered and then
disconnected quickly.

So you're using vdccm? Or something else?

Post by Patrick Shirkey
I have found some info on this page but it doesn't make sense as I can get
the same device to register and stay connected as ppp0

I agree, that doesn't look like your problem.

[...]

Post by Patrick Shirkey
Sep 26 16:05:44 localhost pppd[6299]: Connect: ppp1 <--> /dev/ttyUSB1
Sep 26 16:05:44 localhost pppd[6299]: local IP address 192.168.131.2
Sep 26 16:05:44 localhost pppd[6299]: remote IP address 192.168.131.130
Sep 26 16:05:47 localhost pppd[6314]: LCP terminated by peer

This still smells like some sort of dccm/vdccm problem. What can
happen is the device connects with PPP, then tries to talk to
dccm/vdccm. If it can't talk to that server, it will bring down the
connection after a short while. I am a little surprised it brings it
down this quickly, but this is still my best guess.

At any rate, the way to debug it is to run vdccm with debugging
cranked up, and see what happens when you plug the device in.

Also double-check your firewall; did you have to make any
configuration changes to allow data through from your PDA? If so,
make sure you made those changes for all of the IP addresses the PDAs
will use (192.168.131.*)

----Scott.

[Patrick Shirkey]

Post by Scott Gifford
[...]

Post by Patrick Shirkey
I definitely don't have dccm installed. I have checked the logs
and the relevant message is below. What it says is that the ppp0
device is registered and stays connected but het ppp1 device is
registered and then disconnected quickly.

So you're using vdccm? Or something else?

I running vdccm-0.9.3 fedora package

Post by Scott Gifford

Post by Patrick Shirkey
I have found some info on this page but it doesn't make sense as I
can get the same device to register and stay connected as ppp0

I agree, that doesn't look like your problem.
[...]

Post by Patrick Shirkey
Sep 26 16:05:44 localhost pppd[6299]: Connect: ppp1 <-->
/dev/ttyUSB1 Sep 26 16:05:44 localhost pppd[6299]: local IP
address 192.168.131.2 Sep 26 16:05:44 localhost pppd[6299]: remote

LCP terminated by peer
This still smells like some sort of dccm/vdccm problem. What can
happen is the device connects with PPP, then tries to talk to
dccm/vdccm. If it can't talk to that server, it will bring down the
connection after a short while. I am a little surprised it brings it
down this quickly, but this is still my best guess.
At any rate, the way to debug it is to run vdccm with debugging
cranked up, and see what happens when you plug the device in.

ok.

**********************
vdccm -d 5 -f -i
[static void Utils::runScripts(std::string, std::string):229] Running
script: /home/patrick/.synce/scripts/dccm.sh start

[bool WindowsCEDevice::handleEvent():182] Header: 0
[bool WindowsCEDevice::handleEvent():184] initialization package
[bool WindowsCEDevice::handleEvent():182] Header: 100
[bool WindowsCEDevice::handleInfoMessage(uint32_t):91] this is an
information message

[bool ConnectionFileManager::_writeConnectionFile(std::string, const
WindowsCEDeviceBase*):115] Writing client-file: /home/patrick/.synce/192.168.131.129

[bool ConnectionFileManager::_writeConnectionFile(std::string, const
WindowsCEDeviceBase*):115] Writing client-file: /home/patrick/.synce/active_connection

[static void Utils::runScripts(std::string, std::string):229] Running
script: /home/patrick/.synce/scripts/dccm.sh connect

[void DeviceManager::addConnectedDevice(WindowsCEDeviceBase*):72] Device
connected: 192.168.131.129

[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 0
[bool WindowsCEDevice::handleEvent():184] initialization package
[bool WindowsCEDevice::handleEvent():182] Header: 100
[bool WindowsCEDevice::handleInfoMessage(uint32_t):91] this is an
information message

[virtual void WindowsCEDevice::disconnect():65] Disconnect
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply
[bool WindowsCEDevice::handleEvent():182] Header: 305419896
[bool WindowsCEDevice::handleEvent():186] this is a ping reply

**********************

Post by Scott Gifford
Also double-check your firewall; did you have to make any
configuration changes to allow data through from your PDA? If so,
make sure you made those changes for all of the IP addresses the PDAs
will use (192.168.131.*)

For the purpose of testing I have disabled my firewall using

system-config-securitylevel-tui

Post by Scott Gifford
----Scott.

[Scott Gifford]

Post by Patrick Shirkey

Post by Scott Gifford
[...]

Post by Patrick Shirkey
I definitely don't have dccm installed. I have checked the logs
and the relevant message is below. What it says is that the ppp0
device is registered and stays connected but het ppp1 device is
registered and then disconnected quickly.

So you're using vdccm? Or something else?

I running vdccm-0.9.3 fedora package

0.10.0 is available from the SynCE SourceForge page, or you could try
the one from SVN. Maybe it contains some useful bug fixes.

[...]

Post by Patrick Shirkey

Post by Scott Gifford
At any rate, the way to debug it is to run vdccm with debugging
cranked up, and see what happens when you plug the device in.

ok.
**********************
vdccm -d 5 -f -i
[static void Utils::runScripts(std::string, std::string):229] Running
script: /home/patrick/.synce/scripts/dccm.sh start

[...]

Post by Patrick Shirkey
[void DeviceManager::addConnectedDevice(WindowsCEDeviceBase*):72] Device
connected: 192.168.131.129

[...]

OK, so I see one device connect, but not the other one. That's what
you're seeing in this log, right?

The second device is bringing its PPP interface up, right? A few
ideas:

* See if you can ping the device before the ppp interface goes away.

* Run tcpdump on the ppp interface and see if the device is trying
to connect to vdccm.

* Use netstat or lsof to verify that vdccm is listening on address
"0.0.0.0"

* Run strace on vdccm to see if it's getting the connection request.

Hope this helps,

----Scott.

[Patrick Shirkey]

Post by Scott Gifford

I'm running vdccm-0.9.3 fedora package

0.10.0 is available from the SynCE SourceForge page, or you could try
the one from SVN. Maybe it contains some useful bug fixes.

I have now upgraded to latest svn.

Post by Scott Gifford
[...]

Post by Scott Gifford
At any rate, the way to debug it is to run vdccm with debugging
cranked up, and see what happens when you plug the device in.

ok.
**********************
vdccm -d 5 -f -i
[static void Utils::runScripts(std::string, std::string):229]
Running script: /home/patrick/.synce/scripts/dccm.sh start

[...]

[void DeviceManager::addConnectedDevice(WindowsCEDeviceBase*):72]
Device connected: 192.168.131.129

[...]
OK, so I see one device connect, but not the other one. That's what
you're seeing in this log, right?

Basically.

Post by Scott Gifford
The second device is bringing its PPP interface up, right?

Yes. For about 3 seconds.

Post by Scott Gifford
A few
* See if you can ping the device before the ppp interface goes away.
* Run tcpdump on the ppp interface and see if the device is trying
to connect to vdccm.
* Use netstat or lsof to verify that vdccm is listening on address
"0.0.0.0"
* Run strace on vdccm to see if it's getting the connection request.
Hope this helps,
----Scott.

Thanks for your useful input. Here's the output of the commands you
suggested above.


Everything looks correct to me so I can't see why the device is
disconnecting...




*************************

synce-serial-start /dev/ttyUSB1
Serial connection established.
Using interface ppp1
Connect: ppp1 <--> /dev/ttyUSB1
local IP address 192.168.131.2
remote IP address 192.168.131.130

synce-serial-start is now waiting for your device to connect


*************************



/usr/sbin/tcpdump -i ppp1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp1, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
15:22:34.486865 IP 192.168.131.130.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request, length 247

15:22:34.737779 IP 192.168.131.130.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request, length 247

15:22:34.994489 IP 192.168.131.130.netbios-ns > 192.168.131.255.netbios-ns:
NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST

15:22:35.058972 IP 192.168.131.130.iad2 > 192.168.131.2.dccm: S
16541321:16541321(0) win 32768 <mss 1460,nop,nop,sackOK>

15:22:35.059030 IP 192.168.131.2.dccm > 192.168.131.130.iad2: S
3358762278:3358762278(0) ack 16541322 win 5840 <mss 1460,nop,nop,sackOK>

15:22:35.060216 IP 192.168.131.130.iad2 > 192.168.131.2.dccm: . ack 1 win
33580

15:22:35.061712 IP 192.168.131.130.iad2 > 192.168.131.2.dccm: P 1:5(4) ack
1 win 33580

15:22:35.061734 IP 192.168.131.2.dccm > 192.168.131.130.iad2: . ack 5 win
5840

15:22:35.066844 IP 192.168.131.130.iad2 > 192.168.131.2.dccm: P 5:9(4) ack
1 win 33580

15:22:35.066874 IP 192.168.131.2.dccm > 192.168.131.130.iad2: . ack 9 win
5840

15:22:35.069100 IP 192.168.131.130.iad2 > 192.168.131.2.dccm: P 9:109(100)
ack 1 win 33580

15:22:35.069137 IP 192.168.131.2.dccm > 192.168.131.130.iad2: . ack 109 win
5840

15:22:35.069253 IP 192.168.131.2.dccm > 192.168.131.130.iad2: F 1:1(0) ack
109 win 5840

15:22:35.071471 IP 192.168.131.130.iad2 > 192.168.131.2.dccm: . ack 2 win
33580

15:22:35.082844 IP 192.168.131.130.iad3 > 192.168.131.2.7438: S
16569966:16569966(0) win 32768 <mss 1460,nop,nop,sackOK>

15:22:35.082883 IP 192.168.131.2.7438 > 192.168.131.130.iad3: R 0:0(0) ack
16569967 win 0

15:22:35.087584 IP 192.168.131.130.iad2 > 192.168.131.2.dccm: F 109:109(0)
ack 2 win 33580

15:22:35.087598 IP 192.168.131.2.dccm > 192.168.131.130.iad2: . ack 110 win
5840

15:22:35.088837 IP 192.168.131.130.iad2 > 192.168.131.2.dccm: R
16541431:16541431(0) win 0

15:22:35.245816 IP 192.168.131.130.netbios-ns > 192.168.131.255.netbios-ns:
NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST

15:22:35.496788 IP 192.168.131.130.netbios-ns > 192.168.131.255.netbios-ns:
NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST

15:22:35.563645 IP 192.168.131.130.iad3 > 192.168.131.2.7438: S
16569966:16569966(0) win 32768 <mss 1460,nop,nop,sackOK>

15:22:35.563683 IP 192.168.131.2.7438 > 192.168.131.130.iad3: R 0:0(0) ack
1 win 0

15:22:35.747751 IP 192.168.131.130.netbios-ns > 192.168.131.255.netbios-ns:
NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST

15:22:36.068450 IP 192.168.131.130.iad3 > 192.168.131.2.7438: S
16569966:16569966(0) win 32768 <mss 1460,nop,nop,sackOK>

15:22:36.068493 IP 192.168.131.2.7438 > 192.168.131.130.iad3: R 0:0(0) ack
1 win 0

tcpdump: pcap_loop: recvfrom: Network is down
26 packets captured
26 packets received by filter
0 packets dropped by kernel


*************************
/usr/sbin/lsof | grep "vdccm"

vdccm 20969 patrick 0u CHR 136,3 5
/dev/pts/3

vdccm 20969 patrick 1u CHR 136,3 5
/dev/pts/3

vdccm 20969 patrick 2u CHR 136,3 5
/dev/pts/3

vdccm 20969 patrick 3u IPv4 106623 TCP
*:ftps (LISTEN)

vdccm 20969 patrick 4u IPv4 106624 TCP
*:dccm (LISTEN)

vdccm 20969 patrick 5u unix 0xf5f5f900 106625
/home/patrick/.synce/csock

vdccm 20969 patrick 6r FIFO 0,6 106627 pipe
vdccm 20969 patrick 7w FIFO 0,6 106627 pipe
vdccm 20969 patrick 8u unix 0xf5f5f580 106628
socket

vdccm 20969 patrick 9u unix 0xf565e200 106630
socket

vdccm 20969 patrick 10u IPv4 107765 TCP
192.168.131.1:dccm->192.168.131.129:1028 (ESTABLISHED)

yum 21837 root cwd DIR 253,0 4096 10193029
/usr/local/src/SynCe/vdccm





*************************

netstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address
State

tcp 2383 0 192.168.1.2:50973 ftp.chg.ru:http
CLOSE_WAIT

tcp 2382 0 192.168.1.2:50976 ftp.chg.ru:http
CLOSE_WAIT

tcp 0 0 192.168.131.1:dccm 192.168.131.129:1028
ESTABLISHED

tcp 1 0 192.168.1.2:37498 admin.fedora.redhat.co:http
CLOSE_WAIT

tcp 64639 0 sgmwongnb.dna.dci.dis:49553 download.fedora.redhat:http
ESTABLISHED

tcp 1 0 192.168.1.2:48280 ftp.kddlabs.co.jp:http
CLOSE_WAIT




*************************

strace -p 22556
Process 22556 attached - interrupt to quit
select(6, [3 4 5], NULL, NULL, {4, 346000}) = 0 (Timeout)
gettimeofday({1190969068, 303681}, NULL) = 0
gettimeofday({1190969068, 303730}, NULL) = 0
gettimeofday({1190969068, 303772}, NULL) = 0
select(6, [3 4 5], NULL, NULL, {4, 999333}) = 0 (Timeout)
gettimeofday({1190969073, 303677}, NULL) = 0
gettimeofday({1190969073, 303715}, NULL) = 0
gettimeofday({1190969073, 303742}, NULL) = 0
select(6, [3 4 5], NULL, NULL, {4, 999363}) = 0 (Timeout)
gettimeofday({1190969078, 303679}, NULL) = 0
gettimeofday({1190969078, 303749}, NULL) = 0
gettimeofday({1190969078, 303796}, NULL) = 0
select(6, [3 4 5], NULL, NULL, {4, 999309}) = 1 (in [4], left {4, 334000})
select(5, [4], NULL, NULL, NULL) = 1 (in [4])
accept(4, {sa_family=AF_INET, sin_port=htons(1043), sin_addr=inet_addr("192.168.131.130")}, [16]) = 10

getpeername(10, {sa_family=AF_INET, sin_port=htons(1043),
sin_addr=inet_addr("192.168.131.130")}, [16]) = 0

setsockopt(10, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
getsockname(10, {sa_family=AF_INET, sin_port=htons(5679),
sin_addr=inet_addr("192.168.131.2")}, [16]) = 0

gettimeofday({1190969078, 970473}, NULL) = 0
gettimeofday({1190969078, 970527}, NULL) = 0
select(11, [3 4 5 10], NULL, NULL, {4, 332578}) = 1 (in [10], left {4,
332578})

read(10, "\0\0\0\0", 4) = 4
write(2, "[bool WindowsCEDevice::handleEve"..., 42) = 42
write(2, "Header: 0", 9) = 9
write(2, "\n", 1) = 1
write(2, "[bool WindowsCEDevice::handleEve"..., 42) = 42
write(2, "initialization package", 22) = 22
write(2, "\n", 1) = 1
gettimeofday({1190969078, 971621}, NULL) = 0
gettimeofday({1190969078, 971675}, NULL) = 0
select(11, [3 4 5 10], NULL, NULL, {4, 331430}) = 1 (in [10], left {4,
328000})

read(10, "d\0\0\0", 4) = 4
write(2, "[bool WindowsCEDevice::handleEve"..., 42) = 42
write(2, "Header: 100", 11) = 11
write(2, "\n", 1) = 1
write(2, "[bool WindowsCEDevice::handleInf"..., 55) = 55
write(2, "this is an information message", 30) = 30
write(2, "\n", 1) = 1
read(10, "(\0\0\0\5\0\0\0\21\n\0\0\0\0\0\0)U\211`\0\0\0\0(\0\0\000"...,
100) = 100

open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 11
fstat64(11, {st_mode=S_IFREG|0644, st_size=25486, ...}) = 0
mmap2(NULL, 25486, PROT_READ, MAP_SHARED, 11, 0) = 0xb7f6c000
close(11) = 0
futex(0x4bd27a4c, FUTEX_WAKE, 2147483647) = 0
open("/usr/lib/gconv/ISO8859-1.so", O_RDONLY) = 11
read(11, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \3\0\000"...,
512) = 512

fstat64(11, {st_mode=S_IFREG|0755, st_size=5436, ...}) = 0
mmap2(NULL, 8212, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 11, 0) =
0x24f000

mmap2(0x250000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 11, 0) = 0x250000

close(11) = 0
write(7, "A", 1) = 1
futex(0x95fc0dc, FUTEX_WAKE, 1) = 1
getuid32() = 501
open("/etc/passwd", O_RDONLY) = 11
fcntl64(11, F_GETFD) = 0
fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
fstat64(11, {st_mode=S_IFREG|0644, st_size=1938, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f6b000

read(11, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1938
close(11) = 0
munmap(0xb7f6b000, 4096) = 0
stat64("/home/patrick/.synce", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
write(2, "[bool ConnectionFileManager::_wr"..., 96) = 96
write(2, "Writing client-file: /home/patri"..., 57) = 57
write(2, "\n", 1) = 1
open("/home/patrick/.synce/192.168.131.130", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 11

write(11, "# Modifications to this file wil"..., 78) = 78
write(11, "\n", 1) = 1
write(11, "[dccm]\n", 7) = 7
write(11, "pid=22556\n", 10) = 10
write(11, "\n", 1) = 1
write(11, "[device]\n", 9) = 9
write(11, "os_version=5\n", 13) = 13
write(11, "build_bumber=0\n", 15) = 15
write(11, "processor_type=2577\n", 20) = 20
write(11, "partner_id_1=1619612969\n", 24) = 24
write(11, "partner_id_2=0\n", 15) = 15

<snip>

write(11, "ip=192.168.131.130\n", 19) = 19
write(11, "port=1043\n", 10) = 10
write(11, "\n", 1) = 1
write(11, "[connection]\n", 13) = 13
write(11, "transport=ppp\n", 14) = 14
close(11) = 0
getuid32() = 501
open("/etc/passwd", O_RDONLY) = 11
fcntl64(11, F_GETFD) = 0
fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
fstat64(11, {st_mode=S_IFREG|0644, st_size=1938, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f6b000

read(11, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1938
close(11) = 0
munmap(0xb7f6b000, 4096) = 0
stat64("/home/patrick/.synce", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
write(2, "[bool ConnectionFileManager::_wr"..., 96) = 96
write(2, "Writing client-file: /home/patri"..., 59) = 59
write(2, "\n", 1) = 1
open("/home/patrick/.synce/active_connection", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 11

write(11, "# Modifications to this file wil"..., 78) = 78
write(11, "\n", 1) = 1
write(11, "[dccm]\n", 7) = 7
write(11, "pid=22556\n", 10) = 10
write(11, "\n", 1) = 1
write(11, "[device]\n", 9) = 9
write(11, "os_version=5\n", 13) = 13
write(11, "build_bumber=0\n", 15) = 15
write(11, "processor_type=2577\n", 20) = 20
write(11, "partner_id_1=1619612969\n", 24) = 24
write(11, "partner_id_2=0\n", 15) = 15

<snip>

write(11, "ip=192.168.131.130\n", 19) = 19
write(11, "port=1043\n", 10) = 10
write(11, "\n", 1) = 1
write(11, "[connection]\n", 13) = 13
write(11, "transport=ppp\n", 14) = 14
close(11) = 0
getuid32() = 501
open("/etc/passwd", O_RDONLY) = 11
fcntl64(11, F_GETFD) = 0
fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
fstat64(11, {st_mode=S_IFREG|0644, st_size=1938, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f6b000

read(11, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1938
close(11) = 0
munmap(0xb7f6b000, 4096) = 0
stat64("/home/patrick/.synce", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
stat64("/home/patrick/.synce/scripts", {st_mode=S_IFDIR|0700, st_size=4096,
..}) = 0

open("/home/patrick/.synce/scripts", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 11

fstat64(11, {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
getdents(11, /* 3 entries */, 4096) = 52
lstat64("/home/patrick/.synce/scripts/.", {st_mode=S_IFDIR|0700,
st_size=4096, ...}) = 0

lstat64("/home/patrick/.synce/scripts/dccm.sh", {st_mode=S_IFREG|0755,
st_size=245, ...}) = 0

write(2, "[static void Utils::runScripts(s"..., 62) = 62
write(2, "Running script: /home/patrick/.s"..., 60) = 60
write(2, "\n", 1) = 1
rt_sigaction(SIGINT, {SIG_IGN}, {0x80516f0, [INT], SA_RESTART}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {0x80516f0, [QUIT], SA_RESTART}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0xbf854294) = 22677

waitpid(22677, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 22677
rt_sigaction(SIGINT, {0x80516f0, [INT], SA_RESTART}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {0x80516f0, [QUIT], SA_RESTART}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
lstat64("/home/patrick/.synce/scripts/..", {st_mode=S_IFDIR|0700,
st_size=4096, ...}) = 0

getdents(11, /* 0 entries */, 4096) = 0
close(11) = 0
write(2, "[void DeviceManager::addConnecte"..., 66) = 66
write(2, "Device connected: 192.168.131.13"..., 33) = 33
write(2, "\n", 1) = 1
gettimeofday({1190969078, 992408}, NULL) = 0
gettimeofday({1190969078, 992451}, NULL) = 0
select(11, [3 4 5 10], NULL, NULL, {4, 310654}) = 0 (Timeout)
gettimeofday({1190969083, 302684}, NULL) = 0
gettimeofday({1190969083, 302746}, NULL) = 0



*************************

[Patrick Shirkey]

Post by Patrick Shirkey
Thanks for your useful input. Here's the output of the commands you
suggested above.
Everything looks correct to me so I can't see why the device is
disconnecting...

I should add that 192.168.131.1/192.168.131.129 is the device on ppp0. ppp1
is being assigned 192.168.131.2/192.168.131.130



Cheers.

--
Patrick Shirkey
Boost Hardware Ltd

Post by Patrick Shirkey
*************************
synce-serial-start /dev/ttyUSB1
Serial connection established.
Using interface ppp1
Connect: ppp1 <--> /dev/ttyUSB1
local IP address 192.168.131.2
remote IP address 192.168.131.130
synce-serial-start is now waiting for your device to connect
*************************
/usr/sbin/tcpdump -i ppp1
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode listening on ppp1, link-type LINUX_SLL (Linux cooked), capture
size 96 bytes 15:22:34.486865 IP 192.168.131.130.bootpc >
255.255.255.255.bootps: BOOTP/DHCP, Request, length 247
BOOTP/DHCP, Request, length 247
15:22:34.994489 IP 192.168.131.130.netbios-ns > 192.168.131.255.netbio
NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
15:22:35.058972 IP 192.168.131.130.iad2 > 192.168.131.2.dccm: S
16541321:16541321(0) win 32768 <mss 1460,nop,nop,sackOK>
15:22:35.059030 IP 192.168.131.2.dccm > 192.168.131.130.iad2: S
3358762278:3358762278(0) ack 16541322 win 5840 <mss
1460,nop,nop,sackOK>
15:22:35.060216 IP 192.168.131.130.iad2 > 192.168.131.2.dccm: . ack 1
win 33580
15:22:35.061712 IP 192.168.131.130.iad2 > 192.168.131.2.dccm: P
1:5(4) ack 1 win 33580
15:22:35.061734 IP 192.168.131.2.dccm > 192.168.131.130.iad2: . ack 5
win 5840
15:22:35.066844 IP 192.168.131.130.iad2 > 192.168.131.2.dccm: P
5:9(4) ack 1 win 33580
15:22:35.066874 IP 192.168.131.2.dccm > 192.168.131.130.iad2: . ack 9
win 5840
15:22:35.069100 IP 192.168.131.130.iad2 > 192.168.131.2.dccm: P
9:109(100) ack 1 win 33580
15:22:35.069137 IP 192.168.131.2.dccm > 192.168.131.130.iad2: . ack
109 win 5840
15:22:35.069253 IP 192.168.131.2.dccm > 192.168.131.130.iad2: F
1:1(0) ack 109 win 5840
15:22:35.071471 IP 192.168.131.130.iad2 > 192.168.131.2.dccm: . ack 2
win 33580
15:22:35.082844 IP 192.168.131.130.iad3 > 192.168.131.2.7438: S
16569966:16569966(0) win 32768 <mss 1460,nop,nop,sackOK>
15:22:35.082883 IP 192.168.131.2.7438 > 192.168.131.130.iad3: R
0:0(0) ack 16569967 win 0
15:22:35.087584 IP 192.168.131.130.iad2 > 192.168.131.2.dccm: F
109:109(0) ack 2 win 33580
15:22:35.087598 IP 192.168.131.2.dccm > 192.168.131.130.iad2: . ack
110 win 5840
15:22:35.088837 IP 192.168.131.130.iad2 > 192.168.131.2.dccm: R
16541431:16541431(0) win 0
15:22:35.245816 IP 192.168.131.130.netbios-ns > 192.168.131.255.netbio
NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
15:22:35.496788 IP 192.168.131.130.netbios-ns > 192.168.131.255.netbio
NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
15:22:35.563645 IP 192.168.131.130.iad3 > 192.168.131.2.7438: S
16569966:16569966(0) win 32768 <mss 1460,nop,nop,sackOK>
15:22:35.563683 IP 192.168.131.2.7438 > 192.168.131.130.iad3: R
0:0(0) ack 1 win 0
15:22:35.747751 IP 192.168.131.130.netbios-ns > 192.168.131.255.netbio
NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
15:22:36.068450 IP 192.168.131.130.iad3 > 192.168.131.2.7438: S
16569966:16569966(0) win 32768 <mss 1460,nop,nop,sackOK>
15:22:36.068493 IP 192.168.131.2.7438 > 192.168.131.130.iad3: R
0:0(0) ack 1 win 0
tcpdump: pcap_loop: recvfrom: Network is down
26 packets captured
26 packets received by filter
0 packets dropped by kernel
*************************
/usr/sbin/lsof | grep "vdccm"
vdccm 20969 patrick 0u CHR 136,3
5 /dev/pts/3
vdccm 20969 patrick 1u CHR 136,3
5 /dev/pts/3
vdccm 20969 patrick 2u CHR 136,3
5 /dev/pts/3
vdccm 20969 patrick 3u IPv4 106623
TCP *:ftps (LISTEN)
vdccm 20969 patrick 4u IPv4 106624
TCP *:dccm (LISTEN)
vdccm 20969 patrick 5u unix 0xf5f5f900
106625 /home/patrick/.synce/csock
vdccm 20969 patrick 6r FIFO 0,6
106627 pipe vdccm 20969 patrick 7w FIFO 0,6
106627 pipe vdccm 20969 patrick 8u unix 0xf5f5f580
106628 socket
vdccm 20969 patrick 9u unix 0xf565e200
106630 socket
vdccm 20969 patrick 10u IPv4 107765
TCP 192.168.131.1:dccm->192.168.131.129:1028 (ESTABLISHED)
yum 21837 root cwd DIR 253,0 4096
10193029 /usr/local/src/SynCe/vdccm
*************************
netstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address
State
tcp 2383 0 192.168.1.2:50973 ftp.chg.ru:http
CLOSE_WAIT
tcp 2382 0 192.168.1.2:50976 ftp.chg.ru:http
CLOSE_WAIT
tcp 0 0 192.168.131.1:dccm 192.168.131.129:1028
ESTABLISHED
tcp 1 0 192.168.1.2:37498 admin.fedora.redhat.co
:http
CLOSE_WAIT
tcp 64639 0 sgmwongnb.dna.dci.dis:49553 download.fedora.redhat
:http
ESTABLISHED
tcp 1 0 192.168.1.2:48280 ftp.kddlabs.co.jp:http
CLOSE_WAIT
*************************
strace -p 22556
Process 22556 attached - interrupt to quit
select(6, [3 4 5], NULL, NULL, {4, 346000}) = 0 (Timeout)
gettimeofday({1190969068, 303681}, NULL) = 0
gettimeofday({1190969068, 303730}, NULL) = 0
gettimeofday({1190969068, 303772}, NULL) = 0
select(6, [3 4 5], NULL, NULL, {4, 999333}) = 0 (Timeout)
gettimeofday({1190969073, 303677}, NULL) = 0
gettimeofday({1190969073, 303715}, NULL) = 0
gettimeofday({1190969073, 303742}, NULL) = 0
select(6, [3 4 5], NULL, NULL, {4, 999363}) = 0 (Timeout)
gettimeofday({1190969078, 303679}, NULL) = 0
gettimeofday({1190969078, 303749}, NULL) = 0
gettimeofday({1190969078, 303796}, NULL) = 0
select(6, [3 4 5], NULL, NULL, {4, 999309}) = 1 (in [4], left {4,
334000}) select(5, [4], NULL, NULL, NULL) = 1 (in [4])
accept(4, {sa_family=AF_INET, sin_port=htons(1043),
sin_addr=inet_addr("192.168.131.130")}, [16]) = 10
getpeername(10, {sa_family=AF_INET, sin_port=htons(1043),
sin_addr=inet_addr("192.168.131.130")}, [16]) = 0
setsockopt(10, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
getsockname(10, {sa_family=AF_INET, sin_port=htons(5679),
sin_addr=inet_addr("192.168.131.2")}, [16]) = 0
gettimeofday({1190969078, 970473}, NULL) = 0
gettimeofday({1190969078, 970527}, NULL) = 0
select(11, [3 4 5 10], NULL, NULL, {4, 332578}) = 1 (in [10], left {4,
332578})
read(10, "\0\0\0\0", 4) = 4
write(2, "[bool WindowsCEDevice::handleEve"..., 42) = 42
write(2, "Header: 0", 9) = 9
write(2, "\n", 1) = 1
write(2, "[bool WindowsCEDevice::handleEve"..., 42) = 42
write(2, "initialization package", 22) = 22
write(2, "\n", 1) = 1
gettimeofday({1190969078, 971621}, NULL) = 0
gettimeofday({1190969078, 971675}, NULL) = 0
select(11, [3 4 5 10], NULL, NULL, {4, 331430}) = 1 (in [10], left {4,
328000})
read(10, "d\0\0\0", 4) = 4
write(2, "[bool WindowsCEDevice::handleEve"..., 42) = 42
write(2, "Header: 100", 11) = 11
write(2, "\n", 1) = 1
write(2, "[bool WindowsCEDevice::handleInf"..., 55) = 55
write(2, "this is an information message", 30) = 30
write(2, "\n", 1) = 1
read(10, "(\0\0\0\5\0\0\0\21\n\0\0\0\0\0\0)U\211`\0\0\0\0(\0\0\000"...
,
100) = 100
open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 11
fstat64(11, {st_mode=S_IFREG|0644, st_size=25486, ...}) = 0
mmap2(NULL, 25486, PROT_READ, MAP_SHARED, 11, 0) = 0xb7f6c000
close(11) = 0
futex(0x4bd27a4c, FUTEX_WAKE, 2147483647) = 0
open("/usr/lib/gconv/ISO8859-1.so", O_RDONLY) = 11
read(11, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0
\3\0\000"..., 512) = 512
fstat64(11, {st_mode=S_IFREG|0755, st_size=5436, ...}) = 0
mmap2(NULL, 8212, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 11,
0) = 0x24f000
mmap2(0x250000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_
DENYWRITE, 11, 0) = 0x250000
close(11) = 0
write(7, "A", 1) = 1
futex(0x95fc0dc, FUTEX_WAKE, 1) = 1
getuid32() = 501
open("/etc/passwd", O_RDONLY) = 11
fcntl64(11, F_GETFD) = 0
fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
fstat64(11, {st_mode=S_IFREG|0644, st_size=1938, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7f6b000
read(11, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1938
close(11) = 0
munmap(0xb7f6b000, 4096) = 0
stat64("/home/patrick/.synce", {st_mode=S_IFDIR|0700, st_size=4096,
...}) = 0 write(2, "[bool ConnectionFileManager::_wr"..., 96) = 96
write(2, "Writing client-file: /home/patri"..., 57) = 57
write(2, "\n", 1) = 1
open("/home/patrick/.synce/192.168.131.130", O_WRONLY|O_CREAT|O_TRUNC|
O_LARGEFILE, 0666) = 11
write(11, "# Modifications to this file wil"..., 78) = 78
write(11, "\n", 1) = 1
write(11, "[dccm]\n", 7) = 7
write(11, "pid=22556\n", 10) = 10
write(11, "\n", 1) = 1
write(11, "[device]\n", 9) = 9
write(11, "os_version=5\n", 13) = 13
write(11, "build_bumber=0\n", 15) = 15
write(11, "processor_type=2577\n", 20) = 20
write(11, "partner_id_1=1619612969\n", 24) = 24
write(11, "partner_id_2=0\n", 15) = 15
<snip>
write(11, "ip=192.168.131.130\n", 19) = 19
write(11, "port=1043\n", 10) = 10
write(11, "\n", 1) = 1
write(11, "[connection]\n", 13) = 13
write(11, "transport=ppp\n", 14) = 14
close(11) = 0
getuid32() = 501
open("/etc/passwd", O_RDONLY) = 11
fcntl64(11, F_GETFD) = 0
fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
fstat64(11, {st_mode=S_IFREG|0644, st_size=1938, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7f6b000
read(11, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1938
close(11) = 0
munmap(0xb7f6b000, 4096) = 0
stat64("/home/patrick/.synce", {st_mode=S_IFDIR|0700, st_size=4096,
...}) = 0 write(2, "[bool ConnectionFileManager::_wr"..., 96) = 96
write(2, "Writing client-file: /home/patri"..., 59) = 59
write(2, "\n", 1) = 1
open("/home/patrick/.synce/active_connection", O_WRONLY|O_CREAT|O_TRUN
C|O_LARGEFILE, 0666) = 11
write(11, "# Modifications to this file wil"..., 78) = 78
write(11, "\n", 1) = 1
write(11, "[dccm]\n", 7) = 7
write(11, "pid=22556\n", 10) = 10
write(11, "\n", 1) = 1
write(11, "[device]\n", 9) = 9
write(11, "os_version=5\n", 13) = 13
write(11, "build_bumber=0\n", 15) = 15
write(11, "processor_type=2577\n", 20) = 20
write(11, "partner_id_1=1619612969\n", 24) = 24
write(11, "partner_id_2=0\n", 15) = 15
<snip>
write(11, "ip=192.168.131.130\n", 19) = 19
write(11, "port=1043\n", 10) = 10
write(11, "\n", 1) = 1
write(11, "[connection]\n", 13) = 13
write(11, "transport=ppp\n", 14) = 14
close(11) = 0
getuid32() = 501
open("/etc/passwd", O_RDONLY) = 11
fcntl64(11, F_GETFD) = 0
fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
fstat64(11, {st_mode=S_IFREG|0644, st_size=1938, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7f6b000
read(11, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1938
close(11) = 0
munmap(0xb7f6b000, 4096) = 0
stat64("/home/patrick/.synce", {st_mode=S_IFDIR|0700, st_size=4096,
...}) = 0 stat64("/home/patrick/.synce/scripts", {st_mode=S_IFDIR|0700
, st_size=4096,
..}) = 0
open("/home/patrick/.synce/scripts", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O
_DIRECTORY) = 11
fstat64(11, {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
getdents(11, /* 3 entries */, 4096) = 52
lstat64("/home/patrick/.synce/scripts/.", {st_mode=S_IFDIR|0700,
st_size=4096, ...}) = 0
lstat64("/home/patrick/.synce/scripts/dccm.sh", {st_mode=S_IFREG|0755,
st_size=245, ...}) = 0
write(2, "[static void Utils::runScripts(s"..., 62) = 62
write(2, "Running script: /home/patrick/.s"..., 60) = 60
write(2, "\n", 1) = 1
rt_sigaction(SIGINT, {SIG_IGN}, {0x80516f0, [INT], SA_RESTART}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {0x80516f0, [QUIT], SA_RESTART}, 8)
= 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD,
parent_tidptr=0xbf854294) = 22677
waitpid(22677, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 22677
rt_sigaction(SIGINT, {0x80516f0, [INT], SA_RESTART}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {0x80516f0, [QUIT], SA_RESTART}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
lstat64("/home/patrick/.synce/scripts/..", {st_mode=S_IFDIR|0700,
st_size=4096, ...}) = 0
getdents(11, /* 0 entries */, 4096) = 0
close(11) = 0
write(2, "[void DeviceManager::addConnecte"..., 66) = 66
write(2, "Device connected: 192.168.131.13"..., 33) = 33
write(2, "\n", 1) = 1
gettimeofday({1190969078, 992408}, NULL) = 0
gettimeofday({1190969078, 992451}, NULL) = 0
select(11, [3 4 5 10], NULL, NULL, {4, 310654}) = 0 (Timeout)
gettimeofday({1190969083, 302684}, NULL) = 0
gettimeofday({1190969083, 302746}, NULL) = 0
*************************
----------------------------------------------------------------------
---
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
SynCE-Devel mailing list
https://lists.sourceforge.net/lists/listinfo/synce-devel

[Patrick Shirkey]

Hi Scott,

Thanks for your in depth analysis. It seems that the culprit is:

.synce/scripts/dccm.sh

If I remove the dccm.sh script from the path I get the same result for
ppp0. Putting it back allows ppp0 to stay up.

Here's the script:

++++++++++++++++++++++++++++++++++++++
more .synce/scripts/dccm.sh
#!/bin/sh

case "$1" in

connect)
;;

disconnect)
;;

start|stop)
raki=`dcop | grep raki`
dcop $raki Raki "dccmNotification(QString)" $1
2> /dev/null > /dev/null
;;

install)
;;

uninstall)
;;

*)
echo "Help!"
;;
esac
++++++++++++++++++++++++++++++++++++++




Here's the trace with more defined results for archival purposes...

********************************

strace -p 5446

ppp0 Connects here:


select(6, [3 4 5], NULL, NULL, {4, 999019}) = 1 (in [4], left {3,
598000})
select(5, [4], NULL, NULL, NULL) = 1 (in [4])
accept(4, {sa_family=AF_INET, sin_port=htons(1040),
sin_addr=inet_addr("192.168.131.129")}, [16]) = 10
getpeername(10, {sa_family=AF_INET, sin_port=htons(1040),
sin_addr=inet_addr("192.168.131.129")}, [16]) = 0
setsockopt(10, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
getsockname(10, {sa_family=AF_INET, sin_port=htons(5679),
sin_addr=inet_addr("192.168.131.1")}, [16]) = 0
gettimeofday({1191320688, 196909}, NULL) = 0
gettimeofday({1191320688, 196951}, NULL) = 0
select(11, [3 4 5 10], NULL, NULL, {3, 596228}) = 1 (in [10], left {3,
558000})
read(10, "\0\0\0\0", 4) = 4
write(2, "[bool WindowsCEDevice::handleEve"..., 42) = 42
write(2, "Header: 0", 9) = 9
write(2, "\n", 1) = 1
write(2, "[bool WindowsCEDevice::handleEve"..., 42) = 42
write(2, "initialization package", 22) = 22
write(2, "\n", 1) = 1
gettimeofday({1191320688, 237093}, NULL) = 0
gettimeofday({1191320688, 237136}, NULL) = 0
select(11, [3 4 5 10], NULL, NULL, {3, 556043}) = 1 (in [10], left {3,
552000})
read(10, "d\0\0\0", 4) = 4
write(2, "[bool WindowsCEDevice::handleEve"..., 42) = 42
write(2, "Header: 100", 11) = 11
write(2, "\n", 1) = 1
write(2, "[bool WindowsCEDevice::handleInf"..., 55) = 55
write(2, "this is an information message", 30) = 30
write(2, "\n", 1) = 1
read(10, "(\0\0\0\5\0\0\0\21\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0(\0\0\000"...,
100) = 100
write(7, "A", 1) = 1
getuid32() = 501
open("/etc/passwd", O_RDONLY) = 11
fcntl64(11, F_GETFD) = 0
fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
fstat64(11, {st_mode=S_IFREG|0644, st_size=1938, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f0b000
read(11, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1938
close(11) = 0
munmap(0xb7f0b000, 4096) = 0
stat64("/home/patrick/.synce", {st_mode=S_IFDIR|0700,
st_size=4096, ...}) = 0
write(2, "[bool ConnectionFileManager::_wr"..., 96) = 96
write(2, "Writing client-file: /home/patri"..., 57) = 57
write(2, "\n", 1) = 1
open("/home/patrick/.synce/192.168.131.129", O_WRONLY|O_CREAT|O_TRUNC|
O_LARGEFILE, 0666) = 11
write(11, "# Modifications to this file wil"..., 78) = 78
write(11, "\n", 1) = 1
write(11, "[dccm]\n", 7) = 7
write(11, "pid=5446\n", 9) = 9
write(11, "\n", 1) = 1
write(11, "[device]\n", 9) = 9
write(11, "os_version=5\n", 13) = 13
write(11, "build_bumber=0\n", 15) = 15
write(11, "processor_type=2577\n", 20) = 20
write(11, "partner_id_1=0\n", 15) = 15
write(11, "partner_id_2=0\n", 15) = 15

<snip>

write(11, "ip=192.168.131.129\n", 19) = 19
write(11, "port=1040\n", 10) = 10
write(11, "\n", 1) = 1
write(11, "[connection]\n", 13) = 13
write(11, "transport=ppp\n", 14) = 14
close(11) = 0
getuid32() = 501
open("/etc/passwd", O_RDONLY) = 11
fcntl64(11, F_GETFD) = 0
fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
fstat64(11, {st_mode=S_IFREG|0644, st_size=1938, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f0b000
read(11, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1938
close(11) = 0
munmap(0xb7f0b000, 4096) = 0
stat64("/home/patrick/.synce", {st_mode=S_IFDIR|0700,
st_size=4096, ...}) = 0
write(2, "[bool ConnectionFileManager::_wr"..., 96) = 96
write(2, "Writing client-file: /home/patri"..., 59) = 59
write(2, "\n", 1) = 1
open("/home/patrick/.synce/active_connection", O_WRONLY|O_CREAT|O_TRUNC|
O_LARGEFILE, 0666) = 11
write(11, "# Modifications to this file wil"..., 78) = 78
write(11, "\n", 1) = 1
write(11, "[dccm]\n", 7) = 7
write(11, "pid=5446\n", 9) = 9
write(11, "\n", 1) = 1
write(11, "[device]\n", 9) = 9
write(11, "os_version=5\n", 13) = 13
write(11, "build_bumber=0\n", 15) = 15
write(11, "processor_type=2577\n", 20) = 20
write(11, "partner_id_1=0\n", 15) = 15
write(11, "partner_id_2=0\n", 15) = 15

<snip>

write(11, "ip=192.168.131.129\n", 19) = 19
write(11, "port=1040\n", 10) = 10
write(11, "\n", 1) = 1
write(11, "[connection]\n", 13) = 13
write(11, "transport=ppp\n", 14) = 14
close(11) = 0
getuid32() = 501
open("/etc/passwd", O_RDONLY) = 11
fcntl64(11, F_GETFD) = 0
fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
fstat64(11, {st_mode=S_IFREG|0644, st_size=1938, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f0b000
read(11, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1938
close(11) = 0
munmap(0xb7f0b000, 4096) = 0
stat64("/home/patrick/.synce", {st_mode=S_IFDIR|0700,
st_size=4096, ...}) = 0
stat64("/home/patrick/.synce/scripts", {st_mode=S_IFDIR|0700,
st_size=4096, ...}) = 0
open("/home/patrick/.synce/scripts", O_RDONLY|O_NONBLOCK|O_LARGEFILE|
O_DIRECTORY) = 11
fstat64(11, {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
getdents(11, /* 3 entries */, 4096) = 52
lstat64("/home/patrick/.synce/scripts/.", {st_mode=S_IFDIR|0700,
st_size=4096, ...}) = 0
lstat64("/home/patrick/.synce/scripts/dccm.sh", {st_mode=S_IFREG|0755,
st_size=245, ...}) = 0
write(2, "[static void Utils::runScripts(s"..., 62) = 62
write(2, "Running script: /home/patrick/.s"..., 60) = 60
write(2, "\n", 1) = 1
rt_sigaction(SIGINT, {SIG_IGN}, {0x80516f0, [INT], SA_RESTART}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {0x80516f0, [QUIT], SA_RESTART}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD,
parent_tidptr=0xbfe678a4) = 5957
waitpid(5957, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 5957
rt_sigaction(SIGINT, {0x80516f0, [INT], SA_RESTART}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {0x80516f0, [QUIT], SA_RESTART}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
lstat64("/home/patrick/.synce/scripts/..", {st_mode=S_IFDIR|0700,
st_size=4096, ...}) = 0
getdents(11, /* 0 entries */, 4096) = 0
close(11) = 0
write(2, "[void DeviceManager::addConnecte"..., 66) = 66
write(2, "Device connected: 192.168.131.12"..., 33) = 33
write(2, "\n", 1) = 1
gettimeofday({1191320688, 259462}, NULL) = 0
gettimeofday({1191320688, 259495}, NULL) = 0
select(11, [3 4 5 10], NULL, NULL, {3, 533684}) = 0 (Timeout)
.
.
.

ppp1 Connects here:

gettimeofday({1191320921, 796397}, NULL) = 0
gettimeofday({1191320921, 796440}, NULL) = 0
select(11, [3 4 5 10], NULL, NULL, {4, 996739}) = 1 (in [4], left {0,
793000})
select(5, [4], NULL, NULL, NULL) = 1 (in [4])
accept(4, {sa_family=AF_INET, sin_port=htons(1025),
sin_addr=inet_addr("192.168.131.130")}, [16]) = 11
getpeername(11, {sa_family=AF_INET, sin_port=htons(1025),
sin_addr=inet_addr("192.168.131.130")}, [16]) = 0
setsockopt(11, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
getsockname(11, {sa_family=AF_INET, sin_port=htons(5679),
sin_addr=inet_addr("192.168.131.2")}, [16]) = 0
gettimeofday({1191320926, 871}, NULL) = 0
gettimeofday({1191320926, 918}, NULL) = 0
select(12, [3 4 5 10 11], NULL, NULL, {0, 792261}) = 1 (in [11], left
{0, 792261})
read(11, "\0\0\0\0", 4) = 4
write(2, "[bool WindowsCEDevice::handleEve"..., 42) = 42
write(2, "Header: 0", 9) = 9
write(2, "\n", 1) = 1
write(2, "[bool WindowsCEDevice::handleEve"..., 42) = 42
write(2, "initialization package", 22) = 22
write(2, "\n", 1) = 1
gettimeofday({1191320926, 2103}, NULL) = 0
gettimeofday({1191320926, 2157}, NULL) = 0
select(12, [3 4 5 10 11], NULL, NULL, {0, 791022}) = 1 (in [11], left
{0, 784000})
read(11, "d\0\0\0", 4) = 4
write(2, "[bool WindowsCEDevice::handleEve"..., 42) = 42
write(2, "Header: 100", 11) = 11
write(2, "\n", 1) = 1
write(2, "[bool WindowsCEDevice::handleInf"..., 55) = 55
write(2, "this is an information message", 30) = 30
write(2, "\n", 1) = 1
read(11, "(\0\0\0\5\0\0\0\21\n\0\0\0\0\0\0)U\211`\0\0\0\0(\0\0\000"...,
100) = 100
write(2, "[virtual void WindowsCEDevice::d"..., 48) = 48
write(2, "Disconnect", 10) = 10
write(2, "\n", 1) = 1
close(11) = 0



************************************************8
vdccm -d 5 -f -i


ppp0 Connects here:

[bool WindowsCEDevice::handleInfoMessage(uint32_t):93] this is an
information message
[bool ConnectionFileManager::_writeConnectionFile(std::string, const
WindowsCEDeviceBase*):117] Writing
client-file: /home/patrick/.synce/192.168.131.129
[bool ConnectionFileManager::_writeConnectionFile(std::string, const
WindowsCEDeviceBase*):117] Writing
client-file: /home/patrick/.synce/active_connection
[static void Utils::runScripts(std::string, std::string):230] Running
script: /home/patrick/.synce/scripts/dccm.sh connect
[void DeviceManager::addConnectedDevice(WindowsCEDeviceBase*):85] Device
connected: 192.168.131.129
.
.
.

ppp1 Connects here:

[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 0
[bool WindowsCEDevice::handleEvent():186] initialization package
[bool WindowsCEDevice::handleEvent():184] Header: 100
[bool WindowsCEDevice::handleInfoMessage(uint32_t):93] this is an
information message
[virtual void WindowsCEDevice::disconnect():67] Disconnect
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896

[Scott Gifford]

Post by Patrick Shirkey
Hi Scott,
.synce/scripts/dccm.sh
If I remove the dccm.sh script from the path I get the same result for
ppp0. Putting it back allows ppp0 to stay up.
++++++++++++++++++++++++++++++++++++++
more .synce/scripts/dccm.sh
#!/bin/sh
case "$1" in
connect)
;;
disconnect)
;;
start|stop)
raki=`dcop | grep raki`
dcop $raki Raki "dccmNotification(QString)" $1
2> /dev/null > /dev/null
;;
install)
;;
uninstall)
;;
*)
echo "Help!"
;;
esac
++++++++++++++++++++++++++++++++++++++

That's interesting. It seems to imply that your device requires Raki
to be running to stay up, but I don't know why that would be; I
certainly didn't use Raki when I was syncing multiple PDAs. Maybe
it's a configuration option somewhere? Maybe it would be useful to
redirect output to a log file to see what's going on here?

It's also strange that it makes a difference to call "dccm.sh
connect", which for your script doesn't seem to actually do anything

I also don't see how it could be telling Raki which device to
configure ($1 looks like it contains "connect"), so it would make
sense if it was configuring active_connection, and so never does
anything with the second PDA. Are there logs or configuration options
for Raki that might be helpful?

Maybe it would be useful to try shutting down Raki and see if anything
different happens? Or maybe try compiling without "--enable-desktop-integration"?
and see if that helps?

I'm really grasping at straws here. I suspect this is a feature that
has changed since last time I used synce. I see in vdccm.cpp where
it's running the start scripts, but I don't see any documentation for
exactly what they do or what behavior they change.

Maybe somebody with more recent knowledge of synce and Raki could step
in here with an explanation of what might be going on?

The other thing that's odd is that vdccm seems to be treating the two
devices differently, and I don't know why that would be. The first
device gets writeConnectionFile called, and also "dccm.sh connect",

Post by Patrick Shirkey
[bool WindowsCEDevice::handleInfoMessage(uint32_t):93] this is an
information message
[bool ConnectionFileManager::_writeConnectionFile(std::string, const
WindowsCEDeviceBase*):117] Writing
client-file: /home/patrick/.synce/192.168.131.129
[bool ConnectionFileManager::_writeConnectionFile(std::string, const
WindowsCEDeviceBase*):117] Writing
client-file: /home/patrick/.synce/active_connection
[static void Utils::runScripts(std::string, std::string):230] Running
script: /home/patrick/.synce/scripts/dccm.sh connect
[void DeviceManager::addConnectedDevice(WindowsCEDeviceBase*):85] Device
connected: 192.168.131.129
.
.
.
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 0
[bool WindowsCEDevice::handleEvent():186] initialization package
[bool WindowsCEDevice::handleEvent():184] Header: 100
[bool WindowsCEDevice::handleInfoMessage(uint32_t):93] this is an
information message
[virtual void WindowsCEDevice::disconnect():67] Disconnect
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896

When I ran into weirdness like this, I eventually ended up stepping
into dccm with a debugger. Maybe you'll have to resort to that, too.

Good luck!

----Scott.

[Patrick Shirkey]

Post by Scott Gifford

Post by Patrick Shirkey
Hi Scott,
.synce/scripts/dccm.sh
If I remove the dccm.sh script from the path I get the same result for
ppp0. Putting it back allows ppp0 to stay up.
++++++++++++++++++++++++++++++++++++++
more .synce/scripts/dccm.sh
#!/bin/sh
case "$1" in
connect)
;;
disconnect)
;;
start|stop)
raki=`dcop | grep raki`
dcop $raki Raki "dccmNotification(QString)" $1
2> /dev/null > /dev/null
;;
install)
;;
uninstall)
;;
*)
echo "Help!"
;;
esac
++++++++++++++++++++++++++++++++++++++

That's interesting. It seems to imply that your device requires Raki
to be running to stay up, but I don't know why that would be; I
certainly didn't use Raki when I was syncing multiple PDAs. Maybe
it's a configuration option somewhere? Maybe it would be useful to
redirect output to a log file to see what's going on here?
It's also strange that it makes a difference to call "dccm.sh
connect", which for your script doesn't seem to actually do anything
I also don't see how it could be telling Raki which device to
configure ($1 looks like it contains "connect"), so it would make
sense if it was configuring active_connection, and so never does
anything with the second PDA. Are there logs or configuration options
for Raki that might be helpful?
Maybe it would be useful to try shutting down Raki and see if anything
different happens? Or maybe try compiling without "--enable-desktop-integration"?
and see if that helps?
I'm really grasping at straws here. I suspect this is a feature that
has changed since last time I used synce. I see in vdccm.cpp where
it's running the start scripts, but I don't see any documentation for
exactly what they do or what behavior they change.
Maybe somebody with more recent knowledge of synce and Raki could step
in here with an explanation of what might be going on?
The other thing that's odd is that vdccm seems to be treating the two
devices differently, and I don't know why that would be. The first
device gets writeConnectionFile called, and also "dccm.sh connect",

Hi Scott,

I have been running the tests above without raki.

Disabling the desktop integration on libsynce and vdccm did not change
anything.

It would be helpful if someone could explain what the dccm.sh script is
for.


Cheers.

[Volker Christian]

On Wednesday 03 October 2007, Patrick Shirkey wrote:
...

Post by Patrick Shirkey

Post by Patrick Shirkey
++++++++++++++++++++++++++++++++++++++
more .synce/scripts/dccm.sh
#!/bin/sh
case "$1" in
connect)
;;
disconnect)
;;
start|stop)
raki=`dcop | grep raki`
dcop $raki Raki "dccmNotification(QString)" $1
2> /dev/null > /dev/null
;;
install)
;;
uninstall)
;;
*)
echo "Help!"
;;
esac
++++++++++++++++++++++++++++++++++++++

Hi Scott,
I have been running the tests above without raki.
Disabling the desktop integration on libsynce and vdccm did not change
anything.
It would be helpful if someone could explain what the dccm.sh script is
for.
Cheers.

Hi,

a unix-socket (~.synce/csock) is used for the normal communication between
vdccm and raki. vdccm is the server, and raki connects to it. Thus, there is
no need for a script for normal operation.
Nevertheless, if raki is started before vdccm, it has to be notified when
vdccm has created the server-socket (~.synce/csock). For this the above
script is used, which is executed by vdccm during startup, to force raki to
connect to vdccm.
If you start raki after vdccm, this script is useless.

regards
voc

[Patrick Shirkey]

Post by Volker Christian
...

Post by Patrick Shirkey

Post by Patrick Shirkey
++++++++++++++++++++++++++++++++++++++
more .synce/scripts/dccm.sh
#!/bin/sh
case "$1" in
connect)
;;
disconnect)
;;
start|stop)
raki=`dcop | grep raki`
dcop $raki Raki "dccmNotification(QString)" $1
2> /dev/null > /dev/null
;;
install)
;;
uninstall)
;;
*)
echo "Help!"
;;
esac
++++++++++++++++++++++++++++++++++++++

Hi Scott,
I have been running the tests above without raki.
Disabling the desktop integration on libsynce and vdccm did not change
anything.
It would be helpful if someone could explain what the dccm.sh script is
for.
Cheers.

Hi,
a unix-socket (~.synce/csock) is used for the normal communication between
vdccm and raki. vdccm is the server, and raki connects to it. Thus, there is
no need for a script for normal operation.
Nevertheless, if raki is started before vdccm, it has to be notified when
vdccm has created the server-socket (~.synce/csock). For this the above
script is used, which is executed by vdccm during startup, to force raki to
connect to vdccm.
If you start raki after vdccm, this script is useless.

So is it a bug that my first device only connects for about three
seconds if I remove the dccm.sh script even though I don't have raki
running and it works very well if I leave dccm.sh in place?

- I have removed the scripts from /etc/udev/rules/

But that doesn't make any difference.


Cheers.

[Volker Christian]

Post by Patrick Shirkey

Post by Volker Christian
...

Post by Patrick Shirkey

Post by Patrick Shirkey
++++++++++++++++++++++++++++++++++++++
more .synce/scripts/dccm.sh
#!/bin/sh
case "$1" in
connect)
;;
disconnect)
;;
start|stop)
raki=`dcop | grep raki`
dcop $raki Raki "dccmNotification(QString)" $1
2> /dev/null > /dev/null
;;
install)
;;
uninstall)
;;
*)
echo "Help!"
;;
esac
++++++++++++++++++++++++++++++++++++++

Hi Scott,
I have been running the tests above without raki.
Disabling the desktop integration on libsynce and vdccm did not change
anything.
It would be helpful if someone could explain what the dccm.sh script is
for.
Cheers.

Hi,
a unix-socket (~.synce/csock) is used for the normal communication
between vdccm and raki. vdccm is the server, and raki connects to it.
Thus, there is no need for a script for normal operation.
Nevertheless, if raki is started before vdccm, it has to be notified when
vdccm has created the server-socket (~.synce/csock). For this the above
script is used, which is executed by vdccm during startup, to force raki
to connect to vdccm.
If you start raki after vdccm, this script is useless.

So is it a bug that my first device only connects for about three
seconds if I remove the dccm.sh script even though I don't have raki
running and it works very well if I leave dccm.sh in place?

For that to know, it is necessary for me to know the device-type you use. Is
is t pre-WM5 device of a WM5 device?

Pre-WM5 devices connect by themself to vdccm and start talking to it. WM5
devices need the triggerconnection-command for initiating a connection to
vdccm.
It will be a very strange behavious if your device initially starts talking to
vdccm and disconnect a view seconds. Maybe there is a firewall running
somehow which prevents vdccm sending the "ping" packages to the device and/or
prevents receiving the "pong" packages back. Try to start vdccm with "-d 5 -s
2" and have a look at the output of vdccm - every 2 seconds a ping-package
should be send to the device and the corresponding "pong" package should be
received. If this isn't the case you have some fundamental connection
problems to you device.

regards
voc

Post by Patrick Shirkey
- I have removed the scripts from /etc/udev/rules/
But that doesn't make any difference.
Cheers.

[Patrick Shirkey]

Post by Volker Christian

Post by Patrick Shirkey

Post by Volker Christian
...

Post by Patrick Shirkey

Post by Patrick Shirkey
++++++++++++++++++++++++++++++++++++++
more .synce/scripts/dccm.sh
#!/bin/sh
case "$1" in
connect)
;;
disconnect)
;;
start|stop)
raki=`dcop | grep raki`
dcop $raki Raki "dccmNotification(QString)" $1
2> /dev/null > /dev/null
;;
install)
;;
uninstall)
;;
*)
echo "Help!"
;;
esac
++++++++++++++++++++++++++++++++++++++

Hi Scott,
I have been running the tests above without raki.
Disabling the desktop integration on libsynce and vdccm did not change
anything.
It would be helpful if someone could explain what the dccm.sh script is
for.
Cheers.

Hi,
a unix-socket (~.synce/csock) is used for the normal communication
between vdccm and raki. vdccm is the server, and raki connects to it.
Thus, there is no need for a script for normal operation.
Nevertheless, if raki is started before vdccm, it has to be notified when
vdccm has created the server-socket (~.synce/csock). For this the above
script is used, which is executed by vdccm during startup, to force raki
to connect to vdccm.
If you start raki after vdccm, this script is useless.

So is it a bug that my first device only connects for about three
seconds if I remove the dccm.sh script even though I don't have raki
running and it works very well if I leave dccm.sh in place?

For that to know, it is necessary for me to know the device-type you use. Is
is t pre-WM5 device of a WM5 device?
Pre-WM5 devices connect by themself to vdccm and start talking to it. WM5
devices need the triggerconnection-command for initiating a connection to
vdccm.

The device is running windows CE 5.0

Post by Volker Christian
It will be a very strange behavious if your device initially starts talking to
vdccm and disconnect a view seconds. Maybe there is a firewall running
somehow which prevents vdccm sending the "ping" packages to the device and/or
prevents receiving the "pong" packages back. Try to start vdccm with "-d 5 -s
2" and have a look at the output of vdccm - every 2 seconds a ping-package
should be send to the device and the corresponding "pong" package should be
received. If this isn't the case you have some fundamental connection
problems to you device.

I have disabled the firewall and the device works if the dccm.sh script
is in place.


vdccm -d 5 -s 2 -f -i
[static void Utils::runScripts(std::string, std::string):230] Running
script: /home/patrick/.synce/scripts/dccm.sh start
[bool WindowsCEDevice::handleEvent():184] Header: 0
[bool WindowsCEDevice::handleEvent():186] initialization package
[bool WindowsCEDevice::handleEvent():184] Header: 100
[bool WindowsCEDevice::handleInfoMessage(uint32_t):93] this is an
information message
[bool ConnectionFileManager::_writeConnectionFile(std::string, const
WindowsCEDeviceBase*):117] Writing
client-file: /home/patrick/.synce/192.168.131.129
[bool ConnectionFileManager::_writeConnectionFile(std::string, const
WindowsCEDeviceBase*):117] Writing
client-file: /home/patrick/.synce/active_connection
[static void Utils::runScripts(std::string, std::string):230] Running
script: /home/patrick/.synce/scripts/dccm.sh connect
[void DeviceManager::addConnectedDevice(WindowsCEDeviceBase*):85] Device
connected: 192.168.131.129
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply

[Volker Christian]

Post by Patrick Shirkey
...
The device is running windows CE 5.0

Post by Volker Christian
It will be a very strange behavious if your device initially starts
talking to vdccm and disconnect a view seconds. Maybe there is a firewall
running somehow which prevents vdccm sending the "ping" packages to the
device and/or prevents receiving the "pong" packages back. Try to start
vdccm with "-d 5 -s 2" and have a look at the output of vdccm - every 2
seconds a ping-package should be send to the device and the corresponding
"pong" package should be received. If this isn't the case you have some
fundamental connection problems to you device.

I have disabled the firewall and the device works if the dccm.sh script
is in place.
vdccm -d 5 -s 2 -f -i
[static void Utils::runScripts(std::string, std::string):230] Running
script: /home/patrick/.synce/scripts/dccm.sh start
[bool WindowsCEDevice::handleEvent():184] Header: 0
[bool WindowsCEDevice::handleEvent():186] initialization package
[bool WindowsCEDevice::handleEvent():184] Header: 100
[bool WindowsCEDevice::handleInfoMessage(uint32_t):93] this is an
information message
[bool ConnectionFileManager::_writeConnectionFile(std::string, const
WindowsCEDeviceBase*):117] Writing
client-file: /home/patrick/.synce/192.168.131.129
[bool ConnectionFileManager::_writeConnectionFile(std::string, const
WindowsCEDeviceBase*):117] Writing
client-file: /home/patrick/.synce/active_connection
[static void Utils::runScripts(std::string, std::string):230] Running
script: /home/patrick/.synce/scripts/dccm.sh connect
[void DeviceManager::addConnectedDevice(WindowsCEDeviceBase*):85] Device
connected: 192.168.131.129
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply

Ok, this looks like ok. Vdccm sends and receives those ping-pong packages.
Thus, vdccm is not the reason, why you device disconnects after some time.

regards
voc

[Patrick Shirkey]

Post by Volker Christian

Post by Patrick Shirkey
...
The device is running windows CE 5.0

Post by Volker Christian
It will be a very strange behavious if your device initially starts
talking to vdccm and disconnect a view seconds. Maybe there is a firewall
running somehow which prevents vdccm sending the "ping" packages to the
device and/or prevents receiving the "pong" packages back. Try to start
vdccm with "-d 5 -s 2" and have a look at the output of vdccm - every 2
seconds a ping-package should be send to the device and the corresponding
"pong" package should be received. If this isn't the case you have some
fundamental connection problems to you device.

I have disabled the firewall and the device works if the dccm.sh script
is in place.
vdccm -d 5 -s 2 -f -i
[static void Utils::runScripts(std::string, std::string):230] Running
script: /home/patrick/.synce/scripts/dccm.sh start
[bool WindowsCEDevice::handleEvent():184] Header: 0
[bool WindowsCEDevice::handleEvent():186] initialization package
[bool WindowsCEDevice::handleEvent():184] Header: 100
[bool WindowsCEDevice::handleInfoMessage(uint32_t):93] this is an
information message
[bool ConnectionFileManager::_writeConnectionFile(std::string, const
WindowsCEDeviceBase*):117] Writing
client-file: /home/patrick/.synce/192.168.131.129
[bool ConnectionFileManager::_writeConnectionFile(std::string, const
WindowsCEDeviceBase*):117] Writing
client-file: /home/patrick/.synce/active_connection
[static void Utils::runScripts(std::string, std::string):230] Running
script: /home/patrick/.synce/scripts/dccm.sh connect
[void DeviceManager::addConnectedDevice(WindowsCEDeviceBase*):85] Device
connected: 192.168.131.129
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply
[bool WindowsCEDevice::handleEvent():184] Header: 305419896
[bool WindowsCEDevice::handleEvent():188] this is a ping reply

Ok, this looks like ok. Vdccm sends and receives those ping-pong packages.
Thus, vdccm is not the reason, why you device disconnects after some time.

Cool,

So if the dccm.sh script is unnecessary when not running raki is it just
a simple matter of disabling the check in code to get past that step?


Cheers.

[Mark Ellis]

Post by Patrick Shirkey

Post by Scott Gifford

Post by Patrick Shirkey
Hi Scott,
.synce/scripts/dccm.sh
If I remove the dccm.sh script from the path I get the same result for
ppp0. Putting it back allows ppp0 to stay up.

That's interesting. It seems to imply that your device requires Raki
to be running to stay up, but I don't know why that would be; I
certainly didn't use Raki when I was syncing multiple PDAs. Maybe
it's a configuration option somewhere? Maybe it would be useful to
redirect output to a log file to see what's going on here?

I'm not a raki expert, but I can say with some confidence it does
nothing to keep a connection alive.

Post by Patrick Shirkey

Post by Scott Gifford
Maybe it would be useful to try shutting down Raki and see if anything
different happens? Or maybe try compiling without "--enable-desktop-integration"?
and see if that helps?

--enable-desktop-integration is a slightly misleading name, it's the
code that allows communication with odccm over dbus, it won't make any
difference here.

Post by Patrick Shirkey

Post by Scott Gifford
Maybe somebody with more recent knowledge of synce and Raki could step
in here with an explanation of what might be going on?
The other thing that's odd is that vdccm seems to be treating the two
devices differently, and I don't know why that would be. The first
device gets writeConnectionFile called, and also "dccm.sh connect",

The scripts won't help the situation, but they are a good indicator of
whether the device is fully connected.

Post by Patrick Shirkey
Hi Scott,
I have been running the tests above without raki.

Excellent, I have no particular recommendations (sorry) but I think the
raki discussion was starting to confuse the issue. Until you get it
working I would use vdccm and the command line tools, nothing else is
strictly necessary for a connectionand keeps it simple.

Mark

[Patrick Shirkey]

Post by Mark Ellis

Post by Patrick Shirkey
I have been running the tests above without raki.

Excellent, I have no particular recommendations (sorry) but I think the
raki discussion was starting to confuse the issue. Until you get it
working I would use vdccm and the command line tools, nothing else is
strictly necessary for a connectionand keeps it simple.

Yes, I have been doing that for all the trace tests so far.

Could this be an issue with active_connection in that it is only able to
work with one device at a time?



Cheers.

[Scott Gifford]

Post by Patrick Shirkey
On 9:30:45 am 09/25/07 Scott Gifford

Post by Scott Gifford
I did some similar work, with about 20 devices. I used these patches
to the startup scripts to get the devices to come up automatically,
http://whereabouts.eecs.umich.edu/wiki/lib/exe/fetch.php?id=wherea
bouts_pda_setup&cache=cache&media=synce-serial-0.9.1-sg.tar.gz
They will only work with 128 devices right now, but some simple fixes
to IP address calculations should fix that.

Hi Scott,
I have been looking at the code and I cannot see any specific differences
relating to multiple devices. Can you give me a bit of background on what
you had to modify please?

Hi Patrick,

Yes, I'd be happy to try to help. Unfortunately I no longer have
access to the 20 devices, so I can't test much.

Here is my original post about the patches:

http://www.nabble.com/Patch-to-synce-serial-scripts-t2626112.html

I rewrote nearly all of the serial script code (there wasn't that much
of it). The fixes aren't specific to multiple devices, but they
expand the scripts to be much more flexible, and multiple devices
falls out of that naturally.

The current scripts (at least the 0.10.0 ones) require that you
configure the device with synce-serial-config, then plug it in and run
synce-serial-start. Obviously you don't want to do that individually
for every device, and anyways it only supports one device at a time,
since running synce-serial-config overwrites the previous
configuration file.

My modifications make the scripts configurable from environment
variables and the command-line, with ip addresses assigned
automatically based on the device name, instead of running
synce-serial-config. Then the hotplug/udev scripts can just set the
right environment variables and run synce-serial-start-device to bring
it up, and synce-serial-abort-device to bring it down.

I would love to see these changes incorporated into the main
distribution, but so far haven't seen much interest. If there was a
chance of this happening, I'd be happy to help get things integrated
with the latest SVN trunk, and test with the 1 device I have at least.

Also: I wasn't able to find the serial scripts on the SVN trunk (I
found the 0.10.0 ones). Maybe some of these issues have been
addressed. Did you manage to find these?

----Scott.

[Mark Ellis]

Post by Scott Gifford
I would love to see these changes incorporated into the main
distribution, but so far haven't seen much interest. If there was a
chance of this happening, I'd be happy to help get things integrated
with the latest SVN trunk, and test with the 1 device I have at least.

Hi Scott

I suspect any previous lack of interest had more to do with newer
devices moving away from using a serial connection. Having one of said
older devices I'd be quite interested, bit busy at the moment but once
I've had a chance to catch up on all this maybe we can do something with
it ?

Post by Scott Gifford
Also: I wasn't able to find the serial scripts on the SVN trunk (I
found the 0.10.0 ones). Maybe some of these issues have been
addressed. Did you manage to find these?

It's in

branches/legacy/serial

Mark

[Scott Gifford]

Post by Patrick Shirkey

Post by Scott Gifford
I would love to see these changes incorporated into the main
distribution, but so far haven't seen much interest. If there was a
chance of this happening, I'd be happy to help get things integrated
with the latest SVN trunk, and test with the 1 device I have at least.

Hi Scott
I suspect any previous lack of interest had more to do with newer
devices moving away from using a serial connection.

Ah, that's interesting, I didn't realize that. I just got a WM5
phone, but I haven't plugged it in under Linux yet.

Patrick, you're not using one of the newer WM5 phones that uses RNDIS
are you? If so I'm probably leading you on a wild goose chase with
the serial scripts.

Post by Patrick Shirkey
Having one of said older devices I'd be quite interested, bit busy
at the moment but once I've had a chance to catch up on all this
maybe we can do something with it ?

Sure, whenever somebody has some time I'd be happy to help test and
refine the scripts.

Post by Patrick Shirkey

Post by Scott Gifford
Also: I wasn't able to find the serial scripts on the SVN trunk (I
found the 0.10.0 ones). Maybe some of these issues have been
addressed. Did you manage to find these?

It's in
branches/legacy/serial

Thanks, got it!

---Scott.

[Patrick Shirkey]

Post by Scott Gifford

Post by Patrick Shirkey

Post by Scott Gifford
I would love to see these changes incorporated into the main
distribution, but so far haven't seen much interest. If there
was a chance of this happening, I'd be happy to help get things
integrated with the latest SVN trunk, and test with the 1 device
I have at least.

Hi Scott
I suspect any previous lack of interest had more to do with newer
devices moving away from using a serial connection.

Ah, that's interesting, I didn't realize that. I just got a WM5
phone, but I haven't plugged it in under Linux yet.
Patrick, you're not using one of the newer WM5 phones that uses RNDIS
are you? If so I'm probably leading you on a wild goose chase with
the serial scripts.

Nope. I'm using windows ce 5.0 running on an xscale processor.


Cheers.

--
Patrick Shirkey
Boost Hardware Ltd.