| Anonymous | Login | Signup for a new account | 11-10-2008 11:05 PST |
| Main | My View | View Issues | Change Log | Docs |
| Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||||
| ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||
| 0000993 | [BusyBox] Networking Support | major | always | 08-13-06 18:26 | 09-03-06 05:41 | ||||
| Reporter | pnoffke | View Status | public | ||||||
| Assigned To | BusyBox | ||||||||
| Priority | normal | Resolution | fixed | ||||||
| Status | closed | Product Version | 1.1.x | ||||||
| Summary | 0000993: zcip sends ARP packets with incorrect target IP address | ||||||||
| Description |
I've found a problem with zcip (zeroconf link-local addressing utility, part of busybox). 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. |
||||||||
| Additional Information | Jason Schoon has created a patch that fixes this. I've attached his patch to this issue. | ||||||||
| Attached Files |
|
||||||||
|
|
|||||||||
Notes |
|
|
(0001576) pnoffke 08-22-06 17:21 |
This issue also fixed against 1.2.1 with the patch in issue 1005. |
|
(0001606) vda 09-03-06 05:41 |
Hopefully fix for bug 1005 covers this too |
| Copyright © 2000 - 2006 Mantis Group |