Thank you all for the fantastic and helpful responses so far...



alex wrote:
> Hi,
>
> I am running the 4.2/i386 release.I can get hping to work on FreeBSD but
> not OpenBSD. On OpenBSD after building Hping from ports, I get this:
>
> [root@nas:~]# hping --icmp 172.16.0.100
> [open_pcap] pcap_open_live: : Device not configured
> [main] open_pcap failed
>
> Am I missing something here? I thought ports would have built any
> missing dependencies or patched accordingly to make it work.
>
> How do I fix this error?
>
> Thanks
> Alex

alex wrote:
>> I am running the 4.2/i386 release.I can get hping to work on FreeBSD but
>> not OpenBSD. On OpenBSD after building Hping from ports, I get this:
>> [root@nas:~]# hping --icmp 172.16.0.100
>> [open_pcap] pcap_open_live: : Device not configured
>> [main] open_pcap failed
>> Am I missing something here? I thought ports would have built any missing
>> dependencies or patched accordingly to make it work.
>> How do I fix this error?
> Thank you all for the fantastic and helpful responses so far...

Stop crying. If it helps, hping works fine here. Also, pcap is part of
OpenBSD so it is no dependency problem. I guess it is a network driver
problem (as long as you did not upgrade from a previous release and made any
mistakes). Your could also try to specify an interface manually by using -I.

But probably you should ask at ports@openbsd.org or mail the maintainer (see
Makefile).

Helmut

--
No Swen today, my love has gone away
My mailbox stands for lorn, a symbol of the dawn

Helmut Schneider wrote:
> Stop crying. If it helps, hping works fine here. Also, pcap is part of
> OpenBSD so it is no dependency problem. I guess it is a network driver
> problem (as long as you did not upgrade from a previous release and made
> any mistakes). Your could also try to specify an interface manually by
> using -I.
>
> But probably you should ask at ports@openbsd.org or mail the maintainer
> (see Makefile).
>
> Helmut
>

Thanks. I just more or less needed someone to say whether it works for
them, now that I know it works for you, the issue is on my end I guess.

Alex

Helmut Schneider wrote:
> Stop crying. If it helps, hping works fine here. Also, pcap is part of
> OpenBSD so it is no dependency problem. I guess it is a network driver
> problem (as long as you did not upgrade from a previous release and made
> any mistakes). Your could also try to specify an interface manually by
> using -I.
>
> But probably you should ask at ports@openbsd.org or mail the maintainer
> (see Makefile).
>
> Helmut
>

I am still having issues... I did upgrade from 4.1 to 4.2, but have
never used hping before so I cant confirm whether it worked previously.
I tried the older version (from ports) and the newer version. Same
results for both basically.

[root@nas:~]# uname -srmpv
OpenBSD 4.2 GENERIC#375 i386 Intel(R) Pentium(R) 4 CPU 3.00GHz
("GenuineIntel" 686-class)

[root@nas:~/hping3-20051105]# ./hping3 -D -V -I em1 --icmp 203.0.178.191
using em1, addr: , MTU: 0
DEBUG: pcap_open_live(em1, 99999, 0, 1, 0x3c00ec00)
DEBUG: dltype is 1
Unable to resolve ''

[root@nas:~/hping3-20051105]# hping -D -V -I em1 --icmp 203.0.178.191
using em1, addr: , MTU: 0
DEBUG: pcap_open_live(em1, 99999, 0, 1, 0x3c00be20)
DEBUG: dltype is 1
[resolve] Could not resolve address: Undefined error: 0

It seems to not be able to get information about the interface
specified.

It should read: using em1, addr: 220.239.IP.IP, MTU: 1500

[root@nas:~]# ifconfig

lo0: flags=8049 mtu 33208
groups: lo
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
em0: flags=8843 mtu 1500
lladdr 00:0e:0c:da:27:a1
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 172.16.0.254 netmask 0xffffff00 broadcast 172.16.0.255
inet6 fe80::20e:cff:feda:27a1%em0 prefixlen 64 scopeid 0x1
em1: flags=8843 mtu 1500
lladdr 00:0e:0c:da:27:56
groups: egress
media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
status: active
inet6 fe80::20e:cff:feda:2756%em1 prefixlen 64 scopeid 0x2
inet 220.239.IP.IP netmask 0xffffff00 broadcast 220.239.IP.255
sk0: flags=8843 mtu 1500
lladdr 00:0f:ea:40:af:fd
media: Ethernet autoselect (none)
status: no carrier
inet 172.16.10.254 netmask 0xffffff00 broadcast 172.16.10.255
inet6 fe80::20f:eaff:fe40:affd%sk0 prefixlen 64 scopeid 0x3
enc0: flags=0<> mtu 1536
pflog0: flags=141 mtu 33208
groups: pflog


Helmut, you confirm whether you can actually ping something with this
command?

Thanks Again, Alex.

alex wrote:
> Helmut Schneider wrote:
>> If it helps, hping works fine here. Also, pcap is part of
>> OpenBSD so it is no dependency problem. I guess it is a network driver
>> problem (as long as you did not upgrade from a previous release and made
>> any mistakes). Your could also try to specify an interface manually by
>> using -I.
>>
>> But probably you should ask at ports@openbsd.org or mail the maintainer
>> (see Makefile).
>
> I am still having issues... I did upgrade from 4.1 to 4.2, but have
> never used hping before so I cant confirm whether it worked previously.
> I tried the older version (from ports) and the newer version. Same
> results for both basically.
>
> [root@nas:~]# uname -srmpv
> OpenBSD 4.2 GENERIC#375 i386 Intel(R) Pentium(R) 4 CPU 3.00GHz
> ("GenuineIntel" 686-class)

Hi Alex,

again, works for me.

$ uname -srmpv
OpenBSD 4.2 GENERIC#8 i386 AMD Athlon(tm) XP 2000+ ("AuthenticAMD" 686-class, 256KB L2 cache)

> [root@nas:~/hping3-20051105]# ./hping3 -D -V -I em1 --icmp 203.0.178.191
> using em1, addr: , MTU: 0
> DEBUG: pcap_open_live(em1, 99999, 0, 1, 0x3c00ec00)
> DEBUG: dltype is 1
> Unable to resolve ''
>
> [root@nas:~/hping3-20051105]# hping -D -V -I em1 --icmp 203.0.178.191
> using em1, addr: , MTU: 0
> DEBUG: pcap_open_live(em1, 99999, 0, 1, 0x3c00be20)
> DEBUG: dltype is 1
> [resolve] Could not resolve address: Undefined error: 0

Collapsing repeated lines, I get:

$ sudo hping -D -V -I rl0 --icmp 203.0.178.191
DEBUG: if lo0: DEBUG: (struct DATA) DEBUG: LOOPBACK, SKIPPED
DEBUG: if lo0: DEBUG: (struct DATA is NULL) DEBUG: LOOPBACK, SKIPPED
DEBUG: if lo0: DEBUG: (struct DATA is NULL) DEBUG: LOOPBACK, SKIPPED
DEBUG: if lo0: DEBUG: (struct DATA is NULL) DEBUG: LOOPBACK, SKIPPED
DEBUG: if rl0: DEBUG: (struct DATA) DEBUG: AF_LINK
DEBUG: if rl0: DEBUG: (struct DATA is NULL) AF_INET OK
using rl0, addr: 192.168.14.2, MTU: 1500
DEBUG: pcap_open_live(rl0, 99999, 0, 1, 0x3c00be20)
DEBUG: dltype is 1
HPING 203.0.178.191 (rl0 203.0.178.191): icmp mode set, 28 headers + 0 data bytes
45 00 00 1C C3 98 00 00 40 01 00 00 C0 A8 0E 02 CB 00 B2 BF 08 00 94 BB 63 44 00 00
DEBUG: under pcap_recv()
DEBUG: under pcap_recv()
DEBUG: [pcap_recv] p = NULL
....
DEBUG: [pcap_recv] p = NULL
len=46 ip=203.0.178.191 ttl=44 id=45352 icmp_seq=0 rtt=328.4 ms
DEBUG: under pcap_recv()
DEBUG: [pcap_recv] p = NULL
....
DEBUG: [pcap_recv] p = NULL
45 00 00 1C C7 F1 00 00 40 01 00 00 C0 A8 0E 02 CB 00 B2 BF 08 00 93 BB 63 44 01 00
DEBUG: under pcap_recv()
DEBUG: [pcap_recv] p = NULL
....
DEBUG: [pcap_recv] p = NULL
len=46 ip=203.0.178.191 ttl=46 id=45361 icmp_seq=1 rtt=324.1 ms
DEBUG: under pcap_recv()
....
DEBUG: [pcap_recv] p = NULL
45 00 00 1C BF D6 00 00 40 01 00 00 C0 A8 0E 02 CB 00 B2 BF 08 00 92 BB 63 44 02 00
DEBUG: under pcap_recv()
DEBUG: [pcap_recv] p = NULL
....
DEBUG: [pcap_recv] p = NULL
len=46 ip=203.0.178.191 ttl=46 id=45371 icmp_seq=2 rtt=321.5 ms
DEBUG: under pcap_recv()
DEBUG: [pcap_recv] p = NULL
....
DEBUG: [pcap_recv] p = NULL
DEBUG: under pcap_recv()
DEBUG: [pcap_recv] p = NULL
DEBUG: under pcap_recv()
DEBUG: [pcap_recv] p = NULL
....
DEBUG: [pcap_recv] p = NULL
45 00 00 1C 12 57 00 00 40 01 00 00 C0 A8 0E 02 CB 00 B2 BF 08 00 91 BB 63 44 03 00
DEBUG: under pcap_recv()
DEBUG: [pcap_recv] p = NULL
....
DEBUG: [pcap_recv] p = NULL
len=46 ip=203.0.178.191 ttl=46 id=45377 icmp_seq=3 rtt=324.5 ms
DEBUG: under pcap_recv()
DEBUG: [pcap_recv] p = NULL
....

> It seems to not be able to get information about the interface
> specified.
>
> It should read: using em1, addr: 220.239.IP.IP, MTU: 1500
>
> [root@nas:~]# ifconfig
>
> lo0: flags=8049 mtu 33208
> groups: lo
> inet 127.0.0.1 netmask 0xff000000
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
> em0: flags=8843 mtu 1500
> lladdr 00:0e:0c:da:27:a1
> media: Ethernet autoselect (1000baseT full-duplex)
> status: active
> inet 172.16.0.254 netmask 0xffffff00 broadcast 172.16.0.255
> inet6 fe80::20e:cff:feda:27a1%em0 prefixlen 64 scopeid 0x1
> em1: flags=8843 mtu 1500
> lladdr 00:0e:0c:da:27:56
> groups: egress
> media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
> status: active
> inet6 fe80::20e:cff:feda:2756%em1 prefixlen 64 scopeid 0x2
> inet 220.239.IP.IP netmask 0xffffff00 broadcast 220.239.IP.255
> sk0: flags=8843 mtu 1500
> lladdr 00:0f:ea:40:af:fd
> media: Ethernet autoselect (none)
> status: no carrier
> inet 172.16.10.254 netmask 0xffffff00 broadcast 172.16.10.255
> inet6 fe80::20f:eaff:fe40:affd%sk0 prefixlen 64 scopeid 0x3
> enc0: flags=0<> mtu 1536
> pflog0: flags=141 mtu 33208
> groups: pflog

Helmut suggested it may be a driver problem. Could you test the
equivalent command with another interface (sk(4) would be a good choice,
and you don't appear to be using that interface)?

Joachim

Joachim Schipper wrote:
> Helmut suggested it may be a driver problem. Could you test the
> equivalent command with another interface (sk(4) would be a good choice,
> and you don't appear to be using that interface)?
>
> Joachim

Looks like both helmut and you were right. It seems something broke
during the 4.1 -> 4.2 upgrade. I backed up all my data and did a fresh
install of 4.2, the problem has just miraculously fixed itself. LOL.

I don't even need to use -I to force the interface anymore, it detects
which interface to use. I did try it on the other interface (sk0) before
I wiped everything, and got much the same result.

I guess I'll never know *exactly* what broke. But I am glad its fixed.

My thanks to you both :-)

Alex

alex wrote:
> Joachim Schipper wrote:
>> Helmut suggested it may be a driver problem. Could you test the
>> equivalent command with another interface (sk(4) would be a good choice,
>> and you don't appear to be using that interface)?
> Looks like both helmut and you were right. It seems something broke
> during the 4.1 -> 4.2 upgrade.

*How* did you upgrade?

--
No Swen today, my love has gone away
My mailbox stands for lorn, a symbol of the dawn

Helmut Schneider wrote:
> alex wrote:
>> Joachim Schipper wrote:
>>> Helmut suggested it may be a driver problem. Could you test the
>>> equivalent command with another interface (sk(4) would be a good choice,
>>> and you don't appear to be using that interface)?
>> Looks like both helmut and you were right. It seems something broke
>> during the 4.1 -> 4.2 upgrade.
>
> *How* did you upgrade?
>

I put the 4.2 cdrom in the drive, booted from it, chose upgrade. I let
it finish installing the new packages. after it was all done, I
restarted and everything appeared to be normal. I didnt touch /etc
though, and I think this is probably where I really screwed things up.

etc42.tgz wasnt installed during the upgrade process, I guess this is
something I was supposed to do manually (after backing up any personal
config?)