패킷 체크섬오류에 대한 질문입니다.
글쓴이: mirr / 작성시간: 화, 2006/03/07 - 11:56오전
윈도우프로그램으로 (Visual C++) 소켓통신을 합니다.
클라이언트에서는 일정 데이타를 패킷에 실어서 서버로 보내주고,
서버에서는 그 데이타를 받고, 원하는 내용을 추려낸뒤 다른 mysql서버가 있는 곳으로 인서트 시켜줍니다.
그런데 어느순간부터 - 정확히 1월 1일 - 이 서버에서 전달되어 오는 패킷이나,
서버로 보내어지는 패킷이나 불규칙적으로 손실을 내고 있는것입니다.
몇일을 고민하다 패킷캡춰를 통해(이더리얼이용) 서버프로그램으로 오는 패킷들을 캡춰해 보기로 했습니다.
패킷량이 확실이 별로 없었고, 내부아이피로 접속되거나 몇몇 아이피의 경우에는 아예 패킷이 전달조차 안되었습니다.
의아한 마음에 각종 백신프로그램의(바이로봇, V3)시스템감시 및 인터넷감시를 모두 껐습니다.
그러니 이제 사내 서버에서 오는 공인아이피의 데이타는 잘 날아옵니다만 역시 내부아이피에선 안날라오고있습니다.
그런데 이젠 서버프로그램이 날아온 데이타를 제대로 받아서 sql로 인서트를 못시키는겁니다.
역시 패킷캡춰를 mysql인 3306포트로 해봤습니다.
몇가지 연결이 있었지만 번번히 Checksum에서 오류가 남을 발견할 수 있었습니다.
서버프로그래머와 클라이언트프로그래머는 따로 한분 계십니다.
이분 말로는 특별히 패킷에대한 변화를 가하지도 않았고 12/30일까지는 잘 되던것이 갑자기 안된다는겁니다.
참고로 그날은 윈도우 업데이트를 한뒤 리부팅을 시킨 날입니다.
지금 이놈의 원인을 찾아내느라 정신없습니다 ㅜ.,ㅜ
제게 빛을 밝혀주세요.....
Forums:
checksum에 오류가
checksum에 오류가 난다면 서버와 DB 서버 사이에 다른 통신(telnet 등)은 잘 되나요?
네
잘 돼고 있습니다.
어제 하루종일 또 패킷분석만 해본 결과로는
체크섬에러가 나는 부분은 이미 클라이언트에서 데이터를 패킷에 담아 서버로 보낸후
연결종료 부분에서 에러가 나는것이였습니다.
일단 프로그램의 연결구조를 말씀드리겠습니다.
클라이언트 프로그램은 램에 상주하면서 특정 정보를 주기적으로 혹은 어떤 이벤트가 발생할 경우마다
정해진 정보를 서버로 보냅니다.
서버에서는 WSAOVERLAPPED 만큼의 메모리를 할당 한 후, 이 클라이언트에서
날아오는 패킷을 받아 역시 정해진 SQL 구조대로 쿼리를 만들어 Mysql로 쿼리를 날립니다.
문제가 더 복잡해지는 이유로는 아예 안받아지는게 아니라, 대략 몇십개중에 한두개정도는
제대로 받아들여지고, sql로 쿼리를 날려 DB에 저장시킨다는 점입니다.
어제는 수정한적이 없다고 했는데 지금 프로그래머께서 사실 그 이전 개발자가
12/30일날 퇴사하는거였는데 급하게 고칠게 있어서 수정을 했긴 했답니다.
수정내용은 기존 클라이언트에서 날려보내는 정보중에 몇가지 더 추가한 것이랍니다.
클라이언트에서도 문제가 있는게 사내서버에서 돌리는 경우(사설아이피) 패킷이
제대로 날라오질 않습니다.
이건 사설네트워크 구성의 문제인가요?
수정사항이 있었다는 얘기를 듣고 완전히 처리를 성공한 패킷과 무시되어진 패킷을
비교해봤지만 잘 모르겠습니다.
복잡합니다 ㅜ.,ㅜ
PS. 혹시 패킷의 포맷(길이, 종류등)의 문제라면 클라이언트의 send부분과
서버의 recv부분만 따로 때와서 새로운 테스트프로그램을 통해 테스트해봐도
효과가 있을까요?
단위테스트도 가능할까요? VC를 잘 다뤄보지 못했고, VC로 네트웤프로그래밍을 해본적이 없어서 ㅜ.,ㅜ
--------------------------------------------------------------------------------------
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
가장 좋은 방법은
가장 좋은 방법은 고치기 전의 코드로 돌아가는 것이겠습니다만...
프로그램에 문제가 있다면
1. 패킷의 종류에 따라 오류가 안나기도 한다.
2. 서버에서 제대로 관리하지 못해서 패킷이 뒤엉켜버린다.
두가지를 의심해 볼 수 있겠네요. recv, send를 따로 떼서 패킷 종류별로 테스트를 해보면 도움이 될 것 같습니다.
하지만 그 전에 퇴사하신 분께 전화해서 어떤 수정을 했는지 확인해 보세요.
네..
관심가져주셔서 감사합니당^^
일단 담당프로그래머께서 전화로 물어보기로 했구요,
센드, 리시브루틴을 따로 때서 테스트해봐야 겠습니다.
--------------------------------------------------------------------------------
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
잘 돼고
잘 돼고 있습니다.
어제 하루종일 또 패킷분석만 해본 결과로는
체크섬에러가 나는 부분은 이미 클라이언트에서 데이터를 패킷에 담아 서버로 보낸후
연결종료 부분에서 에러가 나는것이였습니다.
일단 프로그램의 연결구조를 말씀드리겠습니다.
클라이언트 프로그램은 램에 상주하면서 특정 정보를 주기적으로 혹은 어떤 이벤트가 발생할 경우마다
정해진 정보를 서버로 보냅니다.
서버에서는 WSAOVERLAPPED 만큼의 메모리를 할당 한 후, 이 클라이언트에서
날아오는 패킷을 받아 역시 정해진 SQL 구조대로 쿼리를 만들어 Mysql로 쿼리를 날립니다.
문제가 더 복잡해지는 이유로는 아예 안받아지는게 아니라, 대략 몇십개중에 한두개정도는
제대로 받아들여지고, sql로 쿼리를 날려 DB에 저장시킨다는 점입니다.
어제는 수정한적이 없다고 했는데 지금 프로그래머께서 사실 그 이전 개발자가
12/30일날 퇴사하는거였는데 급하게 고칠게 있어서 수정을 했긴 했답니다.
수정내용은 기존 클라이언트에서 날려보내는 정보중에 몇가지 더 추가한 것이랍니다.
클라이언트에서도 문제가 있는게 사내서버에서 돌리는 경우(사설아이피) 패킷이
제대로 날라오질 않습니다.
이건 사설네트워크 구성의 문제인가요?
수정사항이 있었다는 얘기를 듣고 완전히 처리를 성공한 패킷과 무시되어진 패킷을
비교해봤지만 잘 모르겠습니다.
복잡합니다 ㅜ.,ㅜ
PS. 혹시 패킷의 포맷(길이, 종류등)의 문제라면 클라이언트의 send부분과
서버의 recv부분만 따로 때와서 새로운 테스트프로그램을 통해 테스트해봐도
효과가 있을까요?
단위테스트도 가능할까요? VC를 잘 다뤄보지 못했고, VC로 네트웤프로그래밍을 해본적이 없어서 ㅜ.,ㅜ
--------------------------------------------------------------------------------------
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
저같은 경우에는
저같은 경우에는 하드웨어에 문제가 있었습니다. 모델명은 Marvell Yukon 88E8001/8003/8010 PCI Gigabit Ethernet Controller 입니다. 제작사의 드라이버를 이용하면 (XP 상에서) 체크섬 계산을 하드웨어에서 하도록 기본 설정이 되는데, 이렇게 하면 2번에 1번꼴로 패킷 에러를 냅니다. 그래서 드라이버 속성 탭에서 그 기능을 끄니까, 에러가 완전히 사라졌습니다. 이런 경우가 종종 리포트 되나 봅니다. 검색해보면 하드웨어 체크섬을 끄라는 글이 몇개 보이더군요. 혹시나 해서 글을 남겨봅니다.
그건 하드웨어 문제라기 보다는...
giga bit ethernet card가 제공하는 기능이라고 보시는 것이 맞습니다.
giga bit ethernet의 경우 traffic이 많을 수 있기 때문에 프로토콜 스택에서 checksum을 계산하게 되면 os에 많은 부하를 줄 수 있기 때문에 그런 기능을 제공하는 것입니다.
물론 패킷을 전송하는데에는 아무런 문제가 없으며 단지 pcap과 같은 device driver단계에서 패킷을 미러링하는 library는 하드웨어에서 checksum을 계산하기 전에 패킷을 잡기 때문에 ethereal과 같은 프로그램에서는 이런 패킷들이 모두 checksum error로 표시될 뿐입니다.
^^
어떻게든 해결해 내서 이제 클라이언트가 보내어지는 정보량이 늘었습니다.
하지만 이상하게 아직 윈도우 XP 서비스팩2의 자료들이 매우 적군요..
사내에서 실험을 해보는데 아예 패킷 자체가 날라오질 않습니다.
혹시 윈도우 서비스팩2의 자체방화벽의 문제가 있을까 해서 살펴봤지만
별로 특별한 사항을 찾아낼 수 없습니다.
사내에서 실험한 경우인지라 사내 방화벽(NAT)때문인가 생각도 해보는 중인데,
이부분은 어디를 어떻게 살펴봐야 하는지 모르겠습니다..
--------------------------------------------------------------------------------------
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
네... gimmesilver 님
네... gimmesilver 님 말씀이 맞는듯합니다.
제대로 수행되는 패킷들도 체크섬에러를 내뱉고 있습니다.
사실 프로그램을 손보니 처리가 됩니다.
윈도우 XP SP2에서 뭔가 클라이언트가 보내는 코드중 일부를 악성코드로 생각하고 있었든가,
악성코드류로 인식했던것 같습니다. 그래서 SP2에서의 패킷이 막혀졌던것 같습니다.
서버쪽 프로그램은 설정을 바꾸고 여기저기 손봤더니 문제없이 됍니다.
관심가져주셔서 감사합니다.^^
---------------------------------------------------------------------------------------
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
내 마음속의 악마가 자꾸만 나를 부추겨.
늘 해왔던 것에 만족하지 말고 뭔가 불가능해 보이는 것을 하라고 말야.
비록 기바비트 지원
비록 기바비트 지원 네트웍 카드이지만, 100M 물려있고, 사용량이 많지 않은 네트웍입니다. 저는 드라이버나 쳅셋의 문제라고 판단했습니다. 드라이버 설치시 디폴트 값으로는 제속도의 절반도 나오지 않습니다. 언젠가 KT에서 무료 서비스라면서 네트워 체크를 하는 장비를 물려서 봤더니, 에러가 엄청나더군요. 그래서 알았습니다. 하드웨어 체크섬을 처리한 결과를 봐도 분명히 잘못된 값이라는 것을 볼 수 있었습니다. 2번에 1번꼴이라는 것이 왜 그런 것인지 모르지만, 소프트웨어로 처리하면 아무런 문제가 없는 걸로 봐서는 영 미덥지 못한 칩셋 같습니다.
댓글 달기