[speedtouch] Re: SpeedTouch USB lockups

[Duncan Sands]

> I know I asked this many times before but: anyone has an idea where the 
> problem could be ?

Try the latest 2.6 -mm kernel.  I understand that many small bugs in the
uhci driver have been fixed there.

Duncan.

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Andrej Kristofic]

Hi.

I still did not give up a dream of SpeedTouch working reliably on my 
gateway computer. I set up ASDL connection on my desktop computer 
running Mandrake 9.1 and was able to connect without any problems. Also 
downloading problematic all-ones file went smoothly. Of course, the 
desktop machine and gateway machine use (very) different hardware, 
though they use the very same kernel 2.4.27. The only difference is, 
that desktop computer uses usb-ohci driver for USB and gateway uses 
usb-uhci (or just uhci) driver.

This means that there is no problem with modem itself or its 
initialization using modem_run. It also seems that both userland and 
kernel driver are working properly (hats off). I suspect that there is a 
problem somewhere between uhci driver and modem (maybe pci or 
something). But when I check logs in locked-up state I can see that URBs 
are successfuly submited. This is claimed by both speedtouch and uhci 
driver. Question (maybe a little off-topic for this list) is: "Does is 
mean that data was successfully received by modem ?" If it is so, this 
might mean only one thing - data ARE sent by modem, but the reponses are 
stuck somewhere (possibly en route from modem).

There is also one more interesting issue. That all-ones file can lock up 
my connections when downloaded from Internet but does no harm when 
uploaded the other way. I set up http server on my home machine and 
downloaded the file from "outside". The connection survived this test.

I know I asked this many times before but: anyone has an idea where the 
problem could be ?

Thanks for all your help and advices, I really appreciate it.

Regards

Andrej

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Andrej Kristofic]

>
>
>>Maybe it would be worth to comapare Rev. 0.00 windows driver with Rev. 
>>0.01 and check if there are any
>>differencies 
>>
>>
Brief look into Windows driver revealed that it may behave differrently 
according to the revision of modem (POTS/ISDN). This is from some 
phonebook file located on driver CD:

<...>
[Modem.POTS]
ModemMode=11

[Modem.ISDN]
ModemMode=3
<...>

Don't have idea what's ModemMode but maybe it's important for correct 
modem initialation (OTOH maybe not ...).

I also sniffed USB packets when uploading firmware. Unfortunately when 
sniffing in Windows 98 large part of URBs was missing (guess this is 
issue of sniffer and slow machine). So I connected modem to my Win2k 
machine (no DSL line though, the cable is too short).This time 
everything went smoothly. I tracked down the "magic sequence" used in 
modem_run to initialize modem. I discovered one more similar URB 
following this sequence:

0004594411.83704968 >>> URB 187 going down...  
0004594711.83707371   TransferBufferLength = 0001 
0004595111.83710611 : 03
Hmm, maybe this data (0x03) has somthing to do with ModemType=3
0004595211.83711226   UrbLink =    
0004595311.83711924   RequestTypeReservedBits = 00 
0004595411.83712567   Request = 01 
0004595511.83713265   Value   = 0011   
0004595611.83713936   Index   =    

0004596611.83999670   SetupPacket  : 40 01 11 00 00 00 01 00   

Then there are too more Setup Packets
0004599111.84207183   SetupPacket  : c0 26 f7 00 00 00 0e 00   
...
0004601711.84513143   SetupPacket  : c0 26 6b 00 00 00 1a 00   

I modified modem_run to send this voodoo to the modem. The modem seems 
to accept it, but it has no effect on my problem. Maybe there are more 
differences. Can anyone provide me log of Rev 0.00 modem so I can use it 
as reference?

The logs are avaible in zip files at my school server if anyone is 
interested:
http://decef.elf.stuba.sk/~ak99387/log/speedtouch98.log.zip  (cca 500kB, 
there is "magic" part missing)
http://decef.elf.stuba.sk/~ak99387/log/speedtouchNT.log.zip  (cca 800kB, 
the modem was not connected to DSL line)


Duncan Sands wrote:

>Another thing to do would be to use something like usbsnoopy to watch
>the traffic in windows when you download the all-ones file.
>
It is the next thing on my To Do list ...

>Also, if
>you have vmware (running on linux, containing windows), see if the
>windows driver can successfully use the modem.  If so, that shows that
>the problem is not in the linux usb core (vmware sends urbs using
>usbfs, the same as the user space driver).
>
I doubt if vmware would even start on that computer, but when I'll be 
desparate enough I give it a try.

Best regards

Andrej


Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Duncan Sands]

> Maybe it would be worth to comapare Rev. 0.00 windows driver with Rev. 
> 0.01 and check if there are any
> differencies 

Another thing to do would be to use something like usbsnoopy to watch
the traffic in windows when you download the all-ones file.  Also, if
you have vmware (running on linux, containing windows), see if the
windows driver can successfully use the modem.  If so, that shows that
the problem is not in the linux usb core (vmware sends urbs using
usbfs, the same as the user space driver).  What's more, if you are
using a recent 2.6 kernel, you set usbfs_snoop=1 when loading the
usb core, and all packets that pass through usbfs will be dumped to
your system logs (this is an alternative to usbsnoopy).

All the best,

Duncan.

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Andrej Kristofic]

Gilles Espinasse wrote:

>Annex B is ADSL over ISDN line.
>
>So now there is two possibility
>- your line is a standard POTS line and you need a modem working over POTS
>(Annex A)
>- your line is really an ISDN line and something may need to be done in the
>driver to support Rev 0.01
>  
>
I checked a few Slovak forums about this Annex thing. It seems that the 
only difference is, that with Annex B
the ADSL is using higher frequency band so it would not interfere with 
ISDN. Both old POTS lines and
ISDN lines use Annex B standard in my country.

I think that driver doesn't have to do anything special, since the data 
transfer mode is still the same (ATM). The
only thing that is different is frequency, but this is matter of modem 
itself. But there is still a possibility that
the "magic sequence" used to initialize the modem properly is different 
for ISDN revision of modems.
The firmware is definitely the same, I checked my windows drivers and 
alcaudsl.sys matches the one listed
on the Smoothwall firmware page.

Maybe it would be worth to comapare Rev. 0.00 windows driver with Rev. 
0.01 and check if there are any
differencies 

Andrej

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Gilles Espinasse]

- Original Message - 
From: "Andrej Kristofic" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 22, 2004 11:47 PM
Subject: [speedtouch] Re: SpeedTouch USB lockups


>
> Gilles Espinasse wrote:
>
> >According to your Rev 0.01, this is a model to use over isdn line. Is-it
> >really the case?
> >%Avens.ADSL.ISDN%=alcaudsl.Install,USB\VID_06b9&PID_4061&REV_0001
;Alcatel
> >ADSL adapter (ISDN)
> >
> As far as I know, currently I have standard POTS line (though I had ISDN
> line prior the ADSL). The input
> on the splitter is also labeled ISDN. I found out that ISDN revision
> means that the modem is compatible with
> nnex B telephone lines (which has to do something with bandwidth for
> voice) and I guess this is my case.
>
Annex B is ADSL over ISDN line.

So now there is two possibility
- your line is a standard POTS line and you need a modem working over POTS
(Annex A)
- your line is really an ISDN line and something may need to be done in the
driver to support Rev 0.01


Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Andrej Kristofic]

Gilles Espinasse wrote:

>According to your Rev 0.01, this is a model to use over isdn line. Is-it
>really the case?
>%Avens.ADSL.ISDN%=alcaudsl.Install,USB\VID_06b9&PID_4061&REV_0001 ;Alcatel
>ADSL adapter (ISDN)
>
As far as I know, currently I have standard POTS line (though I had ISDN 
line prior the ADSL). The input
on the splitter is also labeled ISDN. I found out that ISDN revision 
means that the modem is compatible with
nnex B telephone lines (which has to do something with bandwidth for 
voice) and I guess this is my case.

Andrej


Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Gilles Espinasse]

- Original Message - 
From: "Andrej Kristofic" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 22, 2004 10:39 AM
Subject: [speedtouch] Re: SpeedTouch USB lockups


>
> Duncan Sands wrote:
>
> >Are you using a 2.4 kernel or a 2.6 kernel?  Also, what kind of host
> >controller do you have (uhci, ohci, ...).
> >
> >Thanks,
> >
> >Duncan.
> >
>
> Currently I'm using 2.4.27 kernel. I also tried 2.6.8.1 one. I've
> experienced the problems in both. I have uhci host controller (my
> chipset is Intel PIIX3).
> I fear that the behaviour of that modem is absolutely unpredictable.
> This morning I was not able to keep connection up for time longer than 1
> minute with kernel driver (even when there were no data transfers).
> Right now I'm connected with user land driver
> which is able to keep connection up for longer time (the problem with
> downloading that 'all ones' file is still present though).
>
> Andrej
>
According to your Rev 0.01, this is a model to use over isdn line. Is-it
really the case?
%Avens.ADSL.ISDN%=alcaudsl.Install,USB\VID_06b9&PID_4061&REV_0001 ;Alcatel
ADSL adapter (ISDN)


Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Gilles Espinasse]

Selon Andrej Kristofic <[EMAIL PROTECTED]>:

>
> Duncan Sands wrote:
>
> >Are you using a 2.4 kernel or a 2.6 kernel?  Also, what kind of host
> >controller do you have (uhci, ohci, ...).
> >
> >Thanks,
> >
> >Duncan.
> >
>
> Currently I'm using 2.4.27 kernel. I also tried 2.6.8.1 one. I've
> experienced the problems in both. I have uhci host controller (my
> chipset is Intel PIIX3).
> I fear that the behaviour of that modem is absolutely unpredictable.
> This morning I was not able to keep connection up for time longer than 1
> minute with kernel driver (even when there were no data transfers).
> Right now I'm connected with user land driver
> which is able to keep connection up for longer time (the problem with
> downloading that 'all ones' file is still present though).
>
> Andrej
>
I am too with PIIX3 usb-uhci and kernel 2.4.27.

If you have such trouble than not be able to keep the line more than 1 mn even
with no data transfers, it could be the line or the connection to the phone
line the problem.
It may vary with exterior condition, so when you switch from one to the other
driver, it may be difficult to conclude.

I will try to find a bit of time to test your files with a speedtouch
Gilles

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Andrej Kristofic]

Duncan Sands wrote:

>Are you using a 2.4 kernel or a 2.6 kernel?  Also, what kind of host
>controller do you have (uhci, ohci, ...).
>
>Thanks,
>
>Duncan.
>

Currently I'm using 2.4.27 kernel. I also tried 2.6.8.1 one. I've 
experienced the problems in both. I have uhci host controller (my 
chipset is Intel PIIX3).
I fear that the behaviour of that modem is absolutely unpredictable. 
This morning I was not able to keep connection up for time longer than 1 
minute with kernel driver (even when there were no data transfers). 
Right now I'm connected with user land driver
which is able to keep connection up for longer time (the problem with 
downloading that 'all ones' file is still present though).

Andrej

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Duncan Sands]

On Tuesday 21 September 2004 21:30, Andrej Kristofic wrote:
> 
> Duncan Sands wrote:
> 
> >And how about
> >
> > modprobe speedtch rcv_buf_size=16
> >
> >?
> >
> Tried that, no luck though. This parameter was already adjusted when I 
> was creating the last logs I sent.

Are you using a 2.4 kernel or a 2.6 kernel?  Also, what kind of host
controller do you have (uhci, ohci, ...).

Thanks,

Duncan.

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Andrej Kristofic]

Ok Overbeek (mz) wrote:

>There is a 'congestion bit' and a CLP-bit.
>The congestion bit is switched on in case of network overload, the
>CLP-bit means real trouble: data has been truncated (clipped).
>As far as I remember, there was someone else some months ago on
>this list, who also had continuous CLP-bits; I do not recall, whether
>he had his problems solved...
>  
>
Well, I did some research on that CLP bit:
"define: CLP" at google.com says:
Cell Loss Priority: This bit in the ATM cell header indicates two levels 
of priority for ATM cells. CLP=0 cells are higher priority than CLP=1 
cells. CLP=1 cells may be discarded during periods of congestion to 
preserve the CLR of CLP=0 cells.
www.dit.upm.es/snh/arhelp/glossaries/atmf/gloss-c.html 


I also checked the sources of pppoa3 to be sure. The message "CLP bit is 
on" is printed, when the first bit of fourth byte in ATM header is set. 
This bit matches the CLP bit described above. I also recall  one 
discussion on whether this bit shouldn't be set by the user when there 
is no need for very high reliability (e.g. AAL5 has mechanism that can 
cope with cell loss, so there will be no errors only the connection will 
be slower when some cell are lost/discarded). I would guess that my 
provider is responsible for setting this bit on.

>Anyhow, this might lead to something; I do not remember, whether
>CLP-bit frames are dropped or not (or if they should be dropped).
>  
>
Obviously, the CLP bit just defines cell priority in case there is a 
need to drop cells. This bit is handled by ATM switches so there is no 
reason to drop cells with this bit on when they arrive to the computer..

>Obviously, however, Windows can handle these frames properly,
>if that's where the errot lies. And if so (and the Win-driver is indeed
>dropping a lot of frames), then you, Andrej, will never be able
>reach your maximum download-throughput under Windows.
>So: could you download some biggy file and see if the download
>speed meets its max?
>  
>
Tried to download kernel sources. The speed was about 40kB/s. This is 
fairly good when I realize that I have 256/64 ADLS link with 1:50 
aggregation. I think it would be impossible to reach this speed with so 
many errors as indicated by pppoa3 because as far as I know, there is no 
way to correct corrupt ATM cell. ATM uses only simple CRC checksum with 
no repair ability.

Well, that's the story about CLP bits :) . But it seems that my 
problem's a different story ...

Andrej

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Ok Overbeek (mz)]

There is a 'congestion bit' and a CLP-bit.
The congestion bit is switched on in case of network overload, the
CLP-bit means real trouble: data has been truncated (clipped).
As far as I remember, there was someone else some months ago on
this list, who also had continuous CLP-bits; I do not recall, whether
he had his problems solved...
Anyhow, this might lead to something; I do not remember, whether
CLP-bit frames are dropped or not (or if they should be dropped).
Obviously, however, Windows can handle these frames properly,
if that's where the errot lies. And if so (and the Win-driver is indeed
dropping a lot of frames), then you, Andrej, will never be able
reach your maximum download-throughput under Windows.
So: could you download some biggy file and see if the download
speed meets its max?

Ok


Andrej Kristofic wrote:

>Just one note. I noticed pppoa3 complains about having CLP bit on in ATM 
>cells. If I recall correctly, CLP means cell loss priority and should be 
>set under exceptional circumstances e.g. line congestion. The posts 
>about this issue in this mailing list suggest that this can be caused by 
>poor line quality. However, the kernel driver don't say a word about 
>this. Then again CLP bit does not necessarily mean an error, it just 
>says that the cell can be discarded if it is needed. Maybe it's just 
>(bad)  habit of my provider to set this bit on. But I suppose it has to 
>do nothing with my problem, because under Win98 everything works 
>correctly. Or I'm wrong ?
>
>Bye
>
>Andrej
>
>Liste de diffusion modem ALCATEL SpeedTouch USB
>Pour se désinscrire : mailto:[EMAIL PROTECTED]
>
>   
>
>  
>


Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Andrej Kristofic]

Duncan Sands wrote:

>And how about
>
>   modprobe speedtch rcv_buf_size=16
>
>?
>
Tried that, no luck though. This parameter was already adjusted when I 
was creating the last logs I sent.

Andrej

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Duncan Sands]

And how about

modprobe speedtch rcv_buf_size=16

?

Duncan.

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Andrej Kristofic]

Ok Overbeek (mz) wrote:

>Am I right in stating, that
>- it works perfectly under Windows (both files)?
>- you get trouble under Linux (Speedtouch kernel setup)?
>
>  
>
Yes, you are right. I've got no problems downloading both files when my 
gateway is running Windows 98SE. But trying to download that "special" 
all ones file under Linux results in lock up described in earlier posts.

>If so, it smells of some well hidden software flaw on the Linux-side...
>
>I know it means some work, but it would be interesting to know,
>whether the Speedtouch user-mode setup will do its work without errors.
>Do you have spare time to try that? Or did you already?
>
>  
>
Not much work at all. Just rmmod-ed speedtch driver, replaced 2684 
bridge with pppoa3 and changed interface for pppoe to tap0. Once again, 
I have connected with no problems but downloading that 'all ones' file 
caused lock up.
Just one note. I noticed pppoa3 complains about having CLP bit on in ATM 
cells. If I recall correctly, CLP means cell loss priority and should be 
set under exceptional circumstances e.g. line congestion. The posts 
about this issue in this mailing list suggest that this can be caused by 
poor line quality. However, the kernel driver don't say a word about 
this. Then again CLP bit does not necessarily mean an error, it just 
says that the cell can be discarded if it is needed. Maybe it's just 
(bad)  habit of my provider to set this bit on. But I suppose it has to 
do nothing with my problem, because under Win98 everything works 
correctly. Or I'm wrong ?

Bye

Andrej

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Gilles Espinasse]

- Original Message - 
From: "Ok Overbeek (mz)" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, September 21, 2004 8:11 PM
Subject: [speedtouch] Re: SpeedTouch USB lockups


>
> Andrej!
>
> Sorry for breaking in in an interesting discussion...
>
> Am I right in stating, that
> - it works perfectly under Windows (both files)?
> - you get trouble under Linux (Speedtouch kernel setup)?
>
> If so, it smells of some well hidden software flaw on the Linux-side...
>
> I know it means some work, but it would be interesting to know,
> whether the Speedtouch user-mode setup will do its work without errors.
> Do you have spare time to try that? Or did you already?
>
I will test, it is easy for me to test in a few clic and plug.
At this time, I have only tested with eciadsl-usermode-0.9 and pppoe plugin
without problem with '1' file.
I can test with speedtch, cxacru (derivated speedtch), unicorn_usb_atm,
eagle-usb, pppoa3 and all with PPPoA, PPPoE usermode or plugin.
I just have more urgent task before.


Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Ok Overbeek (mz)]

Andrej!

Sorry for breaking in in an interesting discussion...

Am I right in stating, that
- it works perfectly under Windows (both files)?
- you get trouble under Linux (Speedtouch kernel setup)?

If so, it smells of some well hidden software flaw on the Linux-side...

I know it means some work, but it would be interesting to know,
whether the Speedtouch user-mode setup will do its work without errors.
Do you have spare time to try that? Or did you already?

Bye

Ok


Andrej Kristofic wrote:

>Gilles Espinasse wrote:
>
>  
>
>>Selon Andrej Kristofic <[EMAIL PROTECTED]>:
>> 
>>
>>
>>
>>>I made a few more experiments. Created two 2MB files, one containg ones
>>>(i.e. FF) and one with zeros. I was able to download 'zeros' file with
>>>no problems, but downloading 'ones' file reliably crashed the connection.
>>>
>>>   
>>>
>>>  
>>>
>>Is it possible to have access to the 2 files?
>>I want to test with other drivers (derivated from speedtch or very differents).
>> 
>>
>>
>>
>
>The files can be found on my school server:
>
>http://decef.elf.stuba.sk/~ak99387/zeros.bin (2MB) padded with 0x00 bytes
>http://decef.elf.stuba.sk/~ak99387/ones.bin  (2MB) padded with 0xFF bytes
>
>Andrej
>
>Liste de diffusion modem ALCATEL SpeedTouch USB
>Pour se désinscrire : mailto:[EMAIL PROTECTED]
>
>   
>
>  
>


Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Andrej Kristofic]

Gilles Espinasse wrote:

>Selon Andrej Kristofic <[EMAIL PROTECTED]>:
>  
>
>>I made a few more experiments. Created two 2MB files, one containg ones
>>(i.e. FF) and one with zeros. I was able to download 'zeros' file with
>>no problems, but downloading 'ones' file reliably crashed the connection.
>>
>>
>>
>Is it possible to have access to the 2 files?
>I want to test with other drivers (derivated from speedtch or very differents).
>  
>

The files can be found on my school server:

http://decef.elf.stuba.sk/~ak99387/zeros.bin (2MB) padded with 0x00 bytes
http://decef.elf.stuba.sk/~ak99387/ones.bin  (2MB) padded with 0xFF bytes

Andrej

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Andrej Kristofic]

Duncan Sands wrote:

>PS: Could you also please send logs obtained when using
>non-verbose debugging, i.e.
>
>#define DEBUG
>/*
>#define VERBOSE_DEBUG
>*/
>
>in the module source (because I see that the kernel's message
>buffer overflowed, meaning some messages were lost).
>
Alright, I disabled verbose debugging and increased size of receive 
buffer in the module. Here are the logs:

Connection phase (includes firmware upload, 3684 bridge startup and pppd 
startup) :

Sep 21 18:36:20 pentium-133 kernel: speedtch.c: udsl_usb_ioctl entered
Sep 21 18:36:43 pentium-133 kernel: speedtch.c: udsl_atm_open: vpi 1, vci 32
Sep 21 18:36:43 pentium-133 kernel: speedtch.c: udsl_atm_open: allocated 
vcc data 0xc2672fa0 (max_pdu: 1536)

After connection was established I tried to wget that 'all ones" file. 
Connection locked up as usual. There are no more
messages from speedtch.c in my logs. I guess that nothing extraordinary 
happens in driver, no buffer overflows or something
else, which could be harmful to the connection.

I'll carry on investigating this weird behaviour.

Regards

Andrej

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Andrej Kristofic]

Benoit PAPILLAULT wrote:

>Andrej Kristofic a écrit :
>  
>
>>/var/log/messages:
>>--
>>Sep 21 11:30:28 pentium-133 pppd[858]: No response to 3 echo-requests
>>Sep 21 11:30:28 pentium-133 pppd[858]: Serial link appears to be 
>>disconnected.
>>Sep 21 11:30:34 pentium-133 pppd[858]: Connection terminated.
>>Sep 21 11:30:34 pentium-133 pppd[858]: Connect time 4.8 minutes.
>>Sep 21 11:30:34 pentium-133 pppd[858]: Sent 2067 bytes, received 47638 
>>bytes.
>>Sep 21 11:30:34 pentium-133 pppoe[859]: Sent PADT
>>Sep 21 11:30:34 pentium-133 pppd[858]: Connect time 4.8 minutes.
>>Sep 21 11:30:34 pentium-133 pppd[858]: Sent 2067 bytes, received 47638 
>>bytes.
>>Sep 21 11:30:34 pentium-133 pppd[858]: Exit.
>>
>>
>
>Hi Andrej.
>
>What are the values of the following parameters : lcp-echo-interval and 
>lcp-echo-failure? It's in the pppd configuration file (usually under 
>/etc/ppp/peers). While downloading your test files, monitor the line 
>with ping to see if ping time increase or not. It "might" be possible 
>that your peer does not answer fast enought to LCP echo request.
>  
>

Hi Benoit.

The parameters are set as following:
lcp-echo-interval = 20
lcp-echo-failure=3
I didn't observe ping time increase while trying to download test files. 
I'm able to download about 100-200kB
of  'all ones' files (that's about 5secs of dowloading) and then 
connection locks up. After that pppd holds ppp0
interface up for approx. 1 min (that's 3*20secs) and then brings it 
down. During that last minute there are no data
coming through and ping to my provider's gateway times out.

Best regards

Andrej

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Gilles Espinasse]

- Original Message - 
From: "Duncan Sands" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, September 21, 2004 8:42 AM
Subject: [speedtouch] Re: SpeedTouch USB lockups


>
> > I enabled debugging in speedtch module and found out, that when in
> > "frozen" state, the packets were leaving the driver. I found dump of
> > three discovery PADI packets sent by 'pppoe -A' in my system log with a
> > message that they were sent. This means, that packets can pass through
> > 2684 bridge and the driver. It seems that problem is burried 'somewhere
> > deeper'. Is there any way to figure out whether the modem is still in
> > synchronised ?
>
> modem_run has a "line monitoring" option, but it hasn't always worked.
> Can you please send all the messages output by the module.
>
> > Richard A Lough adviced me to check PCI timings:
>
> I'd be surprised if that helped.
>
PCI timing is know to cause trouble with eagle-usb driver and PIIX2 usb
chipset when pci_latency is at a value bigger than 0x20 (d32). The driver
never report when sync is true in this case. I don't know more.


Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Gilles Espinasse]

Selon Andrej Kristofic <[EMAIL PROTECTED]>:

>
> I made a few more experiments. Created two 2MB files, one containg ones
> (i.e. FF) and one with zeros. I was able to download 'zeros' file with
> no problems, but downloading 'ones' file reliably crashed the connection.
>
Is it possible to have access to the 2 files?
I want to test with other drivers (derivated from speedtch or very differents).

Gilles

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Duncan Sands]

PS: Could you also please send logs obtained when using
non-verbose debugging, i.e.

#define DEBUG
/*
#define VERBOSE_DEBUG
*/

in the module source (because I see that the kernel's message
buffer overflowed, meaning some messages were lost).

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Duncan Sands]

> I made a few more experiments. Created two 2MB files, one containg ones 
> (i.e. FF) and one with zeros. I was able to download 'zeros' file with 
> no problems, but downloading 'ones' file reliably crashed the connection.

Hi Andrej, thanks for the info.  Does the following help, before plugging
in the modem (if the speedtch module is already loaded, unload it using rmmod):

modprobe speedtch rcv_buf_size=16

?

Thanks,

Duncan.

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Benoit PAPILLAULT]

Andrej Kristofic a écrit :
> /var/log/messages:
> --
> Sep 21 11:30:28 pentium-133 pppd[858]: No response to 3 echo-requests
> Sep 21 11:30:28 pentium-133 pppd[858]: Serial link appears to be 
> disconnected.
> Sep 21 11:30:34 pentium-133 pppd[858]: Connection terminated.
> Sep 21 11:30:34 pentium-133 pppd[858]: Connect time 4.8 minutes.
> Sep 21 11:30:34 pentium-133 pppd[858]: Sent 2067 bytes, received 47638 
> bytes.
> Sep 21 11:30:34 pentium-133 pppoe[859]: Sent PADT
> Sep 21 11:30:34 pentium-133 pppd[858]: Connect time 4.8 minutes.
> Sep 21 11:30:34 pentium-133 pppd[858]: Sent 2067 bytes, received 47638 
> bytes.
> Sep 21 11:30:34 pentium-133 pppd[858]: Exit.

Hi Andrej.

What are the values of the following parameters : lcp-echo-interval and 
lcp-echo-failure? It's in the pppd configuration file (usually under 
/etc/ppp/peers). While downloading your test files, monitor the line 
with ping to see if ping time increase or not. It "might" be possible 
that your peer does not answer fast enought to LCP echo request.

However, I don't understand while "all zeroes" works and not "all ones". 
Kinda strange.

Benoit

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Andrej Kristofic]

I made a few more experiments. Created two 2MB files, one containg ones 
(i.e. FF) and one with zeros. I was able to download 'zeros' file with 
no problems, but downloading 'ones' file reliably crashed the connection.

Duncan Sands wrote:

 >modem_run has a "line monitoring" option, but it hasn't always worked.
 >Can you please send all the messages output by the module.
 >
For brevity sake I'll send only the short version of logs before crash 
and after crash. Full logs (including the one created while connecting 
ADSL line) can be found at http://decef.elf.stuba.sk/~ak99387/log.

Here are the logs just after the attempt to download "all ones"

/var/log/syslog:

Sep 21 11:30:34 pentium-133 pppoe[859]: read (asyncReadFromPPP): Session 
7667: Input/output error

--
/var/log/messages:
--
Sep 21 11:30:28 pentium-133 pppd[858]: No response to 3 echo-requests
Sep 21 11:30:28 pentium-133 pppd[858]: Serial link appears to be 
disconnected.
Sep 21 11:30:34 pentium-133 pppd[858]: Connection terminated.
Sep 21 11:30:34 pentium-133 pppd[858]: Connect time 4.8 minutes.
Sep 21 11:30:34 pentium-133 pppd[858]: Sent 2067 bytes, received 47638 
bytes.
Sep 21 11:30:34 pentium-133 pppoe[859]: Sent PADT
Sep 21 11:30:34 pentium-133 pppd[858]: Connect time 4.8 minutes.
Sep 21 11:30:34 pentium-133 pppd[858]: Sent 2067 bytes, received 47638 
bytes.
Sep 21 11:30:34 pentium-133 pppd[858]: Exit.

---
/var/log/debug:
---
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: udsl_atm_send called 
(skb 0xc11da9e0, len 96)
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: 000 : aa aa 03 00 80 c2 
00 07 00 00 00 90 1a 40 73 e0
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: 016 : 00 90 d0 8c 1a a9 
88 64 11 00 1d f3 00 42 00 21
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: 032 : 45 00 00 40 ac f3 
40 00 40 11 de 48 d4 51 16 75
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: 048 : c3 a8 01 02 04 00 
00 35 00 2c 47 af 79 87 01 00
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: 064 : 00 01 00 00 00 00 
00 00 05 64 65 63 65 66 03 65
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: 080 : 6c 66 05 73 74 75 
62 61 02 73 6b 00 00 01 00 01
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: udsl_write_cells: 
howmany=64, skb->len=96, num_cells=3, num_entire=2, pdu_padding=40
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: udsl_process_send: wrote 
3 cells from skb 0xc11da9e0 to buffer 0xc20bcdc4
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: udsl_process_send: 
buffer contains 3 cells, 61 left
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: udsl_process_send: 
submitting urb 0xc2e49be0 (3 cells), snd 0xc20bcd60, buf 0xc20bcdc4
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: udsl_complete_send: urb 
0xc2e49be0, status 0, snd 0xc20bcd60, buf 0xc20bcdc4
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: udsl_complete_receive: 
urb 0xc2e49960, status 0, actual_length 212, filled_cells 4, rcv 
0xc20bcc64, buf 0xc20bccb4
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: udsl_process_receive: 
sending urb 0xc2e49960, rcv 0xc20bcc64, buf 0xc20bccc4
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: udsl_process_receive: 
processing buf 0xc20bccb4
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: udsl_extract_cells: vpi 
1, vci 32, pti 0
Sep 21 11:29:22 pentium-133 last message repeated 2 times
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: udsl_extract_cells: vpi 
1, vci 32, pti 1
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: udsl_extract_cells: got 
packet (length: 182, pdu_length: 192, vcc: 0xc1abc200)
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: udsl_extract_cells: 
allocated new sk_buff (skb: 0xc11da300, skb->truesize: 384)
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: udsl_extract_cells: 
sending skb 0xc11da300, skb->len 182, skb->truesize 384
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: 000 : aa aa 03 00 80 c2 
00 07 00 00 00 90 d0 8c 1a a9

Sep 21 11:29:22 pentium-133 kernel: speedtch.c: 176 : 00 04 93 af 6f 0f
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: udsl_atm_send called 
(skb 0xc11da8a0, len 92)
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: 000 : aa aa 03 00 80 c2 
00 07 00 00 00 90 1a 40 73 e0

Sep 21 11:29:22 pentium-133 kernel: speedtch.c: 080 : 00 02 ac fb 00 00 
00 00 01 03 03 00
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: udsl_write_cells: 
howmany=64, skb->len=92, num_cells=3, num_entire=1, pdu_padding=4
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: udsl_process_send: wrote 
3 cells from skb 0xc11da8a0 to buffer 0xc20bcdc4
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: udsl_process_send: 
buffer contains 3 cells, 61 left
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: udsl_process_send: 
submitting urb 0xc2e49be0 (3 cells), snd 0xc20bcd60, buf 0xc20bcdc4
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: udsl_complete_send: urb 
0xc2e49be0, status 0, snd 0xc20bcd60, buf 0xc20bcdc4
Sep 21 11:29:22 pentium-133 kernel: speedtch.c: udsl_complete_rece

[speedtouch] Re: SpeedTouch USB lockups

[Duncan Sands]

> I enabled debugging in speedtch module and found out, that when in 
> "frozen" state, the packets were leaving the driver. I found dump of 
> three discovery PADI packets sent by 'pppoe -A' in my system log with a 
> message that they were sent. This means, that packets can pass through 
> 2684 bridge and the driver. It seems that problem is burried 'somewhere 
> deeper'. Is there any way to figure out whether the modem is still in 
> synchronised ?

modem_run has a "line monitoring" option, but it hasn't always worked.
Can you please send all the messages output by the module.

> Richard A Lough adviced me to check PCI timings: 

I'd be surprised if that helped.

All the best,

Duncan.

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Andrej Kristofic]

Just situation report :)

Andrej Kristofic wrote:

> Currently I'm using the firmaware that comes from my original Win98 
> driver. According to 
> http://www.hystedjp.pwp.blueyonder.co.uk/firmware.htm it is version 
> 1.6.1. I also tried version 2.0.1 but observed the same problem. I try 
> to use the firmware you sent link to. I think I already downloaded 
> that file before but its name said it was for SpeedTouch 330 and that 
> confused me. Now I see that in the zip file there is also firmware for 
> Rev 0 and Rev 2 modems. 

I tried to upload 3.012 firmware found on Thomson SpeedTouch site, but 
the problems still prevail.

Just currious: sifting through the firmware file I noticed a lot of 
strings and commands. I assume that these belong to some OS running on 
modem. Is there any way to enter these commands to modem ? I don't think 
it will solve my problem but as I wrote I'm currious 

Andrej

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Andrej Kristofic]

Benoit PAPILLAULT wrote:

>Hi Andrej,
>
>What firmware are you using? I suggest to try the ones in the .zip file 
>from Thomson, available at: 
>http://www.speedtouch.com/driver_upgrade_lx_3.0.1.2.htm
>  
>
Currently I'm using the firmaware that comes from my original Win98 
driver. According to 
http://www.hystedjp.pwp.blueyonder.co.uk/firmware.htm it is version 
1.6.1. I also tried version 2.0.1 but observed the same problem. I try 
to use the firmware you sent link to. I think I already downloaded that 
file before but its name said it was for SpeedTouch 330 and that 
confused me. Now I see that in the zip file there is also firmware for 
Rev 0 and Rev 2 modems.

>Could you send us the PPP logs just before your connection stop working?
>(BTW, there are 2 TCP/IP options that can prevent downloading on 
>specific files  can't remember what they are. Someone?)
>
>Benoit
>
These logs don't say much, but this is what I get with 'debug' and 
'kdebug 1' options in pppd:

This is /etc/log/messages:
Sep 20 21:49:35 pentium-133 pppd[260]: No response to 3 echo-requests
Sep 20 21:49:35 pentium-133 pppd[260]: Serial link appears to be 
disconnected.
Sep 20 21:49:41 pentium-133 pppd[260]: Connection terminated.
Sep 20 21:49:41 pentium-133 pppd[260]: Connect time 66.1 minutes.
Sep 20 21:49:41 pentium-133 pppd[260]: Sent 275410 bytes, received 
6053383 bytes.
Sep 20 21:49:41 pentium-133 pppoe[261]: Sent PADT
Sep 20 21:49:41 pentium-133 pppd[260]: Connect time 66.1 minutes.
Sep 20 21:49:41 pentium-133 pppd[260]: Sent 275410 bytes, received 
6053383 bytes.
Sep 20 21:49:41 pentium-133 pppd[260]: Exit.

and /etc/log/syslog:

Sep 20 21:49:41 pentium-133 pppoe[261]: read (asyncReadFromPPP): Session 
7921: Input/output error

and finally /etc/log/debug

Sep 20 21:49:35 pentium-133 pppd[260]: sent [LCP TermReq id=0x3 "Peer 
not responding"]
Sep 20 21:49:38 pentium-133 pppd[260]: sent [LCP TermReq id=0x4 "Peer 
not responding"]
Sep 20 21:49:41 pentium-133 pppd[260]: Waiting for 1 child processes...
Sep 20 21:49:41 pentium-133 pppd[260]:   script /usr/sbin/pppoe -p 
/var/run/pppoe.conf-adsl.pid.pppoe -I nas0 -T 80 -U  -m 1412   , pid 261
Sep 20 21:49:41 pentium-133 pppd[260]: Script /usr/sbin/pppoe -p 
/var/run/pppoe.conf-adsl.pid.pppoe.conf-adsl.pid.pppoe -I nas0 -T 80 -U  
-m 1412finished (pid 261), status = 0x1

Andrej

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Andrej Kristofic]

Duncan Sands wrote:

>Hi,
>
>  
>
>>After one week trying to get that green thing (Alcatal SpeedTouch USB)
>>to work I decided to ask for some external help. I've managed to establish
>>connection and everything seems running just fine. But approx. once an hour
>>the modem (or driver or something) locks up and connection is broken. 
>>
>>
>
>what does "locks up" mean?  Do you just mean that it stops working?
>
>  
>
It means that no packets are passing through and therefore pppoe (and so 
pppd) times out and disconnects (see syslog part below  from previous post).

>>Actually,
>>I'm able to reproduce this lockup quite reliably by downloading one specific
>>file from Internet. Logs don't give much info about this problem, pppoe just
>>fails reading and times out waiting for PADO offer:
>>
>>pppoe[394]: read (asyncReadFromPPP): Session 4552: Input/output error
>>pppoe[515]: Timeout waiting for PADO packets
>>
>>After this lockup I'm not able to reconnect and I'm forced to reload usb 
>>module
>>and modem microcode to connect again. I'm using kernel driver for SpeedTouch
>>together with RFC 2684 bridge (my provider supports PPPoE only) and 
>>rp-pppoe.
>>
>>I tried to trace the packets in "frozen" state by using "pppoe -A" command
>>(access concentrator discovery). The packets are comming through nas0 
>>interface
>>(RFC 2684 bridge) and they arrive to ATM AAL5 layer. Unfortunately, I 
>>was not
>>able to find out whether they actually arrive to modem via USB.
>>
>>
>
>In the speedtouch module source, you will find the following:
>
>/*
>#define DEBUG
>#define VERBOSE_DEBUG
>*/
>
>If you change this to
>
>#define DEBUG
>#define VERBOSE_DEBUG
>
>then the contents of all packets plus a bunch of other stuff will be dumped
>to your system logs.
>  
>
I enabled debugging in speedtch module and found out, that when in 
"frozen" state, the packets were leaving the driver. I found dump of 
three discovery PADI packets sent by 'pppoe -A' in my system log with a 
message that they were sent. This means, that packets can pass through 
2684 bridge and the driver. It seems that problem is burried 'somewhere 
deeper'. Is there any way to figure out whether the modem is still in 
synchronised ?

Richard A Lough adviced me to check PCI timings: 



If you are running a pentium-133 you may want to increase the latency on 
your pci bus. I use a pentiumpro-200 and this occasionally had problems 
with latency. The command is setpci, and you probably want to read the 
stuff from the list before deciding what setting to use. That may be 
totally unrelated to your problem however


I played a bit with PCI latency setting of USB with no apparent effect. I tried to 
boost latency of USB while lowering latency of the other devices, but this seems to 
have no effect. I also checked latency settings under Win98 a found out that they're 
set to default value of 32 clocks just as in Linux.

>I hope this helps,
>
>Duncan.
>  
>
Thanks
   Andrej

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Benoit PAPILLAULT]

Andrej Kristofic a écrit :
> I tried that, added "-r 0" to modem_run options. modem_run output is 
> same as with default Rev 2.00 except that complaining about revision 
> number mismatch. But outcome is still the same, I'm able to download 
> approx. 200kB of 5MB file and then connection dies. What irritates me 
> the most is that under Win 98SE this green beast works just fine, no 
> disconnect, no lock-ups. There is something terribly wrong and I don't 
> know what and where.
> Thanks for your interest though,
> 
>Andrej

Hi Andrej,

What firmware are you using? I suggest to try the ones in the .zip file 
from Thomson, available at: 
http://www.speedtouch.com/driver_upgrade_lx_3.0.1.2.htm

Could you send us the PPP logs just before your connection stop working?
(BTW, there are 2 TCP/IP options that can prevent downloading on 
specific files  can't remember what they are. Someone?)

Benoit

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Duncan Sands]

Hi,

> After one week trying to get that green thing (Alcatal SpeedTouch USB)
> to work I decided to ask for some external help. I've managed to establish
> connection and everything seems running just fine. But approx. once an hour
> the modem (or driver or something) locks up and connection is broken. 

what does "locks up" mean?  Do you just mean that it stops working?

> Actually,
> I'm able to reproduce this lockup quite reliably by downloading one specific
> file from Internet. Logs don't give much info about this problem, pppoe just
> fails reading and times out waiting for PADO offer:
> 
> pppoe[394]: read (asyncReadFromPPP): Session 4552: Input/output error
> pppoe[515]: Timeout waiting for PADO packets
> 
> After this lockup I'm not able to reconnect and I'm forced to reload usb 
> module
> and modem microcode to connect again. I'm using kernel driver for SpeedTouch
> together with RFC 2684 bridge (my provider supports PPPoE only) and 
> rp-pppoe.
> 
> I tried to trace the packets in "frozen" state by using "pppoe -A" command
> (access concentrator discovery). The packets are comming through nas0 
> interface
> (RFC 2684 bridge) and they arrive to ATM AAL5 layer. Unfortunately, I 
> was not
> able to find out whether they actually arrive to modem via USB.

In the speedtouch module source, you will find the following:

/*
#define DEBUG
#define VERBOSE_DEBUG
*/

If you change this to

#define DEBUG
#define VERBOSE_DEBUG

then the contents of all packets plus a bunch of other stuff will be dumped
to your system logs.

I hope this helps,

Duncan.

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Andrej Kristofic]

Gilles Espinasse wrote:

Alcatel SpeedTouch USB modem: revision: 000a (this is weird, never saw
this one in previous posts)


>>>This is cat /proc/bus/usb/devices | grep 06b9 that show this '000a'?
>>>  
>>>
>>Oops, sorry I missed one line from modem_run output it said:
>>
>>Sep 19 20:35:22 pentium-133 modem_run[1300]: Modem revision: 0001
>>Sep 19 20:35:22 pentium-133 modem_run[1300]: Unexpected modem revision
>>000a, assuming Rev 0200 modem.
>>
>>That unexpected modem revision confused me. Sure the revision of modem
>>is 0001 (same shows procfs)
>>
>>
>Do you have the green stingray model supporting ADSL over isdn line (it
>should be the Rev 1.00) or your modem work over pots line?
>What show cat /proc/bus/usb/devices for you modem?
>  
>
I have got the green one connected to pots line. The procfs shows the 
revision 0.01. It is the same model listed
at http://www.hystedjp.pwp.blueyonder.co.uk/index.htm (the second green 
manta).

[EMAIL PROTECTED]:/var/log# cat /proc/bus/usb/devices
T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=ff(vend.) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=06b9 ProdID=4061 Rev= 0.01
S:  Manufacturer=ALCATEL
S:  Product=Speed Touch USB
S:  SerialNumber=0090D08C1AA9
C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=usbdevfs
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=50ms
I:  If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch
I:  If#= 1 Alt= 1 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch
E:  Ad=06(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=07(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=87(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 1 Alt= 2 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch
E:  Ad=06(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
E:  Ad=07(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms
E:  Ad=87(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 1 Alt= 3 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch
E:  Ad=06(O) Atr=02(Bulk) MxPS=  16 Ivl=0ms
E:  Ad=07(O) Atr=02(Bulk) MxPS=  16 Ivl=0ms
E:  Ad=87(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E:  Ad=05(O) Atr=02(Bulk) MxPS=   8 Ivl=0ms
E:  Ad=85(I) Atr=02(Bulk) MxPS=   8 Ivl=0ms

>To understand what role play endpoint and compare to original Rev0.00, you
>should refer to Benoit recent message concerning the 530.
>http://www.mail-archive.com/[EMAIL PROTECTED]/msg06638.html
>  
>
The endpoints on Rev. 0.01 are identical to the ones Rev. 0.00 listed in 
that post.

>You may too play with modem_run -r option to select like a like Rev0.00
>setting instead of the Rev 2.00 selected by default.
>
>  
>
I tried that, added "-r 0" to modem_run options. modem_run output is 
same as with default Rev 2.00 except that complaining about revision 
number mismatch. But outcome is still the same, I'm able to download 
approx. 200kB of 5MB file and then connection dies. What irritates me 
the most is that under Win 98SE this green beast works just fine, no 
disconnect, no lock-ups. There is something terribly wrong and I don't 
know what and where.
Thanks for your interest though,

   Andrej

Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Gilles Espinasse]

- Original Message - 
From: "Andrej Kristofic" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, September 19, 2004 9:07 PM
Subject: [speedtouch] Re: SpeedTouch USB lockups


>
> Thanks for you quick answer.

> >>Alcatel SpeedTouch USB modem: revision: 000a (this is weird, never saw
> >>this one in previous posts)
> >>
> >>
> >This is cat /proc/bus/usb/devices | grep 06b9 that show this '000a'?
> >
> >
> Oops, sorry I missed one line from modem_run output it said:
>
> Sep 19 20:35:22 pentium-133 modem_run[1300]: Modem revision: 0001
> Sep 19 20:35:22 pentium-133 modem_run[1300]: Unexpected modem revision
> 000a, assuming Rev 0200 modem.
>
> That unexpected modem revision confused me. Sure the revision of modem
> is 0001 (same shows procfs)
>
Do you have the green stingray model supporting ADSL over isdn line (it
should be the Rev 1.00) or your modem work over pots line?
What show cat /proc/bus/usb/devices for you modem?

To understand what role play endpoint and compare to original Rev0.00, you
should refer to Benoit recent message concerning the 530.
http://www.mail-archive.com/[EMAIL PROTECTED]/msg06638.html

You may too play with modem_run -r option to select like a like Rev0.00
setting instead of the Rev 2.00 selected by default.



Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Andrej Kristofic]

Thanks for you quick answer.

Gilles Espinasse wrote:

>It could be a mru/mtu problem (maybe only the primary problem, not the
>reconnection after)
>But it should not make die your connection and only let you unable to
>receive some too big packets.
>
>Reconnection problem may be a 'ghost session' : a pppoe session not properly
>closed that will only die after a certain timeout.
>  
>
The scripts I use should take care of these ghosts, they're killed (if 
can you possibly kill the ghost :) ) and there are
some sleep statements. Besides, I tried to reconnect manually and double 
checked if there are any pppd or pppoe left running.

>Did you use clamp mss, something like this in your firewall rules
> /sbin/iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j
>TCPMSS --clamp-mss-to-pmtu
>  
>
I did not have that  "clamp mss" line in my firewall rules (now I do) 
but the pppoe also has similar parameter set to 1412.

>Could you add debug in your ppp options and show the LCP negociation between
>pppd and your ISP?
>We should not need IPCP part just after, or you can mask confidential info :
>login, your IP if fix.
>
>Wich mtu size is your ppp0 interface set by lcp negociation?
>ifconfig ppp0 should display MTU:1492
>If it is not the cas, you may try to add to your ppp options
>mtu 1492
>mru 1492
>
It  appears that my mtu/mru are set correctly. I set mtu/mru to 1492 in 
ppp options but my provider lowers them to 1460 during negotiation 
(which shouldn't be a problem, I assume):

Sep 19 20:24:15 pentium-133 pppoe[1078]: PADS: Service-Name: ''
Sep 19 20:24:16 pentium-133 pppd[1077]: sent [LCP ConfReq id=0x1  ]
Sep 19 20:24:16 pentium-133 pppd[1077]: rcvd [LCP ConfAck id=0x1  ]
Sep 19 20:24:18 pentium-133 pppd[1077]: rcvd [LCP ConfReq id=0x20   ]
Sep 19 20:24:18 pentium-133 pppd[1077]: sent [LCP ConfAck id=0x20   ]
Sep 19 20:24:18 pentium-133 pppd[1077]: sent [LCP EchoReq id=0x0 
magic=0x9bd345ba]
Sep 19 20:24:18 pentium-133 pppd[1077]: sent [PAP AuthReq id=0x1 
user="[EMAIL PROTECTED]" password=]
Sep 19 20:24:18 pentium-133 pppd[1077]: rcvd [LCP EchoRep id=0x0 
magic=0x7fd604e9]
Sep 19 20:24:18 pentium-133 pppd[1077]: rcvd [LCP ConfReq id=0x1   ]
Sep 19 20:24:18 pentium-133 pppd[1077]: sent [LCP ConfReq id=0x2  ]
Sep 19 20:24:18 pentium-133 pppd[1077]: sent [LCP ConfAck id=0x1   ]
Sep 19 20:24:20 pentium-133 pppd[1077]: rcvd [LCP ConfReq id=0x2   ]
Sep 19 20:24:20 pentium-133 pppd[1077]: sent [LCP ConfAck id=0x2   ]
Sep 19 20:24:21 pentium-133 pppd[1077]: sent [LCP ConfReq id=0x2  ]
Sep 19 20:24:21 pentium-133 pppd[1077]: rcvd [LCP ConfAck id=0x2  ]
Sep 19 20:24:21 pentium-133 pppd[1077]: sent [LCP EchoReq id=0x0 
magic=0x507e85a]
Sep 19 20:24:21 pentium-133 pppd[1077]: sent [PAP AuthReq id=0x2 
user="[EMAIL PROTECTED]" password=]
Sep 19 20:24:21 pentium-133 pppd[1077]: rcvd [LCP EchoRep id=0x0 
magic=0x41d149fb]
Sep 19 20:24:22 pentium-133 pppd[1077]: rcvd [PAP AuthAck id=0x2 ""]
Sep 19 20:24:22 pentium-133 pppd[1077]: sent [IPCP ConfReq id=0x1   ]
Sep 19 20:24:22 pentium-133 pppd[1077]: rcvd [IPCP ConfReq id=0x1 
 ]
Sep 19 20:24:22 pentium-133 pppd[1077]: sent [IPCP ConfRej id=0x1 
]
Sep 19 20:24:22 pentium-133 pppd[1077]: rcvd [IPCP ConfNak id=0x1   ]
Sep 19 20:24:22 pentium-133 pppd[1077]: sent [IPCP ConfReq id=0x2   ]
Sep 19 20:24:22 pentium-133 pppd[1077]: rcvd [IPCP ConfReq id=0x2 ]
Sep 19 20:24:22 pentium-133 pppd[1077]: sent [IPCP ConfAck id=0x2 ]
Sep 19 20:24:22 pentium-133 pppd[1077]: rcvd [IPCP ConfAck id=0x2  ]

>>Alcatel SpeedTouch USB modem: revision: 000a (this is weird, never saw
>>this one in previous posts)
>>
>>
>This is cat /proc/bus/usb/devices | grep 06b9 that show this '000a'?
>  
>
Oops, sorry I missed one line from modem_run output it said:

Sep 19 20:35:22 pentium-133 modem_run[1300]: Modem revision: 0001
Sep 19 20:35:22 pentium-133 modem_run[1300]: Unexpected modem revision 
000a, assuming Rev 0200 modem.

That unexpected modem revision confused me. Sure the revision of modem 
is 0001 (same shows procfs)

Nevertheless, the problems still prevail. Connection dies from time to 
time and I can still deliberately kick it down by downloading one file 
from microsoft.com (I hope its not a sabotage of my Linux gateway :) ).
I have run out of ideas, I tried almost everything to keept the 
connection stable, even setting overkill parameters for send/receive buffers
for the driver. Is there any way how to find out whether are any packets 
comming through driver or USB interface? I just want to find the root 
cause of this problem. If packets arrive to ATM AAL5 layer (as shown 
using atmdiag) does that mean, they passed through driver yet ?

Any more suggestions ?

Thanks a lot
 Andrej


Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]

[speedtouch] Re: SpeedTouch USB lockups

[Gilles Espinasse]

- Original Message - 
From: "Andrej Kristofic" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, September 19, 2004 5:45 PM
Subject: [speedtouch] SpeedTouch USB lockups


>
> Hi.
>
> After one week trying to get that green thing (Alcatal SpeedTouch USB)
> to work I decided to ask for some external help. I've managed to establish
> connection and everything seems running just fine. But approx. once an
hour
> the modem (or driver or something) locks up and connection is broken.
> Actually,
> I'm able to reproduce this lockup quite reliably by downloading one
specific
> file from Internet. Logs don't give much info about this problem, pppoe
just
> fails reading and times out waiting for PADO offer:
>
It could be a mru/mtu problem (maybe only the primary problem, not the
reconnection after)
But it should not make die your connection and only let you unable to
receive some too big packets.

Reconnection problem may be a 'ghost session' : a pppoe session not properly
closed that will only die after a certain timeout.

Did you use clamp mss, something like this in your firewall rules
 /sbin/iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j
TCPMSS --clamp-mss-to-pmtu

Could you add debug in your ppp options and show the LCP negociation between
pppd and your ISP?
We should not need IPCP part just after, or you can mask confidential info :
login, your IP if fix.

Wich mtu size is your ppp0 interface set by lcp negociation?
ifconfig ppp0 should display MTU:1492
If it is not the cas, you may try to add to your ppp options
mtu 1492
mru 1492


> pppoe[394]: read (asyncReadFromPPP): Session 4552: Input/output error
> pppoe[515]: Timeout waiting for PADO packets
>
> After this lockup I'm not able to reconnect and I'm forced to reload usb
> module
> and modem microcode to connect again. I'm using kernel driver for
SpeedTouch
> together with RFC 2684 bridge (my provider supports PPPoE only) and
> rp-pppoe.
>
> I tried to trace the packets in "frozen" state by using "pppoe -A" command
> (access concentrator discovery). The packets are comming through nas0
> interface
> (RFC 2684 bridge) and they arrive to ATM AAL5 layer. Unfortunately, I
> was not
> able to find out whether they actually arrive to modem via USB.
>
> Well, anyone has an idea how to get rid of these lockups?
>
> Thanks for your help
>
> Andrej
>
>
> I almost forgot ... my configuration:
> An old Pentium 133, 64MB RAM, running Slackware 10.0
> Kernel 2.4.27 / 2.6.8.1 (doesn't matter which one I boot, lockups occur)
> Driver: speedtch version: 1.8
> Alcatel SpeedTouch USB modem: revision: 000a (this is weird, never saw
> this one in previous posts)
This is cat /proc/bus/usb/devices | grep 06b9 that show this '000a'?

Gilles


Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]