Date: Wed, 20 Feb 2002 09:48:04 -0800 From: Bakul Shah <bakul@bitblocks.com> To: Julian Elischer <julian@elischer.org> Cc: "George V. Neville-Neil" <gnn@neville-neil.com>, freebsd-hackers@freebsd.org Subject: Re: Kernel Debugging over the Ethernet? Message-ID: <200202201748.MAA01255@repulse.cnchost.com> In-Reply-To: Your message of "Tue, 19 Feb 2002 23:04:50 PST." <Pine.BSF.4.21.0202192303270.60489-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Tue, 19 Feb 2002, Julian Elischer wrote: > > > Hi George. > > > > There was someone recently that posted that they had some sort of > > remote debuging working over an ethernet (or at least that they ALMOST > > had it working.). I remember thinking "Cool". I have however had good > > success with the serial crossover cables needed for the curren serial > > debugger. I know of course that it's not as convenient but > > the serial debugger can possibly work in network debugging situations > > where the ethernet debugger is "too close to the action" :-) > > > > I'll see if I can find the reference in the archives... > > I've looked but I can't find a reference.. > maybe I was dreaming.... This is the way we did it: - add a low level console device that sends & receives ethernet packets of special ether type. Packets are sent to an ethernet multicast address (N). - we enhanced if_ethersubr.c to deal with packets of this type (when addressed to the local machine) - if a console packet is received, it is unpacked and chars from it are interpreted normally. - Interrupts were disabled only while there were outstanding chars to send out or while receivied chars were being processed. - at compile time we hardwired a particular ethernet driver to act as console. - on the remote machine a program can be run that watches for enet dest.addr==N and src.addr==M (machine whose console we are interested in). This program extracts chars from packets from the host M and displays them to /dev/fd/1 and packages up chars from /dev/fd/0 and sends them to enet dest addr==M. This gives you in effect a remote console. You can exit out of the program using cu like commands (. in first column). Among other things this allowed you to use ddb remotely. - To connect to a particular machine from the remote console program we either used its ethernet address directly or via /etc/ethers. - the same program can optionally open a pty and start up gdb (or a debugger of your choice). Basically it just fork-execed a specified program. Use of ethernet multicast allowed us to access the console from any directly connected machine. By not using IP we avoided dealing with a bunch of issues and depended on fewer things that had to work right. Of course, security is compromised. But this is a given if anyone can run gdb remotely in any case. I may have forgotten a few things but this is the gist of how it worked. Credit for all this work goes to someone else. We had meant to give this back to the FreeBSD community but didn't get around to it in time and now it is not possible. -- bakul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202201748.MAA01255>