Cablemodem Technicolor TC7 refuses connection

[lyceus]

From Spanish forum:

A user from Spain reports that one Spanish ISP uses Technicolor TC7110.02 Cablemodem for connect from https://192.168.1.254/RgConnect.asp and http://192.168.100.1/ to Internet. Since MSIE, Chrome and Firefox works fine, Pale Moon have troubles with their certificate which rarely seems to work.

Windows Os: Windows XP 32 bits
PaleMoon versions involved: 20.x

User had tried:

* Clear certificate and get a fresh one
* Use versions 20.x and even the last public beta of Pale Moon 20.3b3
* Use Portable Pale Moon with a clean profile
* Use new profile and even new Pale Moon install

In all cases the profile get random issues and most times don't connect. Original posts can be found here http://forum.palemoon.org/viewtopic.php?f=9&t=2824&p=15734

Any idea of what can happen here? Thank you in advance!

[Moonchild]

Looking at the other thread:

192.168.1.254 : server does not support RFC 5746, see CVE-2009-3555

That's just a warning about the modem's built-in web server not properly supporting safe renegotiation, you can ignore that.

Me pregunto, ¿influirían las claves activas de pipelining (y asociados) que tiene Pale Moon configuradas de forma predeterminada, y estén haciendo mella en estos tipos de url, y otras páginas web?

It's very possible that pipelining is not properly supported by a minimal web server found in a modem, so try switching it off. (pipelining/pipelining over SSL)

Al estar intentando fallidamente acceder con Pale Moon a la url 192.168.1.254, y de momento o al rato intento hacerlo con otro navegador, sea Firefox u Opera, estos también fallan hacia esa url. Pero al cerrar Pale Moon, FF y O acceden exitosamente en nuevo intento.

This makes me think that the modem's UI really just chokes on not finding a "known" browser (meaning really bad programming of the embedded web server pages)...? I mean: Pale moon running or not running should have no bearing at all on how other browsers interact with the web server. I don't think this can be fixed - the user will just have to make sure to use a different browser if/when he actually needs to connect to the modem interface; or get a better modem or upgrade the firmware in it.

[Turson]

Hi forum. Nice to meet you.
I'm the user with that issue. OS: windows xp sp3.

Besides the above. I explain:
Pale Moon running and trying connection (failed or UI non complete) to url modem configuration 192.168.1.254, this have bearing on how other browsers interact with that web server, even stopping PM. These browsers fails too , then I must close PM.

Same issue with Firewall disabled, too.

Also. What Pipelining keys should I try switching it off??

[Rohugh]

Hi forum. Nice to meet you.
Also. What Pipelining keys should I try switching it off??

Hiya


If you have PaleMoon Commander it is Network>Pipelining - uncheck "Pipelining over SSL"

Via About:config set "network.http.pipelining.ssl" to false (double click it)

[Turson]

Hi forum.

Seems to works every time, to fix the issue needs both of:
"network.http.pipelining" to false
"network.http.pipelining.ssl" to false
Then, Should I decide if give up Pipelining requests?
Or, I guess setting another profile, when I go to need enable Wifi from Modem.

Other question: Why "network.http.pipelining.maxrequests" is value 4 by default in PaleMoon?, but this value is 32 by default in Firefox, currently.

http://kb.mozillazine.org/Network.http. ... axrequests » July 2010 document.

[Moonchild]

Seems to works every time, to fix the issue needs both of:
"network.http.pipelining" to false
"network.http.pipelining.ssl" to false
Then, Should I decide if give up Pipelining requests?
Or, I guess setting another profile, when I go to need enable Wifi from Modem.

You could indeed use a separate profile for the cable modem if you need to change it that often.
Not using pipelining in general will have you lose some performance in web traffic for sites with lots of elements, and may give your router more work than it actually needs, so that's why it's enabled by default in Pale Moon -- there are, however, a good number of users that switch it off because it doesn't work for their particular internet connection; no disaster to do so if you need it.

Other question: Why "network.http.pipelining.maxrequests" is value 4 by default in PaleMoon?, but this value is 32 by default in Firefox, currently.

I keep this low on purpose so that the number of requests sent over a single connection is kept low - 32 is much too high (and I'm surprised if this would be the default...?) and you'd likely get "head of line" delays; if the value is too high, then there's a lot of delay and overhead if one element isn't served immediately - everything behind it "in line" would also be delayed.
Also, the page you linked to says the value for Firefox is also 4:

Possible values and their effects
Any integer from 1 to 8 inclusive determines the maximum number of requests to pipeline at once. A value of 1 disables pipelining. (Default: 4)

The combination of preferences currently in Pale Moon has been found using practical tests more than theorizing, and should be optimal for all connection types. If pipelining defaults have changed, then I gather something in the back-end has changed to address these "head of line" delay issues, and I'll have a closer look at that code again with the next major release.

[Rohugh]

Looking at FF 23 (and Nightly) the default for maxrequests is still 32.

[Moonchild]

Looking at FF 23 (and Nightly) the default for maxrequests is still 32.

Yes, and it's still got pipelining disabled by default. I'm also unable to find in which bug this was changed, and why. A pipeline of 32 elements is a moronically high value.

EDIT: Apparently it's been reworked in bug #599164 -- I'll have to re-evaluate this when I have time; first impression is that 32 is still a bad choice even with the more adaptive implementation of pipelining (long pipelines -> more chance to end up in a red state where pipelining is disabled completely until it goes back in yellow after a time-out).

EDIT2: this is also getting way off-topic. With pipelining off the OP's question was resolved, so... further pipelining discussions should be directed to a new topic in the appropriate board, please.