Code working with LIBNET_RAW4, not with LIBNET_LINK

[Karen Pease]

I've just discovered libnet, and have been working on some test programs to
become familiar with it; it looks great. I've worked my way through a number
of stumbling blocks, and have gotten most of what I have attempted to do
working; however, I cannot figure out, nor can find anything online about
this current problem.

I have two versions of the same code; one builds a packet with a UDP header
and an IP header on LIBNET_RAW4 mode; the other builds a packet with a UDP
header, an IP header, and the underlying ethernet header on LIBNET_LINK mode.
tcpdump -w shows the output on the wire of the two commands as being
identical; however, only the RAW4 version makes it to its destination.
Here's a snippet from two tcpdump runs:

Without link:
00004CA0 0C 3A EB 41 E3 40 0B 00 34 00 00 00 34 00 00
00 .:***@..4...4...
00004CB0 00 20 E0 35 54 40 00 50 04 6C E7 30 08 00 45
00 . ***@.P.l.0..E.
00004CC0 00 26 00 F2 00 00 40 11 A9 B7 C0 A8 00 03 81
FF .&***@.........
00004CD0 8D 73 75 30 00 50 00 08 BA 3F 01 02 03 04 05
06 .su0.P...?......
00004CE0 74 65 73 74

With link:
00004B50 40 3A EB 41 E1 A5 0E 00 34 00 00 00 34 00 00 00
@:.A....4...4...
00004B60 00 20 E0 35 54 40 00 50 04 6C E7 30 08 00 45
00 . ***@.P.l.0..E.
00004B70 00 26 00 F2 00 00 40 11 A9 B7 C0 A8 00 03 81
FF .&***@.........
00004B80 8D 73 75 30 00 50 00 08 BA 3F 01 02 03 04 05
06 .su0.P...?......
00004B90 74 65 73 74

**Unknown header**:

Byte 0 is different
Bytes 1 through 3 are the same
Bytes 4 through 6 are different
Bytes 7 through 15 are the same

**Ethernet header**:

dhost: 00 20 E0 35 54 40
shost: 00 50 04 6C E7 30
type: 08 00

**IP header**:

version: 4
ihl: 5
tos: 00
tot_len: 00 26
id: 00 F2
frag_off: 00 00
ttl: 40
proto: 11
check: A9 B7
saddr: C0 A8 00 03
daddr: 81 FF 8D 73

**UDP header**:

Proper source: 75 30
Proper dest: 00 50
Proper length: 00 08
Proper check: BA 3F

**Data**:

Proper data: 01 02 03 04 05 06 74 65 73 74

There is one header that I'm not sure what it is, and what it's for; the only
differences between the RAW and LINK versions are in these 15 bytes of data.
Also, I don't know for certain that this data is a header; it could equally
well be at the end of the packets, as the output runs end on end.

Does anyone have any clue what's wrong, and what's going on here? I'd be very
appreciative. :)

- Karen Pease

[Aaron Turner]

Well without any code, all I can say is you're doing something wrong.
First, it doesn't look like that you used the -e or -XX/-xx flag with
tcpdump to print the ethernet header to know where the packets are
actually going to. However, I can make a guess:

LIBNET_RAW4 will cause an ARP request to be made on your behalf to look
up the destination MAC address. The ethernet header of the built
packet will then go to the correct address.

LIBNET_LINK does NOT do an ARP request and expects you to provide the
dst MAC. I'd guess that you put in the wrong dst MAC and hence it
isn't delivered to the target host.

If you have other questions, you might want to check in the "samples"
directory for how to build packets with the LIBNET_LINK API.
--
Aaron Turner <aturner at pobox.com|synfin.net> http://synfin.net/
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Benjamin Franklin
All emails are PGP signed; a lack of a signature indicates a forgery.

Post by Karen Pease
I've just discovered libnet, and have been working on some test programs to
become familiar with it; it looks great. I've worked my way through a number
of stumbling blocks, and have gotten most of what I have attempted to do
working; however, I cannot figure out, nor can find anything online about
this current problem.
I have two versions of the same code; one builds a packet with a UDP header
and an IP header on LIBNET_RAW4 mode; the other builds a packet with a UDP
header, an IP header, and the underlying ethernet header on
LIBNET_LINK mode.
tcpdump -w shows the output on the wire of the two commands as being
identical; however, only the RAW4 version makes it to its destination.
00004CA0 0C 3A EB 41 E3 40 0B 00 34 00 00 00 34 00 00
00004CB0 00 20 E0 35 54 40 00 50 04 6C E7 30 08 00 45
00004CC0 00 26 00 F2 00 00 40 11 A9 B7 C0 A8 00 03 81
00004CD0 8D 73 75 30 00 50 00 08 BA 3F 01 02 03 04 05
06 .su0.P...?......
00004CE0 74 65 73 74
00004B50 40 3A EB 41 E1 A5 0E 00 34 00 00 00 34 00 00 00
@:.A....4...4...
00004B60 00 20 E0 35 54 40 00 50 04 6C E7 30 08 00 45
00004B70 00 26 00 F2 00 00 40 11 A9 B7 C0 A8 00 03 81
00004B80 8D 73 75 30 00 50 00 08 BA 3F 01 02 03 04 05
06 .su0.P...?......
00004B90 74 65 73 74
Byte 0 is different
Bytes 1 through 3 are the same
Bytes 4 through 6 are different
Bytes 7 through 15 are the same
dhost: 00 20 E0 35 54 40
shost: 00 50 04 6C E7 30
type: 08 00
version: 4
ihl: 5
tos: 00
tot_len: 00 26
id: 00 F2
frag_off: 00 00
ttl: 40
proto: 11
check: A9 B7
saddr: C0 A8 00 03
daddr: 81 FF 8D 73
Proper source: 75 30
Proper dest: 00 50
Proper length: 00 08
Proper check: BA 3F
Proper data: 01 02 03 04 05 06 74 65 73 74
There is one header that I'm not sure what it is, and what it's for; the only
differences between the RAW and LINK versions are in these 15 bytes of data.
Also, I don't know for certain that this data is a header; it could equally
well be at the end of the packets, as the output runs end on end.
Does anyone have any clue what's wrong, and what's going on here? I'd be very
appreciative. :)
- Karen Pease

[Karen Pease]

Thank you for your help. First off, there are no samples that I could find -
there were none included with the libnet on my system (installed from a FC3
rpm), nor could I find any via google. Where are they located? I relied on
reading other people's code that was written with libnet, but it was often
not applicable and I had to experiment around.

Using the tcpdump arguments that you recommended, I was able to see that you
were right - the dest hw address was in fact incorrect, and this is
undoubtedly the problem. I was passing it the hw address reported on the
destination machine by ifconfig for my tests using LIBNET_LINK; however, some
other, unknown hw address was being sent when they were built with
LIBNET_RAW4, which was making it to the destination. Is there a simple
function to look up the MAC address, or will I need to build and send the ARP
packets myself? I suppose it's in the samples.

Again, thank you for your help; it is greatly appreciated.

- Karen

Post by Aaron Turner
Well without any code, all I can say is you're doing something wrong.
First, it doesn't look like that you used the -e or -XX/-xx flag with
tcpdump to print the ethernet header to know where the packets are
LIBNET_RAW4 will cause an ARP request to be made on your behalf to look
up the destination MAC address. The ethernet header of the built
packet will then go to the correct address.
LIBNET_LINK does NOT do an ARP request and expects you to provide the
dst MAC. I'd guess that you put in the wrong dst MAC and hence it
isn't delivered to the target host.
If you have other questions, you might want to check in the "samples"
directory for how to build packets with the LIBNET_LINK API.

[Aaron Turner]

Post by Karen Pease
Thank you for your help. First off, there are no samples that I could find -
there were none included with the libnet on my system (installed from a FC3
rpm), nor could I find any via google. Where are they located? I relied on
reading other people's code that was written with libnet, but it was often
not applicable and I had to experiment around.

Sample code is shipped with the libnet source code.
http://www.packetfactory.net/libnet

Post by Karen Pease
Using the tcpdump arguments that you recommended, I was able to see that you
were right - the dest hw address was in fact incorrect, and this is
undoubtedly the problem. I was passing it the hw address reported on the
destination machine by ifconfig for my tests using LIBNET_LINK; however, some
other, unknown hw address was being sent when they were built with
LIBNET_RAW4, which was making it to the destination. Is there a simple
function to look up the MAC address, or will I need to build and send the ARP
packets myself? I suppose it's in the samples.

How are you building the ethernet header? But yeah, there are LINK
examples shipped with the source.

-Aaron

[Mike Schiffman]

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.

Post by Karen Pease
Thank you for your help. First off, there are no samples that I could find -
there were none included with the libnet on my system (installed from a FC3
rpm), nor could I find any via google. Where are they located? I relied on
reading other people's code that was written with libnet, but it was often
not applicable and I had to experiment around.
Using the tcpdump arguments that you recommended, I was able to see that you
were right - the dest hw address was in fact incorrect, and this is
undoubtedly the problem. I was passing it the hw address reported on the
destination machine by ifconfig for my tests using LIBNET_LINK; however, some
other, unknown hw address was being sent when they were built with
LIBNET_RAW4, which was making it to the destination. Is there a simple
function to look up the MAC address, or will I need to build and send the ARP
packets myself? I suppose it's in the samples.
Again, thank you for your help; it is greatly appreciated.
- Karen

Post by Aaron Turner
Well without any code, all I can say is you're doing something wrong.
First, it doesn't look like that you used the -e or -XX/-xx flag with
tcpdump to print the ethernet header to know where the packets are
LIBNET_RAW4 will cause an ARP request to be made on your behalf to look
up the destination MAC address. The ethernet header of the built
packet will then go to the correct address.
LIBNET_LINK does NOT do an ARP request and expects you to provide the
dst MAC. I'd guess that you put in the wrong dst MAC and hence it
isn't delivered to the target host.
If you have other questions, you might want to check in the "samples"
directory for how to build packets with the LIBNET_LINK API.

--
Mike Schiffman, CISSP
http://www.packetfactory.net/schiffman
Doveryay No Proveryay

[Mike Schiffman]

Dump the relevant code to the list.

PS: Why would you expect to see bi-directional IP traffic from <Source>
to <Target> using udp2.c or tcp1.c? As you noted, they're using
non-legit MAC addresses. In fact, assuming your host OS allows you to
spoof the source MAC address, you should only see the outgoing UDP and
TCP packets, with no response from <Target>. If you want to try an
experiment, go ahead and replace the hardcoded enet_src and enet_dst
with the proper MAC addresses of the machines in question.

PPS: If you want sample code of dynamic MAC address assignment, check
out Firewalk 5.0 (http://www.packetfactory.net/projects/firewalk).

Post by Mike Schiffman
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
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,
tcpdump: listening on eth0
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)
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
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
00:31:45.778733 IP <Source>.30000 > <Target>.http: UDP, leng
0x0000: 0020 e035 5440 0050 046c e730 0800 4500
0x0010: 0026 8d68 0000 4011 1d41 c0a8 0003 81ff
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
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
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

--
Mike Schiffman, CISSP
http://www.packetfactory.net/schiffman
Doveryay No Proveryay

[Karen Pease]

I'm not expecting bidirectional traffic; what made you think that? I started
tcpdump on the target machine, as I stated below. All I want is for the
packet to get there.

Thanks for the recommended code - the it uses libnet_autobuild_ethernet, which
appears to be new as of 1.1, apparently. That the only thing in the doc
directory about it is a reference to its existence in the MIGRATION file, but
I was able to figure it out - it's a pretty simple function. And it works -
packets are making it to their destination now. Thanks, everyone!

- Karen

Post by Mike Schiffman
Dump the relevant code to the list.
PS: Why would you expect to see bi-directional IP traffic from <Source>
to <Target> using udp2.c or tcp1.c? As you noted, they're using
non-legit MAC addresses. In fact, assuming your host OS allows you to
spoof the source MAC address, you should only see the outgoing UDP and
TCP packets, with no response from <Target>. If you want to try an
experiment, go ahead and replace the hardcoded enet_src and enet_dst
with the proper MAC addresses of the machines in question.
PPS: If you want sample code of dynamic MAC address assignment, check
out Firewalk 5.0 (http://www.packetfactory.net/projects/firewalk).

Post by Karen Pease

Post by Mike Schiffman
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
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,
tcpdump: listening on eth0
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)
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
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
00:31:45.778733 IP <Source>.30000 > <Target>.http: UDP, leng
0x0000: 0020 e035 5440 0050 046c e730 0800 4500
0x0010: 0026 8d68 0000 4011 1d41 c0a8 0003 81ff
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
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
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

--
Mike Schiffman, CISSP
http://www.packetfactory.net/schiffman
Doveryay No Proveryay

[Karen Pease]

Post by Mike Schiffman
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:

[***@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 ***@.P.l.0..E.
0x0010: 0026 8d68 0000 4011 1d41 c0a8 0003 81ff .&***@..A......
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

[Manu Garg]

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

Post by Karen Pease

Post by Mike Schiffman
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
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,
tcpdump: listening on eth0
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)
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
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
00:31:45.778733 IP <Source>.30000 > <Target>.http: UDP, leng
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.
0x0020: 8d73 7530 0050 0008 ba3f 0102 0304 0506 .su0.P...?......
0x0030: 7465 7374 test
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
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

[Karen Pease]

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

Post by Manu Garg
Karen,
It seems that there is a router between the machines that you are
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

Post by Mike Schiffman
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
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
tcpdump: listening on eth0
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)
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
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
00:31:45.778733 IP <Source>.30000 > <Target>.http: UDP, leng
0x0000: 0020 e035 5440 0050 046c e730 0800 4500
.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
.su0.P...?...... 0x0030: 7465 7374 test
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
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