Following my failed attempt to setup a stable haxie with my previously purchased Gigabyte GA-Z87N-WIFI motherboard and my fast Haswell CPU, despite other users not having any reported issues (per my search results on the net), I decided to ditch it and go for something different. The price point and budget allowed me to choose between an ASUS and MSI branded mATX motherboard, so I went for the MSI Z97i-AC board, as it was offering DisplayPort that I really want to checkout. Please note, it’s not the “Gaming” variant, which costs more (for some reason).

I installed the Intel Core i7-4790K processor (4.0 GHz), hence still in need of a Z97 chipset that can support such unlocked CPU. Additionally, I used again my 2 Corsair Vengeance (Low Profile) memory modules (1600MHz CL9), totalling 16GB of dual-channel RAM (they support Intel XMP v1.3, too). No dedicated graphics card, since I planned to use the embedded Intel HD Graphics 4600 of the CPU (more like a Mac Mini). The cooling is performed by a Skythe Ashura, for really silent computing (and some over-clocking, too).

After assembly, I booted the computer and went straight to the BIOS update menu, flashed it with latest v4.9 firmware (as found on MSI’s own website). With some parallel research on my favourite forums, the seemingly typical BIOS settings are really minimal, summarized below:

  • Update to the latest available BIOS from manufacturer!
  • Load “Optimized” Defaults;
  • Disable Serial (COM) Port completely (not really needed, but it’s just me);
  • Disable Full Screen Logo (there’s a good reason for it, I can explain);
  • Disable “Intel VT-d Technology” completely (otherwise, OS X won’t boot);
  • Disable “CFG Lock” completely (very critical, won’t boot either);
  • Finally, enable “Extreme Memory Profile (XMP)” to boost performance.

After this handful of changes, go to the main screen and opt to “Save And Reboot” the computer. You are done!

VISUAL GUIDE TO “MSI Z97i-AC” BIOS SETTINGS

Since I need to keep a record of this for my own reference, too, here is the visual guide of minimal BIOS settings to run OS X via Chameleon or Clover.

MSI BIOS Screen

Welcome to the main BIOS screen of this motherboard, freshly updated to latest v4.9 firmware. Click on “Settings” button (left, top) to start.

1. Load Optimized Defaults

MSI Restore Defaults Select

MSI Load Defaults

We need to be sure to start from “scratch” so loading the defaults is the first step to every successful Hackintosh.

2. Disable Serial (COM) Port and Full Screen Logo

I agree, these are my own personal additions to the guide, however, the Serial (COM) Port is nowhere needed on Mac OS X and disabling it will prevent it from appearing in the “Network” interfaces of “System Preferences” as I want my haxie to look as close to a real Mac as possible.

MSI Serial COM Configuration Select

MSI Serial COM Port Select

MSI Serial COM Port Disabled

The reason I always disable the fancy boot screen logos of my Hackintosh efforts, is really practical. If the computer running OS X sleeps, restarts or resets and the boot screen shows the logo, this means that some process or kext faied, resulting to CMOS reset. This was particularly evident in Mac OS X 10.9 (Mavericks) without patching ACPI kext accordingly, causing CMOS reset every time the computer went to sleep and woke up.

MSI Full Screen Logo Select

MSI Full Screen Logo Disabled

3. Important “CPU Features” to disable!

MSI CPU Features Select

I wasn’t aware of these two settings and how critical they are, for recent generations of motherboards, especially “CFG Lock”. I had read somewhere that it’s preferrable to disable Intel’s “VT-d” feature in BIOS (if your CPU supports it) as there doesn’t seem to be any Mac OS X applications that use it. Most of the times, this setting didn’t allow the computer to properly boot OS X, either. In any case, recent iterations of Chameleon and Clover allowed to safely bypass this BIOS setting by including dart=0 in the kernel flags and settings. Use this only if you are sure that you need it.

MSI Intel VT-d Disable

Over on MacBreaker, one reads:

dart=0
Disables the VT-d virtualization technology built into certain Intel processors. For Hackintoshes, VT-d is pretty useless; virtually no Mac OS X applications use it (virtualization apps like Virtualbox tend to use the alternative VT-x technology, instead), and certain Hackintosh motherboards have been known to crash in Mac OS X when VT-d is enabled.

Of course, disabling “VT-d” for starters, allows to setup the haxie with minimum of effort and bootloader settings. Later on, if someone really needs it, using kernel flag “dart=0” during boot time seems to solve the issue. I personally haven’t tried it, but it’s all over the forums.

MSI CFG Lock Disable

The “CFG Lock” is a setting that is quite new in UEFI BIOS, or appears in some manufacturers. For example, I never encountered it on my Gigabyte GA-Z87N-WIFI BIOS settings, despite using this same CPU. Nevertheless, it seems critical and related to Haswell’s power management as nearly all UEFI BIOS versions seem to “lock MSR 0xE2”. Disabling it is crucial, especially for running OS X 10.10 (Yosemite) and booting stock kernel. What does this “locking” do? All I can find is that it locks cuurent C-State until the next reset occurrs. Beats me, but OS X doesn’t like it!

4. Get that RAM in optimal speed

One of the last things to do, for better performance, is to enable the XMP profile of the memory modules if they support it (please check your specifications). I purchased these Corsair RAM modules knowingly that they support XMP, so I wanted to set them to run at 1600MHz.

MSI 12 XMP Profile Select

MSI XMP Profile Enabled

Having XMP as part of the hardware specifications is nice, but not needed. Nevertheless, if someone is going to buy new RAM modules anyway, better get the full monty as price-difference is too small compared to other non-XMP modules, for same total capacity.

5. Save settings and reboot!

Pretty straight-forward action…

MSI Save And Reboot

Now we are ready to run our Mac OS X USB Installer that we previously created on another computer running OS X! More on that, coming soon. I will post my optimal Clover flags, too.

SOME FINAL POINTS

Modern UEFI BIOS versions have important settings enabled by default — that weren’t so, in the past. In the case of the MSI Z97i-AC, I had no more work to do, but it’s always good to check them and remember them, so we never forget.

  • HPET must be enabled and set to “64-bit” mode, if such setting is available;
  • AHCI must be the chosen SATA Control Mode of your setup;
  • Both EHCI and XHCI “Hand-Off” are usually left enabled, depending on your board and chipset;
  • Similarly, XHCI Mode should be left to Auto, if such setting is available (avoid “Smart Auto”);
  • ACPI Suspend Type must always be in S3 (STR) mode;
  • Check that Secure Boot Mode is disabled, or UEFI Mode is set to “Other OS” (i.e. not Windows 8 mode)

END OF PART ONE

I recently needed to install Windows 7 (Home) on my old Dell Inspiron Mini 10V (1011) netbook so my mother-in-law can learn how to type. Quite a strenuous procedure, as I have been spoiled with Mac OS X that has had the smoothest of installation procedures, including all updates (it took almost 24h to get all Windows 7 x86 updates on that small, slow computer).

First of all, an easy and quick way to avoid CD/DVD media burning (of the Windows 7 ISO) is to create a bootable USB disk, through Microsoft’s own free Windows USB/DVD Download Tool tool, requiring an original Windows 7 (x86 or x64) ISO image (e.g. from MSDN).

Then, once the USB preparation is done, a simple hack that requires a single file to be removed (called ei.cfg) will allow to bring up -during installation- a list of choices of Windows “operating systems” to install i.e. Starter, Home, Professional, Ultimate, etc. regardless of the ISO you have used. However, the architecture remains same across: that is, x86 or x64 (depending on the used ISO) and not both (on same USB with this creation method, anyway).

WindowsChoices

A list of actions that I must perform next, will be described here below, for the sake of my next reference instead of searching the web. It’s nothing advanced, just some stuff to remember to do… perhaps useful to you, too.

1. Switch to the automatic logging of main user to Windows
I keep forgetting the command to run is “netplwiz.exe” as found in this useful article. Simply select the user account from the list, uncheck the “Users must enter a user name and password to use this computer” checkbox then click the apply button.

Auto-Login Setting

2. Complete the Windows Update procedure and reclaim space
With a small (in capacity) and old SSD installed in that netbook, I needed to reclaim the wasted space after installing those painfully slow updates. From an initial 30GB drive, after installing Windows 7 (with SP1 integrated) I got left with some 17GB and now down at 10GB due to the storage of the Windows Update backups!

The supposedly magic command is “cleanmgr.exe” as per this article, but I did follow the tips of this other article, too.

UpdateCleanup

3. Remove that annoying Windows 10 Upgrade notification
Ever since it appeared on the bottom taskbar and scared off people as a hoax, I have been searching for a permanent and official way to remove it. It appears it’s related to some Windows Update and more specifically to KB3035583 that needs to be uninstalled from the Windows Update items/list. Unfortunately, in the description that appears (on the right) to this KB3035583 in the Windows Update list, there’s absolutely no reference to this new “Windows 10 Notification” so one need to remember KB3035583 and never install it (and hide it).

KB3035583

4. Change the system language without “Ultimate” version installed

The installation ISO that I used to create that bootable USB was in English language, but the target computer (the Dell notebook) should eventually end up in another system language. As I installed “Home” and not “Ultimate” edition of Windows 7 (x86) I could only get the system language changed via Vistalizator to any other language of my choice. This excellent tool accomplishes the task easily and in a couple of steps, to the point of being fool-proof. It officially downloads the chosen language pack from Microsoft’s own servers, so the end-result is the real deal. Despite being created for Windows Vista originally, Vistalizator remains a highly valuable tool.

Vistalizator

Please note that it is recommended to switch to another system language (via Vistalizator) first thing, after a clean Windows 7 installation.

5. How to facilitate further Windows Update items
Since there was never a Service Pack 2 released (SP-2) to the dissatisfaction of most Windows 7 users (that would indeed make our lives easier) and rather than creating a bootable Windows 7 installation disc/image with slipstreamed updates (not a procedure for everyone) there appears to be a miraculous tool called WSUS Offline Update filling this gap, that is thankfully still being updated.

This tool is seemingly helping users to download and group those (dreadfully many) updates once and in one place, allowing for off-line use in many Windows 7 installations. From the website, one reads “Using WSUS Offline Update, you can update any computer running Microsoft Windows and Office safely, quickly and without an Internet connection.” Of course, any machine-dependent device drivers that normally appear as “updates”, are not downloaded via this tool (for example, Network, WLAN, Graphics, etc.) so you will still need to use the normal route of Windows Update service on your computer.

WSUS

Despite its simple documentation, I have not spent enough time with this tool in order to get a personal opinion or experience using it. My first attempt was to quickly download the main Windows updates for the x86 architecture, and then run its UpdateInstaller.exe on the target machine, as instructed.

UpdateInstaller

However, due to the fact that I used Vistalizator to change the system language (from English) earlier, I am not sure if all the acquired updates were succesfully installed or if WSUS Offline Update was confused about which updates were applicable (due to the new system language) despite saying “multilingual updates” on its main window. It did install some updates, but the target computer’s Window Update service eventually found many more to download and install that I didn’t expect, but excluding device-drivers of course (which is normal).

The next time I ran WSUS Offline Update was to download the Windows updates for both architectures (x86 and x64) as I plan to test the tool on my next VMware Windows 7 installation, on my Mac, to see how it behaves and what updates eventually remain to download/install.

END OF PART ONE

I knew this day would come, as it has come for all other friends of mine who became fathers: create back-ups of your original kids-content DVDs, as their constant playback is not only difficult to manage but damaging to the discs themselves. Hooray for the media playback method: digital files! Long live the Matroska format!

An excellent tool that I’ve been using since my first Intel-based OS X days, HandBrake is the solution to digital files creation and of course, MKVs are the only way to go nowadays. Simple in its GUI yet powerful, HandBrake has been a companion for many of us and I am very happy that its development is still on-going.

What I didn’t know until recently is that HandBrake was counting on third-party software to directly read CSS-encrypted DVDs (e.g. “Fairmount” for Mac, by Metakine) something I’ve never experimented with until now. However, this “third-party” software is no longer available nor updated, as “Fairmount” has been acquired by DVDSuki Software and has been merged into “Mac DVDRipper Pro”. But according to this older article in MacWorld, we can still read and convert encrypted DVDs to MKVs for use with our favourite digital media players. In my case, a Western Digital WDTV Live player.

When prompted by HandBrake, simply install the necessary CSS library in your system, re-launch HandBrake and you’re good to go. In effect, what you need is the installation of the file libdvdcss.2.dylib in /usr/lib/ on your Mac system and you won’t be getting these error messages on HandBrake anymore:

HandBreak Missing Library Warning

Open the inserted DVD via HandBrake and wait until it reads all titles and chapters, then just select what you want to convert. Happy converting…

UPDATE: Just found out that user pmetzger got the source code for Fairmount and released a tweaked version. It may or may not remain alive as a project, but it’s worth having a look: http://github.com/pmetzger/Fairmount/

UPDATE: Seems that MacWorld have updated their same article and now we can get the updated libdvdcss.2.dylib versions directly from http://www.videolan.org/developers/libdvdcss.html

You may certainly find guides on how to share an Internet connection (e.g. from your Ethernet to wireless devices via embedded Wi-Fi) on a Mac computer running Mountain Lion 10.8.x but maybe you are in the same boat as I was, some time ago: do the exact opposite.

Due to the serious economical conditions in my home country, I had to leave wife, child, family and friends and move to another country in Europe where I found employment anew. However, renting a furnished flat was easy; getting a telephone and ADSL connection proved impossible.

I therefore had the landlord talk to my neighbour and convince him to eventually share his Wi-Fi with me, at a monthly fee, therefore providing me with a link to the “outside world” in the evenings (that is, FaceTime with my family).

However, I still wanted to hook up to the Internet my 2 Hackintosh computers and my WDTV Live device, besides my iPad. I had to devise a plan and share Wi-Fi Internet through Ethernet.

My smaller Hackintosh (a Gigabyte GA-H61N-USB3 with Intel Core i3-2125 and 8GB RAM) is used as a file/media server and seemed ideal for the task. Back then, while running 10.8.2, I thought that using Server.app would solve my problems. However, being computer-literate but networking-apprentice, I could not set it up properly and abandoned all hope.

I then turned to the famous, easy “Internet Sharing” feature of the Mac OS X system, but doing the opposite of what most users did; and it was tricky. After purchasing an OEM 802.11n USB dongle with a flexible antenna (running with the official Realtek RTL8192CU8 driver) the task was to properly configure the settings so I could share Internet via Ethernet to my other devices too: my powerful Hackintosh and WDTV Live player, all hooked to a Gigabit switch.

First step was to set up the Wi-Fi dongle driver, then I made sure the connection was working by using DHCP for quicker, fool-proof results. In this case, the ADSL wireless router was serving a range of 192.168.1.x addresses, whilst the DNS assigned was the router/gateway itself, i.e. 192.168.1.1:

Mountain Lion 'Internet Sharing' Wi-Fi Settings

Then, after a lot of searching and experimenting, I realised that the Wi-Fi dongle (en1) had to be first in the list of network devices, as it’s the one that is providing the connection to the Internet. The Ethernet (en0) connection would thus be second:

Mountain Lion 'Internet Share' Service Order

The next step was the tricky one: the Ethernet (en0) connection must get a manual IP address so that DHCP (a service running on Mountain Lion, this time) can serve any wired devices. This IP range had to be different, however, to the one served by the wireless modem/router and in this case I decided to go with 192.168.2.x and that meant I needed to assign 192.168.2.1 on this computer (to start the DHCP pool):

Mountain Lion 'Internet Share' Ethernet Setup

As it can be seen, the tricky part lied to the Router and DNS settings, as Ethernet (en0) now is relying on Wi-Fi (en1) to have all packets properly routed to the Internet. Both these settings had to be set as 192.168.1.1, pointing to the wireless modem/router. The Subnet remained the same 255.255.255.0 for the sake of simplicity.

The final step involved just activating the actual “Internet Sharing” itself. In the “Sharing” preferences pane and after clicking on the “Internet Sharing” service, I made sure that my source was set to the 802.11n WLAN Adapter, sharing to computers using Ethernet. When ticked both the “destination” and the service itself, I could see that my other devices immediately picked up an IP address and got connected to the Internet.

Mountain Lion 'Internet Share' Set Connections

As with each Hackintosh set-up, there are changes and updates needing to reboot the computer. Coming from Windows mentality I often reboot this Hackintosh file/media server, sometimes due to the frame-buffering issues that appear on the vanilla Intel HD 3000 display driver. Even after updating to 10.8.4, the new problem found was that upon reach reboot and despite the “Internet Sharing” service being ticked (implying “active”) the actual underlying service would not kick-start. I always had to manually stop and re-start this service by un-ticking and re-ticking this service on the list. Otherwise, wired devices had no access to Internet and curiously enough, could not get an IP address either.

Mountain Lion 'Internet Share' Confirm Start

This was a harder bug to crunch, as for countless times I was literally “digging” in Google results to find a solution using a multitude of keywords. The answer came after reading for a third or fourth time the insightful article “Running DHCP on Mountain Lion Server” where I found that the bootpd deamon is responsible for my problem. Moreover, it seems that Apple programmers decided to keep this daemon dormant at each reboot, as seen in the untouched file /System/Library/LaunchDaemons/bootps.plist where the <Disabled> key is set to <true> by default, meaning that Mac OS X forces the user to manually start DHCP, whenever it is needed. I guess this is the right way to do things but Apple programmers could at least have “Internet Sharing” stopped and un-checked at each shutdown!

The necessary edit is to change this <Disabled> key in line 6 from <true> to <false> and just reboot the system. Better make a backup copy of the file bootps.plist, just in case. This change is quite sensitive and needs to be performed only if the computer is intended to always behave as a DHCP server just like in my own case; now, it is not necessary to stop and re-start the service after each reboot, as long as “Internet Sharing” remains untouched.

Mountain Lion 'Internet Share' Activate Sharing

After activating “Internet Sharing” and following this article found on StackExchange.com, I could now see how connectivity works with the new bridge created on the file/media server:

$ ifconfig
lo0: flags=8049 mtu 16384
	options=3
	inet6 fe82::1%lo0 prefixlen 64 scopeid 0x1 
	inet 127.0.0.1 netmask 0xff000000 
	inet6 ::1 prefixlen 128
en0: flags=8963 mtu 1500
	options=2b
	ether 00:e0:40:48:e0:40 
	media: autoselect (1000baseT )
	status: active
en1: flags=8863 mtu 1500
	ether 08:02:0a:0d:4c:05 
	inet6 fe82::4a02:2aff:fe9d:4c35%en1 prefixlen 64 scopeid 0x5 
	inet 192.168.1.39 netmask 0xffffff00 broadcast 192.168.1.255
	media: autoselect
	status: active
bridge0: flags=8863 mtu 1500
	ether a8:d2:4a:10:d0:b9 
	inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255
	Configuration:
		priority 0 hellotime 0 fwddelay 0 maxage 0
		ipfilter disabled flags 0x2
	member: en0 flags=3
	         port 4 priority 0 path cost 0

 
NOTE: The boodpd daemon starts with the network settings found in /etc/bootpd.plist which were created when “Internet Sharing” was previously activated. This file must not be confused with the actual daemon launch behaviour in bootps.plist.

I accidentally stumbled upon this tip, the other day, while searching for something completely different. I upgraded to Mountain Lion directly from Snow Leopard, thus ignoring the AirDrop functionality introduced in Lion. However, I soon realized that on my old MacBook Pro 2007 model (MacBookPro3,1) this feature did not exist at all.

Apparently, for AirDrop to work natively (with Lion and Mountain Lion, only) Apple requires the existence of “hardware necessary to support a certain type of point-to-point Wi-Fi connection” that is probably not present on older models.

Thankfully, it appears that it is possible to allow “unsupported” Macs to enable this functionality, too, via a simple Terminal.app command, as with all good things on OS X:

defaults write com.apple.NetworkBrowser BrowseAllInterfaces 1

Whether it works well or not, that is another story!

After successfully entering the command above, it is advised to either relaunch Finder or simply reboot the computer. This system setting appears to be permanent, after each reboot.

People reported that even for newer models, I need to activate this feature on every Mac in my local network in order to use it properly, including ethernet-only connected Macs.

To disable this feature, I only need to set the last digit back to zero, of course:

defaults write com.apple.NetworkBrowser BrowseAllInterfaces 0

I am quite happy this “hack” still works under Mountain Lion 10.8.0 and 10.8.1, so if you have an older Mac computer that can still run Lion or Mountain Lion natively, no need to go jealous on the AirDrop functionality of newer computers!

My thanks to OSXDaily.com for posting the original tip of the anonymous user over MacOSXHints.com.

Update: Looks like it works fine with my MacBook Pro (2007) via Wi-Fi and my Hackintosh via Ethernet! (both running Mountain Lion 10.8.2)

The process of setting up an optimised hackintosh requires the extraction, de-compilation, editing and re-compilation of the computer’s DSDT table. The extraction process itself is extremely easy, using Ubuntu’s Live CD and just typing one command in Terminal. However, it seems that since Ubuntu v11.x the syntax of this command had drastically changed.

After installing Ubuntu on a USB flash disk for this purpose, using the excellent Universal USB Installer tool, open up a terminal session and type the following command (assuming you will later copy the generated/extracted file from the Desktop to another FAT-32 formatted USB flash disk):

cd ~/Desktop
sudo cat /sys/firmware/acpi/tables/DSDT > DSDT.aml

 
For those of you still using Ubuntu Live CD v9.x and v10.x, just type:

cd ~/Desktop
sudo cat /proc/acpi/dsdt > DSDT.aml

 
This extracted file can later be de-compiled using iasl and edited according to various guides (such as those found over at InsanelyMac). But if you definitely need to obtain such a text-version of this file, you can install iasl and de-compile it as easily:

sudo apt-get install iasl

 
…wait while it loads from the Internet and installs (obviously your network card must be properly detected and working) and then type:

iasl -d DSDT.aml

 
The resulting file will be called DSDT.dsl and will also be placed in ~/Desktop/ which can be edited with a simple (but good enough) visual text editor.

Thanks to user AsereBLN for his original article back in October 2009, when I started exploring Mac OS X outside my iMac.

Happy patching!

A few months ago, I had successfully updated the firmware on my Thomson TG585 v8 router to version 8.2.7.8 when I also found out that I could connect to it via telnet, as per my previous post.

Recently, due to connectivity problems, my ISP requested that I perform a factory reset on the device. After solving those connectivity problems, I realised that access via telnet was not possible anymore. The weird thing was that I had not changed any settings on either router or computer, so this problem got really puzzling.

Finally, I found the reason why this was happening, as well as a working solution from member ZhenXlogic over the Greek forum at www.adslgr.com which I replicate here, in English, for those of you that could not easily find a solution, yet. The steps are easy.

First, save your current router settings by visiting the web interface over at 192.168.1.254 and selecting the left icon “Thomson Gateway”. Once inside, click on “Configuration” and then choose to “Save or Restore Configuration”. Then click on “Backup Configuration Now…” and select the location where user.ini will be saved.

Now with your favourite text editor, open the file user.ini and carefully browse inside, until you find the section [servmgr.ini] where you will see the problem itself: the new settings of the router have restrictions on the IP addresses that will access it via telnet, as seen in this output of mine:

[ servmgr.ini ]
ifadd name=PPTP group=lan
ifadd name=HTTP group=lan
ifadd name=HTTPs group=lan
ifadd name=HTTPs group=wan
ifadd name=FTP group=lan
ifadd name=FTP group=wan
ifadd name=TELNET group=lan
ifadd name=TELNET group=wan
ifadd name=DNS-S group=lan
ifadd name=MDAP group=lan
ifadd name=SSDP group=lan
ifadd name=PING_RESPONDER group=lan
ipadd name=HTTPs ip=212.251.87.4
ipadd name=HTTPs ip=62.1.46.29
ipadd name=HTTPs ip=62.1.46.30
ipadd name=HTTPs ip=10.24.11.19
ipadd name=HTTPs ip=10.24.11.20
ipadd name=FTP ip=212.251.87.4
ipadd name=FTP ip=62.1.46.29
ipadd name=FTP ip=62.1.46.30
ipadd name=FTP ip=10.24.11.19
ipadd name=FTP ip=10.24.11.20
ipadd name=TELNET ip=62.1.46.29
ipadd name=TELNET ip=62.1.46.30
ipadd name=TELNET ip=10.24.11.19
ipadd name=TELNET ip=10.24.11.20
ipadd name=TELNET ip=212.251.87.4
modify name=PPTP state=enabled
modify name=SNTP state=enabled
modify name=SLA_ICMP_PING state=enabled
modify name=SLA_UDP_PING state=disabled
modify name=HTTP state=enabled
modify name=HTTPs state=enabled
modify name=WEBF state=disabled
modify name=TFTP-C state=disabled
modify name=FTP state=enabled
modify name=TELNET state=enabled
modify name=RIP state=disabled
modify name=IGMP-Proxy state=enabled
modify name=DNS-S state=enabled
modify name=DNS-C state=enabled
modify name=DHCP-S state=enabled
modify name=MDAP state=enabled
modify name=CWMP-C state=enabled qoslabel=Management
modify name=CWMP-S state=enabled
modify name=SSDP state=enabled
modify name=GRE state=disabled
modify name=IPIP state=disabled
modify name=IP_COMMANDS state=enabled
modify name=PING_RESPONDER state=enabled
mapadd name=HTTP port=www-http
mapadd name=HTTPs port=443
mapadd name=HTTPI intf=LocalNetwork port=www-http
mapadd name=HTTPI intf=LocalNetwork port=1080
mapadd name=HTTPI intf=LocalNetwork port=httpproxy
mapadd name=FTP port=ftp
mapadd name=TELNET port=telnet
mapadd name=DNS-S port=dns
mapadd name=MDAP port=3235
mapadd name=SSDP port=1900

 
As you can see, unless you set the IP of your computer to the above specific values in highlighted red, the router will not allow access to its telnet console. For some reason, the developers of the Thomson firmware forgot to include the router’s default IP subnet, i.e. 192.168.1.xxx completely.

To remedy this situation, you simply need to add the line below as the first entry for TELNET, in order to allow the current router’s IP subnet (static or DHCP) computers to connect to it:

ipadd name=TELNET ip=192.168.1.[1-100]

 
In my example, I restrict the range from 1 to 100 but you can also set it from 1 to 200, accordingly. Therefore, insert this entry with your text editor back in the [servmgr.ini] section, like I did:

[ servmgr.ini ]
ifadd name=PPTP group=lan
ifadd name=HTTP group=lan
ifadd name=HTTPs group=lan
ifadd name=HTTPs group=wan
ifadd name=FTP group=lan
ifadd name=FTP group=wan
ifadd name=TELNET group=lan
ifadd name=TELNET group=wan
ifadd name=DNS-S group=lan
ifadd name=MDAP group=lan
ifadd name=SSDP group=lan
ifadd name=PING_RESPONDER group=lan
ipadd name=HTTPs ip=212.251.87.4
ipadd name=HTTPs ip=62.1.46.29
ipadd name=HTTPs ip=62.1.46.30
ipadd name=HTTPs ip=10.24.11.19
ipadd name=HTTPs ip=10.24.11.20
ipadd name=FTP ip=212.251.87.4
ipadd name=FTP ip=62.1.46.29
ipadd name=FTP ip=62.1.46.30
ipadd name=FTP ip=10.24.11.19
ipadd name=FTP ip=10.24.11.20
ipadd name=TELNET ip=192.168.1.[1-100]
ipadd name=TELNET ip=62.1.46.29
ipadd name=TELNET ip=62.1.46.30
ipadd name=TELNET ip=10.24.11.19
ipadd name=TELNET ip=10.24.11.20
ipadd name=TELNET ip=212.251.87.4
modify name=PPTP state=enabled
modify name=SNTP state=enabled
modify name=SLA_ICMP_PING state=enabled
modify name=SLA_UDP_PING state=disabled
modify name=HTTP state=enabled
modify name=HTTPs state=enabled
modify name=WEBF state=disabled
modify name=TFTP-C state=disabled
modify name=FTP state=enabled
modify name=TELNET state=enabled
modify name=RIP state=disabled
modify name=IGMP-Proxy state=enabled
modify name=DNS-S state=enabled
modify name=DNS-C state=enabled
modify name=DHCP-S state=enabled
modify name=MDAP state=enabled
modify name=CWMP-C state=enabled qoslabel=Management
modify name=CWMP-S state=enabled
modify name=SSDP state=enabled
modify name=GRE state=disabled
modify name=IPIP state=disabled
modify name=IP_COMMANDS state=enabled
modify name=PING_RESPONDER state=enabled
mapadd name=HTTP port=www-http
mapadd name=HTTPs port=443
mapadd name=HTTPI intf=LocalNetwork port=www-http
mapadd name=HTTPI intf=LocalNetwork port=1080
mapadd name=HTTPI intf=LocalNetwork port=httpproxy
mapadd name=FTP port=ftp
mapadd name=TELNET port=telnet
mapadd name=DNS-S port=dns
mapadd name=MDAP port=3235
mapadd name=SSDP port=1900

 
Notice the entries in orange, where TELNET is enabled for access via wired (lan) and wireless (wan) computers, at the default port 23:

ifadd name=TELNET group=lan
ifadd name=TELNET group=wan
modify name=TELNET state=enabled
mapadd name=TELNET port=telnet

 
Now that you’re at it, you can disable (unbind) the router’s SIP port mapping to allow your own SIP devices to work perfectly, as per my older post. Simply remove the line below from section [connection.ini] within user.ini:

bind application=SIP port=5060-5060

 
You can also disable the WPS functionality by setting the proper field inside [wireless.ini] section:

wps config ssid_id=0 state=enabled

 
to:

wps config ssid_id=0 state=disabled

 
Once saved, you need to upload the new configuration back to the router. Thus, you need to visit again the web interface over at 192.168.1.254 and select the left icon “Thomson Gateway”. Right under, click on “Configuration” and then choose to “Save or Restore Configuration”. Then click on “Restore Configuration Now…” and point to the modified user.ini to be uploaded.

The device will reboot in order to apply the new settings; in a couple of minutes, you shall have telnet access!