#!/bin/bash
nc -i 2 vdsl2.xperim.be 23 > /dev/null <<EOS
admin
BGCVDSL2
shell
killall tr98
exit
exit

EOS

If you want to kill more than only tr98, then just add the appropriate killall commands immediately before or after the killall tr98 command.

The box is now more stable and doesn’t use 98% of it’s CPU all the time.

Indeed, if you killed tr69 and/or have VLAN20 disabled, you will not get the firmware updates. The latest firmware revision bears the Runtime Code Version 60R109-60A022. This was specifically intended to allow the 17Mhz profile (aka 30 Mbps for now). The main firmware version has not been updated for a while.
To re-enable tr69, you need to reboot the box. Do not forget to re-enable VLAN20 also. At boot-up, it will check if a new firmware is available.

Thanks for you kind words about the blog. Good to know it is useful to some people out there. It really makes my day

i killed tr69 and sipd since the one melted a bbox and the other one ate all its memory.

a few days ago, BGC introduced its “new” 30 mb/s line rates in our region (Eupen).

my firmware version is VTU-R:5.5.1.2IK105012 from 1st Oct ’09.

not that i have bandwidth issues or somewhat (upstream is a bit bursty, as always), but i wonder if i missed/failed some updates.

@patrick: you wrote in another post about BGC CPE-management (fw-updates over private 10.x.x.x lan).. could it be possible that the box couldn’t update because no process tr69 is running / what was the latest (stable) fw-update for this box?

btw, i’m using the box as a modem for a bsd-box.

cool blog though, didn’t know there where so much other people do mind what they’re getting.

Have a nice one, everybody..

From personal experience,my modem is a bit cooler now those processes are killed. Note, however, that the original Sagem has a different case than the BBOX-2, and tends to be hotter because of that.

I have seen no adverse effects in killing those processes, and one major benefit: the Box does not reboot randomly as it did before. It has been stable now for more than two months, without a single reboot.

Thanks for the link. It is especially worrying that this problem has been reported this long ago to BGC, but still not solved.

> And kill doesn’t solve your problem, as it will be restarted automatically.
> Also, it will stop updates from Belgacom and can result in reboot of the modem.

It is only restarted at boot time, which does not happen very often. Actually, when the tr98 process is inactive, the Bbox2 does not spontaneously reboot at all.
I suspect spontaneous reboots are related to the high load generated by the tr98 process and the memory used by the sipd processes. As for the updates, you are right. I usually wait to hear from other people’s experiences with new firmware versions before allowing my modem to update itself. The lack of information from BGC regarding these updates do not help either.

The difference of opinion on the meaning of the “load average” is as old as Unix itself. It very much depends which kind of machine you are talking about. On a typical CPE with a a low end CPU I would not be concerned for spikes above 1.0. However, a constant load of more than 2.0 over 15 minutes does look strange.

I searched *2 seconds* and I found this:

http://forum.belgacom.net/view.php?bn=selfcareforumnl_bugs&key=1248382769

From July 2009 …

>1. The BBOX2 is not as old (“years ago”)
Yes it is, exactly 2 years old.

And kill doesn’t solve your problem, as it will be restarted automatically.
Also, it will stop updates from Belgacom and can result in reboot of the modem.

>Rather, a load average higher than 1.0 means the CPU is >potentially overloaded.

Not true. Above 10 you can call ‘overloaded’, but still not dying.

Edwin

I certainly make no claim to have been the first one to discover that behaviour. But It was sufficiently annoying to be worth a blog post.

What I have noticed is that, sometimes, any command at the prompt is ineffective. Even “ls” or “exit”. If I try a few minutes later, it usually works again. Don’t ask me why …

Zwintje.