Delivered-To: msasha:[EMAIL PROTECTED]
From: Michael Stolovitzsky <[EMAIL PROTECTED]>
Subject: Re: Rotal USB ADSL *almost* success
Date: Fri, 1 Nov 2002 17:12:21 +0200
User-Agent: KMail/1.4.3
To: Alexander Maryanovsky <[EMAIL PROTECTED]>
Just in case you are interested, we have discovered that, in fact, the modem
will lock itself off the line after a more or less static period of time
regardless of whether ppp link is connected or not. It does not matter.
Experimentation suggested that after a fixed amount of time, no
communications with the upstream would not be available until the modem is
forcefully resynced.
Our current theory is that the modem (or, rather, the firmware) implements an
adaptive modulation control algorithm which is based on line statistics per
element of time. The statistics deteriorate (for whichever reason) to the
point when modem decides that it is no longer viable to support current state
of the line and tries to start resynchronization in the very fashion of usual
modems initializing connection retraining. As soon as it happens,
communications dies off. The modem itself still responds to the control
traffic, but there is absolutely no uplink to the SLAM. Alternative theory is
that the firmware or sync sequence that we use do not implement some
nezeq-specific keepalive functionality, so the connection times out, on
either site of the link.
it is my belief that this is due to a slightly non-standard line modulation in
Nezeq. While there is no technical reason to suppose so and in fact there is
absolutely no proof whatsoever that this is the case, I find it very strange
and disturbing that the Windows drivers for the modem are aware of the
traffic shaping settings on the SLAM - as far as I know, there should be
absolutely no reason for the SLAM to communicate them down to the modem which
raises unhealthy suspicions about proprietary cooperation between the modem
firmware and the Nezeq equipment.
I am no DSL expert and I can only operate subtle terms, most of which I hardly
understand.
Anyway, obvious solution would be to take a dump of the syncronization
sequence under Windows and use it in Linux; however. we were unable to do
that because the USB snooper that is suggested in the sniffing manual crashed
our Windows workstation and we were not able to find a decent workaround.
Perhaps you would like to try? If this is the case, #eci people on
freenode.net can explain you how.
You can forward this email to the list - I am not currently subscribed there.
--
"I'm not saying there should be a capital punishment for stupidity, but why
don't we just take the safety labels off of everything and let the problem
solve itself?"
================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
