극히 개인적이고 극히 대단하지 않은

대부분의 SIP메세지는 TLS로 암호화되어 전달되기 때문에 wireshark로 잡아도 그 내용을 알 수가 없다. 단순히 Application Data로만 표기되기 떄문에 이미 알고있는 IP와 포트정보를 제외하면 유일한 의미있는 정보는 사이즈 밖에 없게되고 여기서 분석의 한계에 부딪히게 된다.  이 떄, 해당 장비에서 암호화와 복호화에 사용한 pem 인증서(개인키)가 있다면, 해당 패킷을 까서 볼 수가 있다. 다만 핸드쉐이크 과정의 세부적인 사항을 알 수 없는 TLSv1.3에서는 불가능하고, 그 이하 버전에만 적용이 가능하다. 구체적인 방법은 다음과 같다.  Wireshark의 편집/설정 메뉴로 들어간다. 왼쪽 박스에서 Protocol을 선택해서 펼쳐진 항목 중 TLS를 선택한다.   여기서 RSA key..

새로운 서버를 설정할 때마다 자꾸 잊어버려 같은 삽질을 반복하는 것 같아서 아예 여기에 박제해둔다. /etc/environment 에 다음을 추가하고 시스템을 재시작해준다. LANG="ko_KR.UTF-8"LANG="ko_KR.EUC-KR"LANGUAGE="ko_KR:ko:en_GB:en"LC_ALL=C 이후 터미널, 특히 vi에디터에서 한글이 깨지지 않는다. 속이 시원하다.

mysqlmysql -u rootmysql -u root -pxxxx어떤 것을 해도 ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)이와 비슷한 에러가 떨어진다. 이럴 때 갑갑하다. 접속을 해서 패스워드를 바꾸던지 뭘 하던지 해야하는데 일단 접속이 안되니 말이다. 이럴 때에는 아래와 같이 기계적으로 풀어보자.mysql daemon 중지 (systemctl로 stop하던, init.d 스크립트를 stop하던 배포판에 맞는 명령으로) sudo mysqld_safe --skip-grant-tables & mysql -u root이제 필요한 작업을 해보자.

환경은 ubuntu 20.04이다. 현장의 장비가 원인없이 reboot되는 경우가 있어서 kdump를 설정했다. 구글링한 정보들을 짜맞춰서 정상적으로 설정이 된 것 같은데 문제가 발생했을 때, reboot이 아니라 hang이 발생하고 crash정보도 생성되지 않아 더 난감한 상황에 빠진 적이 있다. 정상적으로 kdump가 설정된 것은 다음과 같은 정보들로 확인했다. USE_KDUMP가 1이고, current state가 ready to dump이면 kdump가 생성될 조건이 되었을 때, 생성이 되어야 하는 것이다. 이런데도 불구하고 kdump가 생성되지 않는다면, kdump를 위한 메모리 확보가 충분하지 않아 그럴 가능성이 높다. 콘솔에서 다음과 같은 부분이 발견된다면 더더욱... [ 3.598311] ..

언젠가는 좀 상세하게 정리해야 겠지만, 그렇게 할 시간을 내기 전에 간단히, 잊어버리지 않을 정도로 기록을 남길 필요가 있어서 정리해둔다. 다수의 클라이언트에서 주기적으로 같은 시간 대에 데이터를 받아 처리하는 서버를 구현중이다. 클라이언트가 120대 정도 예상하고 있으니 최대 동시에 120 커넥션을 처리해야한다. 이러한 환경에서는 특정 커넥션에서 행이 발생한다던가 그로 인하여 다른 커넥션 및 시스템 전반에도 영향을 준다던가 하는 상황을 만들지 않기 위해, nonblock 소켓을 epoll 로 정확하게 제어하는 것에 매우 신경을 쓰게된다. 기본적인 시험을 통해서는 nonblock 소켓과 epoll 구현이 정확하게 예상대로 잘 동작함을 확인하였고, 120개의 클라이언트를 시뮬레이션할 시뮬레이터를 작성하여 ..

Multithread program을 작성하고 버그를 잡다보면 thread의 pid를 알아야 간지러운 곳이 해결되는 경우가 있다. 특히 gdb를 이용해서 디버깅을 하는 경우에 아쉬울 때가 많다. 그런 경우에는 thread 내부에서 다음과 같은 코드를 수행하면 자신 thread의 pid를 알 수 있다. syscall(__NR_gettid) 예를 들어 다음과 같이 코딩을 하면 thread 이름과 pid를 확보할 수 있다. #include #include #include void *sample_thread (void *arg) { ... printf ("Thread Information :: [%s][%d]\n", __func__, syscall(__NR_gettid)); ... pthread_exit (NU..

C로 프로그램을 작성하고 시험을 하다보면 수없이 많은 core 파일을 만나게 되는 경우가 있다. core 파일은 개발자 입장에서 별로 만나고 싶지 않은 파일이긴 하지만, 정상적으로 동작하지 않는 프로그램과 긴긴 시간을 씨름할 때에 있어서 core 파일은 때로는 사막에서 오아시스를 만나듯이 반가운 경우도 있다. core파일을 얼마나 능수능란하게 다루고 요긴한 명령들을 조합해서 잘 쓰는가에 따라 core파일은 개발자에게 문제를 해결할 수 있는 명쾌하고 직관적인 정보를 주기도 하지만, 그렇지 않은 경우에는 문제점에 더불어 해결해야 할 숙제를 하나 더 떠안은 것 같은 부담으로 작용할 수도 있다. core파이을 분석하기 위해 다양한 명령어를 쓰지만, 흔히 쓰지 않으면서도 알고 있으면 도움이 될만한 명령을 소개한다..

귀차니즘의 극을 달리다가 드디어 정리한다. 뭐 그리 중요하거나 대단한 기술은 아니지만, 더 머리가 굳어가기 전에 남겨두는 게 맞을 것 같아서... 코드를 작성하고 디버깅을 하다보면, 코드 어디 쯤 실행이 되고 있는 것인지 확인하는 가장 좋은 방법이 로그를 찍어보는 것이다. 그런데, 간혹 다른 사람의 코드를 디버깅하다보면 'return NOK!' 라는 출력이 있어 여기 쯤 문제가 있겠구나 하고 추정을 하게되고 'return NOK!' 라는 문자열을 소스에서 찾아보게 되는데, 'return NOK!' 라는 문자열이 이런 저런 소스에 분산되어 한 200군데에 있다면, 정말 짜증이 나지 않을 수 없다. 개인적으로 간단하게 로그의 위치를 확인하기 위해서는 잘 알려진 방법인 __func__와 __LINE__ 매크로..