Re: Code working with LIBNET_RAW4, not with LIBNET_LINK
Karen Pease <[email protected]> Fri, 21 Jan 2005 00:39:37 -0600
| Newsgroups | gmane.comp.security.libnet |
|---|---|
| Message-ID | <[email protected]> |
Thank you very much, Manu. Is there a function that I can call to look up a remote mac address, or do I have to build the arp packet (and wait for the return) myself? I noticed libnet_get_hwaddr, but that gets your own mac. - Karen On Thursday 20 January 2005 2:21 pm, Manu Garg wrote: > Karen, > > It seems that there is a router between the machines that you are > testing with. In that case packets will travel like this: > > Source ---> Router ----> Target > > In case of LIBNET_RAW4, it correctly finds out the mac address of > router NOT the target. That's why it's working. > > In case of LIBNET_LINK, you are hardcoding the mac address of the > target and packet never finds any such destination. > > cheers, > -Manu > > On Thu, 20 Jan 2005 02:32:13 -0600, Karen Pease > > <[email protected]> wrote: > > On Wednesday 19 January 2005 2:10 pm, you wrote: > > > Read through the sample code that comes with libnet > > > (www.packetfactory.net/libnet). This sounds like a simple problem that > > > could be solved by seeing the relevant code. > > > > Actually, I did run into these previously when searching the net; they > > were no help. They don't work, and I can't see how they would work. For > > example, lets look at the one that's closest to what I'm doing - udp2.c. > > It sets the destination mac to the value of enet_dst. This variable > > isn't modified at all in udp2.c - it is defined, initialized, and never > > changed in libnet_test.h, as: > > > > u_char enet_dst[6] = {0x00, 0x10, 0x67, 0x00, 0xb1, 0x86}; > > > > A preset hwaddr? How could that possibly work? > > > > It doesn't, at least when I've tried it. Lets call my machine Source, > > and the other machine Target. First off, I shut off iptables on Source > > and Target, just in case. Now, running tcpdump on the target machine as > > follows: > > > > [root@ipl3 kpease]# /usr/sbin/tcpdump | grep <Source> > > tcpdump: listening on eth0 > > > > Now, lets test the tcpdump by pinging the computer: > > > > 02:15:24.398157 <Source> > <Target>: icmp:echo request (DF) > > 02:15:26.044271 <Source> > <Target>: icmp:echo request (DF) > > 02:15:26.470916 <Source> > <Target>: icmp:echo request (DF) > > > > Etc. So, we know it's working. So, I try: > > > > while true; do ./udp2 -s <Source> -d <Target> -P 22; done > > > > Not a thing shows up (port 22 is not only unblocked, but open and > > recieving connections, as evidenced from nmap from Source). So, lets try > > tcp there: > > > > while true; do ./tcp1 -s <Source>:30000 -d <Target>.22; done > > > > Not a thing. Once again, it's using that hard coded mac addr, so I can't > > see how it would make it. > > > > So, enough with the samples - to my code. Here's what gets sent when I > > use LIBNET_RAW4: > > > > 00:31:45.778733 IP <Source>.30000 > <Target>.http: UDP, leng > > 0x0000: 0020 e035 5440 0050 046c e730 0800 4500 > > [email protected]. 0x0010: 0026 8d68 0000 4011 1d41 c0a8 0003 81ff > > .&[email protected]...... 0x0020: 8d73 7530 0050 0008 ba3f 0102 0304 0506 > > .su0.P...?...... 0x0030: 7465 7374 test > > > > And here is with LIBNET_LINK > > > > 00:34:07.799767 IP <Source>.30000 > <Target>.http: UDP, leng > > 0x0000: 0004 758f 1153 0050 046c e730 0800 4500 > > ..u..S.P.l.0..E. 0x0010: 0026 0000 0000 4011 aaa9 c0a8 0003 81ff > > .&....@......... 0x0020: 8d73 7530 0050 0008 ba3f 0102 0304 0506 > > .su0.P...?...... 0x0030: 7465 7374 test > > > > Looking at the ethernet header, we find: > > > > LIBNET_RAW4: Dest MAC: 00 20 e0 35 54 40 > > LIBNET_LINK: Dest MAC: 00 04 75 8F 11 53 > > > > Source MAC: 00 50 04 6C E7 30 > > > > Ethertype: 08 00 > > > > What I don't get is why LIBNET_RAW uses 00 20 e0 35 54 40. Because, in > > my test case, I hard-coded the target machine's mac addr - here's its > > output from ifconfig: > > > > eth0 Link encap:Ethernet HWaddr 00:04:75:8F:11:53 > > inet addr:<Target> Bcast:<TargetBcast> Mask:255.255.255.0 > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > RX packets:8662615 errors:0 dropped:0 overruns:1 frame:0 > > TX packets:1625176 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:1000 > > RX bytes:2317535814 (2210.1 Mb) TX bytes:996608893 (950.4 Mb) > > Interrupt:17 Base address:0xd400 > > > > So, in short, I'm confused. > > > > - Karen