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
On 5 December 2011 11:57, David Eriksson <twog...@users.sourceforge.net>wrote:
> 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.
> Den 5 dec 2011 04:35 skrev "Kal Sze" <swordan...@gmail.com>:
>
> 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
>>
>> On 29 November 2011 15:19, David Eriksson
>> <twog...@users.sourceforge.net>wrote:
>>
>>> Hi,
>>>
>>> Maybe you can try to unload the USB module and load it again?
>>>
>>> Cheers,
>>>
>>> David
>>>
>>>
>>> On Tue, Nov 29, 2011 at 06:10, Kal Sze <swordan...@gmail.com> wrote:
>>>
>>>> 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
>>>>
>>>> On 20 June 2011 04:05, Mark Ellis <m...@mpellis.org.uk> wrote:
>>>>
>>>>> On Fri, 2011-06-17 at 14:57 +0200, Kal Sze wrote:
>>>>> > On 17 June 2011 19:18, David Eriksson <twog...@users.sourceforge.net>
>>>>> wrote:
>>>>> > > 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
>>>>> SynCE-Devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/synce-devel
>>>>>
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>> SynCE-Devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/synce-devel
>>>>
>>>>
>>>
>>
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
SynCE-Devel mailing list
SynCE-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/synce-devel
