CLISP - an ANSI Common Lisp

clisp-cvs-request@... writes:
 > +++ rawsock.xml	2 Dec 2009 21:05:59 -0000	1.61
 > +   ethernet frame (starting with a 14 byte MAC address) for the protocol,
The ethernet frame actually contains 2 6 byte mac addresses and 2
bytes for next level protocol

 > +++ rawsock.c	2 Dec 2009 21:05:58 -0000	1.127
 > +/* these check sum functions operate on ethernet _frames_,
 > +   i.e., the 14 bytes MAC address followed by an IP datagram. */
ditto

Don Cohen wrote:
> clisp-cvs-request@... writes:
>  > +++ rawsock.xml	2 Dec 2009 21:05:59 -0000	1.61
>  > +   ethernet frame (starting with a 14 byte MAC address) for the protocol,
> The ethernet frame actually contains 2 6 byte mac addresses and 2
> bytes for next level protocol
> 
>  > +++ rawsock.c	2 Dec 2009 21:05:58 -0000	1.127
>  > +/* these check sum functions operate on ethernet _frames_,
>  > +   i.e., the 14 bytes MAC address followed by an IP datagram. */
> ditto

thanks.
this is why I always ask for explicit patches.
OTOH, the good news is that you at least read the diffs.

still awaiting demo code for checksum functions.

Don Cohen wrote:
> clisp-cvs-request@... writes:
>  > +++ rawsock.xml	2 Dec 2009 21:05:59 -0000	1.61
>  > +   ethernet frame (starting with a 14 byte MAC address) for the protocol,
> The ethernet frame actually contains 2 6 byte mac addresses and 2
> bytes for next level protocol

what does "2 bytes for next level protocol" mean?

Sam Steingold writes:
 > thanks.
 > this is why I always ask for explicit patches.
 > OTOH, the good news is that you at least read the diffs.
I try to look for things that I might actually know or care about.
And this is why I hate those updates that automatically generate
dozens of changes (like the ones that affect all modules).

 > still awaiting demo code for checksum functions.
These will only be useful when you want to send raw packets.
We've not yet discussed when this might be useful.
If you want to write some normal thing like ping or dns lookup
then (I'm hoping) you don't need raw packets and the checksums
will be computed for you by the higher level programs you use.
I've not actually looked at them.  For instance, I bet the current 
tcp code used by clisp never has to compute checksums.  It probably
also does not worry about TOS or IP fragmentation or TCP sequence
numbers, all of which would be explicitly required in sending with
(what I call) the raw socket interface.

Sam Steingold writes:
 > Don Cohen wrote:
 > > clisp-cvs-request@... writes:
 > >  > +++ rawsock.xml	2 Dec 2009 21:05:59 -0000	1.61
 > >  > +   ethernet frame (starting with a 14 byte MAC address) for the protocol,
 > > The ethernet frame actually contains 2 6 byte mac addresses and 2
 > > bytes for next level protocol
 > 
 > what does "2 bytes for next level protocol" mean?

That same rfc 1700 (which I believe to be now obsolete) says:

The following list of EtherTypes is contributed unverified information
from various sources.

Assignments:
Ethernet          Exp. Ethernet    Description          References
-------------     -------------   -----------           ----------
decimal  Hex      decimal  octal
   000   0000-05DC   -       -    IEEE802.3 Length Field   [XEROX]
   257   0101-01FF   -       -    Experimental             [XEROX]
   512   0200        512   1000   XEROX PUP (see 0A00)   [8,XEROX]
   513   0201        -      -     PUP Addr Trans (see 0A01)[XEROX]
 ...

The normal ones you see in tcpdump are 
  2048   0800        513   1001   Internet IP (IPv4)     [105,JBP]
and
  2054   0806        -      -     ARP                     [88,JBP]

Recall I said that not all packets are IP ?
An IP packet will have as the last two bytes of the ethernet header
 0800
An ARP packet will have instead 0806
And of course there are 2^16-2 other possible values.

I still can't find the rfc with this packet format map.
I'm sure I once saw it.
BTW, the destination mac address comes first - I guess so the
receiving nic can decide whether to ignore it earlier.

> * Don Cohen <qba-fbheprsbetr-kkm@...> [2009-12-03 12:29:05 -0800]:
>
>  > still awaiting demo code for checksum functions.
> These will only be useful when you want to send raw packets.
> We've not yet discussed when this might be useful.

the functions are there.
ergo, they are useful for _something_.
what?
can we have an example?

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 9.04 (jaunty)
http://ffii.org http://www.PetitionOnline.com/tap12009/ http://dhimmi.com
http://iris.org.il http://jihadwatch.org http://truepeace.org
Software is like sex: it's better when it's free.

Sam Steingold writes:
 > > > still awaiting demo code for checksum functions.
 > > These will only be useful when you want to send raw packets.
 > > We've not yet discussed when this might be useful.
 > 
 > the functions are there.
 > ergo, they are useful for _something_.
I don't think this follows - I don't want to admit it for CONFIGDEV

 > what?
 > can we have an example?

They're useful when you want to send ip packets from a "raw" socket -
one created with either AF packet or AF ip and type packet.  A socket
created with AF ip and type raw, by contrast, I'll call an "ip" socket.

I'm trying to decide whether I think that's strictly necessary.  Even
if it's not, it might be convenient in cases where you are using the
same raw socket for everything and you happen to want to send ip
packets.  It would be necessary to use a raw socket, and therefore to
compute checksums, if you wanted to control the ethernet header of IP
packets.  I've never tried all the stuff for controlling the IP fields
from an ip socket, so I'm not sure whether you ever have to compute
checksums in that case.  The impression I got from the man page was
that you could control everything that made sense and in the end the
checksum would be computed for you.  Of course, if you want to send
illegal IP packets then you almost certainly need to use raw sockets.
And in that case if you want to send correct checksums then the
checksum functions are handy.  Even if you want to send incorrect
checksums that are closely related to correct checksums, e.g., with 
the bytes swapped, it's handy to have checksum functions.

> > (rawsock:socket :inet :raw <ip protocol>)
 > > - does not include the ether header
 > >  (which is also what it says in man RAW(7))
The changes I saw in the doc indicate that the ether header is present
and evidently that has to be changed - whether it is depends on the
arguments.  In fact, it seems quite plausible that other arguments we
have not yet tried might result in even less (or more) information,
such as removing IPv4 headers or removing UDP headers.

 > > Note
 > >   that  packet sockets don't reassemble IP fragments, unlike raw  
 > > sockets.
Note that in this case one might also get IP packets of up to 64K.
(Actually I've noticed that high speed nics tend to support ethernet
packets of >> 1500 bytes.)

I suggest that the sniffer code make the buffer size also a
configuration parameter.  Also that the comment on top show all of
the parameters and their defaults, e.g., 
 sudo clisp sniffer.lisp
 is the same as
 sudo clisp sniffer.lisp -domain inet -type packet -protocol #x300 -repeat 10 -size 1518

(Just realized, you can't enter #x300 into shell without \ and even
then it won't parse as an integer!)

 > > I still get the impression that (rawsock:socket :packet :raw #x300) is
 > > the right way to capture all packets in linux, though it requires
 > > some fancier code for identifying the device.
Namely comparing with the results of ifaddrs.

Don Cohen wrote:
> I suggest that the sniffer code make the buffer size also a
> configuration parameter.

done

> (Just realized, you can't enter #x300 into shell without \ and even
> then it won't parse as an integer!)

use base 10, not base 16.
otoh....
please try again.