["Nisbet, Tom" <Tnisbet@xxxxxxxxxxxxxxxxxx>]

Ethereal and Sniffer are both handling the traffic correctly.  The frames
have 
the lsb of the first octet set.  This is defined as the extended address
bit, 
normally indicating the end of the frame relay header.  Ethereal checks this
and 
stops decoding the header and starts on the payload.

Someone at the frame relay forum eventually noticed that there is no such
thing as 
a one octet frame relay address field, so they stole this bit in the first
octet to
indicate frame relay fragmentation, as defined in FRF.12.  The Sniffer is
trying to 
decode this.

It appears as though the traffic is really using a two octet address field
but is setting 
the EA bits incorrectly.  If you ignore the EA bits and treat the headers as
two octets, 
you get IP traffic using the common ethertype encapsulation.  I've enclosed
an example 
trace below that ignores the EA bits.

Is it possible that the router or other frame relay equipment is building
the frames 
incorrectly?  Other than the EA bits, they look fine.  They are not valid
FRF.12 frames.

Tom


      =============================  Frame Number 2025
=============================
      Frame source = (User)
      Length = 87
      Time received = 11/12/2003 05:48:50.068
Frame Relay
      Header = 0x0f00
          0000 11.. 0000 .... = DLCI 48
          .... ..1. .... 000. = (Response)
      EtherType = 0x0800 IP
Internet Protocol (IP)
      Source address      = 172.25.160.200
      Destination address = 172.25.1.203
      Type of service = 0x00
      Length = 83
      Identification = 0x524d
      Flags = 0x0000 (May fragment, Last fragment)
      Time to live = 29
      Protocol = 17 UDP
User Datagram Protocol (UDP)
      Source Port      = 161 SNMP
      Destination Port = 1055
      Data Length = 63
      Checksum = 0xe593
Simple Network Management Protocol (SNMP)
      Community = public
      getResponse
      Request ID = 292520
      Error Status = OK
      1.3.6.1.4.1.5596.10.3.2.1.0 = OctetStr (len=9) "VideoConf"



> -----Original Message-----
> From: Jeff Foster [mailto:jfoste@xxxxxxxxxxxx]
> Sent: Wednesday, June 23, 2004 6:30 PM
> To: 'Guy Harris'; Marc Carbones
> Cc: Jeff Foster; Ethereal development
> Subject: RE: [Ethereal-dev] WTAP_ENCAP_FRELAY
> 
> 
> 
> It's even worse, I tried to open the capture with Sniffer 4.2 
> and it doesn't
> understand the file. It decodes the first two bytes as Frame Relay
> Fragmentation
> and show the third and fourth byte as the Frame Relay 
> addressing. Even then
> the address decode displays an error.
> 
> Jeff F>
> 
> 
> From: Guy Harris [mailto:gharris@xxxxxxxxx]
> 
> > Marc Carbones said:
> > > The Ethereal can see the FR packets but no the IP 
> information inside,
> > > this is my problem.
> > 
> > The problem is twofold:
> > 
> >     1) it's using DLCI 0, which the Frame Relay dissector currently
> > interprets as LAPF;
> > 
> >     2) it *looks* as if the payload begins with a zero pad 
> byte followed
> > by an Ethernet type (or Cisco HDLC type), which isn't an 
> encapsulation
> > format Ethernet knows about.
> 
> 
> 
> ***
> The information in this e-mail is confidential and intended 
> solely for the individual or entity to whom it is addressed.  
> If you have received this e-mail in error, please notify the 
> sender by return e-mail, delete this e-mail, and refrain from 
> any disclosure or action based on the information.
> ***
> 
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>