상당히 오래전 DD-WRT 펌웨어를 소개하고, 이 설치 방법을 포스팅하겠다고 했는데 어느새 벌써 11월의 마지막 주입니다.

DD-WRT는 WRT계열 오픈소스 라우터 펌웨어로 라즈베리파이를 깊게 사용해보신 분이라면 OpenWRT 정도는 들어보셨을 겁니다.

OpenWRT는 가장 오래되었고 가장 많은 기능을 수행할 수 있지만 여타 리눅스처럼 기본 기능만 들어있고 나머지는 패키지로 별도 설치, 설정해야하는 불편함이 있습니다. 

DD-WRT는 빌드 버전별로, 빈티지 별로 사전에 정의된 모든 기능이 다같이 들어있는 펌웨어로 초보자도 비교적 쉽게 다루지만 세세한 설정을 하기는 힘듭니다.

두 펌웨어 모두 공통적으로 리눅스 기반입니다.

즉, 라우터로써의 기능 뿐 아니라 다른 기능도(웹서버 등) 가능하다는 이야기입니다.

사실 소형 컴퓨터 하나 생긴다고 보셔도 됩니다.

WRT 펌웨어는 WRT 계열만 가능합니다. 모델명이 WRT가 아니라 WRT 계열 펌웨어만 WRT 계열의 다른 해킹펌, 오픈소스 펌웨어로 해킹이 가능합니다.

DD-WRT의 커펌 가능 여부와 다운로드는 이곳에서 조회할 수 있습니다.

DD-WRT의 설치에 앞서 갑자기 다시 포스팅을 한 이유를 알려드리겠습니다.

바로 요놈인데요.

요놈의 이름은 WRT54G Rev.2로 정말 잔고장치레조차 안하기로 유명한 공유기중에서도 제일 안나기로 유명한 리비전입니다.

유선 100mbps, 무선 11g 밖에 지원하지 않는 구형이지만, 여전히 한번 써본 사람들은 11n 공유기가 있음에도 혼용해서 쓰거나 뜯지도 않을 정도로 많은 분들이 애용하는 공유기입니다.

그 정도로 좋고 요즘은 시중에서 보기 힘든, 공유기 안정성으로는 레전드로 칭해도 괜찮은 공유기인데요.

누가 학교에 일반 쓰레기로 버렸더라구요.

<ⓒ 영광군청>

재활용합시다.

어쨌든, 리비전 7 8은 지금도 쉽게 구하지만 리비전 2는 중고로도 구하기 힘든 공유기입니다. 중3? 고1때 모 Wireless lab에 반납한 뒤로 처음 보게되어 되게 설레네요.

일단 공유기를 위 사진과 같이 전원을 공급하고, 컴퓨터와 연결했습니다.

먼저 공유기가 정상 작동을 하는지를 진단하기 위함인데요.

먼저, 저는 820라인에 32g램으로 워크스테이션처럼 굴리기 때문에 랜카드가 다수 설치되어 있어 아이피 대역 충돌이 예상되는 랜카드를 먼저 Off 했습니다.

그 다음 54g가 연결된 이더넷 2의 정보를 확인하니 게이트웨이가 192.168.1.1이네요.

TFTP 방식도 있지만, TFTP는 처음 접하는 분들은 꺼리는 방법이고, 실제로 위험하기도 해서 WebGUI로 먼저 테스트했습니다.

다행히 펌웨어가 잘 올라오고 lan을 하나 더 빼서 다른 공유기에 물려보니 외부 통신도 잘 진행이 됩니다.

이제 DD-WRT 펌웨어로 펌웨어를 교체하는데요.

주의사항이 있습니다.

하드웨어의 내장 프로그램을 교체하는 만큼 아래의 작업을 신중하게 해주셔야 합니다.

SW적인 오작동은 TFTP로 복구가 가능하지만, HW적인 오작동을 하는 순간 그 공유기는 더 이상 살릴 수 없습니다.(수리비가 더 나가죠)

다음으로 30/30/30 Hard Reset을 수행합니다.

30/30/30 하드 리셋은 공유기의 롬을 완전히 초기화하는 기능입니다.

공유기 기종에 따라서 WebGUI에 아무 데이터가 없는 상태로 초기화 되는 것부터, Web마저 동작하지 않는, TFTP만 살아있는 깡통이 되기까지의 상태로 공유기가 필요 최소한의 기능만 제외하고 전부 초기화되는 것을 의미합니다.

WRT 이식에 있어 공장 초기화보다 로우레벨의 초기화를 수행해야 이기종 펌웨어 이식에 문제가 없습니다.

리셋이 끝나면 공유기와 컴퓨터를 연결한 뒤, 아이피는 192.168.1.7 / Sub 255.255.255.0 주시고 192.168.1.1 로 연결합니다.

Administration -> Firmware Upgrade -> 파일 선택을 눌러 DD-WRT 펌웨어를 엽니다.

펌웨어는 RouterDatabases 에서 구할 수 있으며 자신의 기종과 리비전에 맞는 펌웨어중 가장 최신의 바이너리를 다운로드 합니다.

다운로드는 공유기마다 상이하지만 일반적으로 동일 버전 동일 패키지의 mini, std 두가지가 필요합니다.

mini와 std 두가지를 전부 내려받는 이유는

mini는 일종의 인터페이스 역할을 합니다.

Java에도 interface가 있고 Delphi에도 interface가 있죠?

mini는 DD-WRT의 본체가 이식되기 전 먼저 파티셔닝과 사전설치를 해주는 펌웨어입니다.

이놈을 통해서 DD-WRT의 본체가 이식이 되게 됩니다.

Router Databases 에서 본인의 기종 모델명을 검색한 뒤, Revision이 일치하는 레코드를 클릭합니다.

자신의 FLASH 용량을 체크하고, 지원하는 버전중 고르고(안전한 커펌을 원하면 pre가 있는 빌드는 사용하지 마세요) 다운로드 합니다.

저는 여기서 v24SP2 Build 13064 빈티지 버전을 사용했습니다.

이제 다운로드한 파일 중 mini를 선택해서 열고 

Upgrade를 누르면 아래와 같이 진행이 됩니다.

경과 시간은 약 3~4분정도 걸립니다.

폄웨어 교체하는 동안 절대 전원에 문제가 생기면 안됩니다.

잠시 기다리면 완료 되었다는 메시지가 나옵니다.

다시 주소창의 url을 지우고 192.168.1.1 로 접속합니다.

우측 상단에 mini가 보이고 v24sp2가 정상적으로 업로드 되었음을 볼 수 있습니다.

Memory -> Total Available의 손실된 2.4MB는 손실된 것이 아니라 펌웨어가 설치되어 소모된 메모리 용량이니 걱정하지 않으셔도 됩니다. (사실은 제가 처음에 그랬거든요. 손상된줄 알고 ㅋㅋ)

이제 다시 Administration -> Firmware Upgrade 로 들어가서 

파일 선택을 누르고 이번엔 std, 스탠다드를 엽니다.

그리고 Upgrade를 누르면 아래와 같이 진행이 되며 잠시 후 공유기로 재접속이 됩니다.

업그레이드 대기 시간은 최대 300초로 보통은 1분 전후로 끝납니다.

(예, 사실 54g 시간 측정 안했습니다._. WNDR3700은 1분 정도면 끝나더군요)

정상적으로 업그레이드가 되면 우측 상단에 mini가 std로 변경됨을 보실 수 있습니다.

이제 원하는 대로 설정해서 사용하시면 되며 비교적 최신 기종이어서 향후 업데이트가 나오는 기종이라면 별도의 설명이 없다면 Firmware Upgrade에서 std 파일만 바로 올리셔도 됩니다.

WNDR3700 기준으로 13년 이후로 sp는 중단되었지만, 이후 빌드는 16/11/14 기준 30880을 마지막으로 계속 나오고 있네요.

php에서 현재의 시간으로부터 특정 시간의 값을 취하고 싶을 때

방법 1에서

format 에는

interval 에는

방법 2에서

DateInterval 에는

P+

델파이는 Try ... except ... end 로 예외처리를 지원하고 있고 Indy 또한 Error Exception을 지원합니다.

하지만 예전에는 Indy의 exception이 IdException에 정의되어 있었습니다.

하지만 지금은 IdException을 uses 하면 파일이 있다고 나오지만

예전 코드나 예제는 더이상 사용할 수 없습니다.

왜냐하면 에러 정의가 IdException이 아닌 IdStack으로 옮겨졌기 때문입니다. 

그래서 옛날 코드나 예제를 사용하면 특정 인디 버전부터는 E2003 Undeclared identifier 에러가 발생합니다.

델파이는 대부분의 예제가 08년 09년을 기점으로 그 이전에 많이 기록이 남아 있습니다.

이제는 인디 컴포넌트의 예외처리를 하려면 IdStack을 uses해야 합니다.

위와 같이 처리하면 됩니다.

위 코드는 서버 접속 시 10060 Time Out 에러에 대한 예외처리를 하고 있습니다.

어느 상황의 에러가 어떤 코드인지 알고 싶다면, 아래 사이트를 참고하세요.

TRectangle, TEdit... 등등 TBrush나 기타 TAlphaColor를 프로퍼티로 갖는 객체의 색상 값은 일반적으로 BGR코드를 사용합니다.

델파이는 RGB코드가 아닌 BGR코드를 사용하며 #RRGGBB가 아닌 $LLBBGGRR형식을 따릅니다.

기존에 웹이나 포토샵을 많이 다루던 분들은 생소한 포맷이나 기존의 RGB에 HSL의 Lightness 가 추가된 형태라 생각하시면 쉽게 이해하실 수 있으실 겁니다.

LL의 두 자리를 활용하여 해당 색상의 밝기를 조절함으로써 색의 밝기도 같이 표현하죠.

하지만 안그래도 더 복잡해진 코드, 정해진 색상표는 없을까요?

델파이는 이러한 고민을 위해 사전에 색상을 정의하고, 이 색상의 느낌에 맞는 이름을 부여하고, 이를 const 상수화 했습니다.

이 상수화된 색상에는 밝기 부분이 정의되있지 않은 가장 밝은 색에 가까운 색상들입니다.

예를들어 핏빛색에 가까운 claCrimson 을 사용한다면, 델파이의 코드는 이렇게 동작하죠.

어라? 앞에서 분명 델파이의 코드는 $LLBBGGRR이라고 했는데 6자리밖에 없다구요?

델파이의 색상은 별도로 밝기가 정의되지 않으면 밝기는 무조건 FF가 됩니다.

Alpha라는 상수를 보세요.

$FF000000 의 값으로 LL에만 FF 나머지는 00의 값을 가집니다.

이것이 Crimson으로 정의된 BGR 컬러와 or 연산이 되어 $$FFDC143C로 넘어오는 것이죠.

OR은 두 값의 비트를 비교했을 때 둘 중 하나라도 1이 있다면 해당 비트는 1이 되는 연산입니다.

그래서 FF00 0000 과 00DC 143C 를 연산한

이 되죠.

그런데 이 편한 기능이 종종 동작하지 않을 때가 있습니다.

델파이 IDE는 언어와 프레임웍은 정말 좋지만,  다소 불안정한 면이 있어 다른 IDE에서는 부드럽게, 유연하게 동작하는 기능들이 델파이 IDE에서는 정상적으로 동작하지 않는 경우가 있습니다.

예를들어 델파이는 사용한 객체에 따라 자동으도 uses가 되지만, 이것이 사용하지 않을 때 자동으로 해제가 되지 않습니다.

점을 찍어 하위 프로시저 등을 참고하려 해도, 전혀 상관없는 다른 부분의 코드에 문제가 있으면 그 부분을 지적하는 것이 아니라 전체의 소스에서 이 기능이 동작하지 않습니다.(심지어 빌드시에도 알려주지 않습니다)

이러한 불안정한면 중에서, 사용을 하지만 프로그래머가 생성하지 않은 객체에 대한 uses는 되지 않는 것같습니다.

예를들어, TRectangle.Fill.Color 에서 프로그래머는 TRectangle을 선언했지 Color의 TAlphaColor을 선언한 것이 아닙니다.

델파이는 그렇기에 프로그래머가 전혀 사용하지 않는다고 판단하고 상수화된 색상 사용을 위해 반드시 uses 되어야 할 'System.UIConsts' 라이브러리가 자동으로 uses가 안되는 경우가 있습니다.

다른 언어의 IDE는 이런 날코딩으로 사용된 객체도 필요하면 자동으로 인클루드나 임포트가 됩니다만, 델파이 IDE는 아직 보완되어야 할 부분이겠지요.

결론은,

델파이의 색상은 $LLBBGGRR로 저장됩니다.

기본 색상코드를 단어가 사용된 상수를 사용할 수 있습니다.

상수는 cl, 또는 cla + 색상명입니다.

색상에 상수 사용 시 'E2003 Undeclared identifier' 이 발생한 경우 자신의 프레임웍에 맞는 접두사가 아니거나(cl, cla) System.UIConsts가 uses되지 않은 경우입니다.

TEdit은 단일 라인의 입력 컴포넌트로 많이 쓰이는 컴포넌트입니다.

TEdit은 기본적으로 네모 박스 하나만 나오고 이것이 무슨 값을 취하려는지 나오지 않습니다.

이렇게 네모 박스만 생기죠.

그래서 이 박스가 무엇인지를 위해 앞에 TLabel을 달거나 이미지를 붙여줍니다.

하지만 이렇게 하면 VCL이나 PC같이 큰 화면에서는 문제가 없지만 FMX에서는 가용 면적이 줄어드는 역효과가 있습니다.

이를 위해 델파이는 TLabel이 아닌 TEdit의 TextPrompt 프로퍼티가 정의되어 있습니다.

이 프로퍼티는 Prompt 즉, 해당 TEdit에 사용자가 입력한 내용과 별개로 배경처럼 해당 TEdit이 무엇을 입력받으려는지를 명시해주는 역할을 합니다.

이렇게 TEdit을 선택한 뒤, 해당 TEdit에서 입력받을 것이 무엇인지 명시해주면 아래와 같이 희미하게 나타납니다.

문제는 이렇게만 하면 입력 시에 프롬프트가 지워지지 않아 내가 무얼 입력했는지 글자가 겹쳐 보기 힘들다는 점입니다.

TEdit의 OI의 Events를 보면 OnCanFocus 라는 이벤트가 있습니다. 이 이벤트는 해당 개체에 포커스(초점)이 있으면 발생하는 이벤트로 TEdit에서 내용을 입력하기 위해 커서가 들어가는 것도 초점이 들어가는 것입니다.

이제 이 이벤트에 내용을 채웁니다.

간단합니다.

우리의 목적은 입력 시에 내용을 지워주면 되는 거니까요.

문제는 여기서 발생합니다.

만약 포커스가 있었다가, 아무 내용도 없이 떠나면 이게 무슨 입력이었는지 알 수가 없습니다.

내용이 빈값이면 다시 보여주어야겠죠.

Events에 OnExit라는 이벤트가 있습니다.

이 이벤트는 포커스가 떠날 때 발생하는 이벤트입니다.

그럼 이 이벤트의 내용을 채워봅시다.

이렇게 해주시면 TEdit에 포커스가 발생했을 때, 포커스가 떠났을 때 TextPrompt의 내용을 없애기도, 다시 보여주기도 합니다.

이를 응용하면, 항시 프롬프트가 있어야 하면 프롬프트의 색을 더 옅게 한다던지, 프롬프트가 아닌 Text그 자체에 대한 수정도 가능합니다.

반대로 Text에 명시를 해줬다가 입력을 시작하면 Prompt로 바꿔줄 수도 있죠.

이에 대한 응용은 여러분의 몫입니다.