Wiznet makers

Overview

This repository is an embedded network diagnostic tool built around an ESP32-S3, a WIZnet W5500 Ethernet path, a small SPI display, a CST816 touch controller, and an LVGL-based interface. Its visible feature set is narrow but practical: collect LLDP data from the attached Ethernet segment, show summary and detail views, list VLAN information when present, and let the operator run ping tests from the same device.

Main Content

The core design choice is to capture LLDP at the Ethernet frame level instead of treating the device as only an IP endpoint. In the Ethernet input callback, the code checks the EtherType field, handles 0x88CC frames as LLDP, parses them, and only forwards non-LLDP traffic to the normal network stack. The code also enables promiscuous mode on the Ethernet interface, which is consistent with the goal of observing discovery traffic directly from the wire.

That is the repository’s clearest difference from a conventional network utility that starts at IP. LLDP is a vendor-independent link-layer discovery protocol used by network devices to advertise identity and capabilities to directly connected neighbors, so a tool that wants to surface that information cleanly needs access to the Ethernet side of the connection, not just socket-level traffic.

The LLDP parser is intentionally scoped to the most useful operator-facing fields. The code defines buffers for chassis ID, port ID, port description, TTL, system name, system description, management address, port VLAN ID, and a bounded list of VLAN names. It also recognizes IEEE 802.1 organizational TLVs for PVID and VLAN name, which makes the output more useful in managed switch environments than a parser limited to the mandatory LLDP fields.

The user interface is organized as four horizontal LVGL tiles: a summary view, an LLDP details page, a VLAN page, and a ping page. The update timer populates the summary screen with the detected port, VLAN, system name, description, and management address, while the ping screen can prefill its target prefix from the device’s acquired IP address and report live or completed ping statistics.

WIZnet is not incidental here. The repository description explicitly names the W5500, the firmware creates the Ethernet MAC and PHY with esp_eth_mac_new_w5500() and esp_eth_phy_new_w5500(), and the project configuration enables the W5500 SPI-Ethernet target. In practical terms, the WIZnet Ethernet product provides the wired attachment point that lets the ESP32-S3 participate on Ethernet and inspect incoming frames through ESP-IDF’s Ethernet path.

System Context

This device fits best as a field-side helper for network verification, not as a control-plane component. It can reveal what the neighboring switch or access device is advertising over LLDP, expose VLAN hints, show the management address when present, and confirm basic reachability with ping, all without requiring a laptop-based workflow.

Architecture / Design Considerations

The architecture is cleanly split into three parts: Ethernet capture and dispatch in main.c, LLDP decoding in lldp.c, and ICMP probing in ping.c. Dependency metadata also shows an LVGL 8.4 UI stack and a CST816S touch component, which matches the display-and-touch path in the main application code.

The most failure-sensitive design point is the Ethernet input path override. Because LLDP handling happens in the receive callback before other traffic is handed to esp_netif_receive(), any parsing mistake, buffer-handling error, or callback-side stall risks damaging both the diagnostic function and normal Ethernet connectivity. That is a higher-cost mistake than a cosmetic UI problem because it can make the tool blind and disconnected at the same time.

A second important boundary is scope. The code stores one current lldp_info structure and refreshes the UI from that state; it is not a topology database, a switch management station, or a packet recorder. The design favors immediate local inspection over history, correlation, or remote orchestration.

Possible Implications

As a pattern, this repository shows how a small embedded device can combine raw frame inspection, local UI, and simple active probing into a single-purpose maintenance tool. The same structure could be adapted for other adjacent-device diagnostics, but the moment raw frame capture or wired Ethernet is removed, the project stops being an LLDP monitor in the practical sense and becomes only a generic touchscreen network utility.

Conclusion

This repository is technically modest but architecturally clear. Its value is not in broad networking coverage, but in a focused combination of wired Ethernet access, LLDP parsing, VLAN-aware display, and on-device ping. The project’s strongest idea is that discovery data should be read where it actually lives: on the Ethernet link itself.

전체 개요

이 저장소는 ESP32-S3 기반의 소형 현장 진단 장치로 보시면 됩니다. 핵심은 유선 Ethernet 포트에 연결된 상대 장비가 내보내는 LLDP 정보를 직접 읽어 와서, 포트 정보, 시스템 이름, 관리 주소, VLAN 단서 등을 화면에 보여주고, 같은 장치에서 바로 ping까지 수행하게 만든 구조입니다. 저장소 설명과 코드상 구성요소를 보면 W5500 기반 Ethernet, ST7789 디스플레이, CST816 터치, LVGL UI, 별도 LLDP 파서, 별도 ping 모듈로 구성되어 있습니다.

즉, 이 프로젝트는 “네트워크를 운영하는 장치”가 아니라, 네트워크 옆에서 현재 연결 상태를 읽고 확인하는 보조 진단 단말에 가깝습니다. 이 보조 수단으로서의 위치가 중요합니다. 스위치 설정을 바꾸거나 토폴로지를 제어하지 않고, 인접 장비가 지금 무엇을 광고하고 있는지를 직접 확인하는 데 초점이 있습니다.

문제의식과 기술적 맥락 재구성

일반적인 네트워크 확인은 보통 노트북, 스위치 CLI, 웹 관리 화면, 혹은 IP 기반 진단 도구로 진행합니다. 그런데 LLDP는 애초에 링크 계층에서 인접 장비가 뿌리는 정보라서, 단순히 애플리케이션 계층이나 IP 계층만 보는 도구로는 접근이 어색해질 수 있습니다. Cisco 문서도 LLDP를 벤더 독립적인 링크 계층 프로토콜로 설명하고 있고, 이 저장소의 코드도 실제로 EtherType 0x88CC를 직접 검사해서 LLDP 프레임만 따로 파싱합니다.

여기서 기존 접근 대비 핵심 차이는 분명합니다.
이 프로젝트는 “IP를 얻고 그 위에서 뭔가 하는 장치”가 아니라, 유선 Ethernet 프레임을 직접 받아 LLDP를 해석하는 장치입니다. 다시 말해, 단순한 네트워크 단말이 아니라 링크 계층 관찰기라는 점이 핵심 차별점입니다.

LLDP 한 번에 이해하기

LLDP는 네트워크 장비가 바로 옆에 연결된 장비에게 “나는 누구고, 어느 포트고, 어떤 정보가 있다”를 알려주는 표준 프로토콜입니다. IEEE 802.1AB로 정의되어 있고, 벤더 중립이라 서로 다른 회사 장비끼리도 쓸 수 있습니다.

누가 왜 쓰나

주로 스위치, 라우터, AP, IP 전화기 같은 네트워크 장비가 쓰고, 설치 기사나 네트워크 운영자가 이 정보를 봅니다. 이유는 단순합니다.
“이 케이블 반대편에 뭐가 연결됐는지 빨리 확인하려고” 씁니다. 장비 이름, 포트 정보, 관리 주소, 일부 VLAN 관련 정보까지 확인할 수 있어 장애 확인과 설치 검증에 유용합니다.

언제 쓰나

• 새 장비를 연결했을 때
• 포트가 어디로 이어졌는지 추적할 때
• 네트워크 장애 원인을 좁힐 때
• 여러 회사 장비가 섞인 환경에서 연결 정보를 통일해서 보고 싶을 때 

초보자용 한 줄 비유

**LLDP는 “랜선 건너편 장비가 자기소개 명함을 주기적으로 뿌리는 기능”**이라고 생각하시면 됩니다.

기술 흐름 설명

신호 / 데이터 / 동작 순서 중심 설명

1. 장치가 부팅되면 app_main()에서 mutex를 만들고, ping 모듈, LVGL, 디스플레이, 터치, 밝기 제어, Ethernet 초기화를 순서대로 수행합니다. 이후 UI를 만들고 500ms 주기의 갱신 타이머를 등록한 뒤, 별도의 LVGL 처리 태스크를 코어 1에 올립니다. 
2. Ethernet 초기화에서는 W5500을 SPI Ethernet으로 붙입니다. 코드상으로는 esp_eth_mac_new_w5500(), esp_eth_phy_new_w5500()를 사용하고, sdkconfig에서도 W5500 SPI Ethernet 사용이 활성화되어 있습니다. 
3. 그 다음 핵심이 esp_eth_update_input_path()입니다. 이 호출로 Ethernet 입력 경로를 바꿔서, 들어오는 프레임을 먼저 eth_input_callback()에서 확인하게 만듭니다. 여기서 EtherType이 0x88CC이면 LLDP로 보고 직접 파싱하고, 아니면 일반 네트워크 스택으로 넘깁니다. 게다가 promiscuous 모드도 켜고 있습니다. 
4. LLDP 파서는 프레임 payload를 TLV 단위로 해석합니다. chassis ID, port ID, port description, TTL, system name, system description, management address를 읽고, IEEE 802.1 OUI 기반의 조직별 TLV에서는 PVID와 VLAN name도 추출합니다. 
5. UI는 타일 4개로 나뉩니다. 요약 화면, LLDP 상세, VLAN, Ping입니다. 타이머 콜백이 최신 LLDP 정보를 라벨에 반영하고, ping 결과도 같이 갱신합니다. ping 입력창은 장치가 받은 IP의 마지막 점 앞부분까지를 기본값으로 채워 같은 서브넷 대상을 빠르게 찍어볼 수 있게 해 둡니다. 

왜 이런 구조가 나왔는지에 대한 해설

설계 선택의 배경

이 구조의 본질은 LLDP가 있는 위치에서 직접 읽자는 데 있습니다. LLDP는 인접 장비가 같은 LAN 세그먼트에서 광고하는 정보이므로, 유선 링크에 바로 붙어 raw frame 수준으로 읽는 편이 가장 직접적입니다. 그래서 이 프로젝트는 W5500으로 Ethernet 경로를 만들고, 그 위에서 일반 소켓 프로그래밍이 아니라 입력 콜백 경로를 바꿔 LLDP 프레임을 직접 잡는 방향을 택했습니다.

제약 조건

ESP32-S3 하나로 화면, 터치, Ethernet, ping, LLDP 파싱을 다 처리해야 하므로 구조를 세 모듈로 분리한 점이 보입니다. main.c는 장치 통합과 UI, lldp.c는 해석, ping.c는 ICMP 확인으로 나뉘어 있습니다. 이런 분리는 기능 확장보다 현장 사용성을 우선한 흔적으로 읽힙니다.

대안 가능성

대안은 분명 있습니다.
노트북 NIC로 LLDP를 잡는 방법도 있고, 스위치 CLI에서 이웃 정보를 보는 방법도 있습니다. 다만 이 저장소의 선택은 장비 하나만 들고 가서 바로 확인할 수 있는 독립형 단말이라는 쪽입니다. 이 점 때문에 보조 수단이라는 위치가 오히려 더 또렷해집니다. 스위치 그 자체를 대신하지 않고, 현장 확인의 마찰을 줄이는 도구입니다.

생소한 개념에 대한 풀어쓴 설명

LLDP가 무엇인가요?

LLDP는 Link Layer Discovery Protocol입니다. 벤더 독립적으로, 네트워크 장비가 자기 정체성과 능력, 포트 정보를 바로 옆에 연결된 장비에게 알리는 용도로 씁니다. 그래서 라우팅 너머의 세상을 보는 프로토콜이 아니라, “지금 이 케이블 반대편에 누가 있나”를 드러내는 프로토콜에 가깝습니다.

왜 VLAN 정보가 같이 나올 수 있나요?

이 파서는 기본 LLDP 항목만 보는 것이 아니라 IEEE 802.1 계열 조직별 TLV도 일부 읽습니다. 그래서 포트 VLAN ID와 VLAN 이름까지 추출할 수 있습니다. 현장에서는 이게 꽤 유용합니다. 케이블은 꽂혔는데 어느 VLAN 쪽 맥락인지 헷갈릴 때 단서를 줄 수 있기 때문입니다.

W5500은 여기서 정확히 어떤 역할인가요?

WIZnet W5500은 SPI로 외부 MCU에 Ethernet 연결을 제공하는 칩입니다. 문서상으로는 하드와이어드 TCP/IP 스택을 갖고 있지만, 이 저장소에서 보이는 직접적인 역할은 ESP32-S3가 유선 Ethernet 프레임을 받고 LLDP를 확인할 수 있게 만드는 Ethernet 인터페이스입니다. 코드가 esp_eth_* 경로로 W5500을 붙이고 있기 때문에, 여기서는 “오프로드 칩 자체의 소켓 기능 활용”보다 유선 링크 확보와 프레임 수신 경로 제공이 더 핵심적입니다. 마지막 문장은 코드 사용 패턴을 바탕으로 한 해석이며, 추론임입니다.

시스템 구성 및 선택지 해석

하드웨어 쪽은 대체로 다음처럼 읽힙니다.
디스플레이는 SPI 기반 ST7789 240x320, 터치는 I2C 기반 CST816, Ethernet은 별도 SPI 버스의 W5500입니다. 즉, 화면용 SPI와 Ethernet용 SPI를 분리해서 쓰고 있습니다. 코드상 핀도 각각 따로 잡혀 있습니다.

이 선택은 꽤 현실적입니다. 디스플레이와 Ethernet이 같은 SPI를 심하게 공유하면 타이밍과 응답성이 꼬일 수 있는데, 여기서는 애초에 호스트를 분리해서 단순하게 갔습니다. “작고 확실한 현장 도구”라는 방향과 잘 맞습니다. 다들 괜히 복잡하게 만들었다가 밤새는 걸 좋아하지만, 이쪽이 훨씬 덜 비극적입니다. 추론임입니다.

또 하나 중요한 점은 이 장치가 현재 상태만 보는 도구에 가깝다는 것입니다. 코드에는 단일 lldp_info 구조체와 업데이트 플래그가 있고, 최신 값을 UI에 덮어쓰는 방식입니다. 이력 저장, 다중 이웃 비교, 패킷 캡처 기록 같은 기능은 보이지 않습니다. 따라서 현장용 확인 장치로는 적절하지만, 분석 플랫폼으로 보기는 어렵습니다.

내부 관점에서의 시사점

이 시스템에서 실패 비용이 가장 큰 지점은 Ethernet 입력 경로를 직접 바꾸는 부분입니다. LLDP를 잡겠다고 esp_eth_update_input_path()로 가로채고, 비-LLDP 프레임은 다시 esp_netif_receive()로 넘기는데, 여기서 버퍼 처리나 분기 실수가 나면 LLDP도 망가지고 일반 네트워크 연결도 같이 망가집니다. UI 오타보다 훨씬 비싼 실패입니다.

또한 이 설계가 보조 수단인 이유도 명확합니다. 이 장치는 스위치 설정을 변경하지 않고, LLDP 광고를 “읽고”, ping으로 “확인”만 합니다. 즉, 네트워크를 바꾸는 주체가 아니라 판단 재료를 주는 관찰 장치입니다. 내부 발표에서는 이 점을 강조하는 편이 좋습니다. 과장해서 “네트워크 관리 장비”처럼 부르면 구조와 경계가 흐려집니다.

특정 구성요소 제거 시 시스템 성격 변화도 선명합니다.

• W5500 경로가 빠지면 이 프로젝트는 사실상 LLDP 모니터라는 정체성을 잃습니다.
• raw input callback과 promiscuous 설정이 빠지면 그냥 Ethernet 붙은 ping/UI 장치에 가까워집니다.
• LVGL 화면과 터치가 빠지면 휴대형 현장 단말이 아니라 헤드리스 실험 코드 쪽으로 성격이 바뀝니다.
  이 판단은 코드 구조를 바탕으로 한 해석이며, 추론임입니다. 

FAQ

1) 기존 접근과 비교했을 때 이 저장소의 차별점은 무엇인가요?

가장 큰 차이는 IP 위의 진단이 아니라 링크 계층에서 LLDP를 직접 읽는다는 점입니다. 일반적인 ping 중심 도구는 상대가 살아 있는지 확인하는 수준에 머물 수 있지만, 이 장치는 연결 반대편 장비가 자기 포트와 시스템 정보를 무엇으로 광고하는지까지 보여줍니다.

2) 왜 W5500 기반 유선 Ethernet이 중요한가요?

이 프로젝트의 핵심 데이터인 LLDP는 유선 링크 문맥에서 읽는 것이 자연스럽습니다. 코드도 W5500을 SPI Ethernet으로 붙여 raw frame 입력 경로를 다루고 있으므로, 여기서 W5500은 단순 부품이 아니라 프로젝트 정체성을 떠받치는 경로입니다.

3) 구조 선택에서 가장 중요한 이유는 무엇인가요?

LLDP 파서, ping, UI를 분리한 이유는 기능이 서로 다르기 때문입니다. 프레임 해석과 화면 갱신, 능동형 진단을 한 파일에 뒤섞지 않아 유지보수 포인트를 줄인 점이 보입니다.

4) 이 시스템에서 핵심 데이터 흐름은 어떻게 되나요?

Ethernet으로 들어온 프레임을 입력 콜백에서 먼저 검사하고, LLDP면 파싱해서 공유 구조체에 반영하며, 타이머 콜백이 그 값을 UI에 그립니다. LLDP가 아니면 일반 네트워크 스택으로 넘겨 IP 획득과 ping 같은 기능이 계속 동작하도록 합니다.

5) 실패 비용이 가장 큰 판단 지점은 어디인가요?

입력 경로를 가로채는 부분입니다. 여기서 프레임 전달을 잘못 처리하면 LLDP 정보도 못 받고, 일반 Ethernet 통신도 끊길 수 있어서 영향 범위가 큽니다.

6) 이 장치는 왜 보조 수단으로 보는 편이 맞나요?

이 장치는 네트워크 장비를 제어하거나 구성하지 않고, 광고 정보를 읽고 통신 상태를 확인할 뿐입니다. 따라서 운영 장비라기보다 현장 판단을 돕는 관찰 도구로 보는 것이 구조적으로 맞습니다.

저자 정보 (Author Information)

공개적으로 확인되는 정보는 매우 제한적입니다. GitHub에서 확인 가능한 작성자 표시는 davetrees 핸들이며, 현재 공개 프로필에서는 이 저장소 1개가 보이고, 별도 bio나 소속 조직 정보는 노출되지 않습니다. 따라서 실명, 소속, 전문 이력은 이 자료만으로는 확인하기 어렵습니다. 정보 제한입니다.

다만 저장소 내용만 놓고 보면 ESP32-S3, W5500 Ethernet, LVGL UI, 터치 입력, LLDP 파싱을 한 프로젝트에 묶고 있으므로, 작성자는 적어도 임베디드와 네트워크 접점에 관심이 있거나 실험 중인 개인 개발자일 가능성이 있습니다.