ASUS 무슨 일이 일어났습니까?

오늘 PDT 오전 6시 45분경에 일어 났을 때 인터넷 서비스를 사용할 수 없는 것 같았습니다. 휴대전화에서 Wi-Fi 네트워크에 연결되어 있다고 말했지만 연결되지 않았습니다. “음, 이상하군.” 나는 생각했다. 해당 지역의 섬유 절단이나 다른 것일까요? 내 데스크톱 Windows PC에서 내 IRC 클라이언트를 봤습니다. 연결이 끊어졌을 때의 타임스탬프를 기록하기 때문에 좋습니다.

03:24:23 - 연결 끊김(원격 호스트 폐쇄 소켓)
이 시점에서 내 연결은 3시간 이상 중단되었습니다. 기이한! ASUS RT-AC86U 라우터의 웹 인터페이스에 로그인하여 무슨 일이 일어나고 있는지 확인해야겠다고 생각했습니다. 전혀 예상하지 못한 일이 발생했습니다. 페이지가 완전히 로드되지 않았습니다. 그것의 일부는 연결 오류를 나타내는 작은 "슬픈 페이지" 아이콘을 보여주었습니다.

대신 라우터에 SSH를 시도했습니다. 처음 몇 번의 연결 시도는 실패했고, 마침내 접속했습니다. 하지만 제가 찾은 것은 어떤 명령도 실행할 수 없다는 것이었습니다. 그것은 나에게이 오류를 다시 뱉어냅니다.

-sh: 포크할 수 없음
좋아, 뭔가 정말 엉망이었어. 이 시점에서 라우터의 전원을 껐다 켜기로 결정했습니다. 이상한 결함이 발생했을 수도 있습니다. 이상하게도 이 라우터는 시간이 지남에 따라 2.4GHz Wi-Fi 문제를 제외하고는 내가 가지고 있던 이후로 꽤 견고했습니다. 그것은 제가 오늘 다루고 싶지 않은 또 다른 이야기입니다.

어쨌든 라우터가 다시 돌아왔을 때 모든 것이 괜찮아 보였습니다. 그런데 40분 후 같은 증상으로 연결이 다시 끊어졌습니다.

07:26:23 - 연결 끊김(원격 호스트 폐쇄 소켓)
둘 다 정확히 23초에 있었다는 사실은 아마도 미친 우연의 일치일 것입니다. 나는 이 시점에서 약간 패닉에 빠지기 시작했다. 나는 이런 문제가 내 ISP의 잘못일 수 있다고 정말로 생각하지 않았지만 내 네트워크 설정에 대해 단 한 가지도 변경하지 않았습니다. 꽤 오랫동안 라우터 펌웨어를 업데이트하지 않았습니다. 자동 업데이트가 꺼져 있었고 마지막으로 확인한 결과 ASUS는 새 업데이트를 출시하지 않았습니다.

이번에는 라우터에 SSH로 성공적으로 연결할 수 있었고 몇 가지 간단한 진단을 수행했습니다. 나는 무슨 일이 일어나고 있는지 보여주기 위해 top을 사용했습니다. 슬프게도 스크린샷을 찍지 않았지만 asd라는 프로세스가 내 CPU의 50%를 차지하는 것을 알았습니다. /proc/cpuinfo에 따르면 CPU는 듀얼 코어이므로 50%는 하나의 코어가 완전히 고정되었음을 의미합니다.

나의 첫 번째 본능은 asd를 검색하는 것이었지만(작동하지 않는 인터넷 연결에서는 어려웠습니다) ASUS 보안 데몬이라는 것을 알았습니다. 이로 인해 기분이 조금 나아졌지만 여전히 문제에 관여해야 한다고 느꼈습니다. 일반적으로 라우터에 SSH로 연결할 때 top은 CPU의 50%에 가까운 곳을 사용하는 것을 표시하지 않습니다.

Reddit과 Twitter에서 다른 사람이 비슷한 문제를 겪었는지 검색하기 시작했고 그때 @stevecantsmell 의 다음 트윗을 발견했습니다 .

그가 말한 방식은 그가 ISP에서 일하는 것처럼 들립니다. 이것은 시간 프레임까지 내 문제와 매우 유사하게 들렸습니다! 그것은 내 시간대의 오전 3시에 해당합니다. 나는 그의 조언을 따랐다. 라우터를 재빨리 재부팅하고 웹 UI의 펌웨어 업데이트 페이지로 바로 이동했습니다. 아니나 다를까, 저는 3.0.0.4.386.48260 버전을 실행 중이었고 지난달에 출시된 3.0.0.4.386.51529에 대한 업데이트가 있었습니다. 3월에 나온 펌웨어 릴리스도 놓친 것으로 나타났습니다. 라우터를 최신 상태로 유지하고 싶지만 약 1년 동안 업데이트가 없었기 때문에 더 느린 간격으로 확인하고 있었습니다.

업데이트를 설치할 수 있었습니다. 업데이트가 완료된 후 라우터가 자체적으로 재부팅되었으며 그 이후로 모든 것이 정상이었습니다. asd는 더 이상 CPU의 50%를 사용하지 않습니다. 이 문제가 발생한 후 몇 시간 동안 다양한 ASUS 라우터에서 이와 똑같은 문제가 발생한 셀 수 없이 많은 사람들에 대해 들었습니다. 더 많은 사람들이 위에 링크된 Twitter 스레드에 참여했으며 Reddit 및 SNBForums 에 여러 게시물이 있었습니다 . 경우에 따라 문제를 해결하기 위해 베타 펌웨어가 필요했습니다. 저 혼자가 아니라는 사실이 위안이 되기도 했지만 너무 많은 사람들이 영향을 받았다는 소식을 듣고 엄청나게 답답하기도 했습니다. ISP 기술 지원 직원은 오늘 "멋진" 하루를 보냈을 것입니다.

그래서… 이 모든 일을 시작하기 위해 오늘 아침 일찍 정확히 무슨 일이 일어났습니까? ASUS의 asd 프로그램이 서버에서 어떤 종류의 잘못된 파일을 다운로드하여 끊겼습니까? 누군가 ASUS가 최근에 패치한 취약점에 대해 대규모 익스플로잇을 시도했습니까? 펌웨어 업데이트로 문제가 실제로 해결되었습니까? 아니면 곧 다시 시작되는 일련의 이벤트가 중단되었습니까?

잘 모르겠지만 지금까지 모은 것이 여기 있습니다. 내 라우터의 파일 /jffs/asd.log(및 /jffs/asd.log.1, 이전 항목이 포함된 롤오버 버전이라고 생각됨)가 수천 줄의 다음 오류 메시지로 채워진 것 같습니다. :

5월 17일 03:18:14 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7669)]webs_update 수행
5월 17일 03:18:21 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7687)]펌웨어 정보 검색
5월 17일 03:18:21 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7702)]펌웨어 업데이트 확인 최초
5월 17일 03:18:21 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7733)]펌웨어 업그레이드 필요 없음
5월 17일 03:18:51 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7669)]webs_update 수행
5월 17일 03:18:51 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7687)]펌웨어 정보 검색
5월 17일 03:18:51 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7707)]펌웨어 업데이트 확인 1회
5월 17일 03:19:21 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7669)]webs_update 수행
5월 17일 03:19:21 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7687)]펌웨어 정보 검색
5월 17일 03:19:21 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7707)]펌웨어 업데이트 확인 1회
5월 17일 03:19:51 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7669)]webs_update 수행
5월 17일 03:19:51 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7687)]펌웨어 정보 검색
5월 17일 03:19:51 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7702)]펌웨어 업데이트 확인 최초
5월 17일 03:19:51 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7733)]펌웨어 업그레이드 필요 없음
5월 17일 03:22:58 커널: CPU: 1 PID: 12870 통신: 터치 오염: PO 4.1.27 #2
5월 17일 03:22:58 커널: 하드웨어 이름: Broadcom-v8A(DT)
5월 17일 03:22:58 커널: 태스크: ffffffc01730eb00 ti: ffffffc0126dc000 task.ti: ffffffc0126dc000
5월 17일 03:22:58 커널: PC는 0xf6dcc90c에 있습니다.
5월 17일 03:22:58 커널: LR은 0xf6dccfd4에 있습니다.
5월 17일 03:22:58 커널: pc: [<00000000f6dcc90c>] lr: [<00000000f6dccfd4>] pstate: 400f0010
5월 17일 03:22:58 커널: sp : 00000000fff3d154
5월 17일 03:22:58 커널: x12: 00000000fff3d188
5월 17일 03:22:58 커널: x11: 00000000fff3d1d4 x10: 00000000f76334c0
5월 17일 03:22:58 커널: x9: 00000000fff3d189 x8: 00000000fff3d184
5월 17일 03:22:58 커널: x7 : 000000000000000b x6 : 0000000000000000
5월 17일 03:22:58 커널: x5: 00000000fff3e8bc x4: 00000000fff3d420
5월 17일 03:22:58 커널: x3: 000000006e69622f x2: 00000000fff3e8bc
5월 17일 03:22:58 커널: x1: 00000000fff3d420 x0: ffffffffffffffff2
5월 17일 03:23:17 커널: CPU: 1 PID: 12894 통신: 터치 오염: PO 4.1.27 #2
5월 17일 03:23:17 커널: 하드웨어 이름: Broadcom-v8A(DT)
5월 17일 03:23:17 커널: 태스크: ffffffc01730eb00 ti: ffffffc01151c000 task.ti: ffffffc01151c000
5월 17일 03:23:17 커널: PC는 0xf6dcc90c에 있습니다.
5월 17일 03:23:17 커널: LR은 0xf6dccfd4에 있습니다.
5월 17일 03:23:17 커널: pc: [<00000000f6dcc90c>] lr: [<00000000f6dccfd4>] pstate: 400f0010
5월 17일 03:23:17 커널: sp : 00000000fff3d154
5월 17일 03:23:17 커널: x12: 00000000fff3d188
5월 17일 03:23:17 커널: x11: 00000000fff3d1d4 x10: 00000000f76334c0
5월 17일 03:23:17 커널: x9: 00000000fff3d189 x8: 00000000fff3d184
5월 17일 03:23:17 커널: x7 : 000000000000000b x6 : 0000000000000000
5월 17일 03:23:17 커널: x5: 00000000fff3e8bc x4: 00000000fff3d420
5월 17일 03:23:17 커널: x3: 000000006e69622f x2: 00000000fff3e8bc
5월 17일 03:23:17 커널: x1: 00000000fff3d420 x0: ffffffffffffffff4
5월 17일 03:23:51 watchdog: DST 시간으로 인한 restart_firewall 변경(1->0)
5월 17일 03:23:51 rc_service: watchdog 1807:notify_rc restart_firewall
5월 17일 03:23:51 rc_service: watchdog 1807:notify_rc restart_wan
5월 17일 03:23:51 rc_service: watchdog을 통해 "restart_firewall" 대기 중...
5월 17일 03:23:51 방화벽: 규칙 적용 오류(2857)
5월 17일 03:23:51 방화벽: 규칙 적용 오류(2892)
5월 17일 03:23:51 서비스: 규칙 적용 오류(17779)
5월 17일 03:23:51 방화벽: 규칙 적용 오류(4580)
5월 17일 03:23:52 miniupnpd[5322]: MiniUPnPd 종료
5월 17일 03:23:53 DualWAN: 단일 wan wan_led_control 건너뛰기 - WANRED 꺼짐
5월 17일 03:23:58 dnsmasq-dhcp[5503]: /var/lib/misc/dnsmasq.leases 쓰기 실패: 장치에 남은 공간 없음(60초 후에 다시 시도)

그래서 오전 3시 18분에 자동 펌웨어 업데이트를 확인했고(다시 자동 업데이트를 껐습니다) 3분 후 커널이 무언가에 대해 화를 냈습니다. 하단에서 볼 수 있듯이 다른 것들도 실패하기 시작했습니다. dnsmasq 오류는 /var/lib/misc에 사용 가능한 공간이 없음을 분명히 나타냅니다. /var는 tmpfs로 마운트되어 있으므로 라우터의 RAM이 부족하다는 의미라고 생각합니다.

자동 펌웨어 확인은 매일 아침 로그에서 확인하는 것이 꽤 일반적인 것처럼 보이지만, 관련이 있는 경우 월요일에 실패했습니다.

5월 15일 03:18:05 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7669)]webs_update 수행
5월 15일 03:19:17 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7737)]에서 펌웨어 정보를 검색할 수 없음: webs_state_update = 1, webs_state_error = 1, webs_state_dl_error = 0, webs_state_info.len = 23
5월 15일 03:19:46 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7669)]webs_update 수행
5월 15일 03:21:11 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7737)]에서 펌웨어 정보를 검색할 수 없음: webs_state_update = 1, webs_state_error = 1, webs_state_dl_error = 0, webs_state_info.len = 23
5월 15일 03:21:40 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7669)]do webs_update
5월 15일 03:22:44 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7737)]에서 펌웨어 정보를 검색할 수 없음: webs_state_update = 1, webs_state_error = 1, webs_state_dl_error = 0, webs_state_info.len = 23
자동 펌웨어 검사가 문제가 처음 시작된 시점과 관련이 있는지조차 확실하지 않습니다. 아마도 그 시간에 실행되는 여러 주기적 작업 중 하나일까요? 일반적으로 자동 펌웨어 확인 후 약 30-40분 후에 이 메시지가 표시되는 것 같습니다.

ahs: [read_json]ahs JSON 파일을 업데이트합니다.
이것은 내가 활성화했는지 여부조차 알지 못하는 "ASUS Healing System"과 관련이 있는 것 같습니다. 또한 자동 업데이트 확인과 ahs JSON 메시지가 첫 번째 라우터 재부팅 후 오전 6시 47분경에 로그에 다시 표시되는 것을 보았습니다. 그 후 얼마 지나지 않아 dnsmasq.leases "no space left on device" 오류가 다시 발생하여 다시 RAM이 부족한 것 같습니다. 아마도 asd가 CPU 시간 과 RAM을 잡아먹고 있었을 것입니다.

여기에서 일어난 일에 대한 추가 정보가 있는 사람이 있습니까? 내 두 가지 이론은 다음과 같습니다. ASUS에서 잘못된 파일을 다운로드하여 충돌을 일으켰거나 누군가 내 RT-AC86U 라우터에 대한 ASUS의 최신 두 가지 업데이트 중 하나에서 패치된 취약점을 악용하고 있었습니다. 후자라면 당연히 펌웨어를 최신으로 유지하지 못한 제 잘못이지만 한밤중에 자동 파일 다운로드가 원인이 된 것은 아닌지 궁금합니다. 무슨 일이 있었는지 너무 궁금하다! 오늘날 ASUS 라우터를 사용하는 사람 중에 비슷한 문제가 발생 하지 않았 습니까?

easy@

ASUS 무슨 일이 일어났습니까?

댓글

티스토리툴바