How to establish a PPP connection over USB (/dev/ttyUSB0)?

Kal

Yes it does use standard ppp but can't remember the details.

It should be possible to set up a ppp connection file and then have ppp
use that - that is how synce used to work in days gone by.

Karl

David Eriksson

2011-06-04 07:14:32 UTC

Hi,

Back in the days of the serial interface we used a module called "serial"
[1] to configure and start pppd in SynCE and a daemon called "dccm" [2]
(superseded by vdccm and odccm) to maintain the device connection.

Best regards,

David Eriksson
http://www.divideandconquer.se/

[1] http://synce.svn.sourceforge.net/viewvc/synce/branches/legacy/serial/
[2] http://synce.svn.sourceforge.net/viewvc/synce/branches/obsolete/dccmd/

Post by Kal Sze
Hello,
This is not strictly SynCE-related. I have a requirement to establish
communication with Windows CE WITHOUT installing SynCE on SUSE 8 or 9
(rather old kernel, so no usb-rndis-lite patch).
How does SynCE (or HAL, or the kernel - I don't know which component is
responsible) make a PPP connection over USB (/dev/ttyUSB0) with a Windows CE
device (which is NOT RNDIS-capable)?
I tried searching the svn tree but couldn't spot any meaningful mention of
ppp. Does it use the pppd that comes with many Linux distributions?
If I wanted to manually make a PPP connection from bash, what would the
complete command line be?
Best Regards,
Kal
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with
vRanger.
Installation's a snap, and flexible recovery options mean your data is
safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
SynCE-Devel mailing list
https://lists.sourceforge.net/lists/listinfo/synce-devel

Mark Ellis

2011-06-04 08:55:55 UTC

Yes, get connector from svn, and look in scripts/, specifically at
udev-synce-serial.in, from where it calls serial_start_device() in
synceconnector.py.in

Post by Kal Sze
If I wanted to manually make a PPP connection from bash, what would
the complete command line be?
Best Regards,
Kal

Kal Sze

2011-06-17 06:18:28 UTC

Post by Mark Ellis
Yes, get connector from svn, and look in scripts/, specifically at
udev-synce-serial.in, from where it calls serial_start_device() in
synceconnector.py.in

Hi Mark, Hi
Thanks to your hints, I think I'm *this* close to getting a PPP
connection working without SynCE, after some more digging into the
SynCE source code and on the intarweb. I found this page:
http://www.pocketpcfaq.com/wce/linux-serial.htm

Here is what I did so far ...
1. I created a chat script at /etc/ppp/cebox.chat, the content of which is:
TIMEOUT 3600
"CLIENT" "CLIENT\c"
"" "SERVER\c"

2. I created a call script at /etc/ppp/peers/cebox, the content of which is:
/dev/ttyUSB0 115200 crtscts
connect '/usr/sbin/chat -v -f /etc/ppp/cebox.chat'
noauth
nodefaultroute
local
192.168.2.1:192.168.2.2
ms-dns 8.8.8.8

3. I then tried to make a connection by executing:
sudo pppd call cebox

When I did that, the Windows CE device responded, but then almost
immediately told me that it is unable to establish communication with
the desktop computer and that, due to a severe error (which it isn't
able to name - it gives me "%d" instead of a real error code), it is
unable to start the Winsock service.

Would you know what I'm missing?

Best Regards,
Kal Sze

Kal Sze

2011-06-17 08:20:12 UTC

You need a dccm server running.

I see. But the dccm is only for ActiveSync functionality, right?

I just realized that TCP/IP still works even with the presence of that
Winsock error. I could ping and ftp into the Windows CE device and
that's all I need.

I think I can live with that.

Thanks for all the help. :D

Best Regards,
Kal

David Eriksson

2011-06-17 11:18:51 UTC

Yes but when you dismiss the error, the connection closes, I think.

\David

You need a dccm server running.

I see. But the dccm is only for ActiveSync functionality, right?
I just realized that TCP/IP still works even with the presence of that
Winsock error. I could ping and ftp into the Windows CE device and
that's all I need.
I think I can live with that.
Thanks for all the help. :D
Best Regards,
Kal

Kal Sze

2011-06-17 12:57:30 UTC

Post by David Eriksson
Yes but when you dismiss the error, the connection closes, I think.
\David

Yes, that's my experience as well. But my end users will never see
that error box because there will be a full screen application that
always stays on top. All is still well.

:D

Kal

Mark Ellis

2011-06-19 20:05:56 UTC

Post by David Eriksson
Yes but when you dismiss the error, the connection closes, I think.
\David

Yes, that's my experience as well. But my end users will never see
that error box because there will be a full screen application that
always stays on top. All is still well.
:D

Yes, that error probably occurs because there is no dccm on the other
end responding to the keep-alive ping. Don't know how stable the link
will be without a dccm.

Mark

Kal Sze

2011-11-29 05:10:34 UTC

Thanks, Mark, for the reminder about connection stability. So far, I don't
seem to have any issue with that.

I have another problem, however:

As I said before, I'm only using pppd to dial a ppp connection to the
Windows CE device. Once I'm done using the ppp connection, my script
terminates the connection by using linux's `kill` command and giving it the
PID of the pppd process. The problem is that *sometimes*, after I kill the
pppd process, ttyUSB0 disappears, even though the Windows CE device is
still physically connected. If I physically disconnect and reconnect the
Windows CE device, linux's ipaq kernel module will re-create ttyUSB0. Would
somebody have an idea why ttyUSB0 disappears and whether I can prevent that
from happening? I would be happy if I could at least put something in my
script to cause the ipaq kernel module to re-create the ttyUSB0 without
requiring me to physically disconnect and reconnect the device.

Best Regards,
Kal

Post by David Eriksson
Yes but when you dismiss the error, the connection closes, I think.
\David

Yes, that's my experience as well. But my end users will never see
that error box because there will be a full screen application that
always stays on top. All is still well.
:D

Yes, that error probably occurs because there is no dccm on the other
end responding to the keep-alive ping. Don't know how stable the link
will be without a dccm.
Mark
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
SynCE-Devel mailing list
https://lists.sourceforge.net/lists/listinfo/synce-devel

David Eriksson

2011-11-29 07:19:32 UTC

Hi,

Maybe you can try to unload the USB module and load it again?

Cheers,

David

Post by Kal Sze
Thanks, Mark, for the reminder about connection stability. So far, I don't
seem to have any issue with that.
As I said before, I'm only using pppd to dial a ppp connection to the
Windows CE device. Once I'm done using the ppp connection, my script
terminates the connection by using linux's `kill` command and giving it the
PID of the pppd process. The problem is that *sometimes*, after I kill the
pppd process, ttyUSB0 disappears, even though the Windows CE device is
still physically connected. If I physically disconnect and reconnect the
Windows CE device, linux's ipaq kernel module will re-create ttyUSB0. Would
somebody have an idea why ttyUSB0 disappears and whether I can prevent that
from happening? I would be happy if I could at least put something in my
script to cause the ipaq kernel module to re-create the ttyUSB0 without
requiring me to physically disconnect and reconnect the device.
Best Regards,
Kal

Post by David Eriksson
Yes but when you dismiss the error, the connection closes, I think.
\David

Yes, that's my experience as well. But my end users will never see
that error box because there will be a full screen application that
always stays on top. All is still well.
:D

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
SynCE-Devel mailing list
https://lists.sourceforge.net/lists/listinfo/synce-devel

Kal Sze

2011-12-05 03:35:13 UTC

Hi David,

I just tried unloading the ipaq kernel module (by executing `rmmod -v
ipaq`). It immediately caused the SUSE 9 machine to crash. So I guess
that's not an option I can use.

Also, I have discovered that with my current approach, even when ttyUSB0
remains after I terminate the ppp connection by killing the pppd process, I
cannot reuse ttyUSB0 until I physically unplug and replug the Windows CE
device (such that ttyUSB0 device node is removed and remade by the ipaq
kernel module). Without physically replugging the Windows CE device, the
next `pppd call script` cannot successfully establish a connection (it will
output "Connect script failed" after the TIMEOUT specified in the
/usr/sbin/chat script), even though the previous pppd process has really
terminated. Maybe I need to use /usr/sbin/chat to properly "hang up" the
device after the connection is terminated?

Best Regards,
Kal

Post by David Eriksson
Hi,
Maybe you can try to unload the USB module and load it again?
Cheers,
David

Post by Kal Sze
Thanks, Mark, for the reminder about connection stability. So far, I
don't seem to have any issue with that.
As I said before, I'm only using pppd to dial a ppp connection to the
Windows CE device. Once I'm done using the ppp connection, my script
terminates the connection by using linux's `kill` command and giving it the
PID of the pppd process. The problem is that *sometimes*, after I kill the
pppd process, ttyUSB0 disappears, even though the Windows CE device is
still physically connected. If I physically disconnect and reconnect the
Windows CE device, linux's ipaq kernel module will re-create ttyUSB0. Would
somebody have an idea why ttyUSB0 disappears and whether I can prevent that
from happening? I would be happy if I could at least put something in my
script to cause the ipaq kernel module to re-create the ttyUSB0 without
requiring me to physically disconnect and reconnect the device.
Best Regards,
Kal

Post by David Eriksson
Yes but when you dismiss the error, the connection closes, I think.
\David

Yes, that's my experience as well. But my end users will never see
that error box because there will be a full screen application that
always stays on top. All is still well.
:D

David Eriksson

2011-12-05 03:57:38 UTC

I'm quite sure that you only can connect a PPP session once on the ttyUSB
device. This is probably a limitation in Windows CE.

Best regards,

David Eriksson

Skickat från min mobiltelefon.

Post by Kal Sze
Hi David,
I just tried unloading the ipaq kernel module (by executing `rmmod -v
ipaq`). It immediately caused the SUSE 9 machine to crash. So I guess
that's not an option I can use.
Also, I have discovered that with my current approach, even when ttyUSB0
remains after I terminate the ppp connection by killing the pppd process, I
cannot reuse ttyUSB0 until I physically unplug and replug the Windows CE
device (such that ttyUSB0 device node is removed and remade by the ipaq
kernel module). Without physically replugging the Windows CE device, the
next `pppd call script` cannot successfully establish a connection (it will
output "Connect script failed" after the TIMEOUT specified in the
/usr/sbin/chat script), even though the previous pppd process has really
terminated. Maybe I need to use /usr/sbin/chat to properly "hang up" the
device after the connection is terminated?
Best Regards,
Kal

Post by David Eriksson
Hi,
Maybe you can try to unload the USB module and load it again?
Cheers,
David

Post by Kal Sze
Thanks, Mark, for the reminder about connection stability. So far, I
don't seem to have any issue with that.
As I said before, I'm only using pppd to dial a ppp connection to the
Windows CE device. Once I'm done using the ppp connection, my script
terminates the connection by using linux's `kill` command and giving it the
PID of the pppd process. The problem is that *sometimes*, after I kill the
pppd process, ttyUSB0 disappears, even though the Windows CE device is
still physically connected. If I physically disconnect and reconnect the
Windows CE device, linux's ipaq kernel module will re-create ttyUSB0. Would
somebody have an idea why ttyUSB0 disappears and whether I can prevent that
from happening? I would be happy if I could at least put something in my
script to cause the ipaq kernel module to re-create the ttyUSB0 without
requiring me to physically disconnect and reconnect the device.
Best Regards,
Kal

Post by David Eriksson
Yes but when you dismiss the error, the connection closes, I think.
\David

Yes, that's my experience as well. But my end users will never see
that error box because there will be a full screen application that
always stays on top. All is still well.
:D

Kal Sze

2012-04-17 11:16:51 UTC

Hello again,

So it turns out that SuSE 9 does in fact remove /dev/ttyUSB0 when I unplug
my Windows CE device, and re-create /dev/ttyUSB0 when I replug the Windows
CE device. I just had to be a little patient and wait a few seconds
(usually no more than 5 seconds). I have been able to use this fact to
reliably detect whether the /dev/ttyUSB0 has been used in a PPP session (by
comparing `stat -c %z /dev/ttyUSB0` with `stat -c %y /dev/ttyUSB0`). This
way, at least my shell script can instruct the user to unplug and replug
the device after having dialed PPP once (because PPP works only once
everytime the device is plugged, due to the limitation in Windows CE).

Unfortunately I am having trouble with this approach on SuSE 8.
/dev/ttyUSB0 does not get automatically removed and re-created when I
unplug and replug the Windows CE device. In fact, if I start by manually
removing /dev/ttyUSB0, and then plug the Windows CE device, dmesg would
tell me that the device has been created and assigned to ttyUSB0, when in
fact, /dev/ttyUSB0 has not been automatically created at all. So I cannot
use stat -c %z and stat -c %y to check whether ttyUSB0 has been used in a
PPP session. Does this appear fixable at all (without changing the kernel
or kernel module)?

Best Regards,
Kal

Post by David Eriksson
I'm quite sure that you only can connect a PPP session once on the ttyUSB
device. This is probably a limitation in Windows CE.
Best regards,
David Eriksson
Skickat frÃ¥n min mobiltelefon.
Hi David,

Post by Kal Sze
I just tried unloading the ipaq kernel module (by executing `rmmod -v
ipaq`). It immediately caused the SUSE 9 machine to crash. So I guess
that's not an option I can use.
Also, I have discovered that with my current approach, even when ttyUSB0
remains after I terminate the ppp connection by killing the pppd process, I
cannot reuse ttyUSB0 until I physically unplug and replug the Windows CE
device (such that ttyUSB0 device node is removed and remade by the ipaq
kernel module). Without physically replugging the Windows CE device, the
next `pppd call script` cannot successfully establish a connection (it will
output "Connect script failed" after the TIMEOUT specified in the
/usr/sbin/chat script), even though the previous pppd process has really
terminated. Maybe I need to use /usr/sbin/chat to properly "hang up" the
device after the connection is terminated?
Best Regards,
Kal

Post by David Eriksson
Hi,
Maybe you can try to unload the USB module and load it again?
Cheers,
David

Post by Kal Sze
Thanks, Mark, for the reminder about connection stability. So far, I
don't seem to have any issue with that.
As I said before, I'm only using pppd to dial a ppp connection to the
Windows CE device. Once I'm done using the ppp connection, my script
terminates the connection by using linux's `kill` command and giving it the
PID of the pppd process. The problem is that *sometimes*, after I kill the
pppd process, ttyUSB0 disappears, even though the Windows CE device is
still physically connected. If I physically disconnect and reconnect the
Windows CE device, linux's ipaq kernel module will re-create ttyUSB0. Would
somebody have an idea why ttyUSB0 disappears and whether I can prevent that
from happening? I would be happy if I could at least put something in my
script to cause the ipaq kernel module to re-create the ttyUSB0 without
requiring me to physically disconnect and reconnect the device.
Best Regards,
Kal