Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[les-70]

   The firmwares I have been using are in a folder in output in the opensource distribution.

  http://consumer.huawei.com/en/support/downloads/detail/index.htm?id=28981

 We think HG635v1.04t_multicast_with_multicfg_pack.bin is almost if not the same as the "proper" TT 1.04t and with no telnet.   It definitely updates to 1.06t unless you disable TR069/and/or the remote management

  The version HG635v1.04t_multicast_with_multicfg_main.bin has telnet enabled and can be made safe and hopefully compatible with updates but in its raw state telent is open on the WAN and the remote update settings are not the usual ones and may not work unless changed. It is vital to change the remote update port from 23 to disable telnet on the wan.  Telnet open on the wan is a bad a security issue.  Repeated shields up checks should help keep you safe but when fiddling with the telnet version don't assume it is OK but check for all changes.

 If your not using the modem  HG635v1.04t_multicast_with_multicfg_pack.bin should be fine and with a config telnet should work. 


  I guess it depends how much 1.06t is annoying you. 

[broadstairs]

Thanks for pointing me at that. The current f/w bothers me because my wife's laptop is likely to not be able to access the internet if I get a re-sync. I know it is easily fixable but it will probably happen when I'm not around  So I might try one of those.

Stuart

[s60sc]

Thanks to this thread I was able to enable telnet on my new TalkTalk Super Router v1.06, using the 11.txt file, so that I can now monitor it using dslstats.

After modifying the configuration to work with TalkTalk VDSL, the only issue I had was port 23 was open to the world. After some investigation I found the following rule in iptables chain INPUT_SERVICE_ACL
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:telnet
Once I deleted that rule then port 23 was stealthed, and stayed so after reboot.

[les-70]

  Thanks for the very interesting report.  Yes modifying some settings seems to open up port 23 on the WAN.  I did not however think that an iptable mod would survive a reboot. I will try it out ...   


Edit yes - telnet in - su for super user -  then list iptables and delete that line - seems to work and persist.  I am not familiar with editing  iptables and I needed a quick google to find suitable commands. 

[broadstairs]

I have asked TT for a copy of 1.04 since their update gave me an issue I didn't have before. Don't hold your breath though.

Well I got the expected result from TT, they are unable/unwilling to provide a copy of 1.04 for me to load locally. This in my view is unacceptable. There is always the possibility for a problem to happen during the roll out after testing which make the router unsuitable for the end user to continue to use so they really should have a copy available which the end user could load locally to downlevel to a working version.

Stuart

[broadstairs]

Having pestered them they now say they are willing to downlevel my router to 1.04 remotely which I have agreed to. In the process of enabling TR069 it then lost my manual DNS server addresses in DHCP settings again - good job I checked. Anyway will wait and see what happens.

Stuart

[broadstairs]

Well TT downloaded 1.04 remotely today to my router but the strange things was that although my DNS settings disappeared again there was no indication of a reboot in the router log. Anyway will see what happens now, I've disable TR069 and Remote Management in the router so it wont update again. I've rebooted the router manually to make sure it is OK and once again my DNS addresses were not there after the reboot! I'm sure that was not happening before. I'll do some more testing.

Stuart

[les-70]

  That sounds odd.  A hard reset should ensure the past is forgotten.  If not as I said above the version HG635v1.04t_multicast_with_multicfg_pack.bin worked perfectly for me (no telnet version) and also updated OK. 

[npr]

I find both firmware versions to have dns issues:

Both versions forget custom dns settings in the DHCP section of the GUI.
However v1.06t is still issuing the correct dns IP's to my devices even though my custom settings have long since disappeared from the GUI.

Most routers I've used just have a dns relay, the HG635 however has a dns catching resolver.
The cache is a nice feature, but the resolver is pathetically slow taking over twice the time to forward a lookup to my ISP than it would for a direct lookup.

The following DNS benchmark graph shows the HG635 DNS resolver on ip 192.168.1.1.
The two ISP DNS resolvers the router forwards to are 212.159.6.10 and 212.159.6.9
Graph key:
Red == cached time
Green == uncached time
Blue == uncached "dot com" time

[les-70]

 Maybe settings interact? My custom DNS were always OK with HG635v1.04t_multicast_with_multicfg_pack.bin.

[npr]

Is that custom dns in the "internet connection" settings?
They are the DNS IP's used by the routers DNS forwarder which I find to be unacceptably slow and therefore don't use.

The custom dns settings I have problems with are in home network > LAN interface > DHCP server.
I think this is the same settings which broadstairs has problems with.

[broadstairs]

The custom dns settings I have problems with are in home network > LAN interface > DHCP server.
I think this is the same settings which broadstairs has problems with.

Correct.....

Stuart

[les-70]

  It is the same ones -- in under DHCP settings that I use.

[npr]

Very strange this firmware. 
You find dns setting are ok but have problems with open ports.
Whereas I have dns issues but no problem with open ports.
IIRC broadstairs had problems with both.
As you said it must be some kind of settings interaction.

[broadstairs]

Just to clarify I only have DNS issues, it is all stealth. However I am using an alternate config loaded which also gives telnet access on my lan, although I dont need that right now as I'm still using the HG612 (unlocked) as a modem.

Stuart