[MB Premium Ultra] Suspected - Cacheflush causes box and internet connection to crash

[imish]

Was installing a few extensions earlier on this afternoon including Cacheflush and noticed that the box was flooding my network bringing down the crappy Virgin Superhub router.

Through process of elimination I believe its cacheflush that is causing the box to slow down and bizarrely the internet to crash due to the flooding of packets on the private network.

I have now removed cacheflush and the internet is back up and so is the box.

 

[Sicilian]

Theres no need for cacheflush plugin on the MB Ultra.

 

[abu baniaz]

Are you using mgcamd? Does you logging value start with

L: {03} 172.xxxxx

 

[Larry-G]

We have stated this time and time again, cache flush is one of those plugins that should only ever be used when you have 100 percent proof that your receiver needs it. Such as with the infamous memory leak on some of the Vu+Duo's using the 3.1.1 kernel, using it when it is not needed will cause you problems.

There is absolutely no need to use it with any other receiver, regardless of what others tell you.

 

[imish]

We have stated this time and time again, cache flush is one of those plugins that should only ever be used when you have 100 percent proof that your receiver needs it. Such as with the infamous memory leak on some of the Vu+Duo's using the 3.1.1 kernel, using it when it is not needed will cause you problems.

There is absolutely no need to use it with any other receiver, regardless of what others tell you.

Never again.

Was very surprised at how one plugin brought the home network down. I had an engineer booked for next week, luckily disconnected all network devices and the superb started to work. The only piece of the network that held up was my trusted cisco switch.

Seems like crappy software and hardware are the norm these days.

 

[Sicilian]

Never again.

Was very surprised at how one plugin brought the home network down. I had an engineer booked for next week, luckily disconnected all network devices and the superb started to work. The only piece of the network that held up was my trusted cisco switch.

Seems like crappy software and hardware are the norm these days.

Did you read post 3 above?

 

[cactikid]

user error how many of us been there done that

 

[birdman]

We have stated this time and time again, cache flush is one of those plugins that should only ever be used when you have 100 percent proof that your receiver needs it.

Whereas that may be the case, that does indicate that there are occasions when it is needed and should be running. And presumably when it is needed it isn't supposed to bring the user's home network down?
So the fact that it does - even when it is being run unnecessarily - indicates that there is a bug there somewhere.

 

[Larry-G]

Whereas that may be the case, that does indicate that there are occasions when it is needed and should be running. And presumably when it is needed it isn't supposed to bring the user's home network down?
So the fact that it does - even when it is being run unnecessarily - indicates that there is a bug there somewhere.

Cache flush is only useful to the Vu+ Duo's (not all as only a small percentage showed problems) and only when they were suffering from the memory leak associated with the 3.1.1 kernel, it is of no use what so ever in any other circumstance.

 

[birdman]

it is of no use what so ever in any other circumstance.

Which would appear to be irrelevant to its effect on the network.
The fact that the simple solution is to remove it doesn't alter the fact that it's doing something weird, and probably wrong.

If nothing else, a simple test of, "Am I running on a system where I might be of use?" would seem to be in order.

 

[Larry-G]

Which would appear to be irrelevant to its effect on the network.
The fact that the simple solution is to remove it doesn't alter the fact that it's doing something weird, and probably wrong.

we dont have enough information from the OP in order to say with any certainty what was causing his issue, but nerveless cache flush is not the wonder fix plugin some users believe it to be. we do however know that a incorrectly setup Mgcamd config file can and will give these kinds of symptoms, so we are waiting for the OP to return and let us know if this was a contributing factor or not.

 

[ronand]

Personally I doubt the cacheflush plugin was causing a ddos attack (it wouldnt have any network function) and would agree with phoenix that mgcamd was the most likely cause. Logs should have been produced by the op.

 

[imish]

Update

Started with a factory reset and a fresh config and build the setup slowly - to my surprise the problem still persisted when I introduced MGCAM to the equation.

Abu's suggestion in post 3 & the following thread helped. for the past 30 mins all has been good.

 

[abu baniaz]

Glad you are sorted. (By the way, post 3 was a question.)

Unfortunately, you won't be the last. Some time back, we had a user convinced that the Vix image was killing his network. Not his fault, the configs he downloaded had the logging enabled to an IP address that did not exist.

I had network issues until VectorZ pointed it out to me.

 

[imish]

Glad you are sorted. (By the way, post 3 was a question.)

Unfortunately, you won't be the last. Some time back, we had a user convinced that the Vix image was killing his network. Not his fault, the configs he downloaded had the logging enabled to an IP address that did not exist.

I had network issues until VectorZ pointed it out to me.

Not only was there a DDOS on the network which grounded the crappy Virgin Router and (hence the internet and internal network) but i also noticed massive memory consumption on the receiver (slowing down the box).

My initial thoughts were cache flush, however it was the cfg file.

Thanks for your help - been a learning experience.

 

[Larry-G]

Not only was there a DDOS on the network which grounded the crappy Virgin Router and (hence the internet and internal network) but i also noticed massive memory consumption on the receiver (slowing down the box).

My initial thoughts were cache flush, however it was the cfg file.

Thanks for your help - been a learning experience.

Cache flush will account for the memory consumption, Mgcamd the DDos.

 

[imish]

I am not sure whether the problem is fixed despite the changes that Abu mentioned - my internet connection is running at a snails pace.

Using NETSTAT I can see the connections, what I would like to also see is the bandwidth that they are consuming. Is there a command I can use to check.

 

[bbbuk]

Assuming mg_cfg issue has been ruled out, have you more info on setup of network like is it connected wireless, ethernet, ethernet via powerline adapters, running a VPN setup or anything else running on the box, are you going through anything else other than virgin router?

When it's running at a snail's pace, can you visit (from laptop or something) www.pingtest.net and report back it's results (sometimes I find running it a few times and take the average result from that).

 

[abu baniaz]

@Imish
Download mg_cfg from receiver. Compress (zip/rar) it and upload please.

 

[bbbuk]

This is my mg_cfg file (not for cable use) which works fine with no problems network or otherwise:-

# EMM messages
# 00 dont show any EMMs (default)
# 01 show only valid EMMs
# 02 show valid and bad EMMs with complete data display
M: { 01 }

# ECM messages
# 00 dont show anything about ecm
# 01 normal mode, show pids processed, decoded ecm and cw
# 02 verbose mode, show valid and bad ECMs with data
C: { 01 }

# AU
# 00 disable, no emm pids processed
# 01 enable, emm pids always processed for soft-au and shared cards
# 02 auto, emm started only if channel cant be decoded
# 03 process emm pids for network cards update only
A: { 01 }

# key update (sum 01 or 02 with 04)
# 01 update only new keys, default setting
# 02 update all keys (used for valid PMK checking)
# 04 enable TPS au
# + tps SID, which pmt pid contains au pid
U: { 01 }

# config files folder (softcam, autoroll, ignore/priority)
# 00 files in /var/keys
# 01 files in /tmp
T: { 00 }

# network mode, use summ for several clients
# 00 no network (default)
# 01 newcamd netclient
# 02 radegast netclient
# 04 camd3 netclient
# 08 gbox netclient
G: { 33 }

# network retry, use summ for several options
# 00 disable
# 01 retry every new ecm
# 02 try to connect to offline shares every Q: seconds
# 04 try to detect and fast reconnect to lost (and not used atm) server
# + XX messages number and YY seconds to reconnect
# mg will reconnect to server, if no answer to last XX ecm/keepalive or
# if no answer for last ecm or keepalive sent for YY seconds
# set to 0 to disable
N: { 07 }

# network ecm timeout in seconds
K: { 07 }

# newcamd dead routes connect retry, sec
Q: { 10 }

# network shares priority
# 00 gbox, newcamd, radegast, camd3 (default)
# 01 camd3, radegast, newcamd, gbox
# 02 newcamd, camd3, gbox, radegast
P: { 02 }

# on screen display type
# 00 No OSD (default)
# 01 neutrino
# 02 enigma
# 03 relook
# + user password for http auth
O: { 00 }

# on screen display Options, summ of:
# 01 show emu ecm
# 02 show network shares messages
# 04 show decoding failed / fta
# 08 show emm keys update
# + web port to use for osd
S: { 11 } 80

# Log option, summ of:
# 00 off
# 01 network udp log
# 02 log to console
# 04 file, appended ! delete it by yourself, before it eat all your hdd
# + IP udp-port log-file-name
L: { 00 }

# keep ecm cache, seconds
# every cache entry takes 28 bytes, so 24h cache will take *only* 240-400kb of memory,
# for openbox/elanvision users with remote shares make sense to set it higher than default value,
# to not hammer cards while timeshifting or playing crypted recordings.
E: { 15 }

# cache option, summ of:
# 00 Off (default)
# 01 Ecm pids cache, store pids used to decode in /tmp/ca_cache.list at exit, load at startup, same syntax as restore.list
# 02 Ecm data cache, remember CW for (E:) time
# 04 Emm cache for network cards, do not resend the same emm twice, cache not cleared until restart
H: { 04 }

# reread files, summ of:
# 00 No (default)
# 01 reread config file on channel change (including priority and ignore, but not replace/cache)
# 02 reread SoftCam.Key on channel change
# 04 reread SoftCam.Key if file changed
R: { 00 }

# debug, summ of
# 00 off (default)
# 01 debug ecm
# 02 debug emm
# 04 debug network ecm
# 08 debug network emm
# 16 debug network login
# 32 show mem/cpu stats every 1 min
# 64 add timestamp to log messages
D: { 00 }

# box type
# 00 autodetect, change only if you think wrong type detected.
# 01 dbox2
# 02 dreambox
# 03 triple-dragon
# 04 relook
# 05 openbox
B: { 06 }

# Mapping 18xx
# 00 disable mapping
# 01 map 18xx to 1801