Ich hatte im Kundenkreis nur 2 Boxen. Da bin ich über SymOS Connect und per VPN aber drangekommen.
Ich habe seit ein paar Tagen ebenfalls das Problem dass mein Heim nicht erreichbar ist.
Das hat jetzt jahrelang sehr zuverlässig funktioniert, jetzt ist es fast täglich so dass ich die Verbindung neu aufbauen muss. Heute mittag hats noch funktioniert, jetzt nicht mehr.
Sehr ärgerlich!
@Paresy: kann ich irgendwo sehen warum das nicht mehr funktioniert?
VG, Lutz
Ja, magst du mal im Logfile schauen mit welcher Fehlermeldung er abbricht?
paresy
Hi Paresy,
spannend, er meint das Traffic Limit sei erreicht - aber bitte woher kommt der Traffic?
Ich habe von extern gar nichts offen was so viel Traffic erzeugen könnte.
Bis vor ein paar Tagen ist das Problem auch nie aufgetreten, bzw. ich hatte nie eine Fehlermeldung - schaue natürlich aber auch nicht jeden Tag von extern da drauf…
Any Ideas?
VG, Lutz
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_packet_socket_callback: packet: read type 90 [len=76,padding=8,comp=67,payload=67]
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_packet_process: Dispatching handler for packet type 90
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_packet_channel_open: Clients wants to open a forwarded-tcpip channel
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_packet_need_rekey: rekey: [data_rekey_needed=0, out_blocks=119, in_blocks=547]
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_message_channel_request_open_reply_accept_channel: Accepting a channel request_open for chan 0
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_packet_need_rekey: rekey: [data_rekey_needed=0, out_blocks=120, in_blocks=548]
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_socket_unbuffered_write: Enabling POLLOUT for socket
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | packet_send2: packet: wrote [type=91, len=28, padding_size=10, comp=17, payload=17]
12.09.2023 15:19:22 | 12965 | MESSAGE | Connect Control | [11] Neuer Kanal erstellt
12.09.2023 15:19:22 | 12965 | MESSAGE | Connect Control | [11] Verbinde mit 127.0.0.1:3777...
12.09.2023 15:19:22 | 12965 | MESSAGE | Connect Control | [11] Verbunden mit lokalen Server
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_packet_socket_callback: packet: read type 94 [len=812,padding=15,comp=796,payload=796]
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_packet_process: Dispatching handler for packet type 94
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | channel_rcv_data: Channel receiving 787 bytes data in 0 (local win=32000 remote win=24576)
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | channel_default_bufferize: placing 787 bytes into channel buffer (stdout)
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | channel_rcv_data: Channel windows are now (local win=31213 remote win=24576)
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_packet_need_rekey: rekey: [data_rekey_needed=0, out_blocks=120, in_blocks=596]
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_socket_unbuffered_write: Enabling POLLOUT for socket
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | packet_send2: packet: wrote [type=93, len=28, padding_size=18, comp=9, payload=9]
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | grow_window: growing window (channel 53:0) to 1280000 bytes
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_packet_need_rekey: rekey: [data_rekey_needed=0, out_blocks=120, in_blocks=596]
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_channel_read_timeout: Read (787) buffered : 787 bytes. Window: 1280000
12.09.2023 15:19:22 | 12965 | MESSAGE | Connect Control | [11] Erkannte URL... /api/
12.09.2023 15:19:22 | 12965 | MESSAGE | Connect Control | [11] Lese entfernte Daten... 787 bytes
12.09.2023 15:19:22 | 12965 | MESSAGE | Connect Control | [11] Schreibe entfernte Daten...
12.09.2023 15:19:22 | 12965 | MESSAGE | Connect Control | [11] Schreibe entfernte Daten... 787 bytes
12.09.2023 15:19:22 | 12965 | MESSAGE | Connect Control | [11] Lese lokale Daten... Limit: 65536
12.09.2023 15:19:22 | 12965 | MESSAGE | Connect Control | [11] Lese lokale Daten... 218 bytes
12.09.2023 15:19:22 | 12965 | ERROR | Connect Control | Traffic Limit für Symcon Connect ist erreicht (1073741824 bytes)
12.09.2023 15:19:22 | 12965 | MESSAGE | Connect Control | [11] Schreibe lokale Daten... Verfügbar: 166, Fenster: 24576
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_packet_need_rekey: rekey: [data_rekey_needed=0, out_blocks=130, in_blocks=606]
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_socket_unbuffered_write: Enabling POLLOUT for socket
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | packet_send2: packet: wrote [type=94, len=188, padding_size=12, comp=175, payload=175]
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | channel_write_common: ssh_channel_write wrote 166 bytes
12.09.2023 15:19:22 | 12965 | MESSAGE | Connect Control | [11] Schreibe lokale Daten... 166 bytes
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_packet_socket_callback: packet: read type 96 [len=12,padding=6,comp=5,payload=5]
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_packet_process: Dispatching handler for packet type 96
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | channel_rcv_eof: Received eof on channel (53:0)
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_packet_need_rekey: rekey: [data_rekey_needed=0, out_blocks=130, in_blocks=596]
12.09.2023 15:19:22 | 12965 | MESSAGE | Connect Control | [11] Lese entfernte Daten... EOF
12.09.2023 15:19:22 | 12965 | MESSAGE | Connect Control | [11] Lese lokale Daten: Geschlossed
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_packet_need_rekey: rekey: [data_rekey_needed=0, out_blocks=130, in_blocks=596]
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_socket_unbuffered_write: Enabling POLLOUT for socket
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | packet_send2: packet: wrote [type=96, len=12, padding_size=6, comp=5, payload=5]
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_channel_send_eof: Sent a EOF on client channel (53:0)
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_packet_need_rekey: rekey: [data_rekey_needed=0, out_blocks=130, in_blocks=596]
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_socket_unbuffered_write: Enabling POLLOUT for socket
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | packet_send2: packet: wrote [type=97, len=12, padding_size=6, comp=5, payload=5]
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_channel_close: Sent a close on client channel (53:0)
12.09.2023 15:19:22 | 12965 | MESSAGE | Connect Control | [11] Alter Kanal freigegeben. Übrigbleibende Kanäle: 0
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_packet_socket_callback: packet: read type 97 [len=12,padding=6,comp=5,payload=5]
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_packet_process: Dispatching handler for packet type 97
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | channel_rcv_close: Received close on channel (53:0)
12.09.2023 15:19:22 | 12965 | DEBUG | Connect Control | ssh_packet_need_rekey: rekey: [data_rekey_needed=0, out_blocks=130, in_blocks=596]
Wäre es nicht möglich, die Wartezeit bei Fehlschlägen zwar exponentiell zu steigern, aber auf max. 60 Minuten zu deckeln, ohne dass euer Server zusammenbricht?
Verbindungsfehler treten vermutlich am häufigsten „lokal“ beim Anwender durch gestörte Internetverbindungen auf.
Wenn das Internet mal 8 oder 24 Stunden weg ist und Symcon dann erst exponentiell 2-5 Tage? später wieder einen Connect versucht, ist das irgend wie kausal schwer zusammen zu bekommen…
Nein. Maximal 24h
Michael
Hi Jürgen,
genau sowas werden wir demnächst machen. Wir werden langsamer steigern und bei max. 32 Minuten enden. Das sind dann am Tag maximal 60 Anfragen und somit voll ok. Das Limit für Connect werden wir dann auf Maximal 100 anheben.
Außerdem werden wir zusätzlich ein Zeitfenster haben, dass die Wartezeit leicht variiert und unser Connect Server nicht alle Anfragen auf einmal bekommt.
Diese Änderungen kommen noch zur 7.0 und wahrscheinlich also Update für die 6.4.
paresy
Hallo Paresy,
habe herausgefunden woher der Traffic kommt (in irgendeinem anderen Thread hat jemand da schon mal ein Auswertescript gebaut):
Die Console erzeugt innerhalb von 2h >500MB Traffic, auch wenn sie ungenutzt wird:
Dabei ist da nur der Objektbaum offen und ich habe bewusst nichts geöffnet und bearbeitet:
Ist das korrekt bzw. sinnvoll dass da so viel Traffic für „nichts“ erzeugt wird?
Bei der Menge ist mir klar dass da am Tag 1GB innerhalb kürzester Zeit zusammen kommt.
ich würde aber behaupten dass ich „früher“ also noch vor ein paar Monaten die Console von Extern den ganzen Tag lang offen lassen konnte ?!?
IP-Symcon 6.4, Ubuntu (amd64), 23.05.2023, 6dccc096176c
VG, Lutz
Update: nach dem gestern die Trafficgrenze erreicht wurde bleibt das Heim auch heute nicht erreichbar.
VG, Lutz
Kann ich bestätigen, bei mir auch…
Leider hat es die Hardware vom Hauptsystem des Connect Dienstes erwischt und der automatische Recover hat nicht geklappt. Ich habe das Problem jetzt gelöst, sodass Sie die System langsam wieder neu verbinden müssten.
paresy
Hallo zusammen. Hatte sich wohl schon angekündigt. Ich habe die ganze Woche schon Probleme mit Connect, ohne das ich etwas an meinem System geändert habe. Zur Zeit wieder verbunden.
Danke.
Sascha
Tja, nun hat es mich auch erwischt.
Nach Arbeiten an einer IPS View (x-mal geladen) ist das Limit für Symcon Connect erreicht.
Also funktionieren meine Fernbedienungen auch nicht mehr.
Ich habe jetzt 24 Stunden gewartet.
Dann in der Connect Instanz „Connect“ deaktiviert und wieder aktiviert.
Leider keine Besserung.
Muss ich wirklich Symcon neu starten?
Ist es wirklich so, um einen Zähler zurück zu setzen, muss das ganze System neu gestartet werden?
Immer wenn Symcon neu gestartet wird, muss ich alle meine Nanoleafs neu einrichten.
Und das ist nicht lustig 
Was kann ich tun?
Ich empfehle, per VPN zu arbeiten.
Was den ganzen Zweck des Connect-Dienst für die meisten ad absurdum führt.
1 „Gefällt mir“
Magst du dafür evtl. ein neues Thema eröffnen? Das klingt ja nicht wirklich so, als wenn es korrekt wäre, oder?
Für die meisten reichen die 1 GB pro Tag. Ich vermute deine View ist etwas größer?
paresy
Ich zitiere von Connect Control — IP-Symcon :: Automatisierungssoftware
Diese Verbindung kann dazu genutzt werden von überall via Verwaltungskonsole das System zu verwalten oder über die Visualisierungen und mobilen Apps darauf zuzugreifen.
Da steht nichts von umfangreichen Arbeiten an IPSView
Guten Morgen,
mache ich.
Wo kann ich denn eigentlich die Größe einer View sehen.
Ich kann nur die Größe des ViewBackups benennen.
Das ist dann doch bestimmt die Größe der View?
Und ja, die betroffene View ist schon recht umfangreich.
Backupgröße 10,9MB
Und wo kann ich den Traffic von Symcon Connect sehen?
Und ja, 1 GB reichen sicher.
Ich erreichte das Limit auch nur wenn ich mehrfach einen View hochgeladen habe.
Nun gut. Neustart gemacht und es läuft wieder.
Mit dieser Funktion erhältst du alle Werte
$counter=CC_GetTrafficCounter(52365);
$limitcounter=$counter["LimitCounter"] / 1024000;
$localcounter=$counter["LocalCounter"] / 1024000;
$remotecounter=$counter["RemoteCounter"] / 1024000;
Näheres findest du in der Dokumentation.
1 „Gefällt mir“