Promised post about getting root on Philips MCI730/12 media center. As always – no warranty, anything could happens with your device, you are doing this on your own risk.
- You will need USB flash formatted to FAT or FAT32.
- Put file firmware2010_102h.tgz to the root folder of the disk. This is not a real firmware and it will not modify your device. Only purpose of this package is to provide root access on boot.
- Unplug AC cord to power off the device. Insert USB flash in the device. Press and hold EJECT key then plug AC cord. After some time device will start booting in the “Rescue” mode.
- If everything done right you will see something like this:
- To telnet device you need to connect to the Ethernet port. Device address is 192.168.101.211/255.255.255.0, telnetd is running on standard port (23). Password is root/root.
- If you want to start telnetd in normal (non-rescue) mode permanently add line
“/usr/sbin/telnetd -p 23 &” to the /usr/local/etc/mnetwork.conf file using command
echo '/usr/sbin/telnetd -p 23 &' >> /usr/local/etc/mnetwork.conf - Reboot the device. Telnet will be running on standard (e.g. DHCP) device address, on port 23, with root/root login.
Some background information:
File firmware2010_102h.tgz emulate firmware update. When device booting in the “rescue” mode it extracting content of this file to the temporary directories and starts ./install shell script. In normal update tarball this script re-flashing device, but in our case it just configuring network interface and starting telnetd. I am using /usr/local/etc/mnetwork.conf to start telnetd because it only file located on r/w partition. This file is included by /etc/netinit.sh from the read-only (cramfs) rootfs. Also it is used by mediabolic server, but it seems that it silently ignoring this line, so this hack works fine.
I tried this with my MCI298, which is very similar to the MCI730, and it worked. My main purpose is to get the device to work reliably, and stay connected, even if it is only on the wired connection. Any tips on how to do this?
Hi. Currently you can download mplayer package. I do not have a lot of time to work on this now.
For me device is work mostly reliable if using wired, please tell me more about your issues.
My issue is:
1) I do a factory reset, and don’t do network configuration
2) I can play FM radio, no problem for days.
-3) As soon as I connect to the network by sticking in the network cable, no configuration, the MCI298 seems to acquire a network address.
4) After a number of minutes / hours, the network connection seems to temporarily fail, the MCI comes out of standby mode or whatever it is doing, and shows the media library screen.
5) Any menu option selected through the remote results in a reboot.
What I would like to ask:
- Can I force a re-download of the firmware for instance by changing the version in ECD_key? This in case there is corruption in the loaded image.
- Alternatively, can you tell me how to load the firmware from the Philips Site on a USB stick so I can reflash (when I brick the device)?
- The firmware versions for MCI730 and MCI298 are the same, but the CD version of mine is different, MCI298 has a slot loading drive. I doubt that the firmware contains anything related to the CD. So maybe you can make your USB image available.to me?
- My hope for a “simple” solution is to find the offending software module, verify that it is not required, make sure this software does not get loaded, and use the machine on the Ethernet connection. Any thoughts?
I am determined to get this baby to work. Your help is greatly appreciated.
Symptoms looks strange and it is VERY unlikely that it is related to broken firmware. I would assume that something wrong is with networking, may be DHCP server is not answering, or smth. like that. My recommendation is to:
1) enable telnet access to device, as notices in my post.
2) Run ping from the same network to device.
3) Check if device has IP address when problem occurs. If you can access to it via telnet or not. This will help to understand the reason of problem. Also i am recommending to unload wifi module completely to make sure that networking is not broken by it. It is buggy, anyway.
I have done as you said. I have done:
ifconfig eth1 down
killall -9 wpa_supplicant
rmmod vntwusb
The problem still occurs. When it occurs the network indicator on the screen is red, but I can just telnet into the device. I have compared the running processes, but see little difference, except for DHCP seems to have restarted:
1168 root [start_udhcp]
1177 root /sbin/udhcpc -b -p /var/run/udhcpc-eth0.pid -i eth0 -s /etc/default.script -T 5 -t 5
System log does not report anything.
It seems that ./mgfxclient gets upset by some (temporary) networking problem and this results in the media library screen popping up. When interacting with the program through the remote it abends. I think reboot on the line after the call of ./mgfxclient in appinit.sh causes the reboot.
I still don’t know why it is that ./mgfxclient gets her knickers in a twist.
I am going to set a fixed IP address and kill dhcpd as well and se what that does. The annoying thing is that it can take some hours for the error to occur.
Thanks for your help so far
Ok, please let me know if it makes a difference. BTW, i did a custom firmware which boots from USB, has SSH and allows to restart mgfxclient. I can share it if you want.
Ok,
Problem still there, but I noticed that setting a manual IP address (canceling when acquiring an address and setting IP manually) shows up in the status as manual, but after switching of the device, it shows up as automatic again. Looks like it checks if a DHCP server is present and switches manual off. Will further investigate. A custom firmware is interesting and might allow me to do some more rigorous changes without too much risk, so yes please!
I will try to release it on a weekends. BTW, i am not switching my device to off state and using standby instead. It consume minimum electricity and my wife like a big clock on LCD
P.S. On boot it always loading this shity wifi module, etc. That is why i did custom firmware from USB.
Still eagerly awaiting your custom firmware. Found out that the fixed ip sticks if I set router etc by hand as well. It does not solve the problem though. So it is not DHCP related. I hope you find time soon.
Can`t promise – need to solve some time to clean up image, prepare manual,etc. Also i do have a problem – it not always loads. I assume that there are some bugs in kernel related to USB mass media, so sometime it just hanging on load. Need to do serial cable to debug. Before i will do this i can provide you small howto about restarting mgfxclient.
As you found it is not possible to restart mgfxclient by killing it – init will restart device. But there is a funny hack to avoid this – mgfxclient is started by catchsegv. Sop you can “hang” this prorcess and kill mgfxclient. Something like
killall -STOP catchsegv
and then you can kill mgfxclient and start it again (you will need also to do “export LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib:/usr/local/lib/modules:/usr/local/lib/mediaserver” in the console).
If mgfxclient is started in console it will produce a lot of debug messages. I hope this will help you to find and fix a problem. Write me if it helps
Thanks for the how-to. Using it I saw that mgfxclient crashes because of too many open files. Further investigation revealed that every couple of minutes about 20 extra files get opened until it reaches the threshold of 1024. That is when it hangs/crashes.
The file being opened is always the same one: /tmp/uuid. This files hold some descriptor of the MCI298. I found that the incrementing of open files stops when I stop the standard mediaserver on my Synology.
When I start the Twonky mediaserver on the Synology, the incrementing does not occur, or at least at a much slower rate. The media server UPnPlayer on my iPad behaves bad. Windows7 Mediaplayer behaves well.
My conclusion is that the mediaservers announce themselves periodically, and some cause mgfxclient to allocate resources that are not released.
I prefer to use the Synology mediaserver. Have you any pointers to a solution? I have tried changing permissions on /tmp/uuid with no result.
Interesting finding. I am currently do not have upnp server running, but do have positive experience with Logitech Media Server. Also i do not have ipad, so it is hard for me to check.
Some recommendations:
1) Try to change limits (ulimit) to see if it will stop growing at some point (ulimit -n 64000)
2) Its interesting if removing of this file will help or not
3) Unfortunately there is no source code of the [buggy] mgfxclient. one of the workaround is to watchdog this process and kill it if needed.
Please share results with me, it is interesting.
I have spent a lot of time on this with the following result:
Using Wireshark I saw that the MCI298 follows the UPNP standards as defined in http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf
It advertises itself with a set of UDP multicast messages on 239.255.255.250:1900. The advertisement expiration time in the messages is 1801 seconds.
It refreshes the advertisement every 30 seconds. This period is a lot shorter than the advised one-half of the advertisement expiration time.
The advertisement message also contains the address where interested UPNP nodes can find the UPNP description of the MCI298. This is at address http://{mci298}:8888/upnp_descriptor_0
When a UPNP node accesses this address the MCI298 serves the UPNP descriptor XML message. This is also when the file /tmp/uuid is recreated and left open.
Mediaservers like Twonky sparingly access the descriptor. Other mediaservers access the descriptor for every advertisement of a service they are interested in. In my case this means that the threshold of 1024 open files is reached after about 4 hours.
It can be easily tested with the following script after inserting the right ip address:
#!/bin/sh
i=1
while [ $i -le 1024 ]
do
echo $i
i=`expr $i + 1`
wget -O /dev/null http://{mci298}:8888/upnp_descriptor_0
done
Try navigating through the menus on your MCI after running this and it will crash / reboot.
Some of the possible solutions I thought of:
1) Submit the issue to Philips / Mediabolic with threat to file for revocation of the DLNA certificate. (I doubt if they will be impressed)
2) Patch the descriptor URL in the multicast message to point to a non-existing / pre-defined page on a known server with the right data on it.
The descriptor URL can changed by patching the program or mangling the message with an IPTABLES rule on a router.
3) Stop the multicast from reaching the servers, so no query for the descriptor page is issued. Filtering the multicast message can again be done in a router.
I have tried option 2 and 3, but to no avail. I can elaborate on how I tried if you want.
I hope you have some fresh ideas
Thank you for a very detailed report. I see another possible solution – do LD_PRELOAD wrapper for open and return fail if /tmp/uuid is requests. I hate such closes-source mess, really.
BTW, you can try to contact support for this, but i think this device is not _really_ supported. E.g. wifi bug is VERY easy to proof, but nobody care. About DLNA Certification – may be it could be an option, no idea. I will try provided batch script tomorrow and will tell you results.
P.S. i am currently formatted flash to ext2 and boot process seems to be much more reliable. Before i was using vfat + loopback device with ext2 and boot was very problematic. I will probably upload my image on the weekend.
I just tested your script with my device and i`m unable to reproduce this crash. So it possible that it is fixed in my build. I will upload my firmware on weekends to SF.net storage, so you will be able to try mine version.
I am surprised that you were unable to reproduce the crash. Maybe my code got mangled. In the meantime I have managed to put a router running DD-WRT between the player and the rest of my network, and use iptables / ebtables to filter out the broadcasts. This is a workaround, but after 8 days of uptime I now have /tmp/uuid open 87 times. So I think the reboot will only occur every two to three months. For the rest the unit works fine now.