[Frage] 6490 Serial port?

[Cubexed]

Google translate:
Hallo, ich habe eine 6490 zwischen meinen Händen und sah, daß in der Leiterplatte befinden sich 3 Gruppe 4 Löcher.
Scheint, dass einer von ihnen ist ein serieller Port für WLAN-Chips und die anderen 2 sind an SoC verbunden ist, denke ich.
Es ist jede Variante, den anderen 2? Sie scheinen nicht, alle Daten während des Systemstarts oder den Betrieb zu schicken...
Dank für irgendwelche Hilfe. (Ich spreche kein Deutsch)

Original:
Hello, I got an 6490 between my hands and saw that in the PCB there are 3 group of 4 holes.
Seems that one of them is a serial port for WLAN chip and the other 2 are conected to SoC, I guess.
There is any way of enabling the other 2? They don't seem to send any data during boot or operation...
Thanks for any help. (I don't speak german)

 

[thtomate12]

The serial port is enabled until the loading of the kernel.

More confusion: There are 2 SoCs, ARM and ATOM

 

[Cubexed]

I know about the dual nature of ARM/x86 in this device, got confusing at first until figured out what was going on

The problem is that 2 of serial ports are always "high" when looking with a oscilloscope, I'm starting to believe that they are disabled from bootloader or something

 

[Cubexed]

You may continue to believe so.

So no hope?


Analyzing the /dev/mtd reveals some U-boot and CEFDK references, according to binwalk the u-boot opcodes are in ARMEB format and CEFDK part is in x86... maybe a bootloader for each CPU

 

[Cubexed]

After sending some stuff conected to serial the "rx" counter increases in /proc/tty/driver/serial, and when sending via echo "test" > /dev/ttyS0 increases the tx counter, but linux doesn't receive and the signal is not changed from the outside when sending
Maybe the culprit is the serial module in the kernel? without source code is hard to tell... (the interrupts also increment in /proc/interrupts when receiving)

Also the middle port is connected to atom, the lowest one is to arm according to tests

 

[kyle0r]

Hi there,

These three links might help you out:

Search term in Google was "fritz box serial konsole"

http://www.wehavemorefun.de/fritzbox/Serielle_Konsole
https://www.zebradem.com/wiki/index.php?title=Serielle_Konsole
http://www.ip-phone-forum.de/showthread.php?t=159588

I am no expert by any means with hardware level hacking. So I cannot really comment further on this.

However I am very interested in the topic/thread for my future knowledge.

May I ask how gained access to the kernel level details that you posted on the 6490 model? Which Fritz OS?

Myself I'm actually looking for someone to help me with securing an official firmware for later use/recovery, for my own box. Anything you can say to that? See this request.

Good luck

 

[PeterPawn]

Myself I'm actually looking for someone to help me with securing an official firmware for later use/recovery, for my own box. Anything you can say to that?

The process of saving the system from an available 6490 device is absolutely simple.

The following script could be used to copy the content of each firmware partition to the embedded eMMC flash, where it can be accessed via "normal" NAS services.

#! /bin/sh
ringbuffer=savesystem
rm /var/.srb_$ringbuffer
nand=/var/media/ftp
logfile() { showshringbuf -i $ringbuffer; }
log() { echo "$*" | logfile; }
save_part()
{
	local dev="$1" content="$2" version="$3" fn rc
	fn=${content}_$version
	cat $dev >$TD/$fn
	rc=$?
	[ $rc -eq 0 ] && log "Successfully saved $dev to $TD/$fn" || log "Error $rc saving $dev to $TD/$fn"
}
if [ "$CONFIG_PRODUKT" == "Fritz_Box_HW213a" ]; then
	core=ARM
	ledon="update_running"
	ledoff="update_no_action"
else
	if [ "$CONFIG_PRODUKT" == "Fritz_Box_HW213x" ]; then
		core=ATOM
		ledon="wlan_starting"
		ledoff="wlan_on"
	else
		log "Unknown hardware revision $CONFIG_PRODUKT"
		exit 1
	fi
fi
TD=$nand/$core
led-ctrl $ledon
log "Waiting for NAND flash to appear ..."
while true; do
	mode=$(sed -n -e "s|^[^ ]* $nand .* \(r.\),.*|\1|p" /proc/mounts)
	[ x"$mode" == x"rw" ] && break
	log "Still waiting until NAND flash storage is mounted read/write"
	sleep 10
done
log "NAND flash is mounted now on $nand"
rm -r $TD
mkdir -p $TD
log "Saving serial flash content:"
logfile </proc/mtd
sed -n -e "s/^\(mtd[0-9]\{1,2\}\): [0-9a-f]* [0-9a-f]* \"\(.*\)\"\$/MTD=\1 NAME=\"\2\"/p" /proc/mtd |
while read line; do
	eval $line
	NAME=$(echo "$NAME" | sed -e "s/[()]//g" -e "s/ /_/")
	cat /dev/$MTD >$TD/${MTD}_$NAME
	log "Copying /dev/$MTD to $TD/${MTD}_$NAME done, rc=$?"
done
log "Saving serial flash done"
log "Saving kernel and filesystem partitions"
mp=/var/tmp/savesystem.mp
mkdir -p $mp
dmesg | grep "/dev/mmcblk.*logical:.*$core" | sed -n -e "s|.*\(/dev/mmcblk.*\) logical: \(.*\)|DEV=\1 CONTENT=\2|p" | 
while read line; do
	eval $line
	echo "$CONTENT" | grep -q "_reserved_" && stat="inactive" || stat="active"
	CONTENT=$(echo "$CONTENT" | sed -e "s/_reserved//")
	echo "$CONTENT" | grep -q "filesystem"
	if [ $? -eq 0 ]; then	
		mount -t squashfs -o ro $DEV $mp
		rc=$?
		if [ $rc -eq 0 ]; then
			version=$($mp/etc/version --version)
			vdate=$($mp/etc/version --date)
			project=$($mp/etc/version --project)
			umount $mp
			rc=$?
			[ $rc -ne 0 ] && log "Error $rc unmounting $DEV from $mp"
			version=$version${project+-$project}
			log "Device $DEV contains $stat $CONTENT with version $version created at $vdate"
			save_part $DEV $CONTENT $version
		else
			log "Error $rc mounting $DEV to $mp"
		fi
	else
		save_part $DEV $CONTENT $version
	fi
done
rmdir $mp
showshringbuf $ringbuffer >$TD/logfile
rm /var/.srb_$ringbuffer
led-ctrl $ledoff

It saves the whole SPI flash and every system partition from the eMMC device (the 1.2 GB at /var/media/ftp will be ignored, they're accessible without any further actions) to /var/media/ftp. These partitions are dumped as "raw", the shown mount command is only used to detect the firmware version of the saved content to build up an appropriate file name for the saved binary data.

While the script is running, it sets some LEDs to signal its activity ... writing 2x 8 MB kernel and 2x 64 MB filesystem (x2 for two architectures) takes some time and you need an indication when it's finished. The scripts assumes, it will be started on each separate system - so it can detect the correct firmware version.

The "real secret" isn't this way to save the system ... first you've to find a way to execute own scripts on the device. If you can get it running only on a single system (ARM or ATOM), you've to modify the script. Simply changing the "grep" command for the "dmesg" output and handling mount errors in the following loop (the systems can't read the filesystem structures of each other) should be enough to save the whole system from a single architecture.

 

[kyle0r]

tausend dank PeterPawn!! I'm reading the Info now and will reply later!

I also posted my "story" here: I didn't want to hi-jack another thread!

 

[Cubexed]

In my case the box has 6.22 in normal and 6.10 in recovery, IIRC the 6.10 has a bug that allows running command via hostname or something like that, I dont remenber well

I flashed a modified ARM FS for executing user script in TFFS at the end of the boot (I used the Freetz tools for descompressing and compressing the FS in ARM, normal squashfs tools doesn't work), for ATOM FS which you can use the normal squashfs tools in any linux distro...
Then I send the image from pc to router using netcat and dump directly to /dev/mmcblk0p1 and /dev/mmcblk0p3, probably not the most "safe" but everything should be fine if you have the recovery FS working...

While the script is running, it sets some LEDs to signal its activity

The script seems interesting, I didn't knew the way of setting LEDs so thanks

also for curiosity... in Atom I got Gentoo chrooted in a USB, running lspci showed that almost all peripheral are "showed" to atom linux as PCI devices (sflash, nand, serial, SoC power unit...)

 

[kyle0r]

Thanks for coming back and updating! That is very interesting infos for the future!

Yes the natcat is not the safest... but creative perhaps double check and test your recovery image so you know it works?

I didn't know the box has a chip with a recovery image built in? Is there a good place to read more about it? Like how to use it if you need it? I assume you can to do that from the recovery tool (per avm ftp) and/or adam2 console?

What I've _not_yet_ found clearly written online, is how does one choose which architecture flavour to boot? or are they both running after adam2 and you can choose/switch?

Indeed PeterPawn's script is very cool. I'm still making sure I understand it 100% before I give it a go on mine. Just so I know how to interpret the logs etc.

 

[kyle0r]

also for curiosity... in Atom I got Gentoo chrooted in a USB, running lspci showed that almost all peripheral are "showed" to atom linux as PCI devices (sflash, nand, serial, SoC power unit...)

Does that mean if you run a custom distro on the box that you *could* tx/rx on the serial? and that perhaps the stock firmware is somehow not fully operational there?

 

[kyle0r]

What I've _not_yet_ found clearly written online, is how does one choose which architecture flavour to boot? or are they both running after adam2 and you can choose/switch?

Now I found more infos! here http://www.wehavemorefun.de/fritzbox/Dual-Boot-System

Hintergrund ist die Tatsache dass bei einem Update der Firmware nichts schief gehen darf, sonst ist die Box in einem undefinierten Zustand und ein Fall für eine Recovery.

Now it makes a lot more sense.

 

[Cubexed]

In my case I used dd and a USB for dumping mmc/sflash (dd can be very dangerous so be careful), some sort of dd if=/dev/device of=file.img

What I've _not_yet_ found clearly written online, is how does one choose which architecture flavour to boot? or are they both running after adam2 and you can choose/switch?

ARM and ATOM both run in paralel since boot and comunicate between them using rpc commands in userland, I guess that kernel uses mailbox
You can do "rpc dmesg" to dump the ATOM kernel log if you are in ARM or viceversa

Does that mean if you run a custom distro on the box that you *could* tx/rx on the serial? and that perhaps the stock firmware is somehow not fully operational there?

Not exactly, the /dev/ttyS* devices don't send/receive any data, probably the kernel serial driver drops the received data, that would explain why the interrupt and data count increases but nothing reachs userland
Gentoo is interesting for getting extra tools that are not available, in ATOM some commands are missing compared to ARM side (probably the ARM is the "master" and ATOM is secondary)

Now I found more infos! here http://www.wehavemorefun.de/fritzbox/Dual-Boot-System

yep, with linux_fs_start 0 the kernel reports:

/dev/mmcblk0p1: filesystem_ARM
/dev/mmcblk0p2: kernel_ARM
/dev/mmcblk0p3: filesystem_ATOM
/dev/mmcblk0p4: kernel_ATOM
/dev/mmcblk0p5: filesystem_reserved_ARM
/dev/mmcblk0p6: kernel_reserved_ARM
/dev/mmcblk0p7: filesystem_reserved_ATOM
/dev/mmcblk0p8: kernel_reserved_ATOM
/dev/mmcblk0p9: media

and with linux_fs_serial 1

/dev/mmcblk0p1: filesystem_reserved_ARM
/dev/mmcblk0p2: kernel_reserved_ARM
/dev/mmcblk0p3: filesystem_reserved_ATOM
/dev/mmcblk0p4: kernel_reserved_ATOM
/dev/mmcblk0p5: filesystem_ARM
/dev/mmcblk0p6: kernel_ARM
/dev/mmcblk0p7: filesystem_ATOM
/dev/mmcblk0p8: kernel_ATOM
/dev/mmcblk0p9: media

The bootloader probably changes the assigned name of the partitions so linux believes that recovery partitions are the normal, but the number don't change so don't write to 5,6,7,8 believing that they are the 1,2,3,4 partitions

Also I attempted to modify init to do chroot to some folder in media partition at boot time but device refused to boot and had to reflash the main fs from recovery fs >_<
Someone noticed that ATOM has a web server at 192.168.178.254? seems that some options are not disabled like in ARM, for example update tab

 

[PeterPawn]

seems that some options are not disabled like in ARM, for example update tab

That's useless ... the ATOM filesystem doesn't contain the "firmwarecfg" (CGI) binary, which is called from the "update" pages.

Currently the ATOM core processes only the DVB-C part, the NAS services (via HTTP(S) and FTP and Samba, partially via a proxy service on the ARM core) and a NFS (v4) server to communicate/exchange data with the ARM core.

The ATOM core uses an internal IP address of 169.254.1.2 (ARM 169.254.1.1) - the main part of the "internal" communication is done with these addresses.

The "external" IP address for the ATOM kernel is always the highest possiible address within the configured LAN segment ... if you've set up a segment of 192.168.128.1/28 via GUI, the ARM core uses this address and the ATOM core would use 192.168.128.14 (.15 is the broadcast address). So - if your ATOM core uses 192.168.178.254 - you have configured a segment of 192.168.178.0/24 (or starting with a higher base, if the mask is more specific).

I'd think, there's a pitfall in the current implementation ... if you specify the highest address in the segment to be used by the ARM core, there's probably a "deadlock" - some reports were published, that setting an invalid LAN configuration and/or route will "brick" the box or better expressed, will send it to a boot loop.

 

[Cubexed]

Maybe would be posible to diff the ARM/ATOM lua page to "restore" the update tab in ARM... but probably AVM servers dont have the firmware for 6490 for this method...

For the reboot part, seems that in rcS there is:

$curfile
case $? in
  "1") watchdog_rt -t 15 /dev/watchdog; cli && reboot;;
  "2") reboot;;
esac

Which reboots if a script under name /etc/scripts/*_check.sh returns 1 or 2 exit code, also the .pcd files in /etc/scripts have reboot command if some checks fails
Maybe would be posible to disable them to avoid these risk of bootloops?

 

[Cubexed]

These are the count of "reboot" word in /etc/scripts, seems to be a minefield... one step wrong and you get reboot

grep reboot etc/scripts/* -c -i                            
docsis_active.pcd:30
pacm.pcd:3
pacm_setup.sh:2
puma6_system.pcd:5
sys_nostartup.sh:2
system.pcd:2

 

[kyle0r]

This thread is like a ray of light from the fritz knowledge gods right to my brain!

Bravo! Please carry on!

 

[PeterPawn]

For the reboot part, seems that in rcS there is:

Nope, this part is related to the "DOCSIS subsystem" only ... the "normal" reboot will be processed as usual by FRITZ!OS via /var/post_install.

The whole DOCSIS part is initialized in /etc/init.d/S20-docsis_pre and started in /etc/init.d/S45-docsis ... if you detach the coax cable from the box, there should be no boot loop initiated by any DOCSIS related problem as long as you didn't select a special "diagnostic mode", where a missing DOCSIS sync will reboot the device sooner or later.

And my opinion to the "update theme": I can't see any (useful) reason, why you need the "update tab" of the firmware restored under any circumstance ... what would you like to "update" there? As long as you don't have a newer firmware (which could still be copied to the box like the current one you're using and restoring in case of a problem), what's the "use case" for these functionality?

@opto:
IMHO the address gets overwritten again, if you change the LAN configuration via GUI ... but this may depend on the firmware version.

 

[Cubexed]

According to ftp.avm.de/fritz.box/fritzbox_6490_cable/firmware/deutsch/info.txt the latest one is 6.30, mine is 6.22

Also in ARM and ATOM, the etc/init.d/S05-watchdog executes "echo init-start 120 >/dev/watchdog"
and in etc/init.d/rc.tail.sh executes "echo init-done >/dev/watchdog"

so maybe the reboot is caused by deadlock taking too much time and triggering the watchdog?
the rc.core_sync.sh has a function for waiting until the other core executes the same function + checkpoint

 

[kyle0r]

I can't see any (useful) reason, why you need the "update tab"

In my view, its useful for loading pseudo updates when you don't yet have telnet running? To start telnet?