55 replies to this topic

[The_Raven]

This:

root@dm7025:~# ip addr
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0X:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.197/24 brd 192.168.10.255 scope global eth0
3: sit0: <NOARP> mtu 1480 qdisc noop 
    link/sit 0.0.0.0 brd 0.0.0.0
root@dm7025:~# 

[Erik Slagter]

This:
root@dm7025:~# ip addr
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0X:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
inet 192.168.10.197/24 brd 192.168.10.255 scope global eth0
3: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
root@dm7025:~#

So ipv6 is already available. Then I don't know why the webif won't work and I can't test it either.

Edited by Erik Slagter, 4 November 2013 - 19:35.

[The_Raven]

I am sure it has something to do with the update, but don't know what

Can i trace it? Start the webif by hand?

[Erik Slagter]

No unfortunately not, the web interface is part of enigma.

[MiLo]

The Python installation lacks IPv6 support too. That's most likely what it crashes on.

I guess we'll have to "freeze" the openwebif version for the old systems.

[The_Raven]

Yes, maybe not a bad idea. Not realy great, but maybe the only way.

[athoik]

Maybe there is another way
 

have_ipv6 = True
s = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
try:
    s.connect(('ipv6.google.com', 0))
except:
    have_ipv6 = False

http://www.kaarsemak...support-python/

[SpaceRat]

The problem is not even closely (That is: zero point nil percent) IPv6 related:

OpenWebif tests if BOTH, kernel and Python, were compiled with IPv6 support and only if both are it enables IPv6. If only one or none of them are IPv6 enabled, it falls back to IPv4.

if has_ipv6 and fileExists('/proc/net/if_inet6'):

can not become "True" if Python and/or kernel are not IPv6 enabled.

Topf:~# python
Python 2.7.3 (default, Oct 25 2013, 20:42:04)
[GCC 4.6.3 20120613 (STMicroelectronics/Linux Base 4.6.3-111)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.has_ipv6
False
>>> exit()
Topf:~# opkg list_installed *web*
enigma2-plugin-extensions-openwebif - 0.2.5-e2openpluginsgit20131104-r0

[madchip]

hello,

 

This problem appear after upgrade image, i flash again the dm with old version of open pli and the http access works again, and after i updgrade for see if the problem come again , and he come again.

For me the problem is the web interface are disable in the new update (what date exactly booo ???) and by who ??. Maybe need to know what file are change and put old version of this file for enable again http access.

[SpaceRat]

Ok, so the problem is a completely different one:
You are using the OLD Webif (The one by Dream Multimedia).

OpenWebif was originally designed as a more modern alternative to the old DMM-Webif. In its childhood, it defaulted to work on different ports than and in co-existence with the old Webif.

However, DMM has demanded that the Webif gets removed from images for non-DMM boxes and that way OpenWebif became the de-facto standard for the web interface.
This was reflected in the settings for OpenWebif, which now default to the standard http/https ports.
Both web interfaces can still co-exist, but OpenWebif needs to be configured for that, it no longer defaults for it.

With E2 never writing the default values into its /etc/settings, everything will continue to work as long as you are using builds set up for co-existence:
Old Webif hooks port http/80, OpenWebif hooks non-standard port 8088 for http and port 443 for https (Old builds of the old Webif didn't support https, afair) and OpenWebif adds some plugin hook to the old Webif.

Now, after the update, the old Webif is probably borked (Not cleanly removed), OpenWebif defaults to port 80 for http but is still looking for the existence of the old Webif and hooks that too and so on ...
Alternatively, your old Webif is still in theory functional, but OpenWebif wants to hook the same ports and to add the plugin hook ...

I do not own one of those overprized "original" Dreamboxes, so I do not know about the current state of the old Webif on the OpenPLi feeds for these, but in either of the above cases you need to do some cleanup when you update beyond the point were OpenWebif was designed as being the secondary web interface:

a.) Get rid of the old Webif entirely (Incl. remaining files in its plugin dir and that directory itself)
or
b.) Configure them for co-existence manually, that means, set OpenWebif to use other ports than 80 and 443, e.g. 81 and 444.

If b. fails, fall back to a.

[RamsesII]

But us who are using OpenPLi updates regularly have no "old" versions anymore, and the WebIf has been working all right. This is a new problem with the latest updates. It just stopped working, being very good before that.

[SpaceRat]

But us who are using OpenPLi updates regularly have no "old" versions anymore, and the WebIf has been working all right. This is a new problem with the latest updates. It just stopped working, being very good before that.

OpenWebif or the old Webif?

If OpenWebif:
I didn't say it can't malfunction. I just made clear it is not related to IPv6, because that was added with a proper fallback to IPv4.

It works just fine on my Vu+ Ultimo (OpenPLi 3.0, IPv6 enabled kernel, IPv6 enabled Python which I built myself), a friend's Vu+ Duo² (OpenPLi 4.0, IPv6 enabled kernel and Python out of the box) and also on my Topfield TF7700 HD PVR (OpenPLi based "HDMU Image" with IPv6 enabled kernel but non-IPv6-enabled Python) and most other boxes (Which I just assume as less than a handful of people are reporting a problem here).

If we had some more information (original error messages by Webif/OpenWebif), we might be able to investigate the problem, but "it stopped working" is not reproducable.

[RamsesII]

What would be the right logfile to search for errors?

[SpaceRat]

What would be the right logfile to search for errors?

As Enigma2 is absolutely bugless, there is no log ;>

From shell (ssh or telnet):
init 5 && sleep 15 && enigma2
will show all output on the console.

Or better:
init 5
enigma2 > /tmp/debug.log 2>&1

After ~ 5 Min make a copy of the debug.log and send it to me.

Then restart your box to stop logging.

[The_Raven]

As i said before, the only thing i see is:

[OpenWebif] loading external plugins...
[OpenWebif] no plugins to load
[OpenWebif] failed to listen on Port 80
[OpenWebif] failed to listen on Port 443

But i send you the full log. Give me some minutes...

The port 80 and 443 is free, nothing is listen on it.

 

And BTW: Today came an update, but does not fix the problem

[catastrofus]

I guess you mean 'init 4' instead of 'init 5'? With a real linux system you will start the X-window environment with 'init 5'.

 

 

What would be the right logfile to search for errors?

As Enigma2 is absolutely bugless, there is no log ;>

From shell (ssh or telnet):
init 5 && sleep 15 && enigma2
will show all output on the console.

Or better:
init 5
enigma2 > /tmp/debug.log 2>&1

After ~ 5 Min make a copy of the debug.log and send it to me.

Then restart your box to stop logging.

[SpaceRat]

I guess you mean 'init 4' instead of 'init 5'? With a real linux system you will start the X-window environment with 'init 5'.

init 5 works, that's all that matters

[SpaceRat]

Should be fixed with the next build.

It actually was IPv6 related, the affected images have a strange environment:
Kernel and Python were IPv6 enabled but they ship with an ancient Twisted (Version 8.2.0), current is > 13.x (Used on HDMU image) and first with IPv6 support was 12.0.0 (Used in OpenPLi 3.0 e.g. on Vu+ Ultimo).

I've added a version check to ensure Twisted has version 12.x.y or higher.

PS: The better fix would be to update Twisted to at least 12.0.0 to enjoy the benefits of IPv6 and the probable fixes between these versions.

Edited by SpaceRat, 7 November 2013 - 13:18.

[MiLo]

I've added a version check to ensure Twisted has version 12.x.y or higher.

Since versions checks invariably break in future (for example, when "Twisted XP" comes out) can't you just use a try/catch construct to detect Twisted's level of IPv6 support?

[SpaceRat]

A version check must not break, it would be an error on its own.

Your "Twisted XP" is a good example, btw:
- Windows 95 is Windows 4.0 (Running on top of MS-DOS 7.0)
- Windows 98 is Windows 4.1 (Running on top of MS-DOS 7.1)
- Windows ME is Windows 4.9 (Running on top of MS-DOS 8)
- Windows 2000 is Windows NT 5.0
- Windows XP is Windows NT 5.1
- Windows Vista is Windows NT 6.0
- Windows 7 is Windows NT 6.1
- Windows 8 is Windows NT 6.2
and
- Windows 8.1 is Windows NT 6.3
respectively.

There never ever has been a break in the version numbering.

This consistence even goes futher:
When using internal version checks for DOS versioning ..
- MS-DOS 1.0 reports itself as DOS 1.0
- Microsoft/IBM OS/2 1.x reports itself as DOS 10.x
- Microsoft/IBM OS/2 2.x reports itself as DOS 20.x
- Microsoft/IBM OS/2 3.x reports itself as DOS 20.30
- Microsoft/IBM OS/2 4.x reports itself as DOS 20.40
- Windows NT 3.1 reports itself as DOS 30.10
- ...
- Windows 8.1 reports itself as DOS 60.3

And the same is true for Microsoft Office: Office 2010 is Office 14 internally and so on.

As soon as Twisted doesn't report a constantly growing twisted version anymore, it wouldn't be twisted anymore and require re-investigation anyways.

In other words:
Fancy marketing names must not become part of version checks inside the API.


There already is a try/catch construct around creating the sockets, btw

If there was an API change in this part of the API, it would simply be catched again, like it was now.
Making assumptions about how the API might change in the future (Which we can not foresee and which might be ANYWHERE in the twisted API, not only the IPv6 socket creation) and trying to catch them all would be nothing else but bloat.