Может ты имел stealt-сканирование или маскировку от ids ?
Есть такая фишка, которая заключается в том, что при коннекте с машиной не происходит полноценного соединения и в логах сканируемой машины нифига не остается. К тому же такой способ меньше нагружает хост (чем при использовании фун. connect() )
Ну, например:
Хосту А нужно соединиться с хостом В .
1) A --syn-->B/*А спрашивает В о соединени*/
2) B --syn/ack -->A/*В отвечает о возможности коннекта (syn и ack флаги)*/
3)A --ack-->B/*A посылает В пакет с ack флагом*/

Если порт закрыт:
1)A --syn-->B/*A посылает В пакет с  syn флагом*/
2)В--rst-->А/*В отвечает А(глухие телефончики, млин=)), что порт закрыт (rst флаг)*/

Как видишь, програмная реализация connect() довольно проста...
А вот при полуоткрытом соединении (half-open) syn-скан выглядит примерно так:
1)A --syn-->B/*а посылает б запрос на коннект*/
2) B --syn/ack -->A/*б отвечает а, что порт открыт*/
3)-/*а ничего не отвечает*/
Тут тоже все просто: на 3 этапе хост А не посылает Б пакета с аск флагом - отсюда и возникает непонятный коннект ...
вот этот самый реальный сегодня способ скана. По скорости ничем не отличается от обычного connect()-скана.  Единственный его минус - обязательное наличие рут-прав в системе =(
Конечно, мона юзать и FIN-SCAN. Его маза в том, что не нужно делать вообще никакого соединения, а просто отослать пакет с флагом fin, если порт закрыт, то ОС должна ответить пакетом с rst флагом ( в противном случае, она просто промолчит):
1)A --FIN--> B /*Отсылаем fin*/
2)B --RST--> A/*Порт закрыт*/
Ну вот послал ты fin-флаг и если в течении некоторого времени в ответ ничего не приходит, значит, порт открыт...
А вот скорость будет несколько ниже чем у syn, т.к. приходится ожидать таймаут для каждого порта ... Правда, можно создать несколько отдельных потоков для каждого сканируемого порта, но это нам не надо =)
З.Ы. Этим способом нельзя сканировать win-тачки, т.к. у них свой, мне не известный, способ реализации tcp/ip стека