Lorawan-stack: 기본 스테이션 통합 : 재 연결 처리의 경합 상태로 인해 업 링크 전달이 영구적으로 실패합니다.

최신 업데이트에서는 시간 제한이 60 초에서 600 초로 변경되었습니다. 그러나 근본적인 문제는 남아 있으며 위의 단계를 통해 안정적으로 재현 할 수 있습니다.

이를 시뮬레이션하고 프록시 설정을 조정하여 문제가있는 위치를 확인하겠습니다. 그러나 이것은 게이트웨이의 비율에만 영향을 미치는 것으로 보입니다.
다음 그래프에서 상태 메시지 급증의 상승 에지는 600 초의 유휴 기간에 해당합니다. 게이트웨이가 다시 연결될 때마다 단일 상태 메시지 (이 스파이크를 설명 함)를 기록합니다. 그러나 트래픽이 보이면 감소가 미미하지만 모든 게이트웨이에 문제가 있음을 나타낼만큼 심각하지는 않습니다.

안녕하세요 Krishna,이 문제는 서버 측 연결 해제와 관련이 없지만 서버가 즉시 재 연결을 통해 부정확 한 클라이언트 측 연결 해제를 처리하는 방식과 관련이 있습니다. 이 문제는 모든 Basic Station 기반 게이트웨이에 영향을 미치며 위의 지침에 따라 안정적으로 재현 할 수 있습니다.

오류 패턴은 다음과 같습니다.

• 장치가 연결을 비정상적으로 종료 함 (전원 순환, 하드 리셋, WiFi 드롭, TTIG 분리 / 플러그인 등)
• 장치가 즉시 다시 연결됨
• 연결 해제 후 600 초 (이전에는 60 초) 동안 전달 된 패킷이 LNS에 표시됩니다.
• 600 초 이후 및 연결 해제 후 전달 된 패킷은 LNS에 표시되지 않습니다.

시간 제한을 60 초에서 600 초로 늘리면 문제가 더욱 심각해졌습니다. 60 초가되면 TTIG를 뽑은 사용자는 문제가 발생하지 않도록 다시 연결하기 전에 60 초 동안 기다려야했습니다. 이것은 특히 사람들이 공장 초기화를 할 때 충분히 자주 발생했을 수 있습니다. 이제 600 초를 사용하면 더 많은 비율이 문제에 부딪 히게되며 이는 또한 관찰되는 것이기도합니다.

이 시간 제한을 완전히 비활성화하면 아플까요? Basic Station은 기본적으로 TCP를 유지합니다 (https://github.com/lorabasics/basicstation/blob/c29b8502f8c715daecec6666835da6e981dc820a/src/sys.c#L637). 연결 상태를 확인하는 데 충분하지 않습니까?

나에게 그것은 오류 habbens처럼 보입니다, 공급자가 인터넷 연결을 끊고 다시 연결할 때 새 IP를 얻습니다.
매일 내 TTIG 게이트웨이가 더 이상 작동하지 않고 내 앱의 로그에 표시 될 때 마지막으로받은 값은 연결이 끊겼다가 다시 연결되기 전에 짧습니다.
게이트웨이를 다시 실행하려면 플러그를 뽑고 잠시 기다렸다가 다시 연결해야합니다.

그러나이 동작은 문제가되지 않았던 29.01 이후에만 발생합니다.

@JackGruber 인터넷 연결이 끊어진 후 처음 600 초 동안에도 업 링크를 정상적으로 수신 할 수 있는지 확인할 수 있습니까? (정확히 말하면 600 초에서 모뎀과 게이트웨이가 완전히 다시 연결되는 데 걸리는 시간을 뺀 값입니다.)

또는 600 초 동안 업 링크가 표시되지 않으면 장치가 얼마나 자주 전송합니까? (즉, 600 초 동안 일부 업 링크를 수신 할 것으로 예상하십니까?)

모니터링중인 장치는 5 분마다 전송됩니다.

02:42 RX 프레임
02:47 RX 프레임
02:53 RX 프레임
02:56 다시 연결
02:58 RX 프레임
프레임 없음
07:30 TTIG 분리 / 재 연결
07:36 RX 프레임

2:56 재 연결 후 600 초를 고려하면, 2:58 업 링크 이후에도 3:03 업 링크가 예상 될 수 있습니다 (아직 2:56 + 600 초 = 3:06). 그러나 600 초의 시간 제한이 2:53 업 링크 이후 (나중의 연결 유지 / 상태 메시지 이후가 아니라) 재설정되어 3:03 업 링크를 수신해야 할 때 TTN이 컨텍스트 / 상태를 잘못 지우 게 만들 수 있습니다. (물론 다른 이유로 인해 업 링크가 수신되지 않을 수도 있습니다.)

또한 7시 30 분에 TTIG를 다시 시작할 때 문제가 발생 하지 않고 600 초 후에 다시 문제가 발생 @beitler 의 ( 훌륭한 ) 분석을 확인하는 것 같습니다. 약 3:03 또는 3:06.

오늘은 시간을 자세히 살펴 보았습니다
TTIG의 로그 파일도 첨부했습니다.
불행히도 ISP 재 연결 당시부터는 아닙니다.
원하는 경우 긴 로그를 생성하여 재 연결도 포함합니다.
TTIG.log

시간표 (UTC + 1)
02:46 RX 메시지
02:51 RX 메시지
02:56 RX 메시지
02:58 RX 메시지
02:58 ISP 재 연결
03:01 RX 메시지
03:03 RX 메시지
03:06 RX 메시지
더 이상 수신 된 메시지가 없습니다.

TTN 콘솔
상태 : 연결되지 않음
마지막 확인 : 2020 년 2 월 11 일 03:05:04

06:46 Short Un- / Replug TTIG (10 초 동안 전원 없음)

TTN 콘솔
상태 : 연결됨
마지막 확인 : 2020 년 2 월 11 일 06:47:12

06:48 RX 메시지
....

방화벽 규칙에서 CUPS (rjs.sm.tc) 기본 연결이 허용되지 않고 CUPS-BACKUP (mh.sm.tc) 만 허용된다는 오류를 발견했습니다.

신고 해 주셔서 감사합니다. 문제를 확인하여 수정 중입니다. 이 문제는 우리의 독점 코드 기반에 있지만 여기서는 종료됩니다.

오늘 오후 +/- 18 시간 이후 백엔드에서 변경된 사항이 있습니까?
TTN 실내 게이트웨이를 10 분 이상 실행하는 것은 거의 불가능하지만 내가 아는 한 몇 달 동안 잘 작동했습니다.
DHCP 서버를 통해 IP 주소를 변경하면 TTN 네트워크에 10 분 동안 연결되지만 다시 손실됩니다. (재 연결도 10 분 동안 작동합니다)

@ TD-er, 10 분 (600 초) 이상 플러그를 뽑아 두셨습니까?

위에서 설명한 것처럼 2 월 6 일 변경 이후 필요했습니다. 2 월 7 일 이전에는 60 초 동안 전원을 뽑아 두어야했습니다. 오늘의 병합 된 수정 사항도 배포되었는지 확실하지 않습니다.

아니, 그렇게 오래 뽑지 않았다.
플러그를 뽑았을 때 몇 초 동안 만 분리되었습니다.
IP 주소의 DHCP 변경으로 인해 장치는 전원을 껐다가 껐다가 켰을 때도 DHCP 서버에서 새 IP를 수신하여 네트워크 연결을 다시 구축했습니다. 이로 인해 다시 사용할 수 없게 될 때까지 거의 정확히 10 분 동안 작동했습니다.

이제 잠시 플러그를 뽑은 다음 다시 연결 한 후 어떻게되는지 살펴 보겠습니다.

약 25 분 동안 전원을 끄고 이제 약 15 분 동안 전원을 꽂았 는데도 여전히 작동 중입니다.

오늘 수정 사항이 포함 된 v3.5.3을 릴리스하고 있으며 TTIG가 연결되는 서버에 배포 할 수있을 것입니다. 조만간 해결 되길 바랍니다.

내 실내 게이트웨이가 이제 이미 약 3 시간 동안 오프라인 상태이므로 아직 배포되지 않았기를 바랍니다.

최신 수정 사항을 배포 한 후이 문제를 듣지 못했습니다. 다시 관찰하면 언제든지 다시 열어주십시오.