Probleme mit Octopus Net v2 (DVB-S/S2)

    Hi,


    hat noch jemand Probleme mit der octonet s2 v2, bei mir stirbt der octoserve process permanent innerhalb von Sekunden wenn sich mein Panasonic TV verbindet mit segmentation fault.
    Die Zeit auf dem octonet scheint auch nicht automatisch gesetzt zu werden via ntp oder dvb und stand bei mir auf 1970.


    CU
    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

    :modon
    In eigenen Thread verschoben, sonst geht das unter.


    Regards
    fnu

    HowTo: APT pinning

    Kannst Du das octoserve mit "octoserve -d ff" einmal über telnet per Hand neustarten und dann die Ausgaben direkt vor dem nächsten Crash zeigen?


    ntp habe ich keinen Laufen, da die aktuelle Zeit momentan nicht benötigt wird.

    Hi,


    ok, here are the output, I have also a ticket open at digital devices but no response up to now.



    so https://tools.ietf.org/html/rfc2002
    3.5.4. Foreign-Home Authentication Extension
    Type 34


    clould may come from my Loewe TV or Fritzbox, but nothing else has issues here.


    CU
    9000h


    Mod.: Spoiler for long listings please ...

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

    2 Mal editiert, zuletzt von 9000H ()

    Well, rjkm is the right men at DD doing this, I kindly pointed him to your issue ...


    Regards
    fnu


    PS.: Aber deutsch ist glaube ich auch seine Muttersprache ... ;)

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

    Hi,


    the second issue with the octonet is a channel scan auto or manual with the Panasonic TV on Hotbird 13.0E will not find SRF 1 HD, when I do this with a Telestar Digibit R1 it will be found.


    CU
    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

    Das sieht nach einem Problem beim Parsing eines IGMP-Paketes aus.
    Entweder parse ich das falsch (25069 Sources ist auch etwas viel) oder das Paket ist fehlerhaft.


    Wer ist denn 192.168.178.001? Der schickt ja denMembership-Report.


    Das ist übrigens RFC3376 IGMPv3.



    Bzgl.SRF kann ich das hier z.B. mit:


    vlc "rtsp://octonet:554/?src=2&freq=10971&pol=h&msys=dvbs2&sr=29700&pids=all"


    tunen. Ich sehe zwar nichts, da es verschlüsselt ist, aber vlc kann PMTs etc. parsen.

    Hi,


    192.168.178.001 is my fritzbox 7390.


    the Swiss channels are not found by the Panasonic during auto setup or manual scan, will test this again when the octonet runs stable.


    CU
    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

    Hi,


    SRF test with VLC


    the debug lines "SSDP: 192.168.7.108" are looking also not correct, which is probably a cosmetic issue.


    CU
    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

    Einmal editiert, zuletzt von 9000H ()

    Hi,


    here are the igmp packets from the fritzbox, the last one triggers the segfault and tcpdump decodes it with 0 source(s)



    CU
    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

    Code
    20:35:19.236963 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 72, options (RA))
192.168.178.1 > 224.0.0.22: igmp v3 report, 5 group record(s) [gaddr 224.0.0.252 is_ex, 0 source(s)][|igmp]
0x0000: 46c0 0048 0000 4000 0102 912f c0a8 b201
0x0010: e000 0016 9404 0000 2200 61ed 0000 0005
0x0020: 0200 0000 e000 00fc 0200 0000


    Where is the rest of the packet?


    Parsed by hand it looks like this:



    where is the rest of record 2? and record 3,4,5?

    If this is the whole packet, it is too short. It should have 72 bytes according to the header.
    So, the segfault probably occurs when parsing the incomplete second record.


    I admit there are some checks missing. I will add code so that it better detects faulty packets.


    Mod.: Added some code tags, to make it better readable ...

    Thanks for the dump.


    I injected it with tcpreplay -t -i eth0 fritz.pcap
    and it is correctly parsed by an OctopusNet with 1.0.40 firmware:


    Hi,


    the dump was from this morning and from a crash, but as I was only able to sniff on the source the fritzbox and not at the target as there are no tools tcpdump/gdb etc and I could not mirror the port remotely.
    There are 2 switches in between a Netgear GS108v2 and a Cisco SLM2008 all with latest firmware.


    CU
    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

    Hi,


    ok next one, I managed to get tcpdump on the octonet to do a capture the same time as on the fritz.


    for me it looks like the fritz sends the packet right and on the octonet it's broken.


    CU
    9000h

    OK, so somebody messes up the packet.
    The Cisco SLM2008 might be the culprit. According to
    http://www.idealo.de/preisvergleich/OffersOfProduct/ 906479_-slm2008-linksys-by-cisco.html;jsessionid=eJhZmhR3nDZ8
    it destroys IGMPv3 reports with more than one group entry.


    I also still had an SLM2008 lying around and just ran my own tests with it.
    With snooping enabled in the Cisco I can see the same broken packet behind it. So, this is a bug in the Cisco firmware.
    I will of course still make the OctopusNet more robust against broken packets in the next version.


    Thanks for all your dumps helping me to hunt this down.

    Hi,


    thank's also for all the effort to identify the root cause.


    I had already got replacement for the SLM2008 today, and can confirm the igmp looks normal now with the new switch as shown below.
    So I hit two bugs at the same time, and the strangest thing was some hours a day the bug did not occur.
    This fixes one major issue here, now I need to check again what's happen to the Hotbird 13.0E SRF issue first.


    There is also a third hard to describe issue when a stream to the Panasonic TV is established and running.
    The behavior is probably triggered by change in the bit rate or a pid change, there is no optical sign but the audio sounds strange for some seconds.
    This is happen with for example on SKY SyFy with CI in the Panasonic most of the time when a movie ends and the picture is changing from bright to dark.
    The Digibit R1 shows the same issue btw. and this was the reason to go for the most expensive sat>ip server octonet.


    The issue is not there with the open source server minisatip(github), so my impression is the Panasonic is ok.


    With VDR there is no issue with the Digibit R1 and the octonet (SRF I have not checked).



    CU
    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

    Hi,


    Unfortunately I had again a crash but no details jet, hmm.
    I need to wait now if it reoccurs in debug mode.


    20.02 it's still alive


    seams to be ok now, but I'm still not happy in regards to the issues with the Panasonic.


    CU
    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

    2 Mal editiert, zuletzt von 9000H ()

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden