On Dec 1, 2009, at 12:52 PM, Sam Steingold wrote:
> Fred Cohen wrote:
>> On Dec 1, 2009, at 11:08 AM, Sam Steingold wrote:
>>> Fred Cohen wrote:
>>>> configdev sets of the IO device (network card - the "dev"
>>>> argument) on
>>> "configdev sets the IO device"?
>> Yes - the interface being used to send and receive. (e.g., eth0,
> could you please provide some code which uses this function?
(setf socket (rawsock:socket :inet :RAW 0 #+ignore :all)
(make-array 14 :element-type '(unsigned-byte 8)))
(make-array 1518 :element-type '(unsigned-byte 8) :fill-pointer 1518)))
(configdev socket "eth0" 1 1 ) ; eth0 no arp raw mode on socket
(defun getraw ()
(if (not (= -1 socket))
(setf (fill-pointer buffer) 1518
len #+ignore (rawsock::recvfr socket)
(rawsock:recvfrom socket buffer device)
(fill-pointer buffer) len)))
(defun print-buffer () (loop for i below len do (format t "~2,'0X
" (aref buffer i))))
;; a rudimentary dump of all packets seen.
(loop while true do ((getraw)(print-buffer)))
> (defparameter *sock* (rawsock:socket ???))
> (rawsock:configdev *sock* "eth0" ...)
> (rawsock:sock-read *sock* ...)
> or whatever.
>>>> the identified raw socket (scocket argument) to promiscuous
>>>> mode (accept all packets and pass them into the program) no ARP
>>>> mode (the interface does not automatically respond to ARP
>>>> requests, and configures its built-in address to 0.0.0.0 (which
>>>> is to say, it has no particular address).
>>> actually, the code only does something when address is non 0.
>>> (and it only handles ipv4, not ipv6).
>> Actually, it handles any raw bytes on an interface - the checksum
>> code is for IPV4
> I mean the address argument is expected to be an int32.
> Not even a string is accepted.
> It would seem, btw, that the IP address argument should actually be
> a socket address, as returned by host->ip in rawsock/test.tst.
IPv4 addresses are 4 bytes (octets) long - an int32.
>>>> Normally, if you want a silent interface which allows true
>>>> arbitrary behavior bases on what the program tells the
>>>> interface to do, you want all of these to be the case. When you
>>>> are done, you may want to turn these things back to some
>>>> previous state (i.e., the normal IP address, ARP responses per
>>>> the configured ARP address of the Ethernet card, and ignoring
>>>> non-broadcast packets sent to the interface, since this is the
>>>> normal behavior of an ethernet card and reduces system resource
>>>> consumption (if there are no promiscuous modes set by other
>>> so, we are not providing a way to restore the original behavior,
>> You do another configdev to set things to whatever you want them to
>> be when you don't want "raw". The row socket is not persistent or
>> in effect past the process, so other processes may do as they
>> please and handle other raw or non-raw interfaces - although
>> performance will be hit because the interface is looking at
>> everything instead of ignoring packets not broadcast or to its MAC
>> address / IP address. The OS keeps a list of interfaces and the
>> processes that get each of them at what phase in its processing. A
>> raw socket avoids the OS handling (except for the low-level driver
>> code to move bytes via the DMA to and from the hardware and
>> memory). The configdev code uses IOCTL to alter the hardware
>> configuration and tell the OS to put you at an earlier place in
>> the list of handlers.
>>> this should be fixed.
>> Nothing to fix.
> I thought you said that configdev modifies the behavior of both the
> socket and the device (e.g., eth0).
> I can close the socket and open a new one, but how do I bring the
> device back to the original behavior?
(defun close-sock ()
(if (= (rawsock:sock-close #+ignore rawsock::closesock socket) -1)
(error "can't close socket")))
>>>>> 2. checksum functions: what is their contract? (e.g., min/max
>>>>> buffer size? do they modify their argument? how?)
>>>>> where specifically are these checksums documented?
>>>>> how are these functions supposed to be used?
>>>> IP datagrams are limited in total size by RFC791 (http://www.ietf.org/rfc/rfc791.txt
>>> looking at page 10, I see Figure 4. (Example Internet Datagram
>>> it says that the "Total Length" is in bytes 2 and 3 (0-based,
>>> i.e., bits 16-31)
>>> while "Header Checksum" is in bytes 10 and 11.
>>> code in ipcsum takes length not buffer and writes the csum
>>> into bytes 25&26.
>>> I am confused.
>> That's because the first 14 bytes of an Ethernet frame are
>> (normally) for the MAC address. IP datagrams sit inside ethernet
>> frames (or other frames depending on the particulars). rawsock
>> assumes an ethernet - which is the most common situation. So
>> everything is offset from IP by 14 bytes. But ethernet frames are
>> also alterable by rawsock - so you can operate many different
>> ethernet MAC addresses. Ethernet frames include things like
>> manufacturer identification information and from and to MAC
>> addresses (and broadcast addresses), which also have to get
>> changed around to send and receive, and have to get changed when
>> forwarding if the interfaces deal with other infrastructure
>> elements (e.g., switches) that use MAC addresses for decision-
> I see, so "buffer" is not a "datagram" but a "frame".
> what can clisp do with such a frame?
Anything you want - read it, write it, load from the ethernet
interface, send to the ethernet interface, alter when in your
> can you give a code sample?
(loop while true do ((getraw)
(setf (aref buffer 14) 5)
(sendt socket len)
This will change the IP version number to 5 (if it was 4, it will
cause problems...) and send the frame out with the new bytes.
>> It gets even worse because loopback (the lo interface) does not
>> have ethernet frames (it's not on an ethernet) so for these cases
>> the code has to be abused (you do the checksums than shift the
>> bytes to go from ethernet to lo, and add your own MAC addresses
>> which have to be right to lo datagrams to put then in ethernet
>> frames. rawsock does not do this for you.
> the csum functions now take :start/:end arguments, so, I guess, you
> can format them for loopback too.
> actually, I would love to see a piece of code for that.
As I said, I haven't looked at this for a while - and haven't seen the
new versions. It's the same thing as before - just start at 0 instead
of 14 offset.
- This communication is confidential to the parties it is intended to
Fred Cohen & Associates tel/fax: 925-454-0171
http://all.net/ 572 Leona Drive Livermore, CA 94550
Join http://tech.groups.yahoo.com/group/FCA-announce/join for our