반응형

VLC version: VLC media player 1.1.9

테스트한 OS: Ubuntu 11.04 (32bit), Ubuntu 12.04 (64bit)


스트리밍으로 받은 비디오의 품질을 측정하기 위해서, 받은 비디오 스트림을 그대로 YUV 형식의 파일로 저장할 필요가 생겼다. 검색해 보니 VLC media player에서 transcode를 이용해서 YUV 형식(raw 형식)의 파일을 내보낼 수 있다. 실험할 때는 굳이 비디오를 눈으로 볼 필요가 없으므로 command line mode에서 작업을 하였다.


$ cvlc [스트리밍 콘텐츠 주소] --noaudio --sout '#transcode{vcodec:I420}:std{access=file,mux=raw,dst='[저장할 yuv파일 경로와 이름]'}'


참고로 vcodec에 적힌 I420은 YUV format의 한 종류이다. I420, I422, I444 등 여러가지 종류가 있는데, 일단 가장 흔히 언급되는 I420에 대해서만 테스트를 하였다. 각 포맷에 대한 설명은 https://wiki.videolan.org/YUV/ 에서 확인할 수 있다.


예를 들어, 192.168.2.3 에서 HTTP streaming (port 8080)으로 test라는 콘텐츠를 열어 놓았고, 이를 output.yuv 파일에 저장할 경우:

$ cvlc http://192.168.2.3:8080/test --noaudio --sout '#transcode{vcodec:I420}:std{access=file,mux=raw,dst='output.yuv'}'


마찬가지로, 로컬에 있는 원본 비디오 파일에 대한 원본 YUV 생성도 같은 방법으로 가능하다. 

예를 들어, 원본 비디오 파일이 /home/usera/original.mp4 위치에 있을 경우:

$ cvlc /home/usera/original.mp4 --noaudio --sout '#transcode{vcodec:I420}:std{access=file,mux=raw,dst='output_original.yuv'}'



문제는, 스트리밍 서버에서 무한반복을 해 놓으면, 받는 쪽에서 중단하지 않으면 위의 명령은 무한정 수행되고, 엄청난 용량의 YUV 파일이 생성될 수도 있다. 스트리밍 콘텐츠의 처음부터 끝까지 재생이 완료되면 중단하고 싶은데, 이것은 어떻게 해야 하는지 모르겠다. ㅜㅜ 

현재로써는 적당한 선에서 Ctrl + C를 눌러서 중단하는 방법이 최선인 듯 하다...



반응형
블로그 이미지

Bryan_

,
반응형


C언어로 작성된 라우팅 프로토콜에서, 디버그를 목적으로 라우팅 테이블을 문자열(char* )로 출력하도록 했는데, 어느 순간 아래와 같은 buffer overflow 메세지와 함께 프로세스가 중단되었다.


18:58:47.109 AodvUseraLogRtTable: 

        dest            next     dst_seq  ifidx  #nextHops

----------------------------------------------------------------    (여기까지 문자열을 출력하는 중이었음)

*** buffer overflow detected ***: ./aodvd terminated

======= Backtrace: =========

/lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x50)[0x1f5df0]

/lib/i386-linux-gnu/libc.so.6(+0xe4cca)[0x1f4cca]

/lib/i386-linux-gnu/libc.so.6(+0xe43c8)[0x1f43c8]

/lib/i386-linux-gnu/libc.so.6(_IO_default_xsputn+0x95)[0x1797e5]

/lib/i386-linux-gnu/libc.so.6(_IO_vfprintf+0x2b06)[0x14fc66]

/lib/i386-linux-gnu/libc.so.6(__vsprintf_chk+0xad)[0x1f447d]

./aodvd[0x804c395]

./aodvd[0x805228a]

./aodvd[0x80596a1]

./aodvd[0x804dff8]

./aodvd[0x804e3ab]

./aodvd[0x804b179]

/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x126e37]

./aodvd[0x80490d1]

======= Memory map: ========

00110000-0026a000 r-xp 00000000 08:01 1570625    /lib/i386-linux-gnu/libc-2.13.so

0026a000-0026b000 ---p 0015a000 08:01 1570625    /lib/i386-linux-gnu/libc-2.13.so

0026b000-0026d000 r--p 0015a000 08:01 1570625    /lib/i386-linux-gnu/libc-2.13.so

0026d000-0026e000 rw-p 0015c000 08:01 1570625    /lib/i386-linux-gnu/libc-2.13.so

0026e000-00271000 rw-p 00000000 00:00 0 

00271000-0028b000 r-xp 00000000 08:01 1570653    /lib/i386-linux-gnu/libgcc_s.so.1

0028b000-0028c000 r--p 00019000 08:01 1570653    /lib/i386-linux-gnu/libgcc_s.so.1

0028c000-0028d000 rw-p 0001a000 08:01 1570653    /lib/i386-linux-gnu/libgcc_s.so.1

004df000-004fb000 r-xp 00000000 08:01 1570612    /lib/i386-linux-gnu/ld-2.13.so

004fb000-004fc000 r--p 0001b000 08:01 1570612    /lib/i386-linux-gnu/ld-2.13.so

004fc000-004fd000 rw-p 0001c000 08:01 1570612    /lib/i386-linux-gnu/ld-2.13.so

00661000-00662000 r-xp 00000000 00:00 0          [vdso]

08048000-0805e000 r-xp 00000000 08:01 1190565    /home/shan/exp/routing/aodv-uu-usera/aodvd

0805e000-0805f000 r--p 00015000 08:01 1190565    /home/shan/exp/routing/aodv-uu-usera/aodvd

0805f000-08060000 rw-p 00016000 08:01 1190565    /home/shan/exp/routing/aodv-uu-usera/aodvd

08060000-08061000 rw-p 00000000 00:00 0 

09aec000-09b0d000 rw-p 00000000 00:00 0          [heap]

b7846000-b7847000 rw-p 00000000 00:00 0 

b7856000-b7859000 rw-p 00000000 00:00 0 

bfe42000-bfe63000 rw-p 00000000 00:00 0          [stack]

$

--> 내용 수정
  다시 확인한 결과, 위의 출력 결과는 strcat에서 buffer overflow가 발생하기 전에, 다른 debug 함수에서 sprintf 함수에 쓰이는 문자열 버퍼의 크기가 제한되어 있어서 발생한 것이며, strcat으로 인한 출력 결과가 아니었다. 하지만 strcat을 수행할 경우에도 이와 비슷한 형태의 에러가 출력되므로, 단지 형태를 참고하는 정도로만 확인하면 좋겠다.


문제가 발생한 해당 함수(AodvUseraLogRtTable이라는 개인적으로 만든 함수)에서는 strcat을 쓰고 있었고, 정해진 크기의 문자열에 for문으로 임의의 갯수만큼 다른 문자열을 한 줄씩 추가하는 형태였다.

char buf[2000] = {0};


for ( i = 0 ; i < RT_TABLESIZE ; i++ )

{

    char* temp = ~~~~~~~~~~; // temp에 자동으로 입력되는 문자열

    strcat ( buf, temp );

}


라우팅 테이블에 4줄까지는 괜찮다가 5줄짜리를 출력할 때 문제가 생긴 것으로 보면 한 줄에 대략 200바이트 내외의 길이가 추가되면서 buf의 크기를 넘어서면서 문제가 생겼을 것이다. 이런 접근을 허용하게 되면, heap 영역에서 프로세스마다(또는 변수마다) 활용하는 메모리 영역을 넘어서는 부분을 수정하게 되므로, 다른 프로세스(또는 다른 변수)에서 예상치 못한 결과를 얻게 되는 문제가 있다.




C언어에서 다양한 방법이 가능하겠지만, 가장 간단하게는 두 가지의 해결 방향이 있을 것 같다.


(1) temp의 사이즈를 미리 지정하고, if문을 이용해서 붙이는 대상(buf)의 크기를 넘어가지 않도록 제어하기

  위의 경우에는 temp* 문자열의 크기가 어떻게 되는지 알 수 없다. 문자열을 생성하는 코드에 따라서 아주 길 수도 이쏙 짧을 수도 있다. 아예 처음부터 temp 문자열을 일정한 크기로 만들고, 형태(format)를 잘 정의해서 규모 있게 운용하면 예상 외의 buffer overflow는 줄일 수 있을 것이다.

char buf[2000] = {0};

char temp[100] = {0}; // temp의 크기를 강제 지정

int buf_pos = 0;


for ( i = 0 ; i < RT_TABLESIZE ; i++ )

{

    memset( temp, 0, 100);

    sprintf( temp, "~~~~~~", ... ); // temp에 입력시 format을 미리 정해서 크기를 일정하게

    if( buf_pos + 100 < 2000 )

    {

        // buf에 여유 공간이 있을 때만 strcat 수행

        strcat ( buf, temp ); 

        buf_pos += 100;

    }

}



(2) strncat을 이용해서 temp의 맨 처음으로부터 일정 크기의 문자열만 붙이기 (+ if문 활용해서 buf 크기 넘어가지 않도록 제어)

  temp 문자열의 크기를 미리 정할 수 없지만 앞의 일부분만 가져다 쓰면 되는 경우에는, strncat 함수를 이용해서 붙여넣을 temp 문자열 중에서 정해진 크기만큼만 buf에 붙여지도록 지정할 수 있다.

만약 100바이트씩만 붙인다면, " strncat ( buf, temp, 100); "이 될 것이다.

char buf[2000] = {0};

int buf_pos = 0;


for ( i = 0 ; i < RT_TABLESIZE ; i++ )

{

    char* temp = ~~~~~~~~~~; // temp에 자동으로 입력되는 문자열

    if( buf_pos + 100 < 2000 )

    {

        strncat ( buf, temp, 100 ); // temp의 맨 앞에서부터 100바이트 길이만 buf에 붙이기

        buf_pos += 100;

    }

}



반응형
블로그 이미지

Bryan_

,
반응형

OS: Ubuntu 계열 (11.04 32bit, 12.04 64bit 에서 테스트)

무선랜카드: IPTIME N150UA (Ralink RT2870/RT3070 칩셋)



<문제의  배경>

  • Ubuntu 시스템에서 실험을 목적으로 무선랜(Wi-Fi) 디바이스 드라이버(device driver) 코드를 수정하고 재설치하기 위해 compat-wireless-3.6.8-1 의 소스코드를 수정하였다.
  • 개발의 대상이 되는 디바이스 드라이버는 Atheros 계열의 ath9k와 ath9k-htc였고, 이에 따라 compat-wireless 소스코드에서 컴파일 대상을 ath9k로 한정지었다.
    ( $ ./scripts/driver-select ath9k )
  • 저렇게 설정하고 나서 compat-wireless를 컴파일하면($ sudo make install), 원래 Ubuntu에 들어 있던 네트워크 관련 커널모듈을 전부 교체해 버리게 된다. 즉, mac80211, cfg80211과 같이 리눅스에서 무선랜 제어에 사용하는 공통 커널 모듈까지 교체된다는 얘기.
  • 문제는 컴파일 대상 디바이스가 ath9k로 한정되는 바람에 Atheros ath9k 칩셋이 아닌 다른 USB 무선랜카드 (e.g. Ralink 계열, Broadcom 계열 등)는 인식을 못하는 경우가 생긴다.



<문제 상황>

ath9k 디바이스 드라이버를 개발하기 전에 쓰던 USB 무선랜카드는 IPTIME N150UA였다. compat-wireless 개발환경을 사용하고 나서 해당 무선랜카드를 PC에 꽂으니 커널 출력 메세지(dmesg 또는 /var/log/kern.log)에서 아래와 같이 수많은 기능들을 이해할 수 없다는 에러를 뿌린다.

$ dmesg

[338283.992800] usb 1-1.1: new high-speed USB device number 11 using ehci_hcd

[338284.102160] usb 1-1.1: New USB device found, idVendor=148f, idProduct=3070

[338284.102165] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[338284.102168] usb 1-1.1: Product: 802.11 n WLAN

[338284.102171] usb 1-1.1: Manufacturer: Ralink

[338284.102173] usb 1-1.1: SerialNumber: 1.0

[338284.122269] Compat-wireless backport release: compat-wireless-v3.6.8-1

[338284.122273] Backport based on linux-stable.git v3.6.8

[338284.122274] compat.git: linux-stable.git

[338284.124318] cfg80211: Calling CRDA to update world regulatory domain

[338284.129011] rt2x00lib: disagrees about version of symbol ieee80211_register_hw

[338284.129016] rt2x00lib: Unknown symbol ieee80211_register_hw (err -22)

[338284.129022] rt2x00lib: disagrees about version of symbol ieee80211_get_hdrlen_from_skb

[338284.129024] rt2x00lib: Unknown symbol ieee80211_get_hdrlen_from_skb (err -22)

[338284.129031] rt2x00lib: disagrees about version of symbol ieee80211_wake_queue

[338284.129033] rt2x00lib: Unknown symbol ieee80211_wake_queue (err -22)

[338284.129039] rt2x00lib: disagrees about version of symbol ieee80211_get_buffered_bc

[338284.129041] rt2x00lib: Unknown symbol ieee80211_get_buffered_bc (err -22)

[338284.129048] rt2x00lib: disagrees about version of symbol wiphy_rfkill_set_hw_state

[338284.129050] rt2x00lib: Unknown symbol wiphy_rfkill_set_hw_state (err -22)

[338284.129060] rt2x00lib: disagrees about version of symbol ieee80211_queue_delayed_work

[338284.129061] rt2x00lib: Unknown symbol ieee80211_queue_delayed_work (err -22)

[338284.129065] rt2x00lib: disagrees about version of symbol wiphy_rfkill_stop_polling

[338284.129066] rt2x00lib: Unknown symbol wiphy_rfkill_stop_polling (err -22)

[338284.129069] rt2x00lib: disagrees about version of symbol ieee80211_ctstoself_get

[338284.129071] rt2x00lib: Unknown symbol ieee80211_ctstoself_get (err -22)

[338284.129081] rt2x00lib: disagrees about version of symbol ieee80211_rx

[338284.129083] rt2x00lib: Unknown symbol ieee80211_rx (err -22)

[338284.129088] rt2x00lib: disagrees about version of symbol ieee80211_iterate_active_interfaces

[338284.129090] rt2x00lib: Unknown symbol ieee80211_iterate_active_interfaces (err -22)

[338284.129093] rt2x00lib: disagrees about version of symbol ieee80211_free_txskb

[338284.129095] rt2x00lib: Unknown symbol ieee80211_free_txskb (err -22)

[338284.129102] rt2x00lib: disagrees about version of symbol ieee80211_tx_status

[338284.129104] rt2x00lib: Unknown symbol ieee80211_tx_status (err -22)

[338284.129107] rt2x00lib: disagrees about version of symbol ieee80211_stop_queue

[338284.129109] rt2x00lib: Unknown symbol ieee80211_stop_queue (err -22)

[338284.129112] rt2x00lib: disagrees about version of symbol ieee80211_stop_queues

[338284.129114] rt2x00lib: Unknown symbol ieee80211_stop_queues (err -22)

[338284.129119] rt2x00lib: disagrees about version of symbol wiphy_rfkill_start_polling

[338284.129121] rt2x00lib: Unknown symbol wiphy_rfkill_start_polling (err -22)

[338284.129124] rt2x00lib: disagrees about version of symbol ieee80211_iterate_active_interfaces_atomic

[338284.129126] rt2x00lib: Unknown symbol ieee80211_iterate_active_interfaces_atomic (err -22)

[338284.129134] rt2x00lib: disagrees about version of symbol ieee80211_channel_to_frequency

[338284.129136] rt2x00lib: Unknown symbol ieee80211_channel_to_frequency (err -22)

[338284.129139] rt2x00lib: disagrees about version of symbol ieee80211_unregister_hw

[338284.129140] rt2x00lib: Unknown symbol ieee80211_unregister_hw (err -22)

[338284.129146] rt2x00lib: disagrees about version of symbol ieee80211_beacon_get_tim

[338284.129148] rt2x00lib: Unknown symbol ieee80211_beacon_get_tim (err -22)

[338284.129150] rt2x00lib: disagrees about version of symbol ieee80211_rts_get

[338284.129152] rt2x00lib: Unknown symbol ieee80211_rts_get (err -22)

[338284.129159] rt2x00lib: disagrees about version of symbol ieee80211_queue_work

[338284.129161] rt2x00lib: Unknown symbol ieee80211_queue_work (err -22)

[338284.130166] cfg80211: World regulatory domain updated:

[338284.130170] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)

[338284.130173] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)

[338284.130175] cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)

[338284.130177] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)

[338284.130179] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)

[338284.130180] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)

$


USB 연결에는 이상이 없는지 확인해 보니 USB 장치 수준에서는 제대로 인식을 하고 있다.

$ lsusb

Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub

Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Bus 001 Device 012: ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter

$




<해결 방법>

원인이 명확하게 Compat-wireless 개발환경이기 때문에 해결 방법은 간단하다.

Ralink 계열도 이해할 수 있도록 ath9k 뿐만 아니라 다른 모든 칩셋의 소스코드를 다 컴파일하면 된다. 그러면 다른 칩셋 계열의 기능을 이해할 수 있는 mac80211, cfg80211 커널 모듈이 새로 생성되고, 이들이 자동으로 시스템의 /lib/modules/ 에 복사된다.


  (먼저 compat-wireless 개발환경의 최상위 디렉토리로 이동한다.)

$ ./scripts/driver-select restore    <-- 소스코드 전체를 컴파일하도록 기본 설정으로 되돌림

$ sudo make install

  (모든 칩셋을 다 컴파일하기 때문에 성능이 안좋은 PC에서는 꽤 긴 시간이 걸린다.)


$ sudo make wlunload      <-- 기존에 로드된 무선네트워크 관련 모듈을 unload 시킨다.


위와 같이 하고 나서 USB 디바이스 드라이버에 해당하는 모듈을 sudo modprobe를 이용해서 load한다. (예: $ sudo modprobe rt2800usb) 콘솔 화면에서 무슨 모듈이 unload되었는지 확인하고 그것들을 다시 load하면 되는데, 무엇을 load해야 할 지 잘 모르는 경우가 있을 수도 있다. 

그럴 때는 USB 무선랜카드를 뽑았다가 다시 PC에 꽂으면 된다또는 깔끔하게 재부팅하는 것도 좋은 방법이다.





반응형
블로그 이미지

Bryan_

,
반응형

작년(2013년 7월)에 A급 또는 top급으로 분류되는 국제학회에 제출한 논문이 reject 되고 나서 고치는 동안, 그 학회에 논문을 제출했던 때로부터 어느새 거의 1년이 다 되었다. 사실 지난 1년간 많은 부분을 개선하지는 못했다. 이로 인해서 누군가가 이 점을 지적하지 않았는데 도둑 제 발 저리듯이 먼저 괴로워했었고, 내가 이것밖에 안되는지에 대해서 자책을 많이 했었다. 그 자책의 요지는 이런 것이었다:


"작년에 학회에 냈던 논문을 빨리 보완해서 어디든 냈어야 하는데, 어느새 한 것도 없이 같은 학회의 이듬해 제출기한이 오다니! ㅜㅜ"


다시 말하면 나는 지난 1년 조금 안되는 시간 동안에 내 연구주제의 메인이 되는 논문을 빨리 어딘가에 제출해서 성과로 만들어야 한다는 강박관념을 갖고 있었고, 지금에 이르러서는 급기야 그 논문이 마치 썩어 없어질 것만 같은 걱정(;;;)에 휩싸였던 것 같다.


그런데 최근에 지도교수님과 논문에 대해서 토의를 해 보니, 그런 걱정 쓸데없는 것임을 깨달았다. 물론 긴 시간 동안 빨리 보완하지 못한다면 논문 자체의 기술적인 배경이 old-fashioned가 되거나, 아이디어가 다른 사람에 의해 선점당할 수는 있다. 하지만 아직 그런 상태는 아니고, 오히려 시대적인 트렌드 측면에서 논리적으로 설득력 있게 만들어갈 여지가 다양하게 있음을 알게 되었다.


내 연구에 대해서 마음을 놓아버리지 않도록 긴장의 끈을 유지하는 측면에서 스스로 적당히 채찍질할 필요는 있겠지만, 단지 지난 1년간 성과로 만들지 못한 것에 대해서 너무 심각하게 연연할 필요는 없을 것이다. (사실 그동안 B급 이하의 소소한 국제학회에는 1~2저자로 여러 논문을 내서 accept 되었고, 그동안 정부 과제도 수행하고 사물 인터넷 환경도 만들면서 이것저것 일들을 많이 했으므로, 아무것도 안했다는 자책에서는 이제 그만 벗어나야겠다.)


연구에 임하는 마음가짐이 스포츠와 크게 다르지 않아 보인다. 2002년 월드컵을 준비할 때 히딩크 감독의 소신 있는 훈련 속에서 강팀과의 경기에서 여러 번 졌지만 결국 월드컵에서 좋은 결과가 있었던 것을 기억한다. 물론 한국이 포르투갈, 이탈리아, 스페인, 독일과 동급의 최강팀이 결코 아니었지만 자신 있게 그러한 팀들과 붙으면서 한국 입장에서는 최선의 능력을 발휘해서 좋은 경기를 보여 주었다.


나도 마찬가지인 것 같다. 페이지랭크 논문을 쓰고 구글을 창업한 세르게이 브린이나 박사과정 때부터 분산 시스템의 네이밍 분야에서 세계적인 석학 취급을 받은 브라이언 포드 같은 사람이 당장 될 수는 없다. 하지만 개인적으로 지도교수님의 연구 능력과 insight에 대해서 충분히 존경하는 바, 상급 학회의 reject나 단기적 성과의 부재에 연연하지 말고 교수님의 지도에 따라 자신있게 집중적으로 연구에 임한다면 머지않아 나도 내 나름대로의 기준에서는 최선의 좋은 결과를 얻을 수 있을 것이다.


오늘도 화이팅*



반응형
블로그 이미지

Bryan_

,
반응형

OS: Ubuntu 계열 (11.04부터 12.04까지 테스트)



자바(Java)로 서버 소켓을 열고 자기 자신의 IP주소를 다른 연결된 기기에 알려 주는 간단한 프로그램을 짰는데, 이상하게 IP주소가 실제 장비의 IP주소와 다르게 나왔다.

예를 들면, ifconfig 명령을 통해서 나오는 네트워크 인터페이스 주소 192.168.1.6인데, 자바 프로그램에서는 전혀 엉뚱한 192.168.1.17로 인식되는 문제였다. SSH, ping을 비롯한 실제 네트워크 연결은 모두 192.168.1.6으로 정상적으로 수행되는데, 이상하게 Java 코드에서 IP주소를 얻어오는 명령에서는 다른 IP주소를 보게 되는 것이다.



네트워크 설정에 따라서 여러가지 원인이 있을 수 있겠지만, 가장 간단한 원인으로는 /etc/hosts 파일에 IP주소가 잘못 적혀 있는 경우가 있다. 필자의 경우에도 예전에 쓰던 리눅스 머신을 다른 네트워크에 연결시키면서 유동IP를 통해서 새로운 IP주소를 부여받았지만, /etc/hosts 파일에는 예전에 이동하기 전의 IP주소가 기록되어 있는 것을 발견했다.


아래와 같이 /etc/hosts 파일에서 리눅스 머신 이름에 매핑되어 있는 IP주소를 올바른 IP주소로 변경하거나, 아예 해당 라인을 삭제함으로써 해결할 수 있다. 그러나 해당 라인을 아예 삭제할 경우, 상황에 따라 네트워크에 연결하는 특정 프로그램이 작동하지 않을 수도 있으므로 삭제하기 전에 확인이 필요하다.


127.0.0.1  localhost

192.168.1.6  usera-Linux    # IP주소를 올바르게 맞추거나, 해당 라인 삭제




반응형
블로그 이미지

Bryan_

,