TV LG 37LV5500 reflow

I bought this smart TV (LG 37LV5500) set at 2011. At 2015 the problems started. The problem of the TV was that the main processor overheated and lost the connection.

The problem is easily solved by reflowing but only temporarily. After several failed attempts I finally mastered reflowing.

  • I tried the oven method and the TV worked for a month. I even tried to mimic the thermal profile.
  • I tried the heat gun approach and the TV worked for about 1 week.
  • I tried to reball (needs special hardware) and the owner of the reballing hardware talked me out of it. He suggested to buy a new one from e-bay.
  • I bought a replacement board in e-bay but it didn’t work.
  • I finally bought another LG TV with great reservations.

I also found 12v somewhere in the board and added a small fan in order to avoid extensive overheating. The fan must be very thin in order to fit when you try to close the TV. I found that a 40x40x10 was allowing the case to close properly, with a bit of extra pressure. Probably a 50x50x10 or maybe a 60x60x10 fan could also fit in but I wasn’t able to find these fans so there is room for some experimentation.

Enjoy the pictures. The first one shows how to protect the rest of the board (plastic parts etc) by wrapping the board in tinfoil and baker (anti stack) paper. Also I changed thermal paste and replaced the 4 springs with screws in order to make sure the cooler (black metal plate) is hold really tight to the processor.

Definitely a fail but at least I didn’t give up without a decent fight. At the end the local repair shop offered to buy the TV for 40eur.

Continue reading “TV LG 37LV5500 reflow”

GWT SDM (Super Dev Mode) https setup in 7 steps

Introduction

This guide enables you to setup https support for GWT SDM which currently lacks. The guide was created after reading the comments in issue #7535 in github. GWT team may or may not deprecate bookmarklets which SDM currently depends on in order to trigger compilation.

The Guide

The steps required to realize such a setup are:

  1. Install and configure apache: https://wiki.debian.org/Self-Signed_Certificate
    I used the snake oil certificate that comes with Debian and accepted the security exception for the browser to trust the server.
  2. Enable proxy modules for apache
  a2enmod proxy
  a2enmod proxy_http
  a2enmod headers 
  1. Use this or something like this for /etc/apache2/sites-enabled/default-ssl.conf
<IfModule mod_ssl.c>
        <VirtualHost *:9877>
                ServerAdmin webmaster@localhost
                DocumentRoot /var/www/html

                ErrorLog ${APACHE_LOG_DIR}/error.log
                CustomLog ${APACHE_LOG_DIR}/access.log combined

                SSLEngine on
                SSLCertificateFile      /etc/ssl/certs/ssl-cert-snakeoil.pem
                SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
                <FilesMatch "\.(cgi|shtml|phtml|php)$">
                                SSLOptions +StdEnvVars
                </FilesMatch>
                <Directory /usr/lib/cgi-bin>
                                SSLOptions +StdEnvVars
                </Directory>

                ProxyRequests Off
                SSLProxyEngine On
                <Proxy *>
                        Order deny,allow
                        Allow from all
                </Proxy>
                ProxyPass / http://localhost:9876/
                ProxyPassReverse / http://localhost:9876/
                <Location />
                        ProxyPassReverse /
                        Order deny,allow
                        Allow from all     
                </Location>
                Header edit Location ^http://localhost:9876/ https://localhost:9877/
        </VirtualHost>
</IfModule>
  1. Override the CrossSiteIframeLinker
package com.google.gwt.core.linker;

import com.google.gwt.core.ext.LinkerContext;

public class HttpsCrossSiteIFrameLinker extends CrossSiteIframeLinker {
    @Override
    protected String getJsDevModeRedirectHookPermitted(LinkerContext context) {
        return "$wnd.location.protocol == \"http:\" || $wnd.location.protocol == \"file:\" "
                + "|| $wnd.location.protocol == \"https:\"";
    }
}
  1. Add this to you *.gwt.xml
<set-configuration-property name="devModeUrlWhitelistRegexp"
        value="http(s)?://(localhost|127\.0\.0\.1)(:\d+)?/.*"/>
<define-linker name="xsiframe"
        class="com.google.gwt.core.linker.HttpsCrossSiteIFrameLinker"/>
  1. Edit and change the compile bookmarklet from http://localhost:9876 to https://localhost:9877 or edit the bookmarklet accordingly to auto sense the protocol. The provided bookmarklet also compiles the first GWT module it founds. This works great as long you have several projects with one GWT module in each one. If you have multiple GWT modules per project you will need to resort to the official bookmarklet which hardwires the module name.
javascript:{
        var moduleIndex=0;
        var index = 0;
        var module_name;
        for (var key in __gwt_activeModules) {
                if (__gwt_activeModules.hasOwnProperty(key))
                        if (index === moduleIndex) {
                                module_name = key;
                                break;
                        }
                index++;
        }
        var https = window.location.protocol === 'https:';
        var server_url = (https) ? 'https://localhost:9877/' : 'http://localhost:9876/';
        window.__gwt_bookmarklet_params = {server_url:server_url, module_name:module_name};
        var s = document.createElement('script');
        s.src = server_url + 'dev_mode_on.js';
        void(document.getElementsByTagName('head')[0].appendChild(s));
}

In order to encode it you can use an on-line service such as

  1. Redeploy – and start compiling GWT scripts deployed in https server pages.

Final Thoughts

GWT team could streamline SDM https support by teaching bookmarklets to set everything up such as:

  • Allow https by default (step: 4 & 5)
  • Autosense the protocol (http or https) and redirect to the SDM compiler accordingly requiring no manual edit of the bookmarklet (step: 6)

As a final note I would like to add that with bookmarklets it is possible to

  • deploy and debug (one click cycle) in the production site. This is invaluable when the GWT module is a CORS enabled web app acting as widget.
  • with the help of ssh tunnels and RDP allow to compile/debug in various systems and mobile browsers such as:
    • Mac OS X
    • iphone linked with Mac OS X
    • Windows all borwsers,
    • Android browser linked to Windows Chrome

However bookmarklets may be deprecated. Their successor may be the -launcherDir option and Thomas Broyer’s dev-server. It is not entirely clear which option or combination will prevail.

TrendChip firmware (ZTE-H108NS): Derived works

Apparently some people found these series of articles useful and decided to built upon. In this post I will list and update all these efforts that come to my attention.

At first was user stav that commented in this blog https://vasvir.wordpress.com/2015/04/16/trendchip-firmware-zte-h108ns-build-custom-software-add-namecheap-ddns-support/#comments

Recently another blog was created that employs tcrevenge to build custom firmware. Check it out here: http://wiki.ozo.com/doku.php?id=welcome#zte_zxhn_h108ns_unlocking_howto

APC Back-UPS RS 800 overload problem with no load: Solved

That is a quick and easy fix of a very common problem of APC Back-UPS series.

The problem is that the UPS overload red light is constantly turned on even with no load at all. A google search did not reveal any solution other than the board is faulty and there is nothing you can do about it.

I was handed this UPS and naturally I employed all my google foo in order to save a seemingly fine UPS. This time however the solution didn’t come from google but from youtube. If you are like me then you are totally against the wave of video tutorials that are flooding our everyday life. I prefer a text with properly defined steps than a 15′ video documenting a series of three clicks in order to access the desired submenu.

However in electronics repair hackery it actually makes some sense to present your work in a youtube video. I doubt if it faster this way but lots of people are actually posting very useful stuff there especially for obscure repairs such as this one.

I am writing the post because the solution is not in a youtube video but in a comment. If it was in the video or in the title then the solution will be findable by google. Instead the solution was in the comment section (yes I read youtube comments – can you imagine that?) in Spanish by Lujan Luis Giaccardi with the picture that shows the faulty capacitors red circled. Totally not findable. So I am posting it here for future reference.apc_rs_800

The comment translated in google translate says:

If you turn on the red light of “overload” you have to change the two electrolytes marked in the photo this:

The youtube video where you can find the original comment is https://www.youtube.com/watch?v=66oKHjCo5AA

Since I am not much of an expert in soldering and removing surface mount (SM) electrolytic capacitors I found (easily this time) another youtube video to figure how to get rid of them. Here it is:

 

I changed the faulty capacitors with normal capacitors and lo and behold! It worked!

Hope that helps.

ZTE-ZXHN-H208N: Empire strikes back

Hi everybody! It’s been a while.

Unfortunately this time around I have no clever hack nor good news.

About a year a go I decided to change my ISP following one with a much better offer. After signing the request for transfer I was presented the option to select modem for my new connection.

If you are change averse like me you can probably predict the dialog:

-ISP: So when do you want us to deliver the new modem?

-Me: Oh thank you very much but there is no need for that I have my hardware already setup properly

-ISP: Well you can do as you as wish but you have to know that your home phone will not work because we are switching you to VOIP and your modem does not have VOIP support.

-Me: So can I purchase a modem/router of my selection?

-ISP: Of course you can but standard of the shelf modem wil not be compatible with our VOIP service. Only __our__ equipment is compatible with __our__ VOIP service.

-Me: So it’s a trap!

-ISP: Pretty much yeah.. but at least you don’t have to pay for the trap^H^H^H^H modem.

Actually the last two lines never happened but you get the feeling.

So what was the actual modem delivered to me? You guessed it – or at least you pay attention to the titles of the articles you read. It was a ZTE-ZXHN-H208N an update of the venerable ZTE-H108NS. I thought that it was great – I could hack my way through a temporary obstacle. Just a setback that it would lead to an more enjoyable blog series. Unfortunately it didn’t pan out.

The modem as it was delivered from the new ISP was already pre-configured and locked down.

  • No admin account
  • No capability to save/restore firmware
  • No capability to save/restore settings
  • TR069 already enabled – the modem was controlled by my ISP for all intents and purposes.

Furthermore the official link I posted above advertises DLNA capabilities but the damn thing didn’t even have a USB port. From where it would serve multimedia content beats me.

screenshot_20170102_154928 zte_zxhn_h208n_01

That was the final straw for me. I went and bought a linksys1200ac router and installed openwrt on it. Never looked back and never felt any regret for this decision but this is a topic for another post.

After buying the linksys router a new saga started. Due to modem firmware bugs and incompetence of the (always polite) ISP personnel it was impossible to set the modem in bridge mode or survive a reboot with it enabled. The modem was (still is) in full lock down and it was impossible for me to set the bridge mode. After several attempts, firmware upgrades and unit exchanges finally the modem actually started behave as a bridge. Here are some screenshots so people can be prepared for similar issues from that ISP or this modem.

h208n-bridge-problem-firmware h208n-bridge-problem-error

TrendChip firmware (ZTE-H108NS): Update to handle newer firmware

This is the fourth article in a series of articles documenting the reverse engineering of the TrendChip firmware image and the disassembly of its CRC checksum algorithm.

A small update for the newer firmware (1.17 as distributed by OTE).

tcrevenge was not working with the latest firmware because the version number of the firmware (called surprisingly model number in tcrevenge) was hard coded. Initial tests have been done with firmware 1.07 (model number: 3 6035 122 74) while the 1.17 firmware has model number: 3 6035 122 89.

Newest firmware do not allow older firmware to be uploaded so this was a major problem. Thanks to the efforts of user stav it was possible to identify the problem and add a command line option in tcrevenge to manually set the model number. Now when running tcrevenge in check mode it reads:

Manual check (all tests have been done with model 3) Model: 3 6035 122 74 found 3 6035 122 79. If they differ use -m to adjust.

While I was at it I also added a command line argument for the field called firmware_version. Despite the classy name, looks like it is used only for printing and the firmware does not actually run any checks against it.

With these changes in place there are two variables left in the header section that we don’t know how they are used.

  • magic_number with value 0x32524448
  • magic_device with value 0x100 // this is probably the header size

if the need arises I will add a way to set them from the command line too – but it looks that some disassembly is required first.

The modifications are committed and pushed in the repository so you are ready to roll.

Looks like that version 1.17 as distributed by OTE has disabled the telnet functionality. Again read the comments of user stav how to solve this and how to get rid of the TR69 and CWMP functionality.

TrendChip firmware (ZTE-H108NS): Build custom software – add namecheap DDNS support

This is the third article in a series of articles documenting the reverse engineering of the TrendChip firmware image and the disassembly of its CRC checksum algorithm.

In this installment we will see how it is possible to create custom software that will run on your modem router. The task at hand is to modify the ez-ipupdate software so it can handle namecheap’s DDNS protocol. Let’s see first how we can build custom software (hello_world.c – How original!), and then we will take a look at the namecheap’s DDNS protocol and finally we will modify the ez-ipupdate. Sounds like a plan, isn’t it?

What could possibly go wrong?
Petrified - Tinos. Photo by Christos AndronisPhoto by Christos Andronis.

Building software for TrendChip firmware

Generally there are two ways to build software for a foreign architecture.

  1. Cross compile (in the host machine)
  2. Build in place (in the target machine)

Cross compiling means that after setting the cross compiler we will need to cross compile the target system’s libc. In this case the target’s libc is uClibc version 0.9.30. Debian’s support for cross architectures reaches its limit in this one. There is a package named gcc-mips-linux-gnu that provides MIPS compiler with GNU libc (glibc). So I assume there is room for fame and glory for somebody to provide gcc-mips-linux-uclibc packages for Debian. I am father of two,the time is limited, the clock is ticking and surprisingly I don’t feel the urge to do the famous 3 stage bootstrap of gcc. Maybe it’s just me getting older.

What about the other option – building in place?

The problem in the second option is that the modem is not equipped neither with a compiler nor the development headers of a libc. The space required for this machinery is very big compared with the 23M that the uncompressed squashfs has.

So what’s left? Google I suppose and lo and behold – I found it. The uClibc project builds system images for all uClibc versions. You can boot the system image with qemu like this

system-image-mips$ ./run-emulator.sh 
Linux version 2.6.25.10 (landley@driftwood) (libc/sysdeps/linux/mips/crt1.S:(.text+0x1c): undefined reference to `main') #1 SMP Sun Nov 23 06:55:47 CST 2008

LINUX started...
Overriding previous set SMP ops
console [early0] enabled
CPU revision is: 00019300 (MIPS 24K)
FPU revision is: 00739300
registering PCI controller with io_map_base unset
Determined physical RAM map:
 memory: 00001000 @ 00000000 (reserved)
 memory: 000ef000 @ 00001000 (ROM data)
 memory: 0025a000 @ 000f0000 (reserved)
 memory: 07cb5000 @ 0034a000 (usable)
Wasting 26944 bytes for tracking 842 unused pages
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->    32767
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->    32767
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
Kernel command line: root=/dev/hda console=ttyS0 rw init=/usr/bin/qemu-setup.sh panic=1 PATH=/usr/bin 
Primary instruction cache 2kB, VIPT, 2-way, linesize 16 bytes.
Primary data cache 2kB, 2-way, VIPT, no aliases, linesize 16 bytes
Synthesized clear page handler (26 instructions).
Synthesized copy page handler (46 instructions).
Cache parity protection disabled
PID hash table entries: 512 (order: 9, 2048 bytes)
CPU frequency 200.00 MHz
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 126396k/127700k available (1843k kernel code, 1140k reserved, 263k data, 136k init, 0k highmem)
Mount-cache hash table entries: 512
Trying to install interrupt handler for IRQ16
Trying to install interrupt handler for IRQ17
Brought up 1 CPUs
net_namespace: 160 bytes
NET: Registered protocol family 16
pci 0000:00:0a.3: quirk: region 1100-110f claimed by PIIX4 SMB
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
io scheduler noop registered (default)
rtc: SRM (post-2000) epoch (2000) detected
Real Time Clock Driver v1.12ac
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250.2: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
console handover: boot [early0] -> real [ttyS0]
serial8250.2: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
loop: module loaded
pcnet32.c:v1.34 14.Aug.2007 tsbogend@alpha.franken.de
PCI: Enabling device 0000:00:0b.0 (0000 -> 0003)
pcnet32: PCnet/PCI II 79C970A at 0x1020, 52:54:00:12:34:56 assigned IRQ 10.
eth0: registered as PCnet/PCI II 79C970A
pcnet32: 1 cards_found.
Uniform Multi-Platform E-IDE driver
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hda: QEMU HARDDISK, ATA DISK drive
hdc: QEMU DVD-ROM, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 512KiB
hda: 4194304 sectors (2147 MB) w/256KiB Cache, CHS=4161/255/63
hda: cache flushes supported
 hda: unknown partition table
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Freeing prom memory: 956k freed
Freeing unused kernel memory: 136k freed
eth0: link up
Type exit when done.
/ #

 

The system image provides gcc-4.1.2 while the binaries in the modem are built with gcc-3.4.6 (at least the kernel). Let’s hope that the backward compatibility would be good enough in order to build things in the system-image and then copy them in the squashfs filesystem of the modem.

FileSystem woes

Before we continue we need to adjust the environment to our development cycle. The uclibc provided system image is 64MB (around 50MB root filesystem). It has vi and gcc and make but nothing more. It would be nice if we could mount some host’s exported directories in order to:

  • have available more space for the software builds
  • use host based editors and file managers

The combination of qemu and linux provides 3 ways to mount host’s provided directories. For more information and the gory details check this article by Rob Landley and Mark Miller especially this part.

  1. NFS
  2. SAMBA (private samba server runs by qemu with -smb option)
  3. FAT image

Any of them should work in theory but you should know the drill by now. It took me two weeks to accept the bitter truth of failure. The reason of the failure was that the uclibc provided kernel has no support for modules and no support for NFS, SMB and FAT filesystems. It took me a week and several network dumps from wireshark to figure out that the dreaded 111 mount returned error means the kernel has no support for NFS. It took me one more week to accept the fact that I can’t build a kernel for MIPS because:

  • buildroot of the time fails when it’s trying to build the kernel in a modern system
  • cross compiling a MIPS kernel on a recent Debian gives many errors on older kernels and a fatal one in the latest. In any case I cannot find the zImage target in the generated Makefiles.

So what is left? I resized the rootfs image to 2GB and mount it with the loop device. Of course concurrent access via the host and the emulated guest is not allowed so you have to be careful and run qemu / mount / unmount / run qemu again all the time.

Here is how to resize a filesystem image:

#dd if=/dev/zero of=disk.img bs=1M count=1024 oflag=append conv=notrunc
#e2fsck -f disk.img
#resize2fs disk.img

and here is how to mount / unmount between qemu invocations

#mount -o loop ./uclibc/0.9.30/system-image-mips/image-mips.ext2 /mnt/
#umount ./uclibc/0.9.30/system-image-mips/image-mips.ext2

ez-ipupdate invocation

The first step is to establish the beachhead. We make sure that hello world works. Indeed although the compiler is different – compiling in the guest system is good enough for the hello world to run in the modem just by copying the executable around (and rebuilding the firmware with tcrevenge).

The ez-ipupdate is free software hosted on sourceforge. It is written in C so in theory a modification like this is relatively easy. The namecheap’s DDNS protocol is not exactly rocket science to get right. So let’s see what the TrendChip firmware is doing and how it invokes the ez-ipupdate.

There is the file /etc/ddns.conf which looks like a direct dump of what is stored in the XML romfile. Probably cfg_manager dumps it in that form so subsequent scripts can operate on this data more easily.

# cat /etc/ddns.conf 
Active="Yes"
SERVERNAME="www.dyndns.org"
MYHOST="myhost.mydomain.noip"
USERNAME="username"   # It is literally username as it not prefixed with my (as in myusername)
PASSWORD="mypassword"
WILDCARD="No"

Then there is /etc/ipupdate.conf

# cat /etc/ipupdate.conf 
user=username:mypassword
host=myhost.mydomain.noip
service-type=dyndns
max-interval=2073600

which is what will be feed to the ez-ipupdate executable.

There are two scripts. The usr/script/ddns.sh converts the /etc/ddns.conf to the /etc/ipupdate.conf. The other one (/usr/scripts/ddns_run.sh) runs the ez-ipupdate with the /etc/ipupdate.conf as configuration parameter.

Namecheap’s DDNS protocol

It’s not really a protocol. It’s a http GET with certain parameters to the namecheap’s server. Here is how you can update your PC’s DNS manually with curl.

$curl https://dynamicdns.park-your-domain.com/update?host=myhost&domain=mydomain.com&password=mypassword&ip=myip

The only tricky part left is to parse the variables in the configuration file and assemble the GET request.

Finally: Compiling custom software – ez-ipupdate

The following patch implements namecheap support at expense of dyndns support. The potential users of this hack must use the configuration entries of the WEB GUI to fill the proper information in the dyndns section. The TrendChip firmware will use the hostname and password but it will connect to the namecheap’s servers instead.

diff -ur ez-ipupdate-3.0.11b7.orig/ez-ipupdate.c ez-ipupdate-3.0.11b7/ez-ipupdate.c
--- ez-ipupdate-3.0.11b7.orig/ez-ipupdate.c     2002-03-12 01:31:47.000000000 +0200
+++ ez-ipupdate-3.0.11b7/ez-ipupdate.c  2015-03-01 20:35:57.981976162 +0200
@@ -56,9 +56,9 @@
 #define DHS_REQUEST "/nic/hosts"
 #define DHS_SUCKY_TIMEOUT 60
 
-#define DYNDNS_DEFAULT_SERVER "members.dyndns.org"
+#define DYNDNS_DEFAULT_SERVER "dynamicdns.park-your-domain.com"
 #define DYNDNS_DEFAULT_PORT "80"
-#define DYNDNS_REQUEST "/nic/update"
+#define DYNDNS_REQUEST "/update"
 #define DYNDNS_STAT_REQUEST "/nic/update"
 #define DYNDNS_MAX_INTERVAL (25*24*3600)
 
@@ -1919,11 +1919,20 @@
     output(buf);
   }
 
-  snprintf(buf, BUFFER_SIZE, "%s=%s&", "hostname", host);
+  char *dot = strchr(host, '.');
+  *dot = 0;
+  char *domain = dot + 1;
+  
+  snprintf(buf, BUFFER_SIZE, "%s=%s&", "host", host);
+  output(buf);
+  snprintf(buf, BUFFER_SIZE, "%s=%s&", "domain", domain);
+  output(buf);
+  snprintf(buf, BUFFER_SIZE, "%s=%s&", "password", password);
   output(buf);
+    
   if(address != NULL)

One more note: The size of the final ez-update was 122624 bytes while the original was only 84720 bytes. Could it be the compiler? I tried with -Os and stripped all symbols. My guess for this sudden file increase is that ez-ipupdate has support for many DDNS protocols that are not listed in the web GUI of the Trendchip firmware. It is possible therefore that they had stripped the support of the missing protocols from the ez-ipupdate in order to save space.

After patching and moving the ez-ipupdate sources to the guest system the usual procedure of

$./configure
$make

can be used to build the software for MIPS. Copy the resulting executable to the expanded squashfs, create squashfs image, rebuild the firmware and upload it to the modem and you are ready.

Hope it was fun. Now off you go to build minidlna in order to enable streaming from your modem router.