덕만이 잠든 시간에 – HttpInputStream의 read와 FileOutputStream의 write 함수

Java로 웹에 있는 영상 파일을 다운로드하는 기능을 간단하게 구현하면서 기본함수에 대한 의문이 생겼다.

실제로 영상 파일이 깨지는 문제도 있었다.

1. FileOutputStream write(byte[] b)

아래 구문에서 사용된 write 함수는 byte buffer, offset, length를 parameter로 받는다.

좀 더 간단한 형태인 write(byte[] b)를 사용하는 것으로 코드를 변경하면 문제가 발생한다. (테스트했던 영상파일들에서는)


InputStream is = conn.getInputStream();

FileOutputStream fos = new FileOutputStream(filename);

byte[] buffer = new byte[4096];

int readBytes = -1;

while((readBytes = is.read(buffer)) != -1) {

    fos.write(buffer, 0, readBytes);

}

write(byte[] b)의 내용을 보자.

fileoutputstream-write(byte[])내용은 간단하다. byte 배열의 길이만큼 file output stream에 쓰는 기능이다.

2. 왜 문제가 생겼는가?

결과적으로 보자면 HTTP로 들어온 input stream을 읽어들인 byte 수가 byte array의 총 크기보다 작은 경우가 있기 때문이다.

보통의 파일을 읽으면 마지막만 제외하고 buffer로 사용하는 byte array를 꽉꽉 채웠었는데 이 경우는 그렇지 않았다.

궁금해서 살펴보니 HttpInputStream의 read(byte[])는 이렇게 구현되어 있다.

httpinputstream-read(byte[])read(byte[], int, int) 함수를 호출하지만 상속트리를 뒤지다보면 결국 자신이 구현한 read() 함수 호출이 기본이 된다.

read() 함수는 아래 그림처럼 -1이 나오기 전까지 1바이트씩 읽어들이도록 되어있고 read(byte[], int, int) 함수도 -1을 만나기 전까지는 byte array의 길이만큼 읽어들이게 된다.

httpinputstream-read()

그러니까 byte array 만큼 읽어들이지 못하는 경우가 있을 수 있는데 이에 대해서 고려하지 못했던게 문제였다.

실제로 찍어보면 사용된 byte array는 4096만큼 0으로 초기화되어 있고 계속 사용하기 때문에 byte array의 길이는 4096으로 항상 동일하고 읽어들인 실제 byte 수는 그것보다 작은 경우가 지속적으로 발생했다.

이런 상태에서 FileOutputStream의 write(byte[]) 함수를 사용하면 byte array의 길이만큼 쓰게된다. 실제 읽어들인 byte 만큼이 아니라 과거에 사용했던 일부 byte가 섞이게 되는 거다.

3. 결론

가능하면 write(byte[]) 함수는 사용하지 않을 생각이다.

조금 불편해보여도 확실한게 낫다.

덕만이 잠든 시간에 – ESXi RDM 설정

ESXi는 가상화 솔루션이기 때문에 HDD, SSD 등을 사용하기 위해 storage 등록을 선행해야 한다.

Disk를 100GB, 200GB 정도로 만든다면 크게 문제될게 없겠지만 대용량 disk를 통째로 한가지 용도로 등록해서 사용할거라면 storage 등록 과정에 소요되는 시간이 부담스러워질 수 밖에 없다.

내 경우 700GB 정도를 추가 등록하는데 약 3시간 정도가 필요했다.

1. RDM

RDM (Raw Device Mapping)은 여러가지 용도로 나온 기술(?) 이겠지만 위와 같은 경우 소요시간만 보더라도 충분히 유용하게 사용할 수 있다.

직접 storage 등록하는 경우 시간이 많이 소요되는 이유가 VMWare 가상화 환경에서 사용할 수 있는 파일시스템 (vmfs)으로 만들기 때문인 것으로 보이는데 RDM을 사용할 경우 디스크 전체 혹은 일부를 vmfs로 만들지 않아도 된다.

과정이 잘 설명된 이 문서에 기술된 것처럼 raw disk를 가리키는 vmdk 파일을 하나 생성하는 것으로 끝낼 수 있다. (얼마 걸리지 않는다)

2. 제한사항

처음에는 사용중이던 disk (파일들이 있는)를 그대로 활용할 수 있을것이라 생각했는데 불가능했다.

사용중이던 disk는 파티션이 하나 이상 생성되어 있는 상태인데 파티션이 있는 상태에서 파티션을 대상으로 rdm 설정을 하려고 vmkfstools를 실행하면 오류가 발생한다.

그렇다고 파티션을 무시하고 디스크 자체에 대해서 vmkfstools를 실행하면 파티션을 초기화해버릴까봐 진행해보진 않았다.

3. 결론

RDM은 그냥 새 disk 하나 추가할 때 사용하자.

그 때 partition이 있는 상태에서 물리 디스크를 대상으로 RDM 설정하면 어떻게 되는지 시도해볼 예정.

덕만이 잠든 시간에 – Gen8 esxi 삽질기 2번째

지난번에 2주 정도 고생(덕만이 잠든 시간에 – Gen8 esxi 삽질기)하고 된다고 생각했는데 착각이었다.

1. VT-d

HDD가 멈추는 듯한 현상이 지속적으로 발생됐다. 그것도 boot 완료된 시점에서 약 3분후.

아는 분들의 도움으로 BIOS 설정이 잘못된 걸 알게 되었다.

VT-d 설정이 enable로 되어있었는데 현재 사용중인 CPU는 VT-d를 지원하지 않는다.

G1610T 라는 Celeron CPU인데 제조사에서 안된다고 하니 잘못 설정한게 맞다.

http://ark.intel.com/products/71074/Intel-Celeron-Processor-G1610T-2M-Cache-2_30-GHz

esxi-vt-d

BIOS 설정을 공장초기화한 값이 enable로 되어있는게 이해되지 않지만 그래도 제대로 설정.

2. SATA AHCI vs SATA Legacy

VT-d 설정을 변경하고 설치를 다시 진행해봤는데 해결되기를 기대했지만 문제는 여전했다.

현상 만으로는 알 수가 없어서 로그를 뒤져보기로 했다. (이 때부터 커널로그를 보기 시작했다)

esxi-ahci-failed

Failed, Driver ahci, for vmhba0 라는 부분이 반복되는 걸 알 수 있었다.

AHCI driver 로딩하는데 뭔가 문제가 있는 것 같아서 vmware 자료들을 뒤져봤는데 내 상황에서 특별히 조치할만한게 없었다.

(http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2000641 외 기타)

이런 내용도 있었는데 지원안하는 드라이버가 아니었기 때문에 역시 조치할 수 없었다.

드라이버 문제라는 걸 확실히 하기 위해 BIOS setting에서 AHCI 대신 SATA Legacy (IDE 타입의 구형 HDD를 지원하기 위한 내용으로 보인다)를 선택해서 다시 설치를 해보니 문제 해결.

드라이버 문제가 맞다는 확신을 가지고 HDD 등록하고 이런저런 작업을 더 진행해보니 이번엔 너무 느린게 문제였다.

느낌으론 속도가 일반적인 경우에 비해 1/10 또는 그 이상 느린 것 같았다.

순간 ‘버릴까?’ 생각했다.

3. Service Pack for Proliant 설치

목표가 좀 더 뚜렷해졌다.

“AHCI controller를 사용하면서 ESXi를 올린다”

다시 원래대로 돌아가 AHCI driver 로딩에 문제가 발생하는 상황에서 이런저런 내용을 살펴보니 할 게 하나 생겼다.

SPP (Service Pack for Proliant) 업데이트를 안해봤으니 그걸 해보기로 했다.

최신버전이 2015년 10월에 나온 것 같은데 업데이트 해보니 오! 몇 개 system firmware가 업데이트 된다.

하지만 기대했던 AHCI driver는 업데이트 되지 않았다.

초기 로딩화면에 AHCI 버전이 나오는데 HDD에 대한 드라이버는 0.90 버전이 ODD에 대한 드라이버로 0.84 버전이 로딩되는 것처럼 보인다.

esxi-spp

이해 안된다. 그리고 뭔가 잘못 관리되는 듯한 인상을 받았다.

이 때부터 얘네 웹사이트에 올라와있는 파일들의 checksum 값을 확인하기 시작했다.

esxi-spp-version

그래도 SPP 업데이트 후에 몇가지 달라졌다.

(1) SD / USB 설치

ESXi를 SD나 USB에 올리는게 계속 문제가 있었는데 SPP 업데이트 후에는 문제없이 잘 설치된다.

(2) Kernel log

AHCI driver 로딩이 안되는 듯한 로그가 사라졌다!!

잘 되어야 할 것 같았는데 문제는 여전했다.

다시 원점.

4. HDD에 직접 설치

갑자기 멈춘 시점의 커널로그를 보면 특이사항이 없었다.

다만 vmware 측에서는 무시해도 되는 로그라고 하는 warning이 반복적으로 찍혔다.

Scratch partition에 대한 내용인데 SD나 USB에 설치할 경우 시스템 로그가 저장된다는 scratch partition을 만들지 못하는데 없는 경우 ram disk에 저장하기 때문에 단순히 경고만 할 뿐 특별히 시스템에 문제는 주지 않는다고 한다.

ESXi를 SD에 올리고 HDD를 추가한 후 reboot (boot 후 약 3분 후에 freeze 되고 HDD 추가할 때 쯤이면 시간이 얼마 없다)하고

warning을 없애기 위해 HDD에 scratch partition 경로를 지정해줬다.

그래도 문제는 해결되지 않았는데 아무래도 SD나 USB에 ESXi를 올리는게 불안해졌다.

그리고 RAID 구성을 하지 않을거라 굳이 SD 등에 ESXi를 올릴 필요가 없다는 생각이 들었다.

그래서 HDD에 ESXi를 직접 올리기로 했다.

iLO의 remote console에서 가상드라이브 할당해서 해보니 이번엔 HDD 설치 도중 문제가 생긴다.

(1) device or resource busy

(2) 설치 도중 멈춤

난 아무 작업을 하지 않았고 깨끗하게 포맷한건데 이랬다.

이쯤에서 다시 한 번 버릴까 생각했다.

그래도 포기하지 않고 Intelligent provisioning 기능으로 설치해보기로 했다.

참고로 전혀 intelligent 하지 않다.

USB에 여러 버전의 iso 이미지를 담아놓고 설치를 시도했다.

ESXi 6.0 이미지는 intelligent provisioning에서 인식하지 않는다.

ESXi 5.5, 5.1의 여러 버전중에서 최신 순으로 설치해봤다.

esxi-hp-images

이미 SD나 USB로 여러번 반복했던 거였지만 HDD로 설치할 때는 조금씩 현상이 달랐다.

예를 들어 5.5 U2는 device or resource busy 라는 메세지 때문에 설치를 시작조치 못했다.

완전히 동일한 환경에서 설치 버전에 따라 문제가 나타나거나 그렇지 않다는 것은 뭔가 잘못 만든거다.

결국 2014년에 배포된 것으로 보이는 5.5 U1 까지 내려가서야 설치가 완료되었다.

그리고 그 버전 설치 이후에 더이상 문제는 발생하지 않았다.

힘들었다.

5. 기타 문제점들

HP의 문제인지 VMWare의 문제인지 모르겠지만 발견한 기타 문제점들은 아래와 같다.

(1) SD/USB 사용시 scratch partition

ESXi 내에 Scratch Partition이란?

위에서 기술했던 내용이지만 SD나 USB에 ESXi 설치시 scratch partition을 만들지 않는다.

SD나 USB에 여유공간이 많아도 절대 만들지 않는다.

esxi-sd-partition난 16GB짜리 micro SD를 사용했는데 (요즘 마트가면 16GB 이하 제품을 찾기 힘들다) 위 그림에서 몇백메가씩 잡혀있는 나머지 공간은 그냥 버리게 된다.

(2) Driver 버전차이에 따른 문제들

장비 특성상 수많은 controller들과 driver들이 있는건 알겠는데 각 driver 버전에 따른 문제점들이 많은 것 같다.

이번에 내가 경험한 문제도 그런 문제 중 하나로 추측되고 인터넷에는 수많은 문제들이 보고되어 있다.

(3) HP의 esxi custom image 관리

http://www8.hp.com/us/en/products/servers/solutions.html?compURI=1499005#tab=TAB4

이곳에 기록되어 있는 날짜를 신뢰할 수가 없었다.

VMWare 어느 사이트에는 각 이미지별 release date가 위와는 달랐고 일부 해외 유저들이 기술한 문서와도 날짜가 달랐다.

날짜와 Update 번호로는 알기가 너무 어려워서 결국은 Build number를 비교하면서 문서들을 읽었다.

덕만이 잠든 시간에 – Gen8 esxi 삽질기

내 안의 무언가가 답보상태에 있는 것이 아닌가라는 답답함을 이겨내보고자 아이가 잠든 후에 무언가를 해보기로 했다.

그것이 무엇이든 그렇게라도 좀 더 의미있는 시간을 만들어가야 스스로에게 미안하지 않을 것 같았기 때문이다.

그렇게 2주에서 3주 정도를 지속해보고 있는데 답답함은 줄어드는 것 같고 전반적인 생활에 의욕이 조금씩 생겨나는 듯한 느낌이 든다.

1. Gen8

여러가지를 진행했지만 지난 2~3주 야간에 가장 많은 시간을 투입한 것은 Gen8 (HP의 마이크로서버 제품군)에 ESXi (VMware의 hypervisor)를 올리는 작업이었다.

2주 전쯤 중고/신품으로 구매한 장비들이 도착한 것이 시발점이 되었고 다양한 가상화 환경을 경험해 보고싶다는 생각도 있었지만 이런 류가 대부분 그렇듯이 좀 더 그럴싸한 환경을 갖는게 목적이었음을 부정할 수 없다. (사실은 장비욕)

굴러다니는 아이의 DVD를 재생할 수 있게 해주겠다는 감언이설로 부인을 설득했는데 평소에는 워낙 보살같은 분이라 그냥 넘어가준 것 같다. (이 비용이면 DVD player를 몇 개 사고 남은 돈은 맛있는 걸 사먹거나 플레이스테이션4를 사고도 남는다)

아무튼 나의 진정한 목적은 따로 있었지만 DVD play를 1차 목표로 작업을 진행해봤다.

2. ESXi 6.0 올리기

한글, 영문을 따지지 않고 정말 수많은 웹사이트를 참고했다. ‘gen8 esxi’로만 검색해도 내용이 정말 많이 나온다.

하지만 나와 같은 특이한 현상을 경험한 사람은 거의 없었던 것 같다.

많은 사람들이 사용하는 방법대로 sd card를 넣고 (보드에 slot이 내장되어 있다) gen8의 훌륭한 ilo의 remote client로 붙어서 가상 cd/dvd rom에 iso 파일을 추가해 설치를 진행했다. (이런게 된다. remote로…)

처음 6.0을 sd card에 올릴 때에는 전혀 문제가 없었다. 정상적으로 올라간 걸 확인하고 새로 구매한 하드를 장착한 후 data store 등록까지 한 번에 완료할 수 있었다.

이렇게 그냥 가면 되는 거였는데 뭔가 의심병 같은게 도져서 6.0이 아닌 5.5를 올리는게 낫지 않을까라는 생각을 하게 되었다.

(1) SD card / USB format은 필수가 아닌가

보통 os 같은 걸 설치해보면 이미 존재하는 경우 파티션을 새로 잡거나 하면서 포맷을 알아서 하도록 진행할 수 있다.

그런데 6.0이 설치된 sd card에 5.5를 올리려고 하니 진행하다 멈춰버렸다.

이후 과정에서도 멈췄다 라고 판단한 이유는 야밤에 30분 이상 졸다 깨거나 책을 수십페이지 읽다 쳐다봐도 progress가 동일했기 때문이다.

깔끔하게 포맷하고 다시 설치했더니 별 문제없이 끝났다.

(2) CreateVmfsDatastore 오류

6.0이 설치된 상태에서 하드를 data store로 등록했기 때문에 5.5로 내리기 전에 등록된 data store를 삭제했었는데 5.5에서 다시 등록하려고 하니 아래와 같은 오류가 발생했다.

esxi-createvmfsdatastore-error

이후에도 수없이 마주한 저 오류는 사실 esxi 버전의 문제가 아니라 하드 초기화 여부가 원인으로 보인다.

그런데 이 때에는 그 사실을 몰랐기 때문에 ‘5.5는 뭔가 문제가 있나보군’ 이라 생각하며 다시 6.0으로 올리기로 마음먹음.

(3) 5%, 16%, 22%, 90%

이 때부터 문제였다.

sd card를 포맷하고 설치를 시도했음에도 어느 시점부터 설치가 진행되지 않고 멈춰있는 현상이 생겼다.

주로 90%에서 멈추는 경우가 많았는데 실제로 같은 경험을 하신 분이 있다.

https://www.2cpu.co.kr/bbs/board.php?bo_table=vm&wr_id=3017

이 분은 sd card 종류를 타는 것이 아니냐 결론 내리셨던데 그게 원인은 아니라고 판단하고 있다.

왜냐하면 처음엔 문제없이 설치된 card였기 때문이다.

수없이 반복.

sd card도 새로 사서 해보고 usb도 종류를 바꿔가며 올려봤고, remote client로 붙어서 진행했기 때문에 iso 이미지를 실제로는 네트웍으로 전송하는 것이었을테니 iso를 usb에 얹어서도 설치해보고 ilo의 intelligent provisioning으로도 해봤다.

결과는 경우에 따라 달랐지만 5%, 16%, 22%, 90% 진행도중 멈춰버렸고 왜 안되는지 원인을 알 수 없었다.

ilo에 보이는 로그에는 특이사항이 없었던 데다가 더 상세한 로그를 볼 수 있는 방법을 몰랐기 때문이다.

하지만 방법을 바꿔가며 며칠을 시도하다 꿈까지 꿔가며 ‘이제 슬슬 사리가 만들어지겠구나’ 라는 느낌이 들 때 되더라.

왜 된건지 알 수 없었다. 딱 이런 상황.

im-a-web-developer-problem-solve

<출처 : http://www.imawebdeveloper.com/photos/memes/>

3. Data store 등록

간신히 usb에 esxi를 올리고 data store를 등록할 차례가 되었다.

분명 ESXi 6.0에서 문제없이 등록되었던 하드인데 5.5에서와 동일한 오류가 발생하기 시작.

오류 메세지로 검색해보니 역시 많은 내용이 보였다.

많은 사람들이 겪는 문제인가 싶어서 금방 해결될 것 같은 느낌이 들었지만 결과적으로는 이것도 며칠 걸렸고 역시 왜 된건지는 지금도 알 수가 없다.

처음에도 아래의 내용대로 진행해서 실패했고, 마지막에도 아래의 내용대로 진행해서 성공했다.

http://www.virtualizationteam.com/server-virtualization/call-hostdatastoresystem-createvmfsdatastore-for-object-ha-datastoresystem-on-esxi-xxx-xxx-xxx-xxx-failed.html

(1) Format

하드가 WD사 제품이었기 때문에 그들의 툴을 써서 포맷을 했다.

http://uplaza.co.kr/customer/view.aspx?id=pds&code=23&category=&page=&search=

윈도우용 툴밖에 없는 것 같아서 윈도우에서 진행했는데 위와 같이 포맷하고 data store 등록하려고 하면 아래와 같은 화면을 볼 수 있다.

esxi-mbr분명 파티션을 다 날린 상태인데 MBR로 파티션 잡힌게 보인다.

실제로 ESXi console에서 fdisk로 확인해보면 파티션이 있다. 왜 있지?

esxi-ms-reserved-partition그래서 파티션만 날려보고 해봤더니 동일한 오류가 발생했다.

(2) AHCI driver?

로그를 보면 대충 아래와 같은 내용들이 반복해서 등장한다.

esxi-error반복되는 내용 중 가장 마지막 라인이 신경쓰였다.

RAID를 구성하지 않을거라서 Gen8에서 SATA AHCI로 설정한 상태였는데 로그는 AHCI driver를 로딩하는데 문제가 있는 것처럼 생겼다.

혹시나 RAID가 필수인가 싶었는데 생각해보니 처음엔 분명 잘 되었었기 때문에 이것도 원인이 아니다.

드라이버 로딩 문제인가 싶어 별 자료를 다 찾아서 살펴봤는데 딱히 AHCI 드라이버가 로딩이 안 될 이유가 보이질 않았다.

(3) Device locked

하드 포맷을 윈도우, 맥에서 여러가지 툴로 해보고 파티션은 따로 날려보고 하는 등의 작업을 며칠간 수없이 반복하다가 어느 날 다시 로그를 보니 이런 내용이 등장했다.

esxi-final‘아 디바이스가 잠겨있나보네’ 라고 잠깐 생각했는데 포맷하고 바로 밀어넣은 하드인데다 난 추가로 아무런 작업을 하지 않았는데 잠겨있다는게 이상했고 마지막 줄에 다시 초기화를 하는 것 보니 스스로 뭔가 조치를 하는구나 싶었다.

야식으로 라면을 먹고 오니 원래 반복되어야 하는 warning 로그들이 없었다.

‘오 뭔가 다른데?’ 라고 생각하며 스크린 세이버를 걷어버리니 등록이 되어있더라.

왜? 인지를 알 수가 없었다. 답답…

4. VM 생성

드디어 VM을 하나 생성해서 윈도우를 올려봤다.

그리고 부인에게 보고하기 위해 곰 플레이어를 설치하고 Gen8에 꽂아넣은 DVD (장치는 기본적으로 없다. 새로 사서 끼워넣은거)에 dvd 한 장을 올려놓고 재생해봤다.

ESXi client에서 재생해보니 그럭저럭 잘 나오기는 하는데 부인은 이런거 사용할 줄 모른다.

고민하다가 방치된 ipad에 remote desktop 앱을 설치해서 연결한 후에 플레이를 해보니 혹시나 했지만 RDP는 역시나 끊긴다.

5. 다음 여정

VM 하나를 더 생성해서 NAS로 만들어버릴 생각이다.

그리고 DVD는 몽땅 파일로 만들어서 Plex나 기타 서비스로 재생할 계획인데 알 수 없는 문제들을 겪은 터라 벌써부터 겁이 난다.

그래도 해야 한다.

부인 입장에서 뭔가 신기한 효과나 효용성을 보여줘야 내가 다음에 어떤 장비를 사려고 할 때 문제가 없을 것이다.

U+ TV와 공유기 동시 사용시 DDNS 활성화 방안

U+ TV 사용시 불편한 점 하나가 그들의 공유기(나의 경우엔 LG-5000P)를 최상단에 위치시켜야 한다는 점이다.

일반적인 경우라면 문제가 없을 수 있지만 이미 공유기를 하나 사용중이었고 DDNS로 외부에서 접근하곤 했었는데 TV 하나 보자고 조치를 취해야 하는 상황이었다. 초기에는 설치된 상태를 바꿔 LG 공유기를 내 공유기 아래에 붙여 봤었는데 얼마 안가서 TV가 안나오기 시작했다. (지금은 어쩌면 변경할 경우 처음부터 아예 안되게 막혀있는지도 모른다) 고객센터에 전화해서 얘기도 몇번인가 했었는데 기술부서와 연결이 되서 대화해봐도 그들의 공유기가 최상위가 아니면 안된단다. DDNS가 꼭 필요한 것은 아니었지만 외부에서 내 공유기 네트웍에 연결하고 싶었다.

1. 초기 상태

home-nat그림처럼 LG-5000P가 집 내부 네트웍의 최상위에 있고 TV를 제외한 device들은 무선으로 IPTIME 공유기에 붙어있다. 인터넷 연결에는 별 문제가 없는 상황이지만 IPTIME 공유기가 DHCP로 내부 IP를 할당받아 동작하고 있기 때문에 외부에서 접근하지 못한다. 내 공유기를 서랍에 모셔두고 LG 공유기만 사용하면 되지 않느냐 할 수 있지만 LG-5000P는 무선 네트웍이 안된다. (무선이 되는 다른 모델을 받을 수도 있긴 하다) 그리고 포트포워딩 등의 설정을 옮기는 작업이 싫었다. 해본 사람들은 느끼겠지만 LG-5000P 관리화면에 접속하는 순간 그냥 브라우저를 닫고 싶어진다.

2. 일반적인 조치방법들

사용자가 많아져서인지 처음 사용하기 시작했던 2~3년 전보다 알아서 조치해서 사용하는 사례가 많이 보이는데 대충 이렇다.

(1) MAC address 복제

아마도 인증 등의 과정에 LG 공유기의 MAC이 이용되는게 아닌가 싶은데 개인 공유기의 MAC을 LG의 MAC으로 교체하면 LG 공유기는 서랍에 던져놔도 된다고 한다. (IPTIME 공유기의 경우 최근 firmware로 업데이트 해보면 IPTV 설정을 업체별로 할 수 있는 기능도 제공한다.) 이게 제대로만 된다면 가장 깔끔한 방법일 것 같은데 과거에는 TV 볼 때 끊김이 있거나 하는 문제상황들에 대한 글들을 본 기억이 있다.

(2) DMZ 사용

(1)과는 달리 공유기를 모두 사용하되 하단에 위치한 개인 공유기를 LG 공유기의 DMZ에 넣어두고 사용하는 방법이다.

3. Bridged

내 공유기 네트웍에 연결하지 못하는 것은 공유기 IP가 NAT로 동작하는 LG 공유기에서 할당된 내부 IP인 것이 원인이다. 그렇기 때문에 공유기 IP를 LG 공유기 위에서 받을 수 있기만 하면 된다. (LG 공유기도 상위에서 할당받은 외부에서 접근 가능한 IP가 설정되어 있고 개인 공유기를 최상단에 위치하는 것과 같은 효과) 그래서 LG 공유기를 Bridge mode로 변경해보기로 했다. 역시 손대기 싫었던 LG-5000P 관리화면에서 설정을 변경했고 대충 이런 모양으로 바뀌었다. (물리적인 변경은 없음)

home-bridgeTV와 내 공유기가 LG-5000P와 같은 네트웍 대역에서 동일한 위치로 올라왔고 각각 외부에서 접근가능한 IP를 할당받았고 IPTIME의 DDNS에서도 과거엔 등록된 호스트를 찾지 못하다가 정상상태가 되었다. 한 사용자가 외부 IP를 여러개 할당받는게 가능한지 의심스러웠는데 아직 큰 문제는 없는 것 같다.

4. 결론

물리적인 변경없이 NAT를 bridge로 변경하는 것만으로도 필요한 걸 얻을 수 있었다. 하지만 mode 변경 후 IPTIME 공유기가 새로운 IP 할당받는데 시간이 꽤 소요되는 현상이 있었고 이것 때문인지 가끔 TV나 인터넷 연결이 끊어지는 것 같은 느낌이 드는 경우가 있었다. 이런 현상이 지속되면 MAC address 복제하는 방법을 시도할 생각이다.

Update #1.

Bridge mode에서 인터넷, TV 모두 끊기는 현상이 지속되서 결국 MAC address 복제하는 방법을 사용했다.