Problem with zcip's packing of ARP packets?

David Daney ddaney at avtrex.com
Fri Aug 11 15:38:09 UTC 2006


OK, so I didn't fully read your message.  You did say which versions of 
things you are using.

This does not really seem like a uClibc problem as you are using glibc.

It seems more likely to be a problem with the net/if_arp.h and/or tool 
chain you are using. If you look at the arp header of your dump, you 
will see that it is all screwed up (fields in the wrong order).

David Daney

David Daney wrote:
> Works correctly for me on:
> 
> mipsel-linux/linux-2.4.29/glibc-2.3.3/busybox-1.1.0.pre1
> 
> I have not tried zcip on a uClibc system so I cannot speak for how well 
> that works.
> 
> You don't say what archetecture you are using nor library versions.
> 
> Perhaps you have a broken htonl() or htons().
> 
> David Daney.
> 
> 
> Patrick Noffke wrote:
> 
>>I've found a problem with zcip (zeroconf link-local addressing utility, part of busybox), but not sure how to fix it.
>>
>>The arp packet getting sent has the target IP address shifted by 2 bytes.  The arp packet looks like this:
>>
>>struct arp_packet {
>>        struct ether_header hdr;
>>        // FIXME this part is netinet/if_ether.h "struct ether_arp"
>>        struct arphdr arp;
>>        struct ether_addr source_addr;
>>        struct in_addr source_ip;
>>        struct ether_addr target_addr;
>>        struct in_addr target_ip;
>>} ATTRIBUTE_PACKED;
>>
>>
>>And the bit of code that sends the arp packet is this:
>>
>>/**
>> * Broadcast an ARP packet.
>> */
>>static int
>>arp(int fd, struct sockaddr *saddr, int op,
>>        const struct ether_addr *source_addr, struct in_addr source_ip,
>>        const struct ether_addr *target_addr, struct in_addr target_ip)
>>{
>>        struct arp_packet p;
>>
>>        // ether header
>>        p.hdr.ether_type = htons(ETHERTYPE_ARP);
>>        memcpy(p.hdr.ether_shost, source_addr, ETH_ALEN);
>>        memset(p.hdr.ether_dhost, 0xff, ETH_ALEN);
>>
>>        // arp request
>>        p.arp.ar_hrd = htons(ARPHRD_ETHER);
>>        p.arp.ar_pro = htons(ETHERTYPE_IP);
>>        p.arp.ar_hln = ETH_ALEN;
>>        p.arp.ar_pln = 4;
>>        p.arp.ar_op = htons(op);
>>        memcpy(&p.source_addr, source_addr, ETH_ALEN);
>>        memcpy(&p.source_ip, &source_ip, sizeof (p.source_ip));
>>        memcpy(&p.target_addr, target_addr, ETH_ALEN);
>>        memcpy(&p.target_ip, &target_ip, sizeof (p.target_ip));
>>
>>        // send it
>>        if (sendto(fd, &p, sizeof (p), 0, saddr, sizeof (*saddr)) < 0) {
>>                perror("sendto");
>>                return -errno;
>>        }
>>        return 0;
>>}
>>
>>
>>It all looks good, but an ethereal capture (on both Windows and Linux) show the following:
>>
>>Address Resolution Protocol (request)
>>Hardware type: Ethernet (0x0001)
>>Protocol type: IP (0x0800)
>>Hardware size: 6
>>Protocol size: 4
>>Opcode: request (0x0001)
>>Sender MAC address: RealtekU_12:34:56 (52:54:00:12:34:56)
>>Sender IP address: 169.254.2.175 (169.254.2.175)
>>Target MAC address: RealtekU_12:34:56 (52:54:00:12:34:56)
>>Target IP address: 154.191.169.254 (154.191.169.254)
>>
>>
>>In Hex, that's:
>>
>>0000   ff ff ff ff ff ff 52 54 00 12 34 56 81 00 00 01  ......RT..4V....
>>0010   08 06 00 01 08 00 06 04 00 01 52 54 00 12 34 56  ..........RT..4V
>>0020   a9 fe 02 af 52 54 00 12 34 56 9a bf a9 fe 02 af  ....RT..4V......
>>0030   00 00 00 00 00 00 00 00 00 00 00 00              ............
>>
>>The source and target IP address are both supposed to be 169.254.2.175 (a9 fe 02 af), but the target IP address is getting shifted by two bytes.  You can still see the (a9 fe 02 af) pattern after the (9a bf) pattern.  Note:  the arp_packet struct starts at 0x0012 in the above capture.  So the target IP address looks like it's getting written to the start of a 4-byte boundary at 0x002C.  However, the source IP address doesn't start at a multiple of 4 bytes from the start of the ARP packet, so I'm not sure it's even a packing problem.
>>
>>I should also mention the arp function is getting called with the same parameter (ip) for source_ip and target_ip.  And I'm using busybox 1.1.1 with glibc 2.3.5, gcc 3.4.5.
>>
>>Any suggestions what might be going wrong?  I've stared at this code over and over and nothing seems wrong to me.
>>
>>********************************************
>>Patrick Noffke
>>Senior Software Engineer
>>Vision Fire & Security
>>45 Third Avenue
>>Technology Park
>>Mawson Lakes  SA  5095
>>
>>Phone:  +61 8 8300 4038
>>Fax:  +61 8 8300 4001
>>Email:  patrick.noffke at adpro.com.au
>>
>>IMPORTANT - This email and any attachments may be confidential.  Any retransmission, dissemination or other use of these materials by persons or entities other than the intended recipient is prohibited.  If received in error, please contact us and delete all copies.  Before opening or using attachments, check them for viruses and defects.  Our liability is limited to resupplying any affected attachments.  [Any representations or opinions expressed in this email are those of the individual sender, and not necessarily those of Vision Systems Limited.]
>>_______________________________________________
>>uClibc mailing list
>>uClibc at uclibc.org
>>http://busybox.net/cgi-bin/mailman/listinfo/uclibc
> 
> 
> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc




More information about the busybox mailing list