Superb quality and spec AB-Com PULSe 4K SE. Crazy offer! Only £99! FREE UK DELIVERY! 4K UHD, Enigma 2, Multiboot 4 images & more!...
Superb quality and spec AB-Com PULSe 4K Rev II Twin Satellite tuner only £149! FREE UK DELIVERY! 4K UHD, Enigma 2, SATA HDD facility, Multiboot 4 images & more!...
- Status
Without going back over the full thread, what box & router are you using again?
Does the box have a MAC address that your router picks up?
Genuine Vu+ Solo 2, Router TP-Link WR 1043ND with dd-wrt firmware.
What dou you mean by "MAC address that your router picks up"? The router sees the Vu and its MAC and it's configured to assign it a fixed ip inside the network.
View attachment enigma2_crash_1446239982.log
Again '/tmp/' error: "IOError: [Errno 2] No such file or directory: '/tmp/cam.check.log'"
I've done further testing after your crash report lastnight. It's 100% network issue and sorry to say you're going to have to find the cause on your network.
I managed to replicate the crash again using a switch. Also found that simply couch flashing was grinding my network to a halt, strange, but true. At that point swapped Asus router a Linksys router.
No crash using Linksys router, therefore connected up Asus router to lappie, check differences in settings etc.. I found I still had ports opened that I'd opened for a team member a few weeks back, telnet and http ports both forwarded to Duo2, yes what an idiot forgetting about this
I also checked Asus for firmware updates and updated router to latest firmware.
Now connected backup to Asus router, ports closed, firmware upgraded no crash at last So I either had a firmware issue on router or box was being hacked/attacked due to the ports being open.
Yes network/routers can bring receivers down, no matter what you like to believe. Tested with two routers at home as explained above and taken to complete new network at another property, all ports closed on that other network, no issues with the receiver connected to the other network.
I managed to replicate the crash again using a switch. Also found that simply couch flashing was grinding my network to a halt, strange, but true. At that point swapped Asus router a Linksys router.
No crash using Linksys router, therefore connected up Asus router to lappie, check differences in settings etc.. I found I still had ports opened that I'd opened for a team member a few weeks back, telnet and http ports both forwarded to Duo2, yes what an idiot forgetting about this
I also checked Asus for firmware updates and updated router to latest firmware.Now connected backup to Asus router, ports closed, firmware upgraded no crash at last
So I either had a firmware issue on router or box was being hacked/attacked due to the ports being open.Yes network/routers can bring receivers down, no matter what you like to believe. Tested with two routers at home as explained above and taken to complete new network at another property, all ports closed on that other network, no issues with the receiver connected to the other network.
I use this version because after long testing and playing with configs, this version is the one that brings me better ecm timing (compared to v 2.0.9 and v2.3 and also oscam).
Anyway, I've also tested with this other cams (v.2.3 and oscam) and get the same crashes.
Anyway, I've also tested with this other cams (v.2.3 and oscam) and get the same crashes.
I've done further testing after your crash report lastnight. It's 100% network issue and sorry to say you're going to have to find the cause on your network.
I managed to replicate the crash again using a switch. Also found that simply couch flashing was grinding my network to a halt, strange, but true. At that point swapped Asus router a Linksys router.
No crash using Linksys router, therefore connected up Asus router to lappie, check differences in settings etc.. I found I still had ports opened that I'd opened for a team member a few weeks back, telnet and http ports both forwarded to Duo2, yes what an idiot forgetting about this
Now connected backup to Asus router, ports closed, firmware upgraded no crash at last
Yes network/routers can bring receivers down, no matter what you like to believe. Tested with two routers at home as explained above and taken to complete new network at another property, all ports closed on that other network, no issues with the receiver connected to the other network.
Sicilian,
Thanks for all your tests but I'm sorry to have to say that your conclusions are wrong.
As I've tried to explain before, by the fact that the box crashed when connected to router A, but not when connected to router B you can't conclude that router A crashes the box. This is ignoring how a network works, the much you can conclude is the box seems to have a problem processing some packets.
Any device on the network only 'receives' or 'listens' the network traffic coming from other devices (the router in this case) and then 'interprets' it on various layers (hardware, drivers, software on a reduced scheme). Even if a packet is 'malformed' (for example bad hardware timing on the hardware layer, bad ip address on the software protocol layer, etc.), every 'layer' is responsible to process it and pass it to its upper level, or, if it detects an error on the data it processes, to manage this error ordinately.
A 'crash' only can occur when the software is faced to a situation that it can't handle and goes running in an 'uncontrolled' state. Depending on hardware and OS security architecture, this can lead from no consequence to very bad ones, for example writing random data in random areas of memory...
So the device crashes, not because it receives 'bad data' (what I doubt in our case because other devices on the network never crashed and overall because even this same box in exactly the same network don't crashed in the past for around two years now), but because it don't process it correctly in some situations.
Because even receiving 'bad data' a network device doesn't have to crash, it have to just ignore or signal it and then you'll have some network function not working, but never crashing.
This is like if you said for example that a word processor crashes when you write "#!?&;@|". The fault is not because you write strange characters, but because the program don't process them correctly. Try to crash 'Word' by typing what you want in your keyboard: you can't.
Understand please that I'm not trying to argue and be unpleasant. I try to solve a problem that affects me and can affect much more users if it's not understanded and controlled. It's not a critic to you, your team or OpenVIX. I repeat that the same problem is present at least in Black Hole and OpenPLI and that this suggests that it must be in the core or the drivers but it is impossible to progress if you don't understand such basic concepts.
Believe me please when I say that I'm pretty sure everything is right on my side. The only thing on my side I can doubt and can't be 100% sure if it is or not an hardware problem.
As you seem to be able to reproduce the crash easely (me I have to wait sometimes 24 hours before a crash), can you please test if in your same crashing configuration you can repeat the crash with Apollo 166?
Thanks.
Last edited:
I'm out of this thread you have your own conclusions, but yes I was able reproduce with apollo166.
Sent from my iPhone using Tapatalk
Sent from my iPhone using Tapatalk
Not configured properly so, not to mind not using a local card...
Rob van der Does
ViX Beta Tester
Please be aware that the NIC of any STB is only a low quality one, and that applies especially to the drivers. And as the drivers are supplied by the manufacturer and they are 'closed source', there's nothing the image builder can do about it.
Also be aware that Sicilian was able to reproduce this very same issue with different brands STB's.
Also be aware that Sicilian was able to reproduce this very same issue with different brands STB's.
Good point, discards specific manufacturer drivers.
And this lead us to conclude that the problem is into an intermediate layer of software between manufacturer drivers and specific images, right?
Lets say I connect to a receiver not being in the same room.
And we forget it runs smoothly with every cam, it only crashes when using OpenVPN.
But other posts here are from people not using VPN...
Could be different crashing causes with the same final crashing screen?
Last edited:
Rob van der Does
ViX Beta Tester
As far as I can see the image itself (i.e. Linux + Enigma2) is not involved. It's just the NIC (in hardware and drivers); the image just gets the data from there.
But it runs OK without VPN with the same hardware/drivers...
So I more and more think mine is an hardware problem.
Do you know of some software tool to test memory (ram and flash)?
- Status
