IP 를 모르는 LS XGT PLC 를 현장에서 찾는 법

내가 시운전하지 않은 반 앞에 서 있습니다. XG5000 은 연결하려면 IP 를 먼저 요구하는데, CPU 에 붙어 있던 라벨은 떨어졌거나 애초에 없었고, 폴더 속 도면은 개조를 두 번 거치기 전 것입니다. 설비는 돌아가는 중이라 하나씩 뽑아 보며 확인할 수도 없습니다.

대역 전수 스캔이 첫 수로는 좋지 않은 이유

반사적으로 나오는 방법은 대역을 훑는 것입니다. 254개 주소에 ICMP 나 몇몇 포트로 TCP 연결을 시도해 응답하는 것을 봅니다. 실제로 자주 통하기 때문에 다들 계속 이렇게 합니다. 다만 살아 있는 제어망에서는 세 가지 문제가 있습니다.

• 시끄럽습니다. 대역 안의 모든 주소로 패킷이 갑니다 — 이번 작업과 아무 상관 없는 드라이브·HMI·안전 장치까지 포함해서입니다. 오래된 장비 중에는 예상 못 한 연결 시도를 잘 견디지 못하는 것도 있습니다.
• 느립니다. 254개 주소 × 포트별 타임아웃은 금방 쌓이고, 보통 이 작업은 누군가 기다리는 중에 하게 됩니다.
• 응답했다는 것만 알려줍니다. 응답한 다섯 대 중 어느 것이 PLC 인지는 여전히 따로 가려내야 합니다.

아래의 벤더 전용 발견은 이 셋을 모두 피합니다. 전체 패킷이 한 개뿐이고, 응답은 2초 안에 돌아오며, 응답한 것은 정의상 LS PLC 입니다.

주고받는 내용

UDP 소켓을 2007 포트에 bind 하고 broadcast 를 켠 뒤, 같은 포트의 브로드캐스트 주소로 요청을 보냅니다. 요청 문자열은 두 가지를 함께 보내는 편이 좋습니다 — 펌웨어 세대에 따라 응답하는 쪽이 다릅니다.

bind    UDP 0.0.0.0:2007          (broadcast 활성화)
send -> 255.255.255.255:2007      "STATION_LIST_REQ_DATA"
send -> 255.255.255.255:2007      "NP_DATA_REQ_V2"
listen  약 2초

recv <- 192.168.0.31:2007         "STATION_LIST_RESP_DATA…"   <-- PLC, 192.168.0.31
recv <- 192.168.0.44:2007         "STATION_LIST_RESP_DATA…"   <-- 또 한 대

payload 가 평문 ASCII 라서 패킷 캡처에서도 눈으로 바로 알아볼 수 있습니다. 정작 중요한 것은 응답 본문 안이 아니라 응답 datagram 의 출발지 주소 입니다. STATION_LIST_RESP_DATA 표지 뒤쪽은 station 상세 정보이고, XG5000 이 가리킬 주소만 필요하다면 통째로 무시해도 됩니다.

소켓을 임의 포트가 아니라 2007 에 bind 한다는 점을 유의해야 합니다. 응답이 그 포트로 돌아오기 때문인데, 같은 PC 의 다른 프로세스가 이미 그 포트를 쥐고 있으면 bind 가 실패하고 응답이 하나도 안 보입니다. 네트워크가 비어 있는 것이 아니라 포트가 물려 있는 것인데, 화면상으로는 구분되지 않아 오해하기 쉬운 자리입니다.

아무것도 응답하지 않을 때

결과가 비었다고 PLC 가 없는 것은 아닙니다. 실제로 원인이 되는 빈도 순서로 적으면 이렇습니다.

• PLC 가 다른 서브넷에 있습니다. 255.255.255.255 브로드캐스트는 첫 라우터에서 멈춥니다 — 로컬 세그먼트를 벗어나지 못합니다. 폰이나 노트북이 사무망 VLAN 에서 DHCP 주소를 받았고 제어망은 따로 있다면, 아무리 기다려도 오지 않습니다. 가장 흔한 원인입니다.
• Wi-Fi 인데 AP 가 브로드캐스트를 걸러냅니다. 기업용 무선에서는 client isolation 과 broadcast/multicast 억제가 기본으로 켜져 있는 경우가 많습니다. 요청은 단말을 떠났지만 AP 에서 죽습니다.
• 제어망이 유선 전용입니다. PLC 세그먼트를 의도적으로 무선에서 떼어 놓은 현장이 많습니다. 이 경우 폰으로는 어떤 방법으로도 닿지 않습니다.
• 2007 포트가 이미 점유 돼 있습니다. 위에 적은 경우입니다.
• CPU 에 이더넷 모듈이 없거나 FEnet 모듈은 꽂혀 있지만 설정되지 않았습니다. 시리얼 전용 CPU 는 네트워크 발견에 응답할 방법 자체가 없습니다.

앞의 두 가지는 다른 것을 시도하기 전에 먼저 확인할 값어치가 있습니다. 도구 쪽에서는 어느 경우든 "요청을 정상적으로 보냈다" 로 보이기 때문에 화면만 봐서는 구분되지 않습니다.

주소를 찾은 다음

IP 를 알아냈으면 XG5000 은 평소대로 연결합니다. 온라인 → 접속 설정에서 연결 방식을 이더넷으로 두고 주소를 넣은 뒤 접속하고, PLC 로부터 프로젝트를 읽어 옵니다. 타임아웃이 아니라 연결 거부가 뜬다면 주소는 맞고 다른 것이 문제입니다 — FEnet 모듈의 접속 테이블이 가득 찬 경우가 대부분이고, 남아 있던 세션이 타임아웃되면 풀립니다.

내 설비가 아닌 곳을 스캔하는 문제

발견은 읽기 동작입니다. 레지스터도, 모드 스위치도, 프로그램도 건드리지 않습니다. 그래도 산업 장비를 향해 나가는 트래픽인 것은 분명하고, 내 현장이 아니라면 그 판단은 설비 소유자의 몫이지 내 몫이 아닙니다. 먼저 승인을 받아야 합니다. write·job 프레임은 아예 다른 범주이고, 발견 도구에 들어갈 이유가 없습니다.

관련 글

• 포트로 산업 장비 식별하기 — 현장 네트워크의 나머지 다섯 포트가 뜻하는 것과, 포트 번호를 어디까지 믿을 수 있는지.