Since the debugger uses its own driver to talk to the networking hardware,
the number of supported network interfaces is a lot less than what is
supported by the kernel.
At the time of this writing, there is only support for a NE2000 compatible
card in a PCI slot.
In order for
ipkdb
to find your card, you need to specify the slot the card is in via
the
options IPKDB_NE_PCISLOT
.
To use , you have to set up a DHCP server, from which ipkdb can get the IP address for the interface that is used for debugging.
To enter
,
the remote debugger has to send the protocol start packet.
E.g., gdb will do this on the command
target
ipkdb
debuggee
IPKDB
key
for
remote
debugging
where
debuggee
is the name of the machine to debug (which must resolve to the
IP address of the interface), and the rest of the line
corresponds to the definition of
IPKDBKEY
(see below).
For
ipkdb
to actually see this packet, the interface which is used for
debugging has to be set up to actually receive packets,
i.e. it has to be up and running.
To prevent messing around with a secured system,
ipkdb
normally also checks the security level at which the kernel
is running.
ipkdb
will only work with security levels less than 1,
unless the kernel is configured with
options IPKDBSECURE
.
In addition, the debugger is forcedly entered on a panic, as well as on initial startup, if you boot the kernel with the -d option (note that this however is machine dependent). On such a forced enter to ipkdb there is no need for the interface in question to already be up and running, since ipkdb only needs to send/receive packets via its own driver.
As some form of security against the occasional hacker,
ipkdb
uses the definition of
options IPKDBKEY
to compute a checksum on the data in every packet.
The remote debugger has to send this checksum,
based on the data it sends and the key, or
ipkdb
ignores the packet.
This is also used in order to check against data errors
on the connection.
There is no support for ip6(4).