[Prev][Next][Index][Thread]

Re: my ARP message




I wish I had more time to spend on this. It is an interesting problem.
rcf1490.txt, section 7 explains in general terms how Frame Relay and
ARP are used together. This is necesary because Frame Relay understands
dlci addressing rather than IP addressing. ARP must convert the
IP address to the appropriate dlci and put it into a header that
frame relay can use. The format of this is shown in rfc1490.txt.

see: http://majnoon.neda.com/rfc/rfc1490.txt

Your version of ARP must be patched or updated in order to deal
with this stuff. If the author of the frame relay device driver
did not supply an arp fix, then you will need to study the rfc
and the existing device driver. There are calls to arp from the
kernel's IP module and probably from the frame relay device
driver as well.

The frame relay system uses an address scheme known as Q.922.
This scheme is very odd, using the some bits in the middle of
a 16 bit address to represent the frame-relay channel number
(dlci).

Section 8 of the rfc explains how the frame appears when it
it carries and IP packet. You could examine the packets
with tcpdump (get raw packets from tcpdump and put them into
a file using the -w <filename> switch) Then use od to make
a hex version of the file. the hex version can be inspected
manually, though it is time consuming.

ARP packets as well as IP packets must be transported over the
frame-relay at a minimum. Your linux box may also provide the
frame-relay with ipx, smb and who-knows what else.

Interestingly, the frame relay system can be used as an ethernet
bridge, and you can ecapsulate whole ethernet packets into the
frame-relay, making the distant ethernet appear to be local.

OK.. so you can also use the information in rfc1490.txt to
modify tcpdump so that it can understand your frame relay.
But, you might find it easier to just read the hex dump
and get your setup debugged.

--randy
On Sun, 10 Nov 1996, Ira Abramov wrote:
> On Tue, 29 Oct 1996, Randy Wright wrote:
> 
> >                      printk(KERN_ERR "ARP: dev->type mangled!\n");
> > with 
> >                      printk(KERN_ERR "ARP: dev->type mangled! %d  %s\n",dev->type, dev->name);
> > 
> > This will give you a number.Look in /usr/include/linux/if_arp.h to see
> > what the possibilities are. Maybe some ARPHRD_SLIP or ARPHDR_PPP is
> > slipping into the arp stream, possibly due to proxyarp configuration
> > or something of that nature. Your arp_rcv() function is prolly
> >not prepared to handle some of the psuedo-arp types. 
> 
> I can't make tcpdump read the framerelay :-(
> eth0 it reads fine but dlci00 is not it's cup of tee (HA! wonderful pun!)
> 
> [ira@bit ~]$ tcpdump -i dlci00
> tcpdump: snoop: unknown physical layer type
> 
> anyone with brighter ideas, or should I now patch the kernel to at least
> reveal the evil originator of the packets?
> 
>  -------------------------------------------------------------
>  Ira Abramov          <ira@scso.com>        Scalable Solutions
>  SITE Web Presence ("webspace for rent") http://www.site.co.il
>  Beeper 91826 at 058-212121                FAX (972)2-643-0471
>  POBox 3600, Jerusalem 91035, Israel       Tel (972)2-642-6822
>  http://www.scso.com/~ira   Check out: http://www.linux.org.il
> 
> 

  
                       Randy Wright randy@ramat-negev.org.il
                     System Administrator - Ramat-Negev FreeNet
                          http://www.ramat-negev.org.il/
                           07-6572671 voice-telephone
 


References: