Firmware with newest hardware driver BLOB

Earlier we dynamically swapped out the hardware driver BLOB of the HG612 [1].    We tested a new BLOB using an ADSL2+ line and found little to no performance gain between the two BLOBs.

Today, however, we tested again, using firmware built by Hungarian hacker, Csaba Sipos.

This time we tested the latest BLOBs with VDSL2 Annex A and Annex B.

The testing equipment was a Huawei HG612 Revision 3B and a Huawei MA5616 DSLAM with V800R310C00 firmware. [2] The linecard was a H835VDSH 24-port VDSL2 card, with all but one subscriber port deactivated (i.e. no issues of crosstalk.)

The Central Office DSLAM equipment was configured for the G.993.2 Profile 17a.

The VDSL2 PSD class mask was Annex B Plan 998 ADE17-M2x-A (Band Plan B8-11). That is the class mask specified in BT SIN 498 Iss. 4.3 (Jan. 2013).   See. [3]

Upstream band US0 was utilised dynamically.  

In contrast to earlier tests, the subscriber port was de-activated between each test allowing the linecard chipset to be reset:

MA5616(config-if-vdsl-0/4)#deactivate 0

MA5616(config-if-vdsl-0/4)#chipset reset 0
  Note: Please don't operating on port while chipset resetting,
        are you sure to continue? (y/n)[n]:y

MA5616(config-if-vdsl-0/4)#activate 0 template-index 2

The findings are as follows:

Under controlled conditions with no line noise and measured levels of line attenuation, the newest CPE hardware BLOB (A2pv6C035m.d22g) consistently outperforms the original BLOB (A2pv6C030b.d22g).

A third VDSL2 modem, the ECI Arcadyan VG3503J Revision /r, was used as a control.

Screenshot from 2013-03-26 15:38:45

The newer BLOB achieves maximum attainable rates which are statistically higher than the rates obtained with the original BLOB.

graph

 

An (updated) firmware image for the HG612, containing the newest hardware driver BLOB (A2pv6C035m) can be obtained from [4].

Flashing the modem with this new firmware image involves the same procedure as documented earlier. [5]

[1] http://huaweihg612hacking.wordpress.com/2012/11/11/dynamically-swapping-out-the-hardware-driver-blob/
[2] http://insidehuaweima5616msan.wordpress.com/
[3] http://www1.btwebworld.com/sinet/sinlist1.htm
[4] http://docs.google.com/folder/d/0B6wW18mYskvBNWZLWVNXWmUtME0/edit
[5] http://huaweihg612hacking.files.wordpress.com/2011/11/hg612_unlock_instructions_v1-3.pdf

Charity Auction of Huawei HG622 – VDSL2 modem router with 4 ethernet, 802.11n wifi and USB

Here is another batch of modem-routers to be sold 100% in aid of charity, the Dogs Trust.

The Dogs Trust has a strict policy: “We never destroy a healthy dog.

These unlocked devices are compatible with the BT Openreach FTTC services in Britain.

The modems are unused – originally intended for ChinaTel – but are unlocked now for BT and other providers.

The HG622 is based on the Broadcom BCM6368 System-on-Chip. So DSL performance should be the same or similar to the Openreach HG612 which is powered by the 6368, too.

However, the HG622 also has four ethernet (10/100) ports instead of just two, a USB host port and also 802.11n wi-fi (up to 300Mbps).

Below are some photos of the Huawei HG622:

Interested?

The ebay charity sale is here: http://www.ebay.co.uk/itm/130840515303

SORRY SOLD OUT!

Re-listed: http://www.ebay.co.uk/itm/130897747759

SORRY SOLD OUT!

Image Hosted by PicturePush
Image Hosted by PicturePush
Image Hosted by PicturePush
Image Hosted by PicturePush
Image Hosted by PicturePush
Image Hosted by PicturePush
Image Hosted by PicturePush
Image Hosted by PicturePush
Image Hosted by PicturePush
Image Hosted by PicturePush
(Laboratory conditions!)

More screenshots here:

http://asbokid.picturepush.com/slideshow?alid=241207&format=1024

EDIT1:

A total of £920 has so far been raised through ebay for the Dogs Trust from the sale of these two models of Huawei modem.

Thank you everyone!    Hopefully we can soon make £1,000!

 Screenshot from 2013-02-22 02:12:50

Screenshot from 2013-02-22 02:13:23

EDIT2:

Thanks also to Gary Coughlan of British Columbia and Andy Potter of Lanarkshire who made their own personal donations to the Dogs Trust.

Dynamically swapping-out the hardware driver blob

In the firmware of most xDSL modems is a large program file called a hardware driver BLOB (Binary Large OBject). Many hundreds of kilobytes in size, it contains the digital signal processing software. This software manages the xDSL hardware: the modem transceiver, comprising the analog frontend and the line driver.

The Huawei hardware driver blob is a proprietary piece of Broadcom software. There is no publicly available source code. The Broadcom BCM6368 microprocessor in the Huawei has two cores. And the blob is loaded by the control (Linux) core into the shared address space of the second core of the BCM6368. The second core then executes that code, to control the DSL line driver. And some form of inter-process messaging takes place between the two cores.

We can swap out that hardware blob for another blob version. We have already extracted a newer blob version from the Netgear DGND3700, a device running on the same 6368 platform as the Huawei. [1]

That newer driver blob can be downloaded to the Huawei by one of at least four methods: ftp, tftp, http, or the telnet upload trick.

The simplest of those four methods is tftp, the (trivial) file transfer protocol. By default tftpd, the tftp daemon (i.e. the server) uses no authentication.

In debian and ubuntu there are several flavours of tftpd, the simplest being tftp-hpa. [3] It is an extension of the openBSD tftpd. A one-liner installs and configures it:

$ sudo apt-get install tftpd-hpa

From ps we can see (at least on this box) that files hosted by tftpd are stored under /srv/tftp:

$ ps auxw | grep [t]ftpd
root     19331  0.0  0.0  14844   324 ?        Ss   16:29   0:00
/usr/sbin/in.tftpd --listen --user tftp --address 0.0.0.0:69 --secure /srv/tftp

And that is where we will place our new driver blob, ready to upload to the HG612:

$ ls -l /srv/tftp/
total 828
-rw-r--r-- 1 root root 846560 Nov 11 17:29 adsl_phy.A2pv6C035m.bin

Now we log into the Huawei from the PC:

$ telnet 192.168.1.2

Welcome Visiting Huawei  Home Gateway
Copyright by Huawei Technologies Co., Ltd.
Login:admin
Password:admin
ATP>sh

BusyBox v1.9.1 (2010-10-15 17:59:06 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

The contents of read-only /etc are copied into /tmp

# cp -ar /etc /tmp

The original xDSL driver is renamed to preserve it from over-writing during our tests:

# cd /tmp/etc/adsl
# mv adsl_phy.bin adsl_phy.A2pv6C030b.bin

Now we retrieve the newer xDSL driver blob from the tftpd server on the PC:

# tftp -g -r adsl_phy.A2pv6C035m.bin 192.168.1.3    #  (adjust for your PC's IP address)

We now have two driver blobs in /tmp/etc/adsl, one old, one new:

# ls -l /tmp/etc/adsl/
-rw-rw-r--    1 0        0          813980 adsl_phy.A2pv6C030b.bin
-rw-r--r--    1 0        0          846560 adsl_phy.A2pv6C035m.bin

We create a symlink to the newer blob, ready for its loading:

# ln -sfn adsl_phy.A2pv6C035m.bin adsl_phy.bin

Now the /tmp mountpoint is mounted over the top of the (read-only) /etc mountpoint:

# mount -o bind /tmp/etc /etc

Here we see that original hardware driver is still running (A2pv6C030b.d22g):

# xdslcmd --version
xdslcmd version 1.0
DSL PHY: AnnexA version - A2pv6C030b.d22g
******* Pass *********
# 

Old hardware driver blob still running

And here is the current performance of that original driver on this 1000 metre ADSL2+ line:

# xdslcmd info --state
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason:	8000
Max:	Upstream rate = 1184 Kbps, Downstream rate = 19488 Kbps
Path:	0, Upstream rate = 1020 Kbps, Downstream rate = 17659 Kbps

# 

Now the xdsl driver is stopped and re-started, causing the (symlinked) new blob (A2pv6C035m) to be loaded and executed by the second core:

# xdslcmd stop

# xdslcmd start --up
xdslCtl_GetVersion success

We can confirm that the new driver blob has been loaded:

# xdslcmd --version
xdslcmd version 1.0
DSL PHY: AnnexA version - A2pv6C035m.d22g
******* Pass *********
#

New hardware driver blob now running

And… drum roll………..

# xdslcmd info --state
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason:	8000
Max:	Upstream rate = 1248 Kbps, Downstream rate = 19540 Kbps
Path:	0, Upstream rate = 1020 Kbps, Downstream rate = 17585 Kbps

#

The new blob has essentially the same performance as the old one!

But maybe if we down-tweak the target SNR margin (TSNRM) it might hold on at a higher sync rate than the older blob:

Benchmarking first that newer blob with a lower TSNRM:

# xdslcmd start --snr 25

# xdslcmd info --state
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason:	8000
Max:	Upstream rate = 1244 Kbps, Downstream rate = 22308 Kbps
Path:	0, Upstream rate = 1020 Kbps, Downstream rate = 20474 Kbps

#

Now if we swap back to the old driver blob (A2pv6C030b) we can compare that driver to see how it also performs at 25% of the target SNRM (6.0dB):

# ln -sfn /etc/adsl/adsl_phy.A2pv6C030b.bin adsl_phy.bin

# xdslcmd stop

# xdslcmd start --up --snr 25
xdslCtl_GetVersion success

# xdslcmd --version
xdslcmd version 1.0
DSL PHY: AnnexA version - A2pv6C030b.d22g
******* Pass *********
# 

And for the performance comparison, we find:

# xdslcmd info --state
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason:	8000
Max:	Upstream rate = 1184 Kbps, Downstream rate = 22296 Kbps
Path:	0, Upstream rate = 1020 Kbps, Downstream rate = 20502 Kbps

#

EDIT: after running a few more tests, the new driver does appear to have almost identical performance to the original driver!

However, nothing should be read into these tests since they are anything but scientific. Ideally Dynamic Line Management at the DSLAM would be disabled, and line noise and attenuation would be closely controlled under laboratory conditions.

The blob-swapping measures documented above are, fortunately, transient. When the router is rebooted, everything goes back to its original state.

If, however, it was decided to permanently swap-out the driver blob for a different one, that would involve re-making a squashfs root file system, and re-building the entire firmware complete with the kernel image, before flashing in the whole she-bang.

All the tools to perform that permanent change, including a script for automation, are found here [3]

[1] http://huaweihg612hacking.wordpress.com/2012/11/03/updating-the-dsl-hardware-driver-blob/
[2] http://www.kernel.org/pub/software/network/tftp/
[3] http://docs.google.com/folder/d/0B6wW18mYskvBNWJhNmFkYTgtZmE0M…

This entry was posted on November 11, 2012. 9 Comments

JTAG’ing the Broadcom BCM6368 (HG612)

JTAG connection to a BCM6368 board

It is sometimes useful to re-write the bootloader on the HG612 and other devices based on the BCM6368 System on Chip. With a corrupted or missing bootloader, JTAG’ing the device can be the last resort for recovering it from a bricked state.

JTAG is an acronym for Joint Test Action Group. It is a serial wire protocol dedicated to testing and recovering embedded hardware. It is a specialism of the synchronous four wire Serial Peripheral Interface (SPI).

JTAG has a (slow) line clock (TCK), separate data in (TDI) and data out (TDO) lines, and a “test mode select” (TMS) line for controlling the state of the JTAG engine. TDI and TMS are clocked-in on the rising edge of TCK, and TDO is clocked out on its falling edge. Sometimes there is also a test reset line (TRST).

To JTAG a device requires a JTAG cable. Though these days, the “cable” is usually a programmer with its own on-board logic. Chinese clones of the popular Altera USB-Blaster JTAG programmer are inexpensive, costing under CNY30 (£3) [1]

(Genuine) Altera USB Blaster JTAG programmer

With JTAG programming software running on the PC, the USB-Blaster works fine for recovering a bricked BCM6368 device, as illustrated below:

By far the best JTAG software available today is UrJTAG. [2] Open source, it is available for Linux, *BSD, MacOS, and even Microsoft Windows. UrJTAG is regularly maintained and extended to support new devices and platforms.

Connecting the USB Blaster to a PCB


For ease, we run UrJTAG as root:

$ sudo jtag

UrJTAG 0.10 #2007
Copyright (C) 2002, 2003 ETC s.r.o.
Copyright (C) 2007, 2008, 2009 Kolja Waschk and the respective authors

warning: UrJTAG may damage your hardware!
Type "quit" to exit, "help" for help.

The software is connected to a USB-Blaster cable, a JTAG programmer based on the FT23xx, a USB-UART bridge IC:

jtag> cable usbblaster
Connected to libftdi driver.

Big endian byte order is selected:

jtag> endian big

Detect parts on the JTAG chain:

jtag> detect
IR length: 5
Chain length: 1
Device Id: not supported (bit 0 was not a 1)

^^ That’s a fail : ( ^^   UrJTAG failed to detect the JTAG parts on the board. And it’s not clear why.

Not to worry, we will manually discover the JTAG registers and instructions of the BCM6368 and then define them ourselves.

The discovery command in UrJTAG can help us with this.

From that discovery process, see below, a total of seven JTAG instructions are found. Each instruction is of five bits length, and there are seven corresponding data registers of various lengths.

Five of those data registers are 32 bits long, one is 96 bits (a concatenation of three 32 bit registers), and one has just one bit (the Bypass register):

jtag> discovery
Detecting IR length ... 5
Detecting DR length for IR 11111 ... 1
Detecting DR length for IR 00001 ... 32
Detecting DR length for IR 00011 ... 32
Detecting DR length for IR 01000 ... 32
Detecting DR length for IR 01001 ... 32
Detecting DR length for IR 01010 ... 32
Detecting DR length for IR 01011 ... 96

We know from the MIPS EJTAG specifications [3] what these instructions and registers are officially called, and what they are for. And so we can define them in UrJTAG:

jtag> register BR 1
jtag> register DIR 32
jtag> register EJIMPCODE 32
jtag> register EJADDRESS 32
jtag> register EJDATA 32
jtag> register EJCONTROL 32
jtag> register EJALL 96

jtag> instruction length 5
jtag> instruction BYPASS 11111 BR
jtag> instruction IDCODE 00001 DIR
jtag> instruction EJTAG_IMPCODE 00011 EJIMPCODE
jtag> instruction EJTAG_ADDRESS 01000 EJADDRESS
jtag> instruction EJTAG_DATA 01001 EJDATA
jtag> instruction EJTAG_CONTROL 01010 EJCONTROL
jtag> instruction EJTAG_ALL 01011 EJALL

The most reliable way to check that the JTAG chain is working correctly is to shift in the instruction for scanning out the device ID:

jtag> instruction IDCODE
jtag> shift ir
jtag> shift dr
jtag> dr
00000110001101101000000101111111 (0x0636817F)

And from a brief Google search, we find that 0x0636817F is indeed the JTAG Device ID for the BCM6368. Confirming that our JTAG programmer is connected okay, and the embedded JTAG engine is running correctly.

Now we want raw access to the onboard NOR flash IC on the PCB to reprogram it. For that, we must initialise the EJTAG bus driver. The EJTAG bus driver using DMA transfers won’t play ball with the BCM6368, so instead we use the legacy PrAcc bus driver:

jtag> initbus ejtag
ImpCode=00000000100000011000100100000100 00818904
EJTAG version: <= 2.0
EJTAG Implementation flags: R4k MIPS16 DMA MIPS32
Processor entered Debug Mode.

From the kernel boot logs for the HG612, we can see that the flash base is physically mapped to 0xb800,0000 in the 6368 memory map. Once the MIPS TLB (MMU) has stripped the top address bit, we will access the 8MByte NOR flash from virtual address space 0×3800,0000 to 0x387F,FFFF.

The detectflash tool of UrJTAG is used to probe the flash device:

jtag> detectflash 0x38000000
Query identification string:
	Primary Algorithm Command Set and Control Interface ID Code: 0x0002 (AMD/Fujitsu Standard Command Set)
	Alternate Algorithm Command Set and Control Interface ID Code: 0x0000 (null)
Query system interface information:
	Vcc Logic Supply Minimum Write/Erase or Write voltage: 2700 mV
	Vcc Logic Supply Maximum Write/Erase or Write voltage: 3600 mV
	Vpp [Programming] Supply Minimum Write/Erase voltage: 0 mV
	Vpp [Programming] Supply Maximum Write/Erase voltage: 0 mV
	Typical timeout per single byte/word program: 128 us
	Typical timeout for maximum-size multi-byte program: 128 us
	Typical timeout per individual block erase: 1024 ms
	Typical timeout for full chip erase: 0 ms
	Maximum timeout for byte/word program: 1024 us
	Maximum timeout for multi-byte program: 4096 us
	Maximum timeout per individual block erase: 16384 ms
	Maximum timeout for chip erase: 0 ms
Device geometry definition:
	Device Size: 8388608 B (8192 KiB, 8 MiB)
	Flash Device Interface Code description: 0x0002 (x8/x16)
	Maximum number of bytes in multi-byte program: 32
	Number of Erase Block Regions within device: 2
	Erase Block Region Information:
		Region 0:
			Erase Block Size: 65536 B (64 KiB)
			Number of Erase Blocks: 127
		Region 1:
			Erase Block Size: 8192 B (8 KiB)
			Number of Erase Blocks: 8
Primary Vendor-Specific Extended Query:
	Major version number: 1
	Minor version number: 3
	Address Sensitive Unlock: Required
	Process Technology: Bad value
	Erase Suspend: Read/write
	Sector Protect: 1 sectors per group
	Sector Temporary Unprotect: Supported
	Sector Protect/Unprotect Scheme: Bad value
	Simultaneous Operation: Not supported
	Burst Mode Type: Supported
	Page Mode Type: 8 word Page
	ACC (Acceleration) Supply Minimum: 11500 mV
	ACC (Acceleration) Supply Maximum: 12500 mV
	Top/Bottom Sector Flag: Top boot device
	Program Suspend: Not supported

Lastly, we can read and write the flash memory with commands readmem and flashmem. Below, the CFE bootloader is read from the first 64kByte of the NOR and written to a disk file on the PC:

jtag> readmem 0x38000000 0x10000 hg612_cfe.bin
address: 0x38000000
length:  0x00010000
reading:
addr: 0x38000000
addr: 0x38004000
addr: 0x38008000
addr: 0x3800C000
addr: 0x38010000
Done.

jtag> quit

We now check that the flash read has worked:

$ xxd hg612_cfe.bin
...
0000560: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000570: 6366 652d 7601 0025 6606 0000 0000 0000  cfe-v..%f.......
0000580: 0000 0005 653d 3139 322e 3136 382e 312e  ....e=192.168.1.
0000590: 313a 6666 6666 6666 3030 2068 3d31 3932  1:ffffff00 h=192
00005a0: 2e31 3638 2e31 2e31 3030 2067 3d20 723d  .168.1.100 g= r=
00005b0: 6620 663d 766d 6c69 6e75 7820 693d 6263  f f=vmlinux i=bc
00005c0: 6d39 3633 7878 5f66 735f 6b65 726e 656c  m963xx_fs_kernel
00005d0: 2064 3d33 2070 3d30 2000 0000 0000 0000   d=3 p=0 .......
00005e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00005f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000600: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000610: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000620: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000630: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000640: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000650: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000660: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000670: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000680: 0000 0000 3936 3336 384d 5657 4700 0000  ....96368MVWG...
...

And there in our JTAG dump is the CFE bootloader. In the excerpt above, we can see the parameters to the CFE, and the Broadcom board reference number for the Huawei (96368MVWG). So it worked – we successfully read the 64kByte bootloader via JTAG.

Flashing in a new bootloader is a similar task, but using the flashmem command of UrJTAG.

JTAG is a very slow protocol. The USB-Blaster is one of the better programmers but reading that 64KByte bootloader still took nearly nine minutes. Reading the whole 8MByte flash by JTAG would take 19 hours! And writing is even slower!

So when a device is bricked, normally JTAG is a last resort. Only used when the bootloader is damaged and needs re-flashing. The rest of the firmware is transferred by a faster mechanism – either by the UART, or by ethernet.

EDIT:

Pinouts for the USB-Blaster, courtesy of Gerry O’Brien are here [4] and tips for finding JTAG pins on an undocumented board are here [5].

[1] http://item.taobao.com/item.htm?id=5543022160
[2] http://www.urjtag.org/
[3] https://docs.google.com/folder/d/0B6wW18mYskvBMDNmMjE5MTMtYjhmMS00YTcxLWIwOTAtMjM2M2Y4NTYxYzlm/edit
[4] http://hackingbtbusinesshub.wordpress.com/2011/09/12/usb-blaster-plug-connection/
[5] http://hackingbtbusinesshub.wordpress.com/2012/01/26/discovering-jtag-pinouts/

This entry was posted on November 7, 2012. 3 Comments

Spoofing the MAC address

It’s not normally necessary, but the MAC (ethernet or hardware) addresses on the HG612 and most other Broadcom 63xx devices can be changed or “spoofed”. A tool in the Huawei firmware called equipcmd is used to do it.

There’s a lot of illicit interest in this in south-east Asia where WiMAX is a popular alternative to xDSL because of its low rollout cost. WiMAX uses the MAC for AAA (authentication, authorisation and accounting).

So if the MAC can be spoofed then the end user can free-load the internet on someone else’s WiMAX account. That’s the idea, any way! The modem makers and the WiMAX carriers are perpetually playing whac-a-mole to stamp out the activity. For some reason, WiMAX hasn’t caught on in the UK, so it’s not a problem here any way.

As for spoofing the MAC(s) on the HG612..

$ telnet 192.168.1.1

Welcome Visiting Huawei  Home Gateway
Copyright by Huawei Technologies Co., Ltd.
Login:admin
Password:admin
ATP>sh

BusyBox v1.9.1 (2010-10-15 17:59:06 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# equipcmd macaddr display
display macaddr B482FEB7917E    <---- that's the base MAC ending ..91:7e
success
#

 

# ifconfig
    atm1      Link encap:Ethernet  HWaddr B4:82:FE:B7:91:7F    <--- 2nd MAC addr
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:2834997 errors:7 dropped:0 overruns:0 frame:0
              TX packets:1802091 errors:720 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:3634140922 (3.3 GiB)  TX bytes:312427091 (297.9 MiB)

    br0       Link encap:Ethernet  HWaddr B4:82:FE:B7:91:7E    <--- base MAC addr
              inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:1804183 errors:0 dropped:0 overruns:0 frame:0
              TX packets:2832405 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:0
              RX bytes:304213416 (290.1 MiB)  TX bytes:3669797668 (3.4 GiB)

    ptm1      Link encap:Ethernet  HWaddr B4:82:FE:B7:91:80    <--- 3rd MAC addr
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:0 errors:733 dropped:0 overruns:0 frame:0
              TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

We change the MAC address:

    # equipcmd setmacaddr 505152535455
    set macaddr success#

    # equipcmd macaddr display
    display macaddr 505152535455  <---- our new base MAC addr ending ..54:55
    success
    #

Reboot the device:

    # reboot
    Connection closed by foreign host.

    $
    $ telnet 192.168.1.1

    Welcome Visiting Huawei  Home Gateway
    Copyright by Huawei Technologies Co., Ltd.

    Login:admin
    Password:admin
    ATP>sh

And we can see it’s now using the new MAC(s)..

    # ifconfig
    atm1      Link encap:Ethernet  HWaddr 50:51:52:53:54:56    <--- new 2nd MAC addr
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:0 errors:0 dropped:0 overruns:0 frame:0
              TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

    br0       Link encap:Ethernet  HWaddr 50:51:52:53:54:55    <--- new base MAC addr
              inet addr:192.168.1.50  Bcast:192.168.1.255  Mask:255.255.255.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:163 errors:0 dropped:0 overruns:0 frame:0
              TX packets:144 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:0
              RX bytes:16405 (16.0 KiB)  TX bytes:48377 (47.2 KiB)

    ptm1      Link encap:Ethernet  HWaddr 50:51:52:53:54:57    <--- new 3rd MAC addr
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:0 errors:0 dropped:0 overruns:0 frame:0
              TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

There’s a bit more about the equipcmd tool here [1]. Plus a few hidden commands. Not sure what they all do, so use with care!

[1] http://huaweihg612hacking.wordpress.com/2011/07/17/the-atp-cli-and-equipcmd/

This entry was posted on November 4, 2012. 1 Comment

Updating the DSL hardware driver blob

The following info was posted earlier to the popular ThinkBroadband forums:

Hacker Csaba Sipos from Hungary has discovered a slightly newer DSL driver blob for the BCM6368. The BCM6368 is the Broadcom System-on-Chip that powers the HG612 and a good many other VDSL2 CPE.

It seems that the DSL driver version currently shipped in the HG612 firmware is A2pv6C030b.d22g:

# xdslcmd --version
xdslcmd version 1.0
DSL PHY: AnnexA version - A2pv6C030b.d22g
******* Pass *********

However, Actiontec, a N.American CPE supplier, has included a slightly newer driver version in a GPL’ed source code tarball for its 6368-based devices [1]. That driver version is A2pv6C035f.d22g

# xdslcmd --version
xdslcmd version 1.0
DSL PHY: AnnexA version - A2pv6C035f.d22g
******* Pass *********

It looks like a very minor driver revision, but it might just squeeze a couple more bits per hour!

Anyone interested in giving it a whirl?! Csaba has already built some new firmware with the newer driver, if anyone wants to contact him to try it out?

EDIT1:

Over on the Netgear forums, [2] ARobertson676, Gigio755 and Scubbie have spotted even newer DSL drivers in the beta firmware for the Netgear DGND3700. The latest version with build date 03/06/2012  being A2pv6C035m.d23k

The Netgear firmware seems to have a header on its header, but thankfully the firmware-mod-kit can still extract its components, including the driver blob.  The amazing kit was developed by Craig Heffner, Jeremy Collake, Matthias Bucher and others.  [3]

$ wget http://www3.zshare.ma/files/3/82vk2ocjmhtgmi/DGND3700-V1.0.0.20_1.0.20_Static_PPA.chk

$ svn co http://firmware-mod-kit.googlecode.com/svn/ firmware-mod-kit-read-only

$ cd firmware-mod-kit-read-only/trunk

$ ./extract-ng.sh ~/DGND3700-V1.0.0.20_1.0.20_Static_PPA.chk
Firmware Mod Kit (build-ng) 0.78 beta, (c)2011-2012 Craig Heffner, Jeremy Collake  -- http://www.bitsum.com

Scanning firmware...

DECIMAL   	HEX       	DESCRIPTION
-------------------------------------------------------------
143       	0xFFFFFFFE	(null)

Extracting 321 bytes of  header image at offset 0
Extracting squashfs file system at offset 321
Extracting 160 byte footer from offset 8230091
Extracting squashfs files...
Firmware extraction successful!
Firmware parts can be found in 'fmk/*'

$ ls -l fmk/rootfs/etc/adsl/
total 828
-rw-rw-r-- 1 root root 846560 May 12 01:31 adsl_phy.bin

$ strings -n10 fmk/rootfs/etc/adsl/adsl_phy.bin  | grep -A1 A2pv6

Broadcom DSL Version A2pv6C035m
Built on 03/06/2012 17:48:07

EDIT2:  See second part of this blog series [4]

[1] http://peterkieser.com/2011/09/24/actiontec-releases-removed-from-open-source-download-area/

[2] http://forum1.netgear.com/showthread.php?t=76204

[3] http://code.google.com/p/firmware-mod-kit/

[4] http://huaweihg612hacking.wordpress.com/2012/11/11/dynamically-swapping-out-the-hardware-driver-blob/

This entry was posted on November 3, 2012. 6 Comments