:::: MENU ::::

네트워크 패킷 생성기 (NPG: Network Packet Generator)

요즘은 제가 필요한 것을 인터넷에서 찾으면 다 있네요. 누군가는 같은 고민을하고 고맙게도 만들었다는 사실… ^^


NPG는 Winpcap을 사용하여 패킷을 보낼수 있는 윈도우즈 기반의 네트워크 패킷 생성기입니다. 즉 따로 프로그래밍을 하지 않고 원하는 패킷을 만들어서 보낼 수 있는 툴입니다. 사용법도 간단하고 옵션도 많지 않기 때문에 바로 사용이 가능합니다. GPL 라이센스이므로 자유롭게 사용이 가능하네요.
http://www.wikistc.org/wiki/Network_packet_generator 에 자세한 설명이 나와있고, 설치 파일은 이 페이지의 제일 아래보시면 다운받으실 수 있습니다.

사용법

    ); “>

  • npg
  • npg [-?hlw]
  • npg [-vvvw] -fF <packet file name> -d <device interface>
  • npg [-rtvvv] -p <packet byte stream> -d <device interface>


NPG 프로그램을 다운받고 커맨드 창에서 아무런 옵션 없이 실행을 하면, 옵션을 물어보는데 대부분의 경우 옵션을 정하고, 보낼 패킷도 저장을해서 배치파일을 만들어서 테스트를 하는 것이 가장 손쉬운 방법입니다.

옵션

-h 도움말 표시
-d 패킷을 보낼 네트워크 디바이스를 선택
-f  패킷파일의 이름 지정
-F Libpcap 호환 패킷파일 이름 지정
-l 사용 가능한 네트워크 디바이스 나열
-p <packet byte stream> 인젝트할 패킷 바이트를 HEX 값으로 나열해주면 됨
-r <repeat count>  패킷을 몇번 반복할지 카운트를 지정
-t <interval> 패킷을 인젝트 하기 전 시간 간격을 지정 (시간 기준은 밀리세컨드)
-v, -vv, -vvv 동작 상태를 표시함 v 가 많을 수록 세부정보를 표시함

실제로 보낼 데이터 파일을 가지고 설명을 하겠습니다.
아래 패킷 샘플은 ARP request를 하는 샘플입니다.

# Generic example packets to demonstrate npg.exe 
# Current documentation an examples located @ http://www.wikistc.org/wiki/Network_packet_generator

# TCP/IP ARP Request
[3, 1000] # 1000 밀리, 3 번 반복
<ARP Request>
{
# Ethernet2 Header ———

 FF FF FF FF FF FF # Destination MAC
 00 08 DC 01 01 12 # Source MAC
 08 06             # Protocol ; ARP

# ARP Header —————

 00 01             # Hardware type
 08 00             # Protocol type
 06                # Hardware size
 04                # Protocol size
 00 01             # Opcode : Request
 00 08 DC 01 01 12 # Sender MAC address
 c0 a8 0b c8       # Send IP
 00 00 00 00 00 00 # Target MAC address
 c0 a8 0b 64       # Target IP

# Ethernet2 (Trailer) ——

 00 00 00 00 00 00 # Trailer data
 00 00 00 00 00 00 
 00 00 00 00 00 00
}


#  : 주석

[] : 패킷을 보낼 횟수 및 주기를 설정
<> : 어떤 패킷인지 나타내는 태크. 큰 의미는 없다.
{} : 실제로 보낼 패킷을 HEX값으로 적는다. 위 예에서와 같이 각각의 의미를 주석으로 표시하면 알아보기 쉽다.

위와 같이 파일을 만들고 
npg -vv -f arp_request2.txt를 입력하면 NPG 프로그램은 만든 패킷을 분석을 하고 이상이 없을 시 어떤 네트워크 디바이스를 써서 보낼지 물어봅니다. 선택을 숫자로 하면 패킷이 나갑니다.
위 예에서는 패킷을 3번 1000밀리 주기로 보내는 옵션이므로 실제 패킷은 최초에 한번 나가고 추가적으로 1초 간격으로 패킷이 3개 더 나갑니다.








Wireshark Header Checksum Error

와이어샤크를 사용해서 패킷을 잡다보면 패킷에 “Header Checksum Error“라고 표시가 되어 있는 것을 볼 수 있다. 그리고 친절하게도 어떤값이 되어야 한다고 알려주기까지 한다.



체크섬이라는 것은 일반적으로 통신중에 데이터가 깨질수 도있기 때문에 삽입을 해서 데이터가 깨졌는지 여부를 확인을 한다. 
IP 헤더의 경우를 보면 2 바이트로 구성되어 있고, 네트워크를 이동하는 각 홉에서(예를 들면, 라우터 통과시) 체크섬을 검증한다. 그리고 체크섬이 올바르지 않으면 네트워크 장비는 해당 패킷을 버리며, 체크섬은 재 계산되고 업데이트를 하게된다.

그럼 어떻게 헤더체크섬이 틀린 패킷을 보내고 받을 수 있지??
원인은 여러가지가 있을 수 있는데 UDP의 경우는 체크섬 값이 제로로 채워져 있는 경우는 보내는 측 쪽에서 계산되지 않는 경우라 정의하고 있다. (RFC 768)  그리고 네트워크 장비나 기타 원인에 의해 헤더 체크섬 값이 계산되지 않았거나 또는 의도적으로 빠지는 경우도 있다.

와이어샤크에서 패킷 분석시 이게 거슬리면 다음과 같이 와이어샤크의 옵션에서 설정을 바꾸면 된다.
Edit > Preferences.. > 좌측 맨 하단의 Protocols를 선택후 UDP를 선택 > Validate the UDP checksum if possible 옵션을 해제한다.

TCP의 경우도 마찬가지…


Wi-Fi 모듈

Gainspan(www.gainspan.com)에서 Wi-Fi 모듈을 출시했습니다. 

기존에 무선랜 모듈 개발업체들에게 칩을 공급해서 해당 제품을 홈페이지에 소개를 하더니, 자체 모듈을 출시했네요. 어쩌면 이들 업체와 경쟁을 하는게 아닌가 하는 느낌도 있습니다.

지금도 4개 업체의 제품의 소개 페이지가 있습니다. 

다음 그림의 블럭 다이아그램처럼 Serial과 SPI 인터페이스를 통해서 모듈을 설정 및 제어합니다. 즉 간단하게 기존 시스템에 Wi-Fi기능을 추가할 수 있습니다. 



자체 모듈의 출시로 사용자의 확대를 노리고 있는 것 같은데 과연 이 전략이 성공할 지는 두고볼 일입니다. 그리고 GS1011칩셋을 가지고 무선랜 모듈을 만드는 회사는 최소한 Gainspan 보다는 싸게 만들어야 판매가 가능하겠네요. 현재 온라인에서 5개에 125불에 판매되고 있습니다. 

어찌됐던 개발자 입장에서는 좀 더 쉽게 무선랜 응용 개발이 가능할 것 같습니다.




Latch-up (래치업)

요즘에 나오는 대부분의 반도체칩의 경우 CMOS 디바이스입니다. CMOS IC의 경우 여러 장점이 있지만 디자인시에 엔지니어들이 간과하기 쉬운 것이 래치업 상태입니다.

래치업은 CMOS IC 자신이 내장하는 기생의 PNPN 접합부가 도통(low impedance가 되어)하여 IC 에 수백 mA 이상의 많은 전류가 순간적으로 흐르고 파괴에 도달하는 현상입니다. 이러한 상태는 순간적일지라도 한번 IC가 래치업 상태가 되면 전원을 끌 때까지 계속 유지가 됩니다. 
래치업 현상을 방지하려면 다음사항에 유의해야 합니다.
-. 미사용 입력은 pull-up 또는 pull-down 시킬것.
-. I/O 전압레벨을 Vcc보다 높게하거나 Vss보다 낮게하지 말 것.
-. 노이즈나 서지의 유입이 없도록 할것

이외에 고려해야할 사항은 다음의 Zarlink에서 나온 application note를 참고하시 바랍니다.
이 문서에 보면 latch-up이 발생하기 쉬운 8가지 경우에 대한 설명을 하고 대책을 설명하고 있습니다.

이건 TI에서 나온 자료… cfile7.uf.1954E3164CAEB9AD14354B.pdf

그리고 칩 레벨에서 레치업 테스트 규격은 JESD78A 입니다. 
   




브로드캐스트 주소

브로드캐스트 하나의 로컬 네트워크 전체에 있는 클라이언트 모두에게 데이터를 보내는 방식이며 ARP, DHCP, RIP등의 프로토콜에 사용이 됩니다.

그럼 어떻 하면 이게 가능할까요? 
이것을 알려면 브로드캐스트 주소(Broadcast Address)를 이해해야 합니다.

브로드캐스트 주소는 어드레스주소중 가장 큰 수이다. 
간단히 말하면 이것만 기억하면 됩니다. 
즉 네트워크 를래스가 A이고 IP가 192.0.0.0 일 경우 브로드캐스트 주소는 192.255.255.255입니다.
네트워크 를래스가 B이고 IP가 192.168.0.0 일 경우 브로드캐스트 주소는 192.168.255.255입니다.
네트워크 를래스가 C이고 IP가 192.168.16.0 일 경우 브로드캐스트 주소는 192.168.16.255입니다.

위와 같은 경우는 서브네팅이 많이 보는 경우이므로 간단히 알수 있는데 그럼 만약에 서브넷 마스크가 255.255.255.224 일 경우 어떻게 브로드캐스트 주소를 구할 수 있나요?

브로드캐스트 주소 구하는 법
IP address: 192.168.16.1
Subnet mask: 255.255.255.224

1) Subnet mask를 invert한다.
   255.255.255.224 => 11111111.11111111.11111111.11100000
   이것을 invert하면 00000000.00000000.00000000.00011111
2) Invert한 subnet과 IP address를 Logical OR를 한다.
  192.168.16.1    => 11000000.10101000.00010000.00000001
  Invert한 서브넷 =>  00000000.00000000.00000000.00011111
  결과는            =>  11000000.10101000.00010000.00011111 => 192.168.16.31



갤럭시S 무선랜 MAC 주소 찾기

환경설정 > 무선 및 네트워크 >Wi-Fi 설정 >메뉴키를 누르면 고급설정이 나옵니다. 그럼 2 번째 항목에 자신의 무선랜 MAC 주소가 나옵니다. 

갤럭시S의 경우 무선랜 MAC은 “D4-88-90” 로 시작합니다.

IEEE standard association 에서 확인을 해보면 다음과 같이 삼성전자로 나옵니다. ^^

IBIS 모델


IBIS는 “I/O Buffer Information Specification“의 약자입니다.

IBIS는 말 그대로 반도체 칩의 입출력 핀에 대한 정보를 담고 있어서 반도체 칩의 사용자들이 PCB를 설계할 때 신호 충실도(Signal Integrity) 및 EMI/EMC 관련 시물레이션 및 디자인에 필수적인 요소입니다. 즉 회로 설계를 위한 칩의 기본적인 I/O 정보를 담고 있습니다. 물론 보드가 복잡하고 High Speed의 보드일 경우에 그리고 이것을 해석하고 시뮬레이션 할 수 있는 툴이 있을 때 가능한 얘기입니다.
1990년 초, 인텔사에서 PCI 버스에 대한 엄격한 요구사항을 내 놓기 시작하여 그 특이한 형식이 대두되고 그 이후 반도체 제조회사, EDA 및 컴퓨터 제조관련회사 등 약 35개의 회원사를 구성하여 공개적인 표준규격을 정한 것이 바로 이것이 IBIS Model입니다.
이 IBIS 모델의 특징은 다음과 같습니다.
  • 반도체 칩의 I/O 버퍼 특성을 I/V관계로 나타낸다.
  • 회로에 대한 정보를 숨길 수 있어, 제작사에서 IBIS Model를 공개/보급이 가능함
  • Spice Model과는 달리 상용 EDA 도구와 호환성을 가짐
IBIS모델은 반도체 칩의 I/O를 기준으로 칩을 모델링한 것이기 때문에 칩 내부의 정보는 회로설계자들이 알 수 없으므로 칩 제조사의 노하우나 기술들은 비밀이 보장되는 장점이 있습니다. 그리고 시뮬레이션 시간도 SPICE모델에 비해 몇배 빠릅니다. 
보다 많은 정보는 IBIS 오픈 포럼에 ==> http://www.eda.org/ibis/


Auto-MDIX의 동작 원리

Auto-MDIX  Automatic Medium Dependent Interface Crossove를 의미하며 HP에 의해 개발된 Network 기술입니다. HP사의 Auto-MDIX기술 소개 페이지

이더넷 케이블의 형태는 TX/RX 를 기준으로 볼 때TX/RX가 서로 바뀌어져 있는 Crossover Cable(TX-RX, RX-TX) Straight Cable (TX-TX, RX-RX)로 나뉘어집니다. 

각각의 네트워크 디바이스들의 통신은 TX(노드 A)-RX(노드 B) / RX(노드 A)-TX(노드 B)의 연결을 통해서 가능하기 때문에 Straight Cable 로 연결을 하면 통신이 불가능합니다. 

하지만 연결된 노드에서 TX RX를 전기적으로 서로 바꿔줄수 있는 기능이 있다면 Straight Cable을 사용해도 상호간의 통신이 가능하며 이를 Auto-MDIX라고 합니다. 요즘 나오는 대부분의 네트워크 카드나 노트북에에서는 이 기능을 지원하죠.


임베디스 네트워크시스템에서 이 기능을 사용하기 위해서는 Auto-MDIX를 지원하는 PHY를 사용하고 대칭적(symmetrical)인 구조를 가지는 트랜스포머를 사용해야 합니다. 즉 다음과 같은 구조를 같는 트랜스포머 또는 맥잭을 사용해야 합니다. 

트랜스포머가 내장된 UDE사의 RDA-125BAG1A 맥잭

 

그럼 링크 파트너끼리 어떻게 이것을 설정할까요? 2가지 경우의 수가 있을 수 있습니다. 한쪽만 Auto-MDIX를 지원하는 경우와 둘다 Auto-MDIX를 지원하는 경우. 

전자는 쉽습니다.  Auto-MDIX를 지원하는 쪽에서 MDI확인을 한후 MDIX확인을 하면 됩니다. 하지만 후자의 경우 양쪽에서 Auto-MDIX을 체크를 하고 최악의 경우 이 체크하는 주기까지 같으면 영원히 링크를 형성하지 못하는 경우도 있습니다.

따라서 IOT 테스트가 중요합니다. 관련글 읽기 Take Advantage Of Fast Ethernet PHY Testing

그리고 HP에서는 이런 문제를 피하기위해 스위칭 주기를 랜덤하게 하는 알고리즘을 내놓았습니다. Automatic Crossover Algorithm