网络端口及其详解 - 文学城

网络端口及其详解

按端口号可分为3大类：

（1）公认端口（Well Known Ports）：从0到1023，它们紧密绑定（binding）于一些服务。通常

这些端口的通讯明确表明了某种服务的协议。例如：80端口实际上总是HTTP通讯。


（2）注册端口（Registered Ports）：从1024到49151。它们松散地绑定于一些服务。也就是说

有许多服务绑定于这些端口，这些端口同样用于许多其它目的。例如：许多系统处理动态端口从1024

左右开始。


（3）动态和/或私有端口（Dynamic and/or Private Ports）：从49152到65535。理论上，不应

为服务分配这些端口。实际上，机器通常从1024起分配动态端口。但也有例外：SUN的RPC端口从

32768开始。

网络端口及其详解(一)


0 通常用于分析操作系统。这一方法能够工作是因为在一些系统中“0”是无效端口，当你试图使

用一种通常的闭合端口连接它时将产生不同的结果。一种典型的扫描：使用IP地址为0.0.0.0，设置

ACK位并在以太网层广播。


1 tcpmux TCP Port Service Multiplexer 传输控制协议端口服务多路开关选择器


2 compressnet Management Utility compressnet 管理实用程序


3 compressnet Compression Process 压缩进程


5 rje Remote Job Entry 远程作业登录


7 echo Echo 回显


9 discard Discard 丢弃


11 systat Active Users 在线用户


13 daytime Daytime 时间


17 qotd Quote of the Day 每日引用


18 msp Message Send Protocol 消息发送协议


19 chargen Character Generator 字符发生器


20 ftp-data File Transfer[Default Data] 文件传输协议(默认数据口)


21 ftp File Transfer[Control] 文件传输协议(控制)


22 ssh SSH Remote Login Protocol SSH远程登录协议

23 telnet Telnet 终端仿真协议


24 any private mail system 预留给个人用邮件系统


25 smtp Simple Mail Transfer 简单邮件发送协议


27 nsw-fe NSW User System FE NSW 用户系统现场工程师


29 msg-icp MSG ICP MSG ICP


31 msg-auth MSG Authentication MSG验证


33 dsp Display Support Protocol 显示支持协议


35 any private printer server 预留给个人打印机服务


37 time Time 时间


38 rap Route Access Protocol 路由访问协议


39 rlp Resource Location Protocol 资源定位协议


41 graphics Graphics 图形


42 nameserver WINS Host Name Server WINS 主机名服务


43 nicname Who Is "绰号" who is服务


44 mpm-flags MPM FLAGS Protocol MPM(消息处理模块)标志协议


45 mpm Message Processing Module [recv] 消息处理模块


46 mpm-snd MPM [default send] 消息处理模块(默认发送口)


47 ni-ftp NI FTP NI FTP

48 auditd Digital Audit Daemon 数码音频后台服务

49 tacacs Login Host

Protocol (TACACS) TACACS登录主机协议

50 re-mail-ck Remote Mail Checking


Protocol 远程邮件检查协议[未结束]


51 la-maint IMP Logical Address Maintenance IMP(接口信息处理机)逻辑地址维护


52 xns-time XNS Time Protocol 施乐网络服务系统时间协议


53 domain Domain Name Server 域名服务器


54 xns-ch XNS Clearinghouse 施乐网络服务系统票据交换


55 isi-gl ISI Graphics Language ISI图形语言


56 xns-auth XNS Authentication 施乐网络服务系统验证


57 ? any private terminal access 预留个人用终端访问


58 xns-mail XNS Mail 施乐网络服务系统邮件


59 any private file service 预留个人文件服务


60 Unassigned 未定义


61 ni-mail NI MAIL NI邮件?


62 acas ACA Services 异步通讯适配器服务


63 whois+ whois+ WHOIS+


64 covia Communications Integrator (CI) 通讯接口

65 tacacs-ds TACACS-Database Service TACACS数据库服务


66 sql*net Oracle SQL*NET Oracle SQL*NET


67 bootps Bootstrap Protocol Server 引导程序协议服务端


68 bootpc Bootstrap Protocol Client 引导程序协议客户端


69 tftp Trivial File Transfer 小型文件传输协议


70 gopher Gopher 信息检索协议


71 netrjs-1 Remote Job Service 远程作业服务


72 netrjs-2 Remote Job Service 远程作业服务


73 netrjs-3 Remote Job Service 远程作业服务


74 netrjs-4 Remote Job Service 远程作业服务


75 any private dial out service 预留给个人拨出服务


76 deos Distributed External Object Store 分布式外部对象存储


77 any private RJE service 预留给个人远程作业输入服务


78 vettcp vettcp 修正TCP?


79 finger Finger 查询远程主机在线用户等信息


80 http World Wide Web HTTP 全球信息网超文本传输协议


81 hosts2-ns HOSTS2 Name Server HOST2名称服务


82 xfer XFER Utility 传输实用程序


83 mit-ml-dev MIT ML Device 模块化智能终端ML设备


84 ctf Common Trace Facility 公用追踪设备


85 mit-ml-dev MIT ML Device 模块化智能终端ML设备


86 mfcobol Micro Focus Cobol Micro Focus Cobol编程语言


87 any private terminal link 预留给个人终端连接


88 kerberos Kerberos Kerberros安全认证系统


89 su-mit-tg SU/MIT Telnet Gateway SU/MIT终端仿真网关


90 dnsix DNSIX Securit Attribute Token Map DNSIX 安全属性标记图


91 mit-dov MIT Dover Spooler MIT Dover假脱机


92 npp Network Printing Protocol 网络打印协议


93 dcp Device Control Protocol 设备控制协议


94 objcall Tivoli Object Dispatcher Tivoli对象调度


95 supdup SUPDUP


96 dixie DIXIE Protocol Specification DIXIE协议规范


97 swift-rvf（Swift Remote Virtural File Protocol）快速远程虚拟文件协议


98 tacnews TAC News TAC新闻协议


99 metagram Metagram Relay


100 newacct [unauthorized use]


101=NIC Host Name Server


102=ISO-TSAP


103=Genesis Point-to-Point Trans Net


104=ACR-NEMA Digital Imag. & Comm. 300


105=Mailbox Name Nameserver


106=3COM-TSMUX3com-tsmux


107=Remote Telnet Service


108=SNA Gateway Access Server


109=Post Office Protocol - Version 2


110=Post Office Protocol - Version 3


111=SUN RPC


112=McIDAS Data Transmission Protocol

113=Authentication Service


114=Audio News Multicast


115=Simple File Transfer Protocol


116=ANSA REX Notify


117=UUCP Path Service


118=SQL Servicessqlserv


119=Network News Transfer Protocol


120=CFDPTKTcfdptkt


121=Encore Expedited Remote Pro.Call


122=SMAKYNETsmakynet


123=Network Time Protocol


124=ANSA REX Trader


125=Locus PC-Interface Net Map Ser


126=Unisys Unitary Login


127=Locus PC-Interface Conn Server


128=GSS X License Verification

129=Password Generator Protocol


130=cisco FNATIVE


131=cisco TNATIVE


132=cisco SYSMAINT


133=Statistics Service


134=INGRES-NET Service


135=Location Service


136=PROFILE Naming System


137=NETBIOS Name Service


138=NETBIOS Datagram Service


139=NETBIOS Session Service


140=EMFIS Data Service


141=EMFIS Control Service


142=Britton-Lee IDM


143=Interim Mail Access Protocol v2


144=NewSnews

145=UAAC Protocoluaac


146=ISO-IP0iso-tp0


147=ISO-IPiso-ip


148=CRONUS-SUPPORT


149=AED 512 Emulation Service


150=SQL-NETsql-net


151=HEMShems


152=Background File Transfer Program


153=SGMPsgmp


154=NETSCnetsc-prod


155=NETSCnetsc-dev


156=SQL Service


157=KNET/VM Command/Message Protocol

158=PCMail Serverpcmail-srv


159=NSS-Routingnss-routing


160=SGMP-TRAPSsgmp-traps


161=SNMP


162=SNMP TRAP


163=CMIP/TCP Manager


164=CMIP/TCP Agent


165=Xeroxxns-courier


166=Sirius Systems


167=NAMPnamp


168=RSVDrsvd


169=Send


170=Network Post


170=Network Post


171=Network Innovations Multiplex


172=Network Innovations CL/1

173=Xyplexxyplex-mux


174=MAILQ


175=VMNET


176=GENRAD-MUXgenrad-mux


177=X Display Manager Control Protocol


178=NextStep Window Server


179=Border Gateway Protocol


180=Intergraphris


181=Unifyunify


182=Unisys Audit SITP


183=OCBinderocbinder


184=OCServerocserver


185=Remote-KIS


186=KIS Protocolkis


187=Application Communication Interface


188=Plus Five


网络端口及其详解(二)




401=Uninterruptible Power Supply


402=Genie Protocol


403=decapdecap


404=ncednced


405=ncldncld


406=Interactive Mail Support Protocol


407=Timbuktutimbuktu


408=Prospero Resource Manager Sys. Man.


409=Prospero Resource Manager Node Man.


410=DECLadebug Remote Debug Protocol


411=Remote MT Protocol


412=Trap Convention Port


413=SMSPsmsp


414=InfoSeekinfoseek


415=BNetbnet


416=Silverplattersilverplatter


417=Onmuxonmux


418=Hyper-Ghyper-g


419=Arielariel1


420=SMPTEsmpte


421=Arielariel2


422=Arielariel3


423=IBM Operations Planning and Control Start


424=IBM Operations Planning and Control Track


425=ICADicad-el


426=smartsdpsmartsdp


427=Server Location


429=OCS_AMU


430=UTMPSDutmpsd


431=UTMPCDutmpcd

432=IASDiasd


433=NNSPnnsp


434=MobileIP-Agent


435=MobilIP-MN


436=DNA-CMLdna-cml


437=comscmcomscm


439=dasp, Thomas Obermair


440=sgcpsgcp


441=decvms-sysmgtdecvms-sysmgt


442=cvc_hostdcvc_hostd


443=https


444=Simple Network Paging Protocol


445=Microsoft-DS


446=DDM-RDBddm-rdb


447=DDM-RFMddm-dfm


448=DDM-BYTEddm-byte

449=AS Server Mapper


450=TServertserver


512=exec, Remote process execution


513=login, remote login


514=cmd, exec with auto auth.


514=syslog


515=Printer spooler


516=Unassigned


517=talk


519=unixtime


520=extended file name server


521=Unassigned


522=Unassigned


523=Unassigned


524=Unassigned


526=newdate

530=rpc courier


531=chatconference


532=readnewsnetnews


533=for emergency broadcasts


539=Apertus Technologies Load Determination


540=uucp


541=uucp-rlogin


542=Unassigned


543=klogin


544=kshell


545=Unassigned


546=Unassigned


547=Unassigned


548=Unassigned


549=Unassigned


550=new-who

551=Unassigned


552=Unassigned


553=Unassigned


554=Unassigned


555=dsf


556=remotefs


557-559=rmonitor


560=rmonitord


561=dmonitor


562=chcmd


563=Unassigned


564=plan 9 file service


565=whoami


566-569 Unassigned


570=demonmeter


571=udemonmeter

572-599 Unassigned ipc server


600=Sun IPC server


607=nqs


606=Cray Unified Resource Manager


608=Sender-Initiated/Unsolicited File Transfer


609=npmp-trapnpmp-trap


610=npmp-localnpmp-local


611=npmp-guinpmp-gui


634=ginadginad


666=Doom Id Software


704=errlog copy/server daemon


709=EntrustManager


729=IBM NetView DM/6000 Server/Client


730=IBM NetView DM/6000 send/tcp


731=IBM NetView DM/6000 receive/tcp


741=netGWnetgw

742=Network based Rev. Cont. Sys.


744=Flexible License Manager


747=Fujitsu Device Control


748=Russell Info Sci Calendar Manager


749=kerberos administration


751=pump


752=qrh


754=send


758=nlogin


759=con


760=ns


762=quotad


763=cycleserv


765=webster


767=phonephonebook


769=vid

771=rtip


772=cycleserv2


774=acmaint_dbd


775=acmaint_transd


780=wpgs


786=Concertconcert


800=mdbs_daemon


996=Central Point Software


997=maitrd


999=puprouter


1023=Reserved


1024=Reserved


1025=network blackjack

1030=BBN IAD


1031=BBN IAD


1032=BBN IAD


1067=Installation Bootstrap Proto. Serv.


1068=Installation Bootstrap Proto. Cli.


1080=SOCKS


1083=Anasoft License Manager


1084=Anasoft License Manager


1155=Network File Access


1222=SNI R&D network


1248=hermes


1346=Alta Analytics License Manager


1347=multi media conferencing


1347=multi media conferencing


1348=multi media conferencing


1349=Registration Network Protocol

1350=Registration Network Protocol


1351=Digital Tool Works (MIT)


1352=/Lotus Notelotusnote


1353=Relief Consulting


1354=RightBrain Software


1355=Intuitive Edge


1356=CuillaMartin Company


1357=Electronic PegBoard


1358=CONNLCLIconnlcli


1359=FTSRVftsrv


1360=MIMERmimer


1361=LinX


1362=TimeFliestimeflies


1363=Network DataMover Requester


1364=Network DataMover Server


1365=Network Software Associates

1366=Novell NetWare Comm Service Platform


1367=DCSdcs


1368=ScreenCastscreencast


1369=GlobalView to Unix Shell


1370=Unix Shell to GlobalView


1371=Fujitsu Config Protocol


1372=Fujitsu Config Protocol


1373=Chromagrafxchromagrafx


1374=EPI Software Systems


1375=Bytexbytex


1376=IBM Person to Person Software


1377=Cichlid License Manager


1378=Elan License Manager


1379=Integrity Solutions


1380=Telesis Network License Manager


1381=Apple Network License Manager

1382=udt_os


1383=GW Hannaway Network License Manager


1384=Objective Solutions License Manager


1385=Atex Publishing License Manager


1386=CheckSum License Manager


1387=Computer Aided Design Software Inc LM


1388=Objective Solutions DataBase Cache


1389=Document Manager


1390=Storage Controller


1391=Storage Access Server


1392=Print Managericlpv-pm


1393=Network Log Server


1394=Network Log Client


1395=PC Workstation Manager software


1396=DVL Active Mail


1397=Audio Active Mail

1398=Video Active Mail


1399=Cadkey License Manager


1400=Cadkey Tablet Daemon


网络端口及其详解(三)




1401=Goldleaf License Manager


1402=Prospero Resource Manager


1403=Prospero Resource Manager


1404=Infinite Graphics License Manager


1405=IBM Remote Execution Starter


1406=NetLabs License Manager


1407=DBSA License Manager


1408=Sophia License Manager


1409=Here License Manager


1410=HiQ License Manager


1411=AudioFileaf


1412=InnoSysinnosys


1413=Innosys-ACLinnosys-acl


1414=IBM MQSeriesibm-mqseries


1415=DBStardbstar

1416=Novell LU6.2novell-lu6.2


1417=Timbuktu Service 1 Port


1417=Timbuktu Service 1 Port


1418=Timbuktu Service 2 Port


1419=Timbuktu Service 3 Port


1420=Timbuktu Service 4 Port


1421=Gandalf License Manager


1422=Autodesk License Manager


1423=Essbase Arbor Software


1424=Hybrid Encryption Protocol


1425=Zion Software License Manager


1426=Satellite-data Acquisition System 1


1427=mloadd monitoring tool


1428=Informatik License Manager


1429=Hypercom NMSnms

1430=Hypercom TPDUtpdu


1431=Reverse Gosip Transport


1432=Blueberry Software License Manager


1433=Microsoft-SQL-Server


1434=Microsoft-SQL-Monitor


1435=IBM CISCibm-cics


1436=Satellite-data Acquisition System 2


1437=Tabulatabula


1438=Eicon Security Agent/Server


1439=Eicon X25/SNA Gateway


1440=Eicon Service Location Protocol


1441=Cadis License Management


1442=Cadis License Management


1443=Integrated Engineering Software


1444=Marcam License Management


1445=Proxima License Manager

1446=Optical Research Associates License Manager


1447=Applied Parallel Research LM


1448=OpenConnect License Manager


1449=PEportpeport


1450=Tandem Distributed Workbench Facility


1451=IBM Information Management


1452=GTE Government Systems License Man


1453=Genie License Manager


1454=interHDL License Manager


1454=interHDL License Manager


1455=ESL License Manager


1456=DCAdca


1457=Valisys License Manager


1458=Nichols Research Corp.

1459=Proshare Notebook Application


1460=Proshare Notebook Application


1461=IBM Wireless LAN


1462=World License Manager


1463=Nucleusnucleus


1464=MSL License Manager


1465=Pipes Platform


1466=Ocean Software License Manager


1467=CSDMBASEcsdmbase


1468=CSDMcsdm


1469=Active Analysis Limited License Manager


1470=Universal Analytics


1471=csdmbasecsdmbase


1472=csdmcsdm


1473=OpenMathopenmath


1474=Telefindertelefinder

1475=Taligent License Manager


1476=clvm-cfgclvm-cfg


1477=ms-sna-server


1478=ms-sna-base


1479=dberegisterdberegister


1480=PacerForumpacerforum


1481=AIRSairs


1482=Miteksys License Manager


1483=AFS License Manager


1484=Confluent License Manager


1485=LANSourcelansource


1486=nms_topo_serv


1487=LocalInfoSrvr


1488=DocStordocstor


1489=dmdocbrokerdmdocbroker

1490=insitu-confinsitu-conf


1491=anynetgateway


1492=stone-design-1


1493=netmap_lmnetmap_lm


1494=icaica


1495=cvccvc


1496=liberty-lmliberty-lm


1497=rfx-lmrfx-lm


1498=Watcom-SQLwatcom-sql


1499=Federico Heinz Consultora


1500=VLSI License Manager


1501=Satellite-data Acquisition System 3


1502=Shivashivadiscovery


1503=Databeamimtc-mcs


1504=EVB Software Engineering License Manager


1505=Funk Software, Inc.

1524=ingres


1525=oracle


1525=Prospero Directory Service non-priv


1526=Prospero Data Access Prot non-priv


1527=oracletlisrv


1529=oraclecoauthor


1600=issd


1651=proshare conf audio


1652=proshare conf video


1653=proshare conf data


1654=proshare conf request


1655=proshare conf notify


1661=netview-aix-1netview-aix-1


1662=netview-aix-2netview-aix-2


1663=netview-aix-3netview-aix-3


1664=netview-aix-4netview-aix-4

1665=netview-aix-5netview-aix-5


1666=netview-aix-6netview-aix-6


1986=cisco license management


1987=cisco RSRB Priority 1 port


1988=cisco RSRB Priority 2 port


1989=cisco RSRB Priority 3 port


1989=MHSnet systemmshnet


1990=cisco STUN Priority 1 port


1991=cisco STUN Priority 2 port


1992=cisco STUN Priority 3 port


1992=IPsendmsgipsendmsg


1993=cisco SNMP TCP port


1994=cisco serial tunnel port


1995=cisco perf port


1996=cisco Remote SRB port


1997=cisco Gateway Discovery Protocol

1998=cisco X.25 service (XOT)


1999=cisco identification port


2009=whosockami


2010=pipe_server


2011=raid


2012=raid-ac


2013=rad-am


2015=raid-cs


2016=bootserver


2017=terminaldb


2018=rellpack


2019=about


2019=xinupageserver


2020=xinupageserver


2021=xinuexpansion1


2021=down

2022=xinuexpansion2


2023=xinuexpansion3


2023=xinuexpansion4


2024=xinuexpansion4


2025=xribs


2026=scrabble


2027=shadowserver


2028=submitserver


2039=device2


2032=blackboard


2033=glogger


2034=scoremgr


2035=imsldoc


2038=objectmanager


2040=lam


2041=interbase

2042=isis


2043=isis-bcast


2044=primsl


2045=cdfunc


2047=dls


2048=dls-monitor


2065=Data Link Switch Read Port Number


2067=Data Link Switch Write Port Number


2201=Advanced Training System Program


2500=Resource Tracking system server


2501=Resource Tracking system client


2564=HP 3000 NS/VT block mode telnet


2784=world wide web - development


3049=ccmail


3264=ccmail, cc:mail/lotus


3333=dec-notes

3984=MAPPER network node manager


3985=MAPPER TCP/IP server


3986=MAPPER workstation server


3421=Bull Apprise portmapper


3900=Unidata UDT OS


4132=NUTS Daemonnuts_dem


4133=NUTS Bootp Server


4343=UNICALL


4444=KRB524


4672=remote file access server


5002=radio free ethernet


5010=TelepathStarttelelpathstart


5011=TelepathAttack


5050=multimedia conference control tool


5145=rmonitor_secure


5190=aol, America-Online

5300=HA cluster heartbeat


5301=hacl-gs # HA cluster general services


5302=HA cluster configuration


5303=hacl-probe HA cluster probing


5305=hacl-test


6000-6063=x11 X Window System


6111=sub-process HP SoftBench Sub-Process Control


6141/=meta-corp Meta Corporation License Manager


6142=aspentec-lm Aspen Technology License Manager


6143=watershed-lm Watershed License Manager


6144=statsci1-lm StatSci License Manager - 1


6145=statsci2-lm StatSci License Manager - 2


6146=lonewolf-lm Lone Wolf Systems License Manager


6147=montage-lm Montage License Manager


7000=afs3-fileserver file server itself


7001=afs3-callback callbacks to cache managers

7002=afs3-prserver users & groups database


7003=afs3-vlserver volume location database


7004=afs3-kaserver AFS/Kerberos authentication service


7005=afs3-volser volume managment server


7006=afs3-errors error interpretation service


7007=afs3-bos basic overseer process


7008=afs3-update server-to-server updater


7009=afs3-rmtsys remote cache manager service


7010=ups-online onlinet uninterruptable power supplies


7100=X Font Service


7200=FODMS FLIP


7626=冰河


8010=Wingate


8181=IMail


9535=man


45576=E代时光专业代理端口


网络端口及其详解(四)


下面解释的更具体，也算是补充。


0 通常用于分析操作系统。这一方法能够工作是因为在一些系统中“0”是无效端口，当你试图使

用一种通常的闭合端口连接它时将产生不同的结果。一种典型的扫描：使用IP地址为0.0.0.0，设置

ACK位并在以太网层广播。


1 tcpmux 这显示有人在寻找SGI Irix机器。Irix是实现tcpmux的主要提供者，缺省情况下tcpmux

在这种系统中被打开。Iris机器在发布时含有几个缺省的无密码的帐户，如lp, guest, uucp,

nuucp, demos, tutor, diag, EZsetup, OutOfBox, 和4Dgifts。许多管理员安装后忘记删除这些帐

户。因此Hacker们在Internet上搜索tcpmux并利用这些帐户。


7 Echo 你能看到许多人们搜索Fraggle放大器时，发送到x.x.x.0和x.x.x.255的信息。常见的一

种DoS攻击是echo循环（echo-loop），攻击者伪造从一个机器发送到另一个机器的UDP数据包，而两

个机器分别以它们最快的方式回应这些数据包。另一种东西是由DoubleClick在词端口建立的TCP连

接。有一种产品叫做“Resonate Global Dispatch”，它与DNS的这一端口连接以确定最近的路由。

Harvest/squid cache将从3130端口发送UDP echo：“如果将cache的source_ping on选项打开，它将

对原始主机的UDP echo端口回应一个HIT reply。”这将会产生许多这类数据包。


11 sysstat 这是一种UNIX服务，它会列出机器上所有正在运行的进程以及是什么启动了这些进

程。这为入侵者提供了许多信息而威胁机器的安全，如暴露已知某些弱点或帐户的程序。这与UNIX系

统中“ps”命令的结果相似。再说一遍：ICMP没有端口，ICMP port 11通常是ICMP type=11。


19 chargen 这是一种仅仅发送字符的服务。UDP版本将会在收到UDP包后回应含有垃圾字符的包。

TCP连接时，会发送含有垃圾字符的数据流知道连接关闭。Hacker利用IP欺骗可以发动DoS攻击。伪造

两个chargen服务器之间的UDP包。由于服务器企图回应两个服务器之间的无限的往返数据通讯一个

chargen和echo将导致服务器过载。同样fraggle DoS攻击向目标地址的这个端口广播一个带有伪造受

害者IP的数据包，受害者为了回应这些数据而过载。


21 ftp 最常见的攻击者用于寻找打开“anonymous”的ftp服务器的方法。这些服务器带有可读写

的目录。Hackers或Crackers 利用这些服务器作为传送warez (私有程序) 和pr0n(故意拼错词而避免

被搜索引擎分类)的节点。


22 ssh PcAnywhere 建立TCP和这一端口的连接可能是为了寻找ssh。这一服务有许多弱点。如果

配置成特定的模式，许多使用RSAREF库的版本有不少漏洞。（建议在其它端口运行ssh）。还应该注

意的是ssh工具包带有一个称为make-ssh-known-hosts的程序。它会扫描整个域的ssh主机。你有时会

被使用这一程序的人无意中扫描到。UDP（而不是TCP）与另一端的5632端口相连意味着存在搜索

pcAnywhere的扫描。5632（十六进制的0x1600）位交换后是0x0016（使进制的22）。


23 Telnet 入侵者在搜索远程登陆UNIX的服务。大多数情况下入侵者扫描这一端口是为了找到机

器运行的操作系统。此外使用其它技术，入侵者会找到密码。


25 smtp 攻击者（spammer）寻找SMTP服务器是为了传递他们的spam。入侵者的帐户总被关闭，他

们需要拨号连接到高带宽的e-mail服务器上，将简单的信息传递到不同的地址。SMTP服务器（尤其是

sendmail）是进入系统的最常用方法之一，因为它们必须完整的暴露于Internet且邮件的路由是复杂

的（暴露+复杂=弱点）。


53 DNS Hacker或crackers可能是试图进行区域传递（TCP），欺骗DNS（UDP）或隐藏其它通讯。

因此防火墙常常过滤或记录53端口。需要注意的是你常会看到53端口做为UDP源端口。不稳定的防火

墙通常允许这种通讯并假设这是对DNS查询的回复。Hacker常使用这种方法穿透防火墙。


67&68 Bootp和DHCP UDP上的Bootp/DHCP：通过DSL和cable-modem的防火墙常会看见大量发送到广

播地址255.255.255.255的数据。这些机器在向DHCP服务器请求一个地址分配。Hacker常进入它们分

配一个地址把自己作为局部路由器而发起大量的“中间人”（man-in-middle）攻击。客户端向68端

口（bootps）广播请求配置，服务器向67端口（bootpc）广播回应请求。这种回应使用广播是因为客

户端还不知道可以发送的IP地址。

79 finger Hacker用于获得用户信息，查询操作系统，探测已知的缓冲区溢出错误，回应从自己

机器到其它机器finger扫描。


80 web站点默认80为服务端口，采用tcp或udp协议。


98 linuxconf 这个程序提供linux boxen的简单管理。通过整合的HTTP服务器在98端口提供基于

Web界面的服务。它已发现有许多安全问题。一些版本setuid root，信任局域网，在/tmp下建立

Internet可访问的文件，LANG环境变量有缓冲区溢出。此外因为它包含整合的服务器，许多典型的

HTTP漏洞可能存在（缓冲区溢出，历遍目录等）


109 POP2 并不象POP3那样有名，但许多服务器同时提供两种服务（向后兼容）。在同一个服务器

上POP3的漏洞在POP2中同样存在。


110 POP3 用于客户端访问服务器端的邮件服务。POP3服务有许多公认的弱点。关于用户名和密码

交换缓冲区溢出的弱点至少有20个（这意味着Hacker可以在真正登陆前进入系统）。成功登陆后还有

其它缓冲区溢出错误。


111 sunrpc portmap rpcbind Sun RPC PortMapper/RPCBIND。访问portmapper是扫描系统查看允

许哪些RPC服务的最早的一步。常见RPC服务有：rpc.mountd, NFS, rpc.statd, rpc.csmd,

rpc.ttybd, amd等。入侵者发现了允许的RPC服务将转向提供服务的特定端口测试漏洞。记住一定要

记录线路中的daemon, IDS, 或sniffer，你可以发现入侵者正使用什么程序访问以便发现到底发生了

什么。


113 Ident auth 这是一个许多机器上运行的协议，用于鉴别TCP连接的用户。使用标准的这种服

务可以获得许多机器的信息（会被Hacker利用）。但是它可作为许多服务的记录器，尤其是FTP,

POP, IMAP, SMTP和IRC等服务。通常如果有许多客户通过防火墙访问这些服务，你将会看到许多这个

端口的连接请求。记住，如果你阻断这个端口客户端会感觉到在防火墙另一边与e-mail服务器的缓慢

连接。许多防火墙支持在TCP连接的阻断过程中发回RST，着将回停止这一缓慢的连接。


119 NNTP news 新闻组传输协议，承载USENET通讯。当你链接到诸如：

news://comp.security.firewalls/. 的地址时通常使用这个端口。这个端口的连接企图通常是人们

在寻找USENET服务器。多数ISP限制只有他们的客户才能访问他们的新闻组服务器。打开新闻组服务

器将允许发/读任何人的帖子，访问被限制的新闻组服务器，匿名发帖或发送spam。


135 oc-serv MS RPC end-point mapper Microsoft在这个端口运行DCE RPC end-point mapper为

它的DCOM服务。这与UNIX 111端口的功能很相似。使用DCOM和/或RPC的服务利用机器上的end-point

mapper注册它们的位置。远端客户连接到机器时，它们查询end-point mapper找到服务的位置。同样

Hacker扫描机器的这个端口是为了找到诸如：这个机器上运行Exchange Server吗？是什么版本？这

个端口除了被用来查询服务（如使用epdump）还可以被用于直接攻击。有一些DoS攻击直接针对这个

端口。


137 NetBIOS name service nbtstat (UDP) 这是防火墙管理员最常见的信息。


139 NetBIOS File and Print Sharing 通过这个端口进入的连接试图获得NetBIOS/SMB服务。这

个协议被用于Windows“文件和打印机共享”和SAMBA。在Internet上共享自己的硬盘是可能是最常见

的问题。大量针对这一端口始于1999，后来逐渐变少。2000年又有回升。一些VBS（IE5 VisualBasic

ing）开始将它们自己拷贝到这个端口，试图在这个端口繁殖。


143 IMAP 和上面POP3的安全问题一样，许多IMAP服务器有缓冲区溢出漏洞运行登陆过程中进入。
记住：一种Linux蠕虫（admw0rm）会通过这个端口繁殖，因此许多这个端口的扫描来自不知情的已被

感染的用户。当RadHat在他们的Linux发布版本中默认允许IMAP后，这些漏洞变得流行起来。Morris

蠕虫以后这还是第一次广泛传播的蠕虫。这一端口还被用于IMAP2，但并不流行。已有一些报道发现

有些0到143端口的攻击源于脚本。


161 SNMP(UDP) 入侵者常探测的端口。SNMP允许远程管理设备。所有配置和运行信息都储存在数

据库中，通过SNMP客获得这些信息。许多管理员错误配置将它们暴露于Internet。Crackers将试图使

用缺省的密码“public”“private”访问系统。他们可能会试验所有可能的组合。SNMP包可能会被

错误的指向你的网络。Windows机器常会因为错误配置将HP JetDirect remote management软件使用

SNMP。HP OBJECT IDENTIFIER将收到SNMP包。新版的Win98使用SNMP解析域名，你会看见这种包在子

网内广播（cable modem, DSL）查询sysName和其它信息。

162 SNMP trap 可能是由于错误配置


177 xdmcp 许多Hacker通过它访问X-Windows控制台， 它同时需要打开6000端口。


513 rwho 可能是从使用cable modem或DSL登陆到的子网中的UNIX机器发出的广播。这些人为

Hacker进入他们的系统提供了很有趣的信息。


553 CORBA IIOP (UDP) 如果你使用cable modem或DSL VLAN，你将会看到这个端口的广播。CORBA

是一种面向对象的RPC（remote procedure call）系统。Hacker会利用这些信息进入系统。


600 Pcserver backdoor 请查看1524端口。 一些玩的孩子认为他们通过修改ingreslock和

pcserver文件已经完全攻破了系统-- Alan J. Rosenthal.


635 mountd Linux的mountd Bug。这是人们扫描的一个流行的Bug。大多数对这个端口的扫描是基

于UDP的，但基于TCP的mountd有所增加（mountd同时运行于两个端口）。记住，mountd可运行于任何

端口（到底在哪个端口，需要在端口111做portmap查询），只是Linux默认为635端口，就象NFS通常

运行于2049端口。


1024 许多人问这个端口是干什么的。它是动态端口的开始。许多程序并不在乎用哪个端口连接网

络，它们请求操作系统为它们分配“下一个闲置端口”。基于这一点分配从端口1024开始。这意味着

第一个向系统请求分配动态端口的程序将被分配端口1024。为了验证这一点，你可以重启机器，打开

Telnet，再打开一个窗口运行“natstat -a”，你将会看到Telnet被分配1024端口。请求的程序越

多，动态端口也越多。操作系统分配的端口将逐渐变大。再来一遍，当你浏览Web页时用“netstat”

查看，每个Web页需要一个新端口。


1025，1026 参见1024


1080 SOCKS 这一协议以管道方式穿过防火墙，允许防火墙后面的许多人通过一个IP地址访问

Internet。理论上它应该只允许内部的通信向外达到Internet。但是由于错误的配置，它会允许

Hacker/Cracker的位于防火墙外部的攻击穿过防火墙。或者简单地回应位于Internet上的计算机，从

而掩饰他们对你的直接攻击。WinGate是一种常见的Windows个人防火墙，常会发生上述的错误配置。

在加入IRC聊天室时常会看到这种情况。


1114 SQL 系统本身很少扫描这个端口，但常常是sscan脚本的一部分。


1243 Sub-7木马（TCP）


1524 ingreslock 后门许多攻击脚本将安装一个后门Shell于这个端口（尤其是那些针对Sun系统

中sendmail和RPC服务漏洞的脚本，如statd, ttdbserver和cmsd）。如果你刚刚安装了你的防火墙就

看到在这个端口上的连接企图，很可能是上述原因。你可以试试Telnet到你的机器上的这个端口，看

看它是否会给你一个Shell。连接到600/pcserver也存在这个问题。


2049 NFS NFS程序常运行于这个端口。通常需要访问portmapper查询这个服务运行于哪个端口，

但是大部分情况是安装后NFS运行于这个端口，Hacker/Cracker因而可以闭开portmapper直接测试这

个端口。


3128 squid 这是Squid HTTP代理服务器的默认端口。攻击者扫描这个端口是为了搜寻一个代理服

务器而匿名访问Internet。你也会看到搜索其它代理服务器的端口：8000/8001/8080/8888。扫描这

一端口的另一原因是：用户正在进入聊天室。其它用户（或服务器本身）也会检验这个端口以确定用

户的机器是否支持代理。


5632 pcAnywere 你会看到很多这个端口的扫描，这依赖于你所在的位置。当用户打开pcAnywere

时，它会自动扫描局域网C类网以寻找可能得代理（译者：指agent而不是proxy）。Hacker/cracker

也会寻找开放这种服务的机器，所以应该查看这种扫描的源地址。一些搜寻pcAnywere的扫描常包含

端口22的UDP数据包。


6776 Sub-7 artifact 这个端口是从Sub-7主端口分离出来的用于传送数据的端口。例如当控制者

通过电话线控制另一台机器，而被控机器挂断时你将会看到这种情况。因此当另一人以此IP拨入时，

他们将会看到持续的，在这个端口的连接企图。（译者：即看到防火墙报告这一端口的连接企图时，

并不表示你已被Sub-7控制。）

6970 RealAudio RealAudio客户将从服务器的6970-7170的UDP端口接收音频数据流。这是由

TCP7070端口外向控制连接设置的。


13223 PowWow PowWow 是Tribal Voice的聊天程序。它允许用户在此端口打开私人聊天的连接。

这一程序对于建立连接非常具有“进攻性”。它会“驻扎”在这一TCP端口等待回应。这造成类似心

跳间隔的连接企图。如果你是一个拨号用户，从另一个聊天者手中“继承”了IP地址这种情况就会发

生：好象很多不同的人在测试这一端口。这一协议使用“OPNG”作为其连接企图的前四个字节。


17027 Conducent 这是一个外向连接。这是由于公司内部有人安装了带有Conducent "adbot" 的

共享软件。Conducent "adbot"是为共享软件显示广告服务的。使用这种服务的一种流行的软件是

Pkware。有人试验：阻断这一外向连接不会有任何问题，但是封掉IP地址本身将会导致adbots持续在

每秒内试图连接多次而导致连接过载： 机器会不断试图解析DNS名—ads.conducent.com，即IP地址

216.33.210.40 ；216.33.199.77 ；216.33.199.80 ；216.33.199.81；216.33.210.41。（译者：不

知NetAnts使用的Radiate是否也有这种现象）


27374 Sub-7木马(TCP)


30100 NetSphere木马(TCP) 通常这一端口的扫描是为了寻找中了NetSphere木马。


31337 Back Orifice “elite” Hacker中31337读做“elite”/ei’li:t/（译者：法语，译为中

坚力量，精华。即3=E, 1=L, 7=T）。因此许多后门程序运行于这一端口。其中最有名的是Back

Orifice。曾经一段时间内这是Internet上最常见的扫描。现在它的流行越来越少，其它的木马程序

越来越流行。


31789 Hack-a-tack 这一端口的UDP通讯通常是由于"Hack-a-tack"远程访问木马（RAT, Remote

Access Trojan）。这种木马包含内置的31790端口扫描器，因此任何31789端口到317890端口的连接

意味着已经有这种入侵。（31789端口是控制连接，317890端口是文件传输连接）


32770~32900 RPC服务 Sun Solaris的RPC服务在这一范围内。详细的说：早期版本的Solaris

（2.5.1之前）将portmapper置于这一范围内，即使低端口被防火墙封闭仍然允许Hacker/cracker访

问这一端口。扫描这一范围内的端口不是为了寻找portmapper，就是为了寻找可被攻击的已知的RPC

服务。


33434~33600 traceroute 如果你看到这一端口范围内的UDP数据包（且只在此范围之内）则可能

是由于traceroute。


安全事件日志事件编号与描述


●帐号登录事件(事件编号与描述)


672 身份验证服务（AS）票证得到成功发行与验证。


673 票证授权服务（TGS）票证得到授权。TGS是一份由Kerberos 5.0版票证授权服务（TGS）发

行、且允许用户针对域中特定服务进行身份验证的票证。


674 安全主体重建AS票证或TGS票证。


675 预身份验证失败。这种事件将在用户输入错误密码时由密钥分发中心（KDC）生成。


676 身份验证票证请求失败。这种事件在Windows XP Professional操作系统或Windows Server产

品家族成员中将不会产生。


677 TGS票证无法得到授权。这种事件在Windows XP Professional操作系统或Windows Server产

品家族成员中将不会产生。


678 指定帐号成功映射到一个域帐号。


681 登录失败。域帐号尝试进行登录。这种事件在Windows XP Professional操作系统或Windows

Server产品家族成员中将不会产生。


682 用户重新连接到一个已经断开连接的终端服务器会话上。


683 用户在没有注销的情况下与终端服务器会话断开连接。


●帐号管理事件


624 一个用户帐号被创建。


627 一个用户密码被修改。


628 一个用户密码被设置。


630 一个用户密码被删除。


631 一个全局组被创建。


632 一个成员被添加到特定全局组中。


633 一个成员从特定全局组中被删除。


634 一个全局组被删除。


635 一个新的本地组被创建。


636 一个成员被添加到本地组中。


637 一个成员从本地组中被删除。


638 一个本地组被删除。


639 一个本地组帐号被修改。


641 一个全局组帐号被修改。


642 一个用户帐号被修改。

643 一个域策略被修改。


644 一个用户帐号被自动锁定。


645 一个计算机帐号被创建。


646 一个计算机帐号被修改。


647 一个计算机帐号被删除。


648 一个禁用安全特性的本地安全组被创建。说明：正式名称中的SECURITY_DISABLED意味着这个

组无法用于在访问检查中授予权限。


649 一个禁用安全特性的本地安全组被修改。


650 一个成员被添加到一个禁用安全特性的本地安全组中。


651 一个成员从一个禁用安全特性的本地安全组中被删除。


652 一个禁用安全特性的本地组被删除。


653 一个禁用安全特性的全局组被创建。


654 一个禁用安全特性的全局组被修改。


655 一个成员被添加到一个禁用安全特性的全局组中。


656 一个成员从一个禁用安全特性的全局组中被删除。


657 一个禁用安全特性的全局组被删除。


658 一个启用安全特性的通用组被创建。


659 一个启用安全特性的通用组被修改。


660 一个成员被添加到一个启用安全特性的通用组中。


661 一个成员从一个启用安全特性的通用组中被删除。


662 一个启用安全特性的通用组被删除。


663 一个禁用安全特性的通用组被创建。


664 一个禁用安全特性的通用组被修改。


665 一个成员被添加到一个禁用安全特性的通用组中。


666 一个成员从一个禁用安全特性的通用组中被删除。


667 一个禁用安全特性的通用组被删除。


668 一个组类型被修改。


684 管理组成员的安全描述符被设置。说明：在域控制器上，一个后台线程每60秒将对管理组中

的所有成员（如域管理员、企业管理员和架构管理员）进行一次搜索并对其应用一个经过修复的安全

描述符。这种事件将被记录下来。


685 一个帐号名称被修改。

●审核登录事件


528 用户成功登录到计算机上。


529 登录失败：试图使用未知用户名或带有错误密码的已知用户名进行登录。

530 登录失败：试图在允许时间范围以外进行登录。


531 登录失败：试图通过禁用帐号进行登录。


532 登录失败：试图通过过期帐号进行登录。


533 登录失败：试图通过不允许在特定计算机上进行登录的用户帐号进行登录。


534 登录失败：用户试图通过不允许使用的密码类型进行登录。


535 登录失败：针对指定帐号的密码已经过期。


536 登录失败：网络登录服务未被激活。


537 登录失败：由于其它原因导致登录失败。说明：在某些情况下，登录失败原因可能无法确

定。


538 针对某一用户的注销操作完成。


539 登录失败：登录帐号在登录时刻已被锁定。


540 用户成功登录到网络。


541 本地计算机与所列对等客户身份标识之间的主模式Internet密钥交换（IKE）身份验证操作已

经完成（建立一条安全关联），或者快速模式已经建立一条数据通道。


542 数据通道被中断。


543 主模式被中断。说明：这种事件可能在安全关联时间限制到期（缺省值为8小时）、策略修改

或对等客户中断时发生。

544 由于对等客户未能提供合法证书或签署未通过验证导致主模式身份验证失败。


545 由于Kerberos失败或密码不合法导致主模式身份验证失败。


546 由于对等客户发送非法了非法提议，IKE 安全关联建立没有成功。收到一个包含非法数据的

数据包。


547 IKE握手过程中发生错误。


548 登录失败：来自信任域的安全标识符（SID）与客户端的帐号域SID不匹配。


549 登录失败：在跨域身份验证过程中，所有同非信任名称空间相对应的SID均已被过滤掉。


550 能够指示可能发生拒绝服务（DoS）攻击的通知消息。


551 用户发起注销操作。


552 用户在已经通过其他身份登录的情况下使用明确凭据成功登录到计算机上。


682 用户重新连接到一个已经断开连接的终端服务器会话上。


683 用户在没有注销的情况下与终端服务器会话断开连接。说明：这种事件将在用户通过网络与

终端服务器会话建立连接时产生。它将出现在终端服务器上。

●对象访问事件


560 访问由一个已经存在的对象提供授权。


562 一个对象访问句柄被关闭。


563 试图打开并删除一个对象。说明：当您在Createfile()函数中指定FILE_DELETE_ON_CLOSE标


志时，这种事件将被文件系统所使用。


564 一个保护对象被删除。


565 访问由一种已经存在的对象类型提供授权。


567 一种与句柄相关联的权限被使用。说明：一个授予特定权限（读取、写入等）的句柄被创

建。当使用这个句柄时，至多针对所用到的每种权限产生一次审核。


568 试图针对正在进行审核的文件创建硬连接。


569 身份验证管理器中的资源管理器试图创建客户端上下文。


570 客户端试图访问一个对象。说明：针对对象的每次操作尝试都将产生一个事件。


571 客户端上下文被身份验证管理器应用程序删除。


572 管理员管理器初始化应用程序。


772 证书管理器拒绝了挂起的证书申请。


773 证书服务收到重新提交的证书申请。


774 证书服务吊销了证书。


775 证书服务收到发行证书吊销列表(CRL) 的请求。


776 证书服务发行了证书吊销列表(CRL)。


777 更改了证书申请扩展。


778 更改了多个证书申请属性。


779 证书服务收到关机请求。


780 已开始证书服务备份。


781 已完成证书服务备份。


782 已开始证书服务还原。


783 已完成证书服务还原。


784 证书服务已经开始。


785 证书服务已经停止。


786 证书服务更改的安全权限。


787 证书服务检索了存档密钥。


788 证书服务将证书导入数据库中。


789 证书服务更改的审核筛选。


790 证书服务收到证书申请。


791 证书服务批准了证书申请并颁发了证书。


792 证书服务拒绝证书申请。


793 证书服务将证书申请状态设为挂起。

794 证书服务更改的证书管理器设置


795 证书服务更改的配置项。


796 证书服务更改属性。


797 证书服务存档了密钥。


798 证书服务导入和存档了密钥。


799 证书服务将证书发行机构（CA）证书发行到Active Directory。


800 从证书数据库删除一行或多行。


801 角色分隔被启用。

●审核策略更改事件


608 用户权限已被分配。


609 用户权限已被删除。


610 与另一个域的信任关系已被创建。


611 与另一个域的信任关系已被删除。


612 审核策略已被更改。


613 Internet协议安全性（IPSec）策略代理已经启动。


614 IPSec策略代理已被禁用。

615 IPSec策略代理已被更改。


616 IPSec策略代理遇到一个潜在的严重问题。


617 Kerberos 5.0版策略已被更改。


618 经过加密的数据恢复策略已更改。


620 与另一个域的信任关系已被修改。


621 系统访问权限已被授予帐号。


622 系统访问权限已从帐号中删除。


623 审核策略以对等用户为单位进行设置。


625 审核策略以对等用户为单位进行刷新。


768 检测到一个森林中的名称空间元素与另一个森林中的名称空间元素发生冲突。说明：当一个

森林中的名称空间元素与另一个森林中的名称空间元素发生重叠时，它将无法明确解析属于这两个名

称空间元素的名称。这种重叠现象也称作冲突。并非针对每种记录类型的参数均合法。举例来说，诸

如DNS名称、NetBIOS名称和SID之类的字段对于“TopLevelName”类型的记录便是非法的。


769 添加了受信任的森林信息。说明：这种事件消息将在更新受信任的森林信息以及添加一条或

多条记录时生成。针对每条添加、删除或修改的记录都将生成一条事件消息。如果在针对森林信任信

息的单一更新操作中添加、删除或修改多条记录，生成的所有事件消息都将被分配一个相同且唯一标

识符（称作操作编号）。这种方式使您能够判断出多条事件消息是由一次操作生成的。并非针对每种

记录类型的参数均合法。举例来说，诸如DNS名称、NetBIOS名称和SID之类的字段对于

“TopLevelName”类型的记录便是非法的。


770 删除了受信任的森林信息。说明：查看编号为769的事件描述。


771 修改了受信任的森林信息。说明：查看编号为769的事件描述。


805 事件日志服务读取针对会话的安权限使用事件

●权限使用事件


576 特定权限已被添加到用户访问令牌中。说明：这种事件将在用户登录时产生。


577 用户试图执行受到权限保护的系统服务操作。


578 在已经处于打开状态的受保护对象句柄上使用权限。


●详细跟踪事件


592 已经创建新的过程。


593 已经退出某过程。


594 对象的句柄被重复


595 已经取得对象的间接访问权。


596 数据保护主密钥备份。说明：主密钥将供CryptProtectData和CryptUnprotectData例程以及

加密文件系统（EFS）所使用。这种主密钥将在每次创建新增主密钥时予以备份。（缺省设置为90

天。）密钥备份操作通常由域控制器执行。


597 数据保护主密钥已由恢复服务器恢复完毕。


598 审核数据已得到保护。


599 审核数据保护已取消。


600 分派给进程一个主令牌。


601 用户尝试安装服务。


602 一个计划作业已被创建。

●面向审核系统事件的系统事件消息


512 正在启动 Windows。


513 Windows 正在关机。


514 本地安全机制机构已加载身份验证数据包。


515 受信任的登录过程已经在本地安全机制机构注册。


516 用来列队审核消息的内部资源已经用完，从而导致部分审核数据丢失。


517 审核日志已经清除。


518 安全帐户管理器已经加载通知数据包。


519 一个过程正在试图通过无效本地过程调用（LPC）端口来模拟客户端并针对客户端地址空间执

行回复、读取或写入操作。


520 系统时间已更改。说明：这种审核操作通常成对出现。

Kernel hacking made easy

http://www.w00w00.org/files/articles/lkmhack.txt

w00w00!

lkm: Kernel hacking made easy
By: w00w00 Security Development article by Nicolas Dubee

The following applies to the Linux i86 2.0.x kernel series.
It may also be accurate for previous releases, but has not been
tested. 2.1.x kernels introduced a bunch of changes, notably in
the memory managment routines, and are not discussed here.

Thanks to Halflife who first got the idea to use lkm for malicious
purposes, and tiepilot, my living hero.



User space vs. Kernel space
---------------------------

Linux is a protected operating system. It is implemented over the
protected mode of the i386 series of CPUs.

Memory is divided into roughly two parts: kernel space and user space.
Kernel space is where the kernel code lives, and user space is where
the user programs live. Of course, a given user program can't write to
kernel memory or to another program's memory area.

Unfortunately, this is also the case for kernel code. Kernel code
can't write to user space either. What does this mean? Well, when a given
hardware driver wants to write data bytes to a program in user memory, it
can't do it directly, but rather it must use specific kernel functions
instead. Also, when paramaters are passed by address to a kernel function,
the kernel function can not read the parameters directly. It must use
other kernel functions to read each byte of the parameters.

Here are a few useful functions to use in kernel mode for transferring
data bytes to or from user memory.

#include 

get_user(ptr)
Gets the given byte, word, or long from user memory. This is a macro,
and it relies on the type of the argument to determine the number of bytes
to transfer. You then have to use typecasts wisely.

put_user(ptr)
This is the same as get_user(), but instead of reading, it writes data
bytes to user memory.

memcpy_fromfs(void *to, const void *from,unsigned long n)
Copies n bytes from *from in user memory to *to in kernel memory.

memcpy_tofs(void *to,const *from,unsigned long n)
Copies n bytes from *from in kernel memory to *to in user memory.



System calls
------------

Most libc calls rely on system calls, which are the simplest kernel
functions a user program can call. These system calls are implemented
in the kernel itself or in loadable kernel modules, which are little
chunks of dynamically linkable kernel code.

Like MS-DOS and many others, Linux system calls are implemented through
a multiplexor called with a given maskable interrupt. In Linux,
this interrupt is int 0x80. When the 'int 0x80' instruction is executed,
control is given to the kernel (or, more accurately, to the function
_system_call()), and the actual demultiplexing process occurs.

* How does _system_call() work ?

First, all registers are saved and the content of the %eax register
is checked against the global system calls table, which enumerates
all system calls and their addresses.
This table can be accessed with the extern void *sys_call_table[] variable.
A given number and memory address in this table corresponds to each system
call. System call numbers can be found in /usr/include/sys/syscall.h.
They are of the form SYS_systemcallname. If the system call is not
implemented, the corresponding cell in the sys_call_table is 0, and an
error is returned. Otherwise, the system call exists and the corresponding
entry in the table is the memory address of the system call code.

Here is an example of an invalid system call:

[root@plaguez kernel]# cat no1.c
#include 
#include 
#include 

extern void *sys_call_table[];

sc()
{ // system call number 165 doesn't exist at this time.
   __asm__(
     "movl $165,%eax
            int $0x80");
}

main()
{
   errno = -sc();
   perror("test of invalid syscall");
}
[root@plaguez kernel]# gcc no1.c
[root@plaguez kernel]# ./a.out
test of invalid syscall: Function not implemented
[root@plaguez kernel]# exit


The control is then transferred to the actual system call, which performs
whatever you requested and returns. _system_call() then calls
_ret_from_sys_call() to check various stuff, and ultimately returns to user
memory.


* libc

The int $0x80 isn't used directly for system calls; rather, libc
functions, which are often wrappers to interrupt 0x80, are used.

libc generally features the system calls using the _syscallX() macros, where
X is the number of parameters for the system call.

For example, the libc entry for write(2) would be implemented with a _syscall3
macro, since the actual write(2) prototype requires 3 parameters.
Before calling interrupt 0x80, the _syscallX macros are supposed to
set up the stack frame and the argument list required for the system call.
Finally, when the _system_call() (which is triggered with int $0x80) returns,
the _syscallX() macro will check for a negative return value (in %eax)
and will set errno accordingly.

Let's check another example with write(2) and see how it gets preprocessed.

[root@plaguez kernel]# cat no2.c
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

_syscall3(ssize_t,write,int,fd,const void *,buf,size_t,count);

main()
{
   char *t = "this is a test.\n";
   write(0, t, strlen(t));
}
[root@plaguez kernel]# gcc -E no2.c > no2.C
[root@plaguez kernel]# indent no2.C -kr
indent:no2.C:3304: Warning: old style assignment ambiguity in "=-".  Assuming "= -"

[root@plaguez kernel]# tail -n 50 no2.C


#9 "no2.c" 2




ssize_t write(int fd, const void *buf, size_t count)
{
   long __res;
   __asm__ __volatile("int $0x80":"=a"(__res):"0"(4), "b"((long) (fd)), "c"((long) (buf)), "d"((long) (count)));
   if (__res >= 0)
 return (ssize_t) __res;
   errno = -__res;
   return -1;
};

main()
{
   char *t = "this is a test.\n";
   write(0, t, strlen(t));
}
[root@plaguez kernel]# exit


Note that the "0"(4) in the write() function above matches the SYS_write
definition in /usr/include/sys/syscall.h.




* Making your own system calls.

There are a few ways to make your own system calls.
For example, you could modify the kernel sources and append your own code.
A far easier way, however, would be to write a loadable kernel module.

A loadable kernel module is nothing more than an object file containing
code that will be dynamically linked into the kernel when it is needed.

The main purposes of this feature are to have a small kernel, and to load
a given driver when it is needed with the insmod(1) command.
It's also easier to write a lkm than to write code in the kernel source tree.

* Writing a lkm

A lkm is easily made in C.
It contains a chunk of #defines, some functions, an initialization function
called init_module(), and an unload function called cleanup_module().

Here is a typical lkm source structure:


#define MODULE
#define __KERNEL__
#define __KERNE_SYSCALLS__

#include 
#ifdef MODULE
#include 
#include 
#else
#define MOD_INC_USE_COUNT
#define MOD_DEC_USE_COUNT
#endif

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int errno;

char tmp[64];

/* for example, we may need to use ioctl */
_syscall3(int, ioctl, int, d, int, request, unsigned long, arg);

int myfunction(int parm1,char *parm2)
{
  int i,j,k;
  /* ... */
}

int init_module(void)
{
  /* ... */
  printk("\nModule loaded.\n");
  return 0;
}

void cleanup_module(void)
{
  /* ... */
}

Check the mandatory #defines (#define MODULE, #define __KERNEL__) and
#includes (#include  ...)

Also note that as our lkm will be running in kernel mode, we can't use
libc functions, but we can use system calls with the previously
discussed _syscallX() macros.

You would compile this module with 'gcc -c -O3 module.c' and insert it
into the kernel with 'insmod module.o' (optimization must be turned
on).

As the title suggests, lkm can also be used to modify kernel code without
having to rebuild it entirely. For example, you could patch the write(2)
system call to hide portions of a given file.
Seems like a good place for backdoors, too: what would you do if you
couldn't trust your own kernel?



* Kernel and system calls backdoors

The main idea behind this is pretty simple. We'll redirect those damn
system calls to our own ones in a lkm, which will enable us to force the
kernel to react as we want it to.
For example, we could hide a sniffer by
patching the IOCTL system call and masking the PROMISC bit. Lame but
efficient.

To modify a given system call, just add the definition of the
extern void *sys_call_table[] in your lkm, and have the init_module()
function modify the corresponding entry in the sys_call_table to point to
your own code. The modified call can then do whatever you wish it to, call
the original system call by modifying sys_call_table once more, and ...

Kernel System Calls

Kernel System Calls

by Alessandro Rubini

This article is the first step towards an understanding of how kHTTPd can take the role of a web server while never leaving kernel space.

System Calls: the Facts

One of the most renown features of Unix is the clear distinction between ``kernel space'' and ``user space''. System calls have always been the means through which user space programs can access kernel services. The Linux kernel implementation allows to break this clean distinction by allowing kernel code to invoke some of the system calls. This leverages the kernel's capabilities to include some of the tasks that have traditionally been reserved to user space.

To keep the discussion simple, throughout the article I'll refer to the PC platform and to x86 processor features, disregarding for a while any cross-platform issues. While I write this article, the official kernel is version 2.4.0-test8 and that is what I refer to in both the discussion and the code. Sample code is available as ksyscall.tar.gz from here.

Please note that invoking system calls from kernel space is not in general a good thing. To the sake of maintaining, debugging and porting the code, what has always been performed in user space should not be converted to run in kernel space, unless that is absolutely necessary to meet performance or size requirements.

The gain in performance comes for avoidance of costly user-space/kernel-space transitions and associated data passing; the gain in size comes from avoidance of a separate executable with its libc and associated material.

System Calls: the Mechanisms

In order to understand the speed benefits achieved by invoking system calls from kernel space, we should first analyze the exact steps performed by a normal system call, like read. The function's role is copying data from a source, (usually a device, either a mass-storage or a communication medium) to buffers held in the application.

Figure 1 shows the steps involved in performing a call to read from a user space function, like the main procedure of a C program. You can verify the exact steps by running objdump on compiled code for the user-space part and browsing kernel source files for the kernel-space part.

---

Figure 1: Steps involved in performing a call to read

The image is available as PostScript ksys-figure1.ps here

---

A system call is implemented by a ``software interrupt'' that transfers control to kernel code; in Linux/i386 this is ``interrupt 0x80''. The specific system call being invoked is stored in the EAX register, abd its arguments are held in the other processor registers. In our example, the number associated to read is __NR_read, defined in .

After the switch to kernel mode, the processor must save all of its registers and dispatch execution to the proper kernel function, after checking whether EAX is out of range. The system call we are looking at is implemented in the sys_read function, and it must (like several other system call) dispatch execution to a file object. The file object itself must first be looked up based on the file descriptor that the user application passed to the system call. The read method for the file object finally performs the data transfer and all the previous steps are unwound up to the calling user function.

Each arrow in the figure represents a jump in CPU instruction flow, and each jump may require flushing the prefetch queue and possibly a ``cache miss'' event. Transitions between user and kernel space are especially important, as they are the most expensive in processing time and prefetch behavior.

Timing Execution

To add real-world figures to the theoretical discussion, let's look at the exact time lapse needed by an empty read system call to execute. An empty call is one that transfers no data at all. We'll invoke it on the stdin file descriptor, 0, because stdin is always opened for reading. Moreover, it can be easily redirected to check for differences according to what file is being read.

In order to measure time lapses we can use the ``timestamp counter'' processor register. The counter, available on all kinds of Pentium processors is a 64 bit register that gets incremented at each clock tick.

To read the counter a program can invoke the rdtsc assembly instruction. After including , (named after "machine specific registers"), C code can call readtsc(low,high) to retrieve the 64 bit counter into two 32 bit variables, orreadtscl(low) to retrieve only the lower half of the counter. We'll use the latter form, as we'll just need subtract two values, an operation immune to 32-bit overflow if the measured difference is less than 32 bits in size.

Listing 1, part of the usystime.c sample file, can be used to measure the number of clock ticks the processor takes to execute a read call. The code tries several times and only the best figure is considered because process execution can be interrupted or delayed because of processor scheduling, extra cache misses or other unexpected events.

int main()
{
   unsigned long ini, end, now, best, tsc;
   int i;
   char buffer[4];

#define measure_time(code) \
   for (i = 0; i < NTRIALS; i++) { \
 rdtscl(ini); \
       code; \
 rdtscl(end); \
 now = end - ini; \
 if (now < best) best = now; \
   }

   /* time rdtsc (i.e. no code) */
   best = ~0;
   measure_time( 0 );
   tsc = best;

   /* time an empty read() */
   best = ~0;
   measure_time( read(STDIN_FILENO, buffer, 0) );

   /* report data */
   printf("rdtsc: %li ticks\nread(): %li ticks\n",
    tsc, best-tsc);
   return 0;
}

Running the code on my 500MHz box reports a count of 11 ticks for the rdtsc instruction, and 474 ticks for the empty system call. It corresponds to aboout 0.95 microseconds. The same code executed on a different processor takes 578 ticks (and 32 for reading the timestamp).

 ; This is the pair of consecutive rdtsc after compilation
8048150:       0f 31           rdtsc 
8048152:       89 c3           movl   %eax,%ebx   ; ini
8048154:       0f 31           rdtsc 
8048156:       89 c1           movl   %eax,%ecx   ; end

; And this is the system call wrapped by two rdtsc
804817c:       0f 31           rdtsc 
804817e:       89 c3           movl   %eax,%ebx   ; ini
8048180:       6a 00           pushl  $0x0        ; arg 3 = 0
8048182:       8b 45 f4        movl   0xfffffff4(%ebp),%eax
8048185:       50              pushl  %eax        ; arg 2 = buffer
8048186:       6a 00           pushl  $0x0        ; arg 1 = 0
8048188:       e8 23 49 00 00  call   804cab0 <__libc_read>
804818d:       0f 31           rdtsc 
804818f:       89 c1           movl   %eax,%ecx   ; end

Doing it in kernel space

Let's now consider issuing the same read system call from kernel space. The easiest way to accomplish the task is exploiting the definition of read and several other system calls that exports if [cw]KERNEL_SYSCALLS[/] is defined. Therefore, sample code declares the macro before including any header.

Before calling the function, however, a preparing step must be performed. Like any other function that transfers data to/from user space using a user-provided pointer, the system call checks whether the provided buffer is a valid address or not. During normal operation, an address that lies in the user address range (0-3GB for standard kernel configuration) is considered valid, and an address that lies in kernel address space (3GB-4GB) is not.

If the system call is invoked from kernel space, though, we must prevent the usual check to fail, because the virtual address of our destination buffer will be in kernel space, above the 3GB mark.

The field addr_limit in the task_struct structure is used to define the highest virtual address that is to be considered valid; the macros get_fs and set_fs can be used to read and write the value. The limit that must be used when invoking system calls from kernel space (in practice, the "no limit" case) is returned by the get_ds macro. See the box in this page for an explanation of the names and meanings of the macro calls.

For this reasong, kernel system calls, must be wrapped by the following code:

      mm_segment_t fs;

     fs = get_fs();     /* save previous value */
     set_fs (get_ds()); /* use kernel limit */

     /* system calls can be invoked */

     set_fs(fs); /* restore before returning to user space */

There's no need to wrap each individual system call, and group of them can occur in a row. It's important, however, that the original ``fs'' is restored before returning to user space. Otherwise, the user program that executed this code will retain permission to overwrite kernel memory by passing bogus pointers to further read (or ioctl) system calls.

Once equipped with these ``grossly misnamed'' tools, we can measure the performance of a system call invoked from kernel space. The code shown in listing 3 is part of the ksystime.c source; it can be compiled into a module that executes the code in kernel space (in init_module) and then exits. Since the initialization of the module returns a failure indication, you can re-load the module to run the measure once again without the need to unload it in advance.

    /* time rdtsc (i.e. no code) */
   best = ~0;
   measure_time( 0 );
   tsc = best;
   ksys_print("tsc", tsc);

   /* prepare to invoke a system call */
   fs = get_fs();
   set_fs (get_ds());

   /* time an empty read() */
   best = ~0;
   measure_time( read(0 /* stdin */, buffer, 0) );
   ksys_print("read()", best - tsc);

   /* restore fs and make insmod fail */
   set_fs (fs);
   return -EINVAL;

The code executed in kernel space reports 11 ticks for rdtsc (the same reported in user space, as expected) and 424 ticks for the empty system call. The savings is 50 ticks.

Why get_fs() is called get_fs()

Once upon a time, when Linus was playing with his new 386 PC and Linux wasn't even there, Linus said "Intel gave us the segments, let's use the segments". And he used the segments.

A ``segment register'', in i386 protected mode, acts mainly as an index into a table of ``virtual-address descriptors'', the ``descriptor table''. And each memory access uses one of CS (code segment, default for code fetch), DS (data segment, default for data access), ES, FS (extra segments, useable for data access) as its virtual-address space descriptor.

The first implementation of the kernel-space memory map used virtual addresses that mapped one-to-one to physical addresses. The user-space memory map on the other hand was dictated by the binary formats in use for executable files, and all of them use low virtual addresses for executable and data pages. Therefore, executing system calls required switching to a completely different memory map than the one of user space, and this was accomplished by using different descriptors for the memory map associated to the code and data segment in charge in user-space and kernel-space. Since several system calls need to access the user address space, the FS register was reserved to hold the user memory map while in kernel space.

This explains the name of the macros:

• get_fs returns the current segment descriptor stored in FS.
• get_ds returns the segment descriptor associated to kernel space, currently stored in DS.
• set_fs stores a descriptor into FS, so it will be used for data transfer instructions.

This layout of virtual memory and segment descriptors remained in use up to version 2.0 of the kernel, included. The first great innovation brought in by version 2.1 was the switch to a different approach, consistent to what other platforms were already doing. The user and the kernel descriptors now share the lower 3GB of the virtual address space, and life is both easier and more performant. The FS segment register has been put to rest and user memory is now accessed by the DS register, just like kernel memory. FS only survives in the names of a few preprocessor macros.

Going further

You may object that the savings measured, 10%, is not as large as one may expect.

Actually, a quick look at the definition of the macro (in the header) or at disassembled object code shows that the implementation of read as defined in still calls interrupt 0x80. The kernel implementation of the system call is not optimized for speed, and is only there for the convenience of a few kernel needs.

It's interesting to note how code for some Linux platforms invokes kernel system calls by directly jumping to the sys_read (or equivalent) function, thus skipping the workload associated to the third column of figure 1. This is not currently possible with the PC platform, unless you do nasty hacks; with those hacks in place (shown and explained in the code but not worth showing here) the call takes 216 ticks,, 54% less than the user-space case.

But if you are really interested to get the best performance out of your kernel system calls, the thing to do is directly invoke the read file method, after retrieving a pointer to the file structure represented by the file descriptor (0 for stdin). This approach to system calls invocation from kernel space is the one used the kHTTPd, as it is the fastest possible: the processor will only incur in the workload associated with the last column of figure 1, i.e. only the actual data transfer operation.

Listing 4 shows the code that implements this technique in the sample module ksystime.c. The set_fs and associated calls are not shown as they are the same as above).

    /* use the file operation directly */
   file = fget(0 /* fd */);
   if (file && file->f_op && file->f_op->read) {
 best = ~0;
 measure_time(
     file->f_op->read(file, buffer, 0, &file->f_pos)
 );
 ksys_print("f_op->read()", best - tsc);
   }
   if (file) fput(file);

The execution time of this code is reported as 175 clock ticks, 63% (or 0.6 microseconds) less than the user space case. You may even try to cache the two pointers being used in the call (f_op->read and &file->f_pos), this is reported in the sample code as well. Unfortunately it makes no real difference and in some cases it can even make execution slower because of the inappropriate small size of the PC register set.

This is how the output of themodule looks like on my system (the output is found in /var/log/kern.log or equivalent):

kernel: ksystime:  11 -- tsc
kernel: ksystime: 424 -- read()
kernel: ksystime: 216 -- sys_read()
kernel: ksystime: 175 -- f_op->read()
kernel: ksystime: 173 -- cached_f_op_read()

So what?

Up to now we have collected a few figures, and found that making system calls from kernel space can significantly reduce the overhead of the system call mechanism. It's high time, in my opinion, to step back for a while and ponder over the figures we collected.

How could we still incur in 175 clock ticks of overhead associated to the read system call?

The answer is in looking at the read file operation we are using: the insmod program, whose standard input is being used, is connected to a tty (specifically, a pseudo tty controlled by xterm in this case). If the standard input of the test program is connected to a different kind of file we get completely different figures. Reading a disk file for example is much faster (but it still depends on the underlying filesystem), and reading /dev/null has almost no overhead (7 clock ticks, but the read method of the file just return end-of-file). The numbers collected will also vary across processor vendor and stepping, thus making all benchmarks almost pointless. As usual.

Figure 2 shows the times I collected on my PC, to give an idea of the great difference in the various read file operations.

---

Figure 2: Times in the various read file operations on my PC

The image is available as PostScript ksys-figure2.ps here

---

It shows that my CPU has an overhead of 50 ticks (0.1usec) in crossing the user/kernel threshold twice, it also spends 210 ticks (0.4usec) in processing generic system call entry/exit and 40-75 ticks in sys_read. Since actual data transfer takes two or three clock ticks per byte (measured by copying a 64-byte buffer in the read calls), the overhead that can be avoided by using kernel system calls is worth a data transfer of 100-150 bytes. This is a non-trivial figure if performance is your main concern and you transfer small data packets. On the other hand, it may well not be worth the effort for most of the applications.

While kernel-space system calls are an interesting tool, and playing with them can teach a lot about kernel internals, I still think their use should be as limited as possible. For example, a device driver shouldn't read a configuration file using kernel-space system calls; reading a file involves error manamegent and parsing of file contents -- not something suited for kernel code. The best way to feed data to device drivers is through ioctl via a user-space application.

This column showed how kernel system calls work in order to lay the foundations for a discussion of the kHTTPd implementation, that will follow the next month.

Requirements - madwifi.org - Trac

Requirements - madwifi.org

Hardware

Wireless Card

• A PCI/miniPCI or Cardbus card with an Atheros chipset.
• Please refer to Compatibility on which wireless cards are supported by the MadWifi driver.

Architecture

• Please refer to Architecture for the list of supported systems for MadWifi.

Software

• root privileges for the machine on which you intend to install MadWifi.

Kernel

• Linux Kernel 2.4.23+ and 2.6.x series
  • Others may work, but are unsupported; also, beware if using the very latest release candidate (RC#) kernel as it may not yet be supported
• Kernel Source and Headers of running kernel
• No module versioning support
  • option CONFIG_MODVERSIONS
• Wireless Extensions support in kernel
  • v14+ required, v17+ recommended; option CONFIG_NET_RADIO (kernel 2.6.22 and later: CONFIG_WLAN_80211)
• Sysctl support in kernel
  • option CONFIG_SYSCTL
• Crypto API support in kernel
  • option CONFIG_CRYPTO
• HMAC support
  • option CONFIG_CRYPTO_HMAC
• AES support (for WPA networks)
  • option CONFIG_CRYPTO_AES

Use the kernel config guide to help set these kernel options.

Building the driver

• gcc -- The same GCC version used to compile the kernel
  • otherwise, "Invalid module format" errors may occur
• subversion -- If you choose to get the most recent MadWifi code, you'll need to check it out of our Subversion repository.
• make -- Used to automatically build programs.
• perl -- Used by Madwifi Makefile to generate code
• madwifi -- Download the latest MadWifi driver.

Configuring the wireless card

• iwconfig -- Used to connect to a wireless network; often called wireless-tools by distributions.
• wpa_supplicant -- Used to join a network with WPA encryption; often called wpasupplicant by distributions.

Please check your Linux distribution for more specific information.

UserDocs/KernelConfig - madwifi.org - Trac

UserDocs/KernelConfig - madwifi.org

Kernel Configuration ¶

The following options should be included in your kernel for the best MadWifi experience:

Kernel 2.4.x: ¶

• Loadable module support -> Set version information on all module symbols: disabled
• Networking device support -> Wireless LAN (non-hamradio) -> Wireless LAN (non-hamradio): enabled
• Cryptographic options -> Cryptographic API: enabled
• Cryptographic options -> Cryptographic API -> HMAC support: enabled
• Cryptographic options -> Cryptographic API -> AES cipher algorithm: enabled (optional, needed for WPA/WPA2 with CCMP)

Kernel 2.6.x: ¶

• Loadable module support -> Module versioning support: disabled
• Device Drivers -> Network device support -> Wireless LAN (non-hamradio) -> Wireless LAN drivers (non-hamradio) & Wireless Extensions: enabled (before 2.6.22)
• Networking -> Wireless -> Wireless extensions: enabled (2.6.22 and later)
• Cryptographic options -> Cryptographic API: enabled
• Cryptographic options -> Cryptographic API -> HMAC support: enabled
• Cryptographic options -> Cryptographic API -> AES cipher algorithm: enabled (optional, needed for WPA/WPA2 with CCMP)

Note: beginning with kernel 2.6.22 two "Generic IEEE 802.11 Networking Stack" options are available. Neither of them is needed for MadWifi.

ath_hal message for ixp425

# uname
-a                                                                   
Linux meshok-x 2.4.20_mvl31-ixdp4xx #334 Wed Sep 7 02:19:42 MSD 2005
armv5teb unknown

Before DHCP connection to Meshok AP:

# iwconfig
ath0                                                              
ath0      IEEE 802.11g  ESSID:"LocustWorld"
Nickname:"192.168.217.1"        
        Mode:Ad-Hoc  Frequency:2.437 GHz  Cell:
02:60:B3:C5:C4:79          
        Bit Rate:0 kb/s   Tx-Power:18 dBm 
Sensitivity=0/3                
        Retry:off   RTS thr:off   Fragment
thr:off                         
        Encryption
key:off                                                 
        Power
Management:off                                               
        Link Quality=38/94  Signal level=-57 dBm  Noise level=-95
dBm      
        Rx invalid nwid:73  Rx invalid crypt:0  Rx invalid
frag:0          
        Tx excessive retries:0  Invalid misc:0   Missed
beacon:0           

# ifconfig
ath0                                                              
ath0      Link encap:Ethernet  HWaddr
00:60:B3:C5:C4:79                      
        inet addr:10.2.29.217  Bcast:10.255.255.255
Mask:255.0.0.0        
        UP BROADCAST RUNNING MULTICAST  MTU:1500
Metric:1                 
        RX packets:0 errors:1 dropped:0 overruns:0
frame:1                 
        TX packets:386 errors:0 dropped:0 overruns:0
carrier:0             
        collisions:0
txqueuelen:200                                        
        RX bytes:0 (0.0 B)  TX bytes:23932 (23.3
KiB)                      
        Interrupt:27 Memory:4bff0000-4c000000

After DHCP is established:

# ifconfig
ath0                                                              
ath0      Link encap:Ethernet  HWaddr
00:60:B3:C5:C4:79                      
        inet addr:10.2.29.217  Bcast:10.255.255.255
Mask:255.0.0.0        
        UP BROADCAST RUNNING MULTICAST  MTU:1500
Metric:1                 
        RX packets:5 errors:3 dropped:0 overruns:0
frame:3                 
        TX packets:868 errors:1 dropped:0 overruns:0
carrier:0             
        collisions:0
txqueuelen:200                                        
        RX bytes:1326 (1.2 KiB)  TX bytes:54316 (53.0
KiB)                 
        Interrupt:27 Memory:4bff0000-4c000000

So, it seems Tx/Rx counters work properly.

---- dmesg print - madwifi version ----

ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413,
REGOPS_FUNC)
wlan: 0.8.6.0
(EXPERIMENTAL)                                                 
ath_rate_sample:
1.2                                                         
ath_pci: 0.9.6.0
(EXPERIMENTAL)                                              
divert: allocating divert_blk for
ath0                                       
Build date: Aug 26
2005                                                      
Debugging version
(IEEE80211)                                                
ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps
11Mbps                                  
ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps
24Mbps 36M
bps 48Mbps
54Mbps                                                            
ath0: turboG rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps
54Mbps    
ath0: H/W encryption support: WEP AES AES_CCM
TKIP                           
ath0: mac 5.6 phy 4.1 radio
4.6                                              
ath0: Use hw queue 1 for WME_AC_BE
traffic                                   
ath0: Use hw queue 0 for WME_AC_BK
traffic                                   
ath0: Use hw queue 2 for WME_AC_VI
traffic                                   
ath0: Use hw queue 3 for WME_AC_VO
traffic                                   
ath0: Use hw queue 8 for CAB
traffic                                         
ath0: Use hw queue 9 for
beacons                                             
Debugging version
(ATH)                                                      
ath0: Atheros 5212: mem=0x4bff0000, irq=28

--
http://forum.openwrt.org/viewtopic.php?id=11989
--

On this device 2 mini-pci a socket.
I have replaced wifi device in other socket - and it has completely worked!!!
At loading there are differences:
wlan: 0.8.4.2 (svn r2568)
ath_hal: module license 'Proprietary' taints kernel.
ath_hal: 0.9.30.13 (AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, REGOPS_FUNC)
ath_rate_sample: 1.2 (svn r2568)
ath_pci: 0.9.4.5 (svn r2568)
PCI: enabling device 0000:00:02.0 (0340 -> 0342)  <---- instead  0000:00:01.0
ath_pci: switching rfkill capability off
ath_pci: switching per-packet transmit power control off
wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: turboA rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: H/W encryption support: WEP AES AES_CCM TKIP
wifi0: mac 5.6 phy 4.1 radio 3.6
wifi0: Use hw queue 1 for WME_AC_BE traffic
wifi0: Use hw queue 0 for WME_AC_BK traffic
wifi0: Use hw queue 2 for WME_AC_VI traffic
wifi0: Use hw queue 3 for WME_AC_VO traffic
wifi0: Use hw queue 8 for CAB traffic
wifi0: Use hw queue 9 for beacons
wifi0: Atheros 5212: mem=0x48000000, irq=27  <--instead   irq=28



root@OpenWrt:/# iwlist ath0 scan
ath0      Scan completed :
          Cell 01 - Address: 00:60:B3:8E:40:94
                    ESSID:"LIFE"
                    Mode:Master
                    Frequency:2.412 GHz (Channel 1)
                    Quality=71/70  Signal level=-24 dBm  Noise level=-95 dBm
                    Encryption key:off
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
                              9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
                              48 Mb/s; 54 Mb/s
                    Extra:bcn_int=100
YEAP!!!

船长和大副(小笑话） - 文学城

船长和大副
每一条船上都有船长和大副的。
有一条船上的船长和大副的不和。
大副酗酒，船长劝说，大副不听。
一日大副又酗酒，船长在航海日志上记下：
大副今日酗酒。
第二天大副当班，看到昨天船长在航海日志上记下他酗酒。
心里当然不高校了，但是也没有什么好说的。
他一边当班，一边想，哎！
大副在航海日志上记下船长今天没有酗酒。
到了港口航海日志照例是要被查看的。

老鼠吹牛及其它

老鼠吹牛及其它

原文：万维论坛之惠风山庄


* 四只老鼠吹牛：
甲：我每天都拿鼠药当糖吃；
乙：我一天不踩老鼠夹脚发痒；
丙：我每天不过几次大街不踏实；
丁：时间不早了，回家抱猫去咯。


* 鸭子和螃蟹赛跑,一起达到终点,难分胜负,裁判说:你们来个剪刀石头布吧!鸭子怒:妈的,算计我?我一出就是布,他总是剪刀!


* 蜘蛛和蜜蜂订婚，蜘蛛感到很不满意，于是就问他的妈妈：“为什么要让我娶蜜蜂？”蜘蛛的妈妈说：“蜜蜂是吵了一点，但人家好歹也是个空姐。”蜜蜂也感到很 不满意，于是也问她的妈妈：“为什么要让我嫁给蜘蛛呢？”蜜蜂的妈妈说：“蜘蛛是丑了一点，但人家好歹也是搞网络的。”

* 文字游戏
熊对能说：穷成这样啦，四个熊掌全卖了；
兵对丘说：兄弟，踩上地雷了吧，两腿咋都没了？
王对皇说：当皇上有什么好处，你看，头发都白了；
口对回说：亲爱的，都怀孕这么久了，也不说一声；
果对裸说：哥们儿，你穿上衣服还不如不穿！
比对北说：夫妻何必闹离婚呢？
巾对币说：戴上博士帽就身价百倍了；
臣对巨说：一样的面积，但我是三室两厅；
日对曰说：该减肥了

* 新生入学军训时接受校长的检阅。
“同学们好！”
“校长好！”
“同学们辛苦了！”
“为人民服务！”
“同学们晒黑了！”
新生们顿时语塞，不知如何回答。沉默片刻后，一男生大声答道：“校长更黑！”

* 一天，一只兔子在山洞前写文章，
一只狼走了过来，问："兔子啊，你在干什么？"
答曰："写文章。"问："什么题目？"答曰："《浅谈兔子是怎样吃掉狼的》。"
狼哈哈大笑，表示不信，于是兔子把狼领进山洞。
过了一会，兔子独自走出山洞，继续写文章。
一只野猪走了过来，问："兔子你在写什么？"答："文章。"问："题目是什么？"
答："《浅谈兔子是如何把野猪吃掉的》。"野猪不信，于是同样的事情发生。
最后，在山洞里，一只狮子在一堆白骨之间，满意的剔着牙读着兔子交给它的文章，
题目："《一只动物，能力大小关键要看你的老板是谁》。"

<信仰——一个老头的故事 >(ZT) - 文学城: 热点论坛 web.wenxuecity.com

<信仰——一个老头的故事 >第一章：人生的选择

(作者: 杨柳青杨)

这个老头子，和咕噜家的老头子出身完全不是同一个阶层。他出身于旧北洋官僚家庭，家里面就是那种宣传中的标准恶霸地主，大商人，买办。他从出身就被家族选 定了命运——不是嫡出长子，家族财产就不要指望了。去学门手艺混饭吃吧。从出生就开始领相当于嫡系子孙1/2的月钱，以正常的眼光来看，大概拿着家族的月 钱混吃等死过完一生。没有什么人欺负他，也没什么人鄙视他，家族中的强者没兴趣也没时间关心一个平凡得不能再平凡的旁系男孩的人生。

得益于家族的财力，这个老头子从小就受到严格的西式教育，熟练地掌握了日语，德语，英语3门外语，一路从本土小学-日本中学-北大-美国深造走过来。确实 是掌握了一门足以成为技术的手艺——土木工程。这门手艺，大概不管谁来执政都不愁吃饭，因为谁都要修桥铺路。不过很遗憾，他不愿意给日本人干活，光头并没 有修路的想法。直到49年，他还都是一个默默无闻的小职员。直到1949年。

因为恐惧土改，恐惧共产，家族中的大部分人都携带着细软逃了。作为一个毫不出色的旁系，没人打算带上他。他也没打算走。因为这里有他的老母，弟弟妹妹，有 他的家。1949年2月，红色政权和平的进入了帝都。新生政权迫切地需要技术人才。早就参加地下党的妹妹来劝他为国服务。出于对土改先天的不满，他大骂了 妹妹。因为在他保守的思想中，女人不应该参与政治，他一个技术人员也不应该。不过, 因为土改，再也没有月钱可拿了，虽然暂时有一些积蓄不愁吃穿，但弟弟还在读大学，家里需要收入。他不得不参加红色政权，去做他的老本行- 修桥铺路。

1950年，美国轰炸丹东的消息传来，他很激动。百年来衡绕在旧文人心中的民族自豪感刺激着他。他希望这个新生的红色政权能够捍卫祖国和民族的尊严。但是 他又很怀疑。终于，志愿军入朝参战的消息传来。他毫不犹疑地报名参加了赴朝铁道兵队伍。他要用自己的技术捍卫祖国和民族的尊严。50年11月，他如愿以偿 地奔赴朝鲜。去守卫清川江铁路大桥，直到战争结束。从朝鲜回来，他成了红色政权最忠诚狂热的信仰者。战后，他主持设计修筑了3条铁路，几十座桥梁。随后， 又奔赴越南，守卫那英雄的杜梅铁路桥。然后回国, 主持作训工作。直到离休。

改革开放之后，那些49年前逃到国外的亲戚们回国探亲了。大家聚在一起叙旧，喝到半醉的时候，他们那一代的长子半挑衅地问他:"留在国内几十年，出生入死 2次，最后没钱也没名，你后悔吗？"他微笑着反问："你这一生作了什么？钱财名声和权位？我都没有。但是，我的一生在为中国修铁路。不管主义，不管信仰， 他们都在为我们的民族和国家服务，不是吗？我的一生有2次机会捍卫祖国的尊严。不管主义，不管信仰，我们都是中国人。"然后是冷场，尴尬。国民党中将和共 产党将军人生的最后一次见面，就这么结束了。直到彼此都步入人生的终点。

人生的选择，很多时候就这么奇妙。不管主义，不管信仰，他的后半生都是这个红色政权最坚定的拥护者和支持者。到死为止。作为他的孙子，我会继续这份忠诚和 坚持，直到我死为止。这是我对他最好的纪念。信仰？嗯，信仰。我信仰这个红色政权，不管他有多少瑕疵，多少阴暗。此生无悔。

PS：细节片断以后写。守卫清川江铁路桥和杜梅桥铁路桥，有很多片断可写。

细节--弹坑：

刚到朝鲜的时候，铁道兵基本上毫无防空能力，也无防空经验。多山多河的朝鲜，铁路线往往多有隧道，涵洞，桥梁。铁路在那些关键性节点根本无法绕行。漫长的铁路线只好让美国飞机随便炸。一枚火箭弹就可以在铁路上炸开个大洞。几架美国飞机就可以轻松的瘫痪一长段铁路。

没有任何施工机械，当时的铁道兵只能靠铁锨和铁锹来填平铁路上的弹坑，铺上枕木和铁轨。然后再被炸断，然后继续修补。修补的速度远远跟不上破坏。虽然派出 了防空警戒哨，但是面对每天路过几次，几十次的敌机，这么躲来躲去得怎么施工？谁知道敌机去炸谁？前方需要物资，铁路不能总不通。就算躲避，也没有足够时 间修防空洞。在路基附近躲，死伤一样会很惨重。于是，老头子所在的营，决定不再躲空袭。冒着敌机的轰炸持续抢修。敌机在天上肆虐，那些铁道兵在下面不躲不 闪，在血与火中继续修路。没有战史关心他们，战史只会写下：因为缺乏冬装，长津湖冻死冻伤残废XXXXX人。在那个冬天，老头子所在营损失了编制数字 4倍的生命，铁路还是时断时续。血，染红了铁轨下面的枕木，但是，血还是白流了。

细节--土石方：

被敌机轰炸搞到快要疯狂的老头子想尽了办法。他一次又一次去量弹坑，去查施工。用铁锨和铁锹施工，现在已经是修复路基的极限速度了。毕竟弹坑周围可以站的人是有限的，毕竟人的体力是有限的。战士们实在无法跟得上敌机破坏的速度。办法到底是什么……

问题在路基的设计土石方量。那些师里的苏联专家是根据西伯利亚铁路的经验测算的。现在我们不需要考虑长期使用寿命，反正敌机会反复炸。我们不需要考虑温度 变化，我们不需要考虑其他所有的一切，我们只需要最短时间内通车。于是，他做了个疯狂的计划：不再填弹坑，准备木料作成弹坑大小的三角架填入弹坑，只要固 定三角架附近的地方，就可以铺枕木铁轨，其他的部分可以慢慢填，只要现在勉强能通车。而且不需要那么多土石方量，缩小到正常的2/3-3/4就行。寿命不 需要考虑。

这个计划一经提出，就在总部和师里吵翻了天。苏联专家对此不屑一顾，老头子拍着桌子用手枪指着自己脑袋保证，出了事故枪毙我。现在最最重要的就是缩短工 期，其他的都不是问题。于是，老头子被匀速在自己负责的营试验，效果还不错。于是推广到全部3个师。轰炸在继续，抢修也在继续。前线还是没有足够的物资。 共和国的天之骄子们，为什么你们不能守卫我们头顶上的那一点点蓝天。这个成了老头子一生的心结。每到喝醉，他都会这么对我们说。沾满了铁兵献血的分段限时 通车铁路，成了他一生的遗憾。铁路——生命线。

细节--桥墩：

因为前面表现得很好，所以老头子被调到守卫清川江铁路桥的团负责。当时清川江铁路桥只剩下桥墩子孤零零的耸立在江中。要修桥，就要从修复桥墩开始。河岸的 植被已经被轰炸扫光了，桥墩子一点掩护也没有。如果敌机来轰炸，上面的人和河岸上的，船上的，都不可能掩蔽。只能随便被炸。防空部队虽然很努力，但是这点 依旧无法保障。

当时的抢修，团长立下了个铁规矩：共产党员上桥墩，共青团员上船运输材料，其他人在岸上接力。并且要求各营要100%不打折扣的执行。于是，不到 48小时，各连指导员那里堆满了入党入团申请书。不为了权力，不为了官位，为了一个更接近死亡的位置。上桥墩的人，有一半不会再活着回来，这点其实大家都 知道。在船上运输材料工具的人，有1成机会不会再活着回来，这点其实大家都知道。在河岸上的人，危险是最小的，这点大家还是知道。每个刚刚加入的新兵在第 一天来报到的时候，都会被告知这点。桥墩，就是鬼门关。但是，在老头子守卫的那17个月中，没有人害怕，那些年轻单纯的战士，坦然地走向死亡。其中绝大多 数人都没留下遗言。所谓慷慨赴死，不过如此。

老头子的第一次负伤，就是在那里。作为全团的宝贝，他被1个班的战士保护着。团长告诉他，它只能在团部防空洞指挥抢修，绝对不许离开防空洞。可是，不实地 观察指导抢修，进度太慢了。老头子一次又一次的违反命令，越来越接近河岸。不过炸弹一直很关照他，没有落到它附近。于是他越来越不把命令当一回事，越来越 靠前。直到有一天，一架飞机扫射找上了他。那些保护他的战士拼死把他压在身下。战士牺牲了6个，他胳膊被打了3个洞。战士的鲜血染红了老头子的衣服，那件 衣服后来成了我家的镇家之宝，一直放在老头子的枕头下面，他不允许任何人动他。就在那个晚上，老头子写下了入党申请书。清川江的水，是银色的，也是红色 的。桥，缓慢而顽强的慢慢通车了。老头子一支守卫在那，拒绝了所有调离的命令。那里是他灵魂得到升华的地方，是他魂牵梦萦的地方。

细节--入党介绍人:

共产党军队有个轻伤不下火线的传统。作为团里的技术负责人，团长和政委很希望老头子能留下来继续指挥修复工作。老头子毫不犹豫地答应了。据说，他觉得那些 战士的热血一直在烧灼着他的身体。他要继续修复工作，直到大桥通车。大喜过望的团长和政委主动要求作老头子的入党介绍人，老头子当时不怎么在意，谁介绍入 党不是入党。他只是想要一个更靠近桥墩的机会罢了。他只是想要一个更接近那些勇士的机会罢了。

修复工程在继续，应对敌机轰炸的办法被逐渐得想出来，抢修进度越来越快。不过前线的卫生条件太差了，老头子伤口感染发起了烧，不过修复工程正处在最关键的 阶段，距离通车只有一步之遥，老头子每天带病继续在河滩上指挥修复。政委要求老头子上担架指挥，老头子不听，它是个很骄傲的人，不想在人前便显得那么虚 弱。于是，逞强的代价就是晕倒了好几次。

政委看警卫的战士劝阻不了老头子，就自己带了1个班团警卫连的战士抬着老头子指挥。其他的警卫连战士在守卫铁轨存放处，年轻的共和国生产这些铁轨很不容 易。运输兵把铁轨运到这里更不容易。政委寸步不离得跟着担架，不让老头子乱跑乱东。老头子很感动也很感激，不过，人生经历差距太大的他和政委实在找不到话 题。一直没找到好机会和政委说谢谢。距离大桥通车还有几天的时候，敌机组织了一次大规模的轰炸，对空警戒哨没有准确发现敌人的规模……

政委安排了老头子就地隐蔽之后，就跑向河滩上的铁轨存放点，呼叫周围的战士迅速分散转移铁轨。这个时候，一颗炸弹落了下来。政委的热血洒在那些来之不易的 铁轨上。在他的遗体上，发现了给老头子的入党介绍信……8天以后，占着政委献血的铁轨作为最后一根轨铺在大桥上，清川江铁路桥通车了。10天后，老头子对 着殷红的党旗和带血的入党介绍信加入了中国共产党。唯有牺牲多壮志，敢叫日月换新天。那个党那支军队，就靠这些年轻的热血男儿向全世界宣誓，它是不可战胜 的。

热血的信仰

这个古老的国家沉沦的太久了。它积贫积弱，它受尽了列强的欺凌。作为生在那个黑暗时代得人，老头子没有任何办法改变这个国家的命运。他只是个卑微的小人 物，只是个空有一技之长而报国无门的落魄酸儒。那个新生的红色政权给了老头子希望，振兴这个国家这个民族的希望，在茫茫黑夜中摸索了太久，失败了太多次的 旧时代文人愿意为这个那怕很渺茫的希望付出一切。有热血，有生命，它只恨不能为这个新生的国家多做些什么。在国外受尽轻蔑的经历，让老头子深深知道没国哪 有家。国家和民族的尊严如果能靠热血和生命换来的话，那没什么，他愿意奉献出他的那份。

所以他提前写下遗书，抛下怀孕的妻子和病危的母亲奔赴朝鲜。所以他不顾家族起名的排序给50年11月27日出生的第4个孩子：他的女儿起名克平。以纪念克 复平壤。所以他在朝鲜负伤3次，留下一支左臂而从没回后方养伤。我没生在那个时代，但是我尽可能的去理解他。理解那千千万万为了国家和民族在朝鲜浴血奋 战，舍生忘死的志愿军。

PS：太过激动。今天到此为止。其他德等我心情平静下来之后继续。不要催。

细节--殉暴:

为了增加大桥的物资输送量，一般来说白天过汽车运输队，晚上过火车。敌机的夜间轰炸相对比较容易应付，所以不容易躲避的火车走夜间。白天通行容易分散隐蔽 的汽车。这样干在一段时间内确实大大提高了大桥的物资输送量。不过终于还是出事了。一天，敌机突然来袭，正在通过的汽车打算加速通过大桥后隐蔽。其中的一 辆车不幸被敌机的扫射引燃了大火。那位英雄的司机不顾自身的安危，继续加速打算冲过大桥。可惜的是，他前面的一辆车也被击中了，驾驶员牺牲了。失控的第一 辆车和着火的第2辆车撞在一起，并且导致车上装载的物资殉暴，在桥上炸了的大洞。桥又需要大修了……上级首长很重视这件事，要求修筑新的汽车通行浮桥来确 保大桥的安全。可前线急需物资，汽车通行浮桥不是短时间内可以建好的。在建好前，只能继续使用大桥通行。

为了能解决被击中汽车的殉暴问题，汽车兵们主动要求拆卸掉大桥的全部护栏。如果被击中起火，就自己开到河里去确保大桥的安全。那样，驾驶员一定会牺牲，铁 兵一开始不同意，可汽车兵们再三主动要求这样做。最后采用了折衷意见。每天汽车运输队通过的时候，不当班抢修任务的战士携带着全团的洗脸盆和被子，一字排 开站在桥上。洗脸盆中装满了水，一旦汽车起火，就把水倒在被子上，用湿棉被灭火。如果火比较大或者汽车损坏了的话，就一起把汽车推下河。面对敌机的轰炸扫 射，待在毫无遮蔽物的桥上很危险，很危险。灭火推车更危险。但是无需动员，不必组织，每天不当班的战士都会主动奔赴大桥。在桥附近隐蔽，等待天黑过河的其 他部队也会主动了来做这件事。甚至等待后送的轻伤员也会来。殉暴事故还是经常会发生，每天都有人为此付出鲜血和生命的代价。但是，抢险队从没缺员过。那条 炸不烂的钢铁运输线……

朝鲜战争的伤亡如何，我不知道。我只知道，老头子调动到这个团的头6个月，该团阵亡xxxx人，远远超过了编制数字。负伤人数甚至没有严格的统计过。轻伤 包扎一下继续干活是在平凡不过的事情。每天都有新兵加入，每天都有人离开。烈士们的遗体埋葬在清川江两岸的向阳坡上，墓碑一律面对着祖国。青山有幸埋忠 骨，何必马革裹尸还。老头子晚年一直想去那里祭奠一次，可惜总不能成行，一直到死都没能如愿。很多年后，家父终于帮老头子完成了遗愿。英灵长存，至少还有 人记住他们。

细节--重逢:

有一天，老头子得到上级的指示，汽车兵要在附近修建个修车厂，希望铁兵大力配合。于是，团长政委精心准备了个欢迎会，打算欢迎一起来共事的兄弟部队。战地 的生活是枯燥的，很久没有这么个好机会一起高兴一下了。老头子也在开会的那天兴冲冲的去参加。在欢迎会上。老头子很惊讶的发现，来的主角之一是他的老朋 友。很久的老朋友，老王。

老王是南京中央大学学发动机毕业的，后来出国深造过。家里面出身非常不好。他的岳父在土改的时候定性为恶霸地主，被执行枪决。被杀后邻里的群众纷纷冲过去 用小刀分食其肉，可见民愤之大。他全家早就在49年初就坐船离开祖国去香港了，准备转道前往美国。老头子还是送行者之一。那时候老王对TG可是骂不绝口。 现在怎么他回来了？这个人的出现实在很让老头子惊讶。

久别后的重逢很让人高兴，欢迎会后老头子和老王彻夜长谈。老王告诉老头子，他是听说了紫石英事件之后就没出发去美国。中国终于有一个敢对列强开炮的政权 了，他想认真的关注一下。当中国入朝参战之后，他就决定回国。很多朋友和家人劝他，TG杀了他的家族很多很多人，没收了他们在大陆的财产。为什么要去帮助 TG？最多不去台湾反共就好了。但是他还是回国了。作为旧时代的文人，他亲眼目睹了租界，横行无忌的外国军舰驻军，华人与狗不得入内的公园。这个苦难深重 的国家自天朝大国的迷梦破灭之后，积贫积弱了太久太久。他曾经怀着实业救国的梦想开过工厂，不过被米国货搞破产了。他曾经怀着教育救国的梦想作过老师，不 过学校被大兵征用了做军营。现在他看到了希望，一个敢于对列强开炮的新生政权给了他希望。所以他愿意奉献出他的才能建设新时代。于是，老王自愿来了朝鲜， 投身战火。一段时间后，老王收到一封家信。他唯一的儿子得了肺结核，病危，希望他回去见最后一面。但他没和任何人提过这件事，继续工作。不久，他收到第二 封家信，儿子病故。没多久，第三封家信：妻子深受打击，病故。但他还是把信偷偷藏起来，没有回国去，直到战争结束。此后，老王一直没再结婚。

很久很久之后，老王在西欧谈判某型发动机生产线的进口。国内传来88的消息，当地的政府，和他谈判的企业，他来海外的亲戚，都劝他留下吧，别再回去。他微 笑着拒绝了那些人，辗转回国。某次和老头子喝酒的时候，曾经无意中提到过这个，他的答案是：从紫石英事件之后，他就相信TG可以救国，个人的恩怨和国家没 人和办法比较，他50年的选择，至死无悔。

(未完待续)