Conference 7.286::fddi

2015.0. "Bits get swapped in addr - packetfilter" by RHETT::AMAN () Wed Apr 17 1996 12:24

    My customer is writing an application using the packetfilter interface
    over FDDI.  He says he has to swap the bits in the bytes of the
    destination address in order for it to be received properly.  Any
    comments?  He is running OSF V3.2 and has a DEFPA interface.  From the
    customer -
    
    ------------------
    Hello
    
    Here is my question about fddi.
    
    I use the packetfilter interface to
    send fddi frames over a network. I found out that in order for
    the target computer to receive the frame, I have to modify its
    hardware address before I put it as destination address in the
    MAC header.
    
    Here is the h/w address of the target computer (it is not a alpha):
    00:00:3d:70:40:17
    
    Here is how I open the fddi packetfilter device on the alpha:
    
    ...
    
      fd=pfopen(dev_name,*oflag);
    
      /* set max # of packets in waiting in queue */
      maxp = 64;
      ioctl(fd, EIOCSETW, &maxp);
    
      /* receive at most 1 packet per read() */
      bits = ENBATCH;
      if (ioctl(fd, EIOCMBIC, &bits))
      {
        perror("fddi_open: error ENBATCH ioctl");
        return(-203);
      }
    
      /* add stamp */
      bits = ENTSTAMP;
      if (ioctl(fd, EIOCMBIS, &bits))
      {
        perror("fddi_open: error ENTSTAMP ioctl");
        return(-203);
      }
    
      /* enable non-blocking IO */
      tv.tv_sec=-1;
      tv.tv_usec=-1;
      if (ioctl(fd,EIOCSRTIMEOUT,&tv))
      {
        perror("fddi_open: error enable non-blocking IO");
        return(-203);
      }
    
      /* filter with type = 0x0cae */
      f.enf_Priority = 36;        /* [0..255] highest = 0 */
      f.enf_FilterLen = 0;
      f.enf_Filter[ENMAXFILTERS];
      f.enf_Filter[f.enf_FilterLen++] = ENF_PUSHWORD + 8;
      f.enf_Filter[f.enf_FilterLen++] = ENF_PUSHLIT | ENF_EQ;
      f.enf_Filter[f.enf_FilterLen++] = 0xae0c;
      ioctl(fd, EIOCSETF, &f);
    
      /* flush this queue */
      if (ioctl(fd, EIOCFLUSH, 0))
      {
        perror("fddl_open: error ioctl EIOCFLUSH\n");
        return(-203);
      }
    
    ...
    
    Here is how I send the packet:
    
      fh = (struct fddi_header *) buf;
      fh->fddi_ph[0] = 0;
      fh->fddi_ph[1] = 0;
      fh->fddi_ph[2] = 0;
      fh->fddi_fc = FDDIFC_LLC_ASYNC;
      len = 4050;
      status=write(fd, buf, len);
    
    
    These are the first 32 bytes of the packet, as seen with dbx:
    0000000140000750:  0ebc000050000000 d413b32b0008e802
    0000000140000760:  0000000000000000 3131313131313131
    
    For convenience, I reverse the bytes:
    000000500000bc0e02e808002bb313d4
    00000000000000003131313131313131
    
    This is what I receive in the other computer:
    0000005000003d7040171000d4cdc82b
    00010000000000003131313131313131
    
    
    1 - If I put as destination address the exact address of my target
    machine,
    It does not receive the frame. I have to swap the bits of each byte of
    the
    destination address for my target machine to receive the frame.
    For each byte of the dst address, I have to exchange bit 0 and 7,
    bit 1 and 6, etc.
    
    My question is why do I have to swap the bits ? Is it because of the
    fddi driver, or is it because of the fddi card itself ? Is it a feature
    of DEC fddi implementation, or is it a standard feature of the fddi
    technology ? I have not seen this behaviour with, for example,
    Ethernet controllers.
    
    I can see also that in the received frame, the source address has also
    been swapped.
    
    ---------
    
    Is this something else that if fixed OSF320-194?  Thanks for any input.
    
    Thanks,
    janet aman
    CSC/CS

That's because the other FDDI drivers/devices are stupid.  FDDI is like Token
Ring in that it transmits bit 7 first instead of bit 0 like Ethernet.  DEC
FDDI gear is smart enough to automatically bit reverse each byte of FDDI MAC
header for you.  Other manufacturers boards are not smart.  

00:00:03:70:40:17
00-00-bc-0e-02-e8

    Thanks for the reply!  I'll give this information to the customer. 
    Hopefully, doing the prep-work for the addressing won't be too painful
    for him.
    
    Thanks!
    janet
    

    .1 should read
    
    00:00:03:70:40:17 being 00-00-c0-0e-02-e8
    
    Walter