unknown
1970-01-01 00:00:00 UTC
Ahh nuts.
This is the one thing keeping me from releasing this.....
I actually have no idea how to fix it at the moment, but I know exactly
why it happens. When a device connects, we open a listening tcp server
on port 990 and 5679, the first is for WM5 and the second is for
'legacy'. We do both because we dont know what kind it is yet. When the
Wm2003 device connects to port 5679, we close the server on 990 because
we don't need it.
But it doesn't close on 990, so when the device is unplugged and
replugged, we again open both servers, but 990 failed to close, so when
we try and open it we get an error.
I've gone right down to trying to close the file descriptor manually, no
good. It's bound to be something obvious. Anyone that spots it gets to
be King of Synce !!!!!!
=20
=20
-------------------------------------------------------------------------=
-----
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEABECAAYFAk08nXcACgkQkQq5eu6iQvDzKwCfQcfkTjjDbjeT00G4SGnQ5ufy
Cu0An0peegSCG/dkAtyrSrlZbUUugh0i
=Dnhc
-----END PGP SIGNATURE-----
--=-RqlGobMPPC+Mbiydhfe7--
This is the one thing keeping me from releasing this.....
I actually have no idea how to fix it at the moment, but I know exactly
why it happens. When a device connects, we open a listening tcp server
on port 990 and 5679, the first is for WM5 and the second is for
'legacy'. We do both because we dont know what kind it is yet. When the
Wm2003 device connects to port 5679, we close the server on 990 because
we don't need it.
But it doesn't close on 990, so when the device is unplugged and
replugged, we again open both servers, but 990 failed to close, so when
we try and open it we get an error.
I've gone right down to trying to close the file descriptor manually, no
good. It's bound to be something obvious. Anyone that spots it gets to
be King of Synce !!!!!!
I think my new udev rules and thus simplified udev-synce-serial (as per
my patch) are good. Happy to try and debug hal-dccm if you can give me
some pointers.
=20
Karl
=20
inmy patch) are good. Happy to try and debug hal-dccm if you can give me
some pointers.
=20
Karl
=20
=20
Hi Karl
=20
Apologies, I should have replied earlier.
=20
The ubuntu package is actually a bit out of date, so I've already added
some of the fixes you've been sending. I'll upload a new one as soon as
I can.
=20
I'll also take a look at the below. I would rather do this at the udev
level, but I couldn't figure out how. If you've cracked it that will be
great.
=20
The main problem that had stopped me releasing the udev stuff was with
pre WM 5 devices. It worked connecting once, but to connect again I had
to kill dccm. I've now managed to lose my WM2003 test device, can you
try connecting multiple times and confirm if it works or not ?
=20
Thanks
Mark
=20
Hi Karl
=20
Apologies, I should have replied earlier.
=20
The ubuntu package is actually a bit out of date, so I've already added
some of the fixes you've been sending. I'll upload a new one as soon as
I can.
=20
I'll also take a look at the below. I would rather do this at the udev
level, but I couldn't figure out how. If you've cracked it that will be
great.
=20
The main problem that had stopped me releasing the udev stuff was with
pre WM 5 devices. It worked connecting once, but to connect again I had
to kill dccm. I've now managed to lose my WM2003 test device, can you
try connecting multiple times and confirm if it works or not ?
=20
Thanks
Mark
=20
I've done some digging, and worked out that the device querying code =
udev-synce-serial is only necessary for trying to handle two-port
devices. I think this can be better handled in the udev rules, from
which we can launch udev-synce-serial only when required (i.e. on the
2nd port of a two port device), and thus remove all that logic from
udev-synce-serial itself.
=20
That means udev-synce-serial no longer has to call udevadm or use a
library to interrogate the udev database, cutting a chunk of code.
=20
The patch below does just that.
=20
Regards
Karl
devices. I think this can be better handled in the udev rules, from
which we can launch udev-synce-serial only when required (i.e. on the
2nd port of a two port device), and thus remove all that logic from
udev-synce-serial itself.
=20
That means udev-synce-serial no longer has to call udevadm or use a
library to interrogate the udev database, cutting a chunk of code.
=20
The patch below does just that.
=20
Regards
Karl
=20
-------------------------------------------------------------------------=
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand=20
malware threats, the impact they can have on your business, and how you=
=20Learn about various malware tactics and how to avoid them. Understand=20
malware threats, the impact they can have on your business, and how you=
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
SynCE-Devel mailing list
https://lists.sourceforge.net/lists/listinfo/synce-devel
--=-RqlGobMPPC+Mbiydhfe7http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
SynCE-Devel mailing list
https://lists.sourceforge.net/lists/listinfo/synce-devel
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEABECAAYFAk08nXcACgkQkQq5eu6iQvDzKwCfQcfkTjjDbjeT00G4SGnQ5ufy
Cu0An0peegSCG/dkAtyrSrlZbUUugh0i
=Dnhc
-----END PGP SIGNATURE-----
--=-RqlGobMPPC+Mbiydhfe7--