Bug 28974

Additional notes, the network card is an NE2000 compatible, RTL8029,
using the ed driver.

When initializing it with -arp up, and no IP, hping fails, whereas
assigning it an unroutable IP (11.1.10.1) causes hping to start working
properly. nmap is still unable to function.

Previous occasions have returned a send_tcp_raw error (permission
denied), which a few others have reported as well. I will submit
examples in another followup.

Brad

> >Number:         28974
> >Category:       kern
> >Synopsis:       PPPoE software fails when SOCK_RAW employed

Heh, I tried the hping port and found that it didn't work at all for 
me.  After looking at the sources, it seems that it's misparsing the 
results of the SIOCGIFCONF (patch attached), but after looking at the 
sources for a bit longer, I really think this port should be marked 
BROKEN -- see the rest of my rantings below.  I've cc'd the maintainer.

I've only looked at two functions.  The first is get_if_name() in 
getifname.c:

  o It mis parses the ifreq array returned from SIOCGIFCONF (see 
    patch below)

  o It's got a rather pessimistic idea that a machine will only 
    have up to 16 interface addresses -- unlikely in my experience.

  o It doesn't find the most appropriate interface, it just picks the 
    first one it finds that's UP.  This program doesn't look like it 
    works on machines with more than one interface.

  o It doesn't handle non-AF_INET addresses.

  o It hard-codes the MTU at 1500


The second function I looked at -- which prevents hping working for 
PPPoE is get_linkhdr_size() in getlhs.c.

This function is ridiculous.  Not only does it hard-code lots of 
interface names (leaving out tun*), but it even gets that wrong by 
using strstr().

roman, is there any chance of fixing this port -- or should I just 
mark it BROKEN ?

brad, it seems that when the above two functions are made to work 
(with a little hard-coding in my case), hpinging an address that's 
reached through the tun interface over a PPPoE link works.  I think 
you should raise several bug reports, one for each of the programs 
that you find doesn't work.  Let's leave this one as applying to 
hping.  Is that ok ?

Cheers.

-- 
Brian <brian@freebsd-services.com>                <brian@Awfulhak.org>
      http://www.freebsd-services.com/        <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour !      <brian@[uk.]OpenBSD.org>


--- getifname.c.orig	Thu Jul  6 18:06:10 2000
+++ getifname.c	Sun Jul 15 02:52:01 2001
@@ -52,7 +52,7 @@
 	ifrp = ibuf;
 	ifend = (struct ifreq*) ((char*)ibuf + ifc.ifc_len);
 
-	for (; ifrp < ifend; ifrp++) {
+	for (; ifrp < ifend; ifrp = (char *)&ifrp->ifr_addr + ifrp->ifr_addr.sa_len) {
 		strncpy(ifr.ifr_name, ifrp->ifr_name, sizeof(ifr.ifr_name));
 
 		if ( ioctl(fd, SIOCGIFFLAGS, (char*)&ifr) == -1) {

Hping is an example of the tool I used to further troubleshoot the
problem, not the problem itself; PPPoE is definitely broken, and has been
reported as such on several occasions, but in the wrong place.

The problem is that what I used as a diagnostic is itself flawed to the
point of not working with PPPoE based connections.

I would still like to further understand why programs such as nmap
are having such a difficult time working with a networking
implementation that should by all rights be transparent.

My only surmise to date is that since NetGraph is dealing with Raw
Sockets to encapsulate PPPoE, it is interfering with userspace programs'
ability to do same.

I am however glad to have been able to point out the problematic port,
being overproductive is a good thing. :)

Here is an example of the problem as related by another person. I've had
this identical issue, and have not yet corrected it:

http://groups.google.com/groups?hl=en&safe=off&ic=1&th=7866b9324b3e2b97,2&seekm=002e01c0b710%24d3306da0%242ac67fd8_blah2%40ns.sol.net#p

The surmise is misconfigured libcap, but this is nullified by the user's
claim that nmap functions over interfaces not covered by PPPoE, also my
experience.

Please continue to consider this a PPPoE issue, but let me know if you'd
like me to submit a PR regarding hping itself.

Thanks,
Brad

On Sun, 15 Jul 2001, Brian Somers wrote:

> brad, it seems that when the above two functions are made to work
> (with a little hard-coding in my case), hpinging an address that's
> reached through the tun interface over a PPPoE link works.  I think
> you should raise several bug reports, one for each of the programs
> that you find doesn't work.  Let's leave this one as applying to
> hping.  Is that ok ?
>
> Cheers.
>
> --
> Brian <brian@freebsd-services.com>                <brian@Awfulhak.org>
>       http://www.freebsd-services.com/        <brian@[uk.]FreeBSD.org>
> Don't _EVER_ lose your sense of humour !      <brian@[uk.]OpenBSD.org>
>
>
> --- getifname.c.orig	Thu Jul  6 18:06:10 2000
> +++ getifname.c	Sun Jul 15 02:52:01 2001
> @@ -52,7 +52,7 @@
>  	ifrp = ibuf;
>  	ifend = (struct ifreq*) ((char*)ibuf + ifc.ifc_len);
>
> -	for (; ifrp < ifend; ifrp++) {
> +	for (; ifrp < ifend; ifrp = (char *)&ifrp->ifr_addr + ifrp->ifr_addr.sa_len) {
>  		strncpy(ifr.ifr_name, ifrp->ifr_name, sizeof(ifr.ifr_name));
>
>  		if ( ioctl(fd, SIOCGIFFLAGS, (char*)&ifr) == -1) {
>
>
>

Hi,

I've marked hping as BROKEN for the time being as email addressed to 
the maintainer bounces.

I'm not (yet) convinced that this is a PPPoE problem, but I'm willing 
to be proven wrong.  It's possible that nmap doesn't work with 
POINT2POINT interfaces but does with broadcast interfaces.  I'll have 
a look at installing nmap myself in the near future and follow up.

Cheers.

> Hping is an example of the tool I used to further troubleshoot the
> problem, not the problem itself; PPPoE is definitely broken, and has been
> reported as such on several occasions, but in the wrong place.
> 
> The problem is that what I used as a diagnostic is itself flawed to the
> point of not working with PPPoE based connections.
> 
> I would still like to further understand why programs such as nmap
> are having such a difficult time working with a networking
> implementation that should by all rights be transparent.
> 
> My only surmise to date is that since NetGraph is dealing with Raw
> Sockets to encapsulate PPPoE, it is interfering with userspace programs'
> ability to do same.
> 
> I am however glad to have been able to point out the problematic port,
> being overproductive is a good thing. :)
> 
> Here is an example of the problem as related by another person. I've had
> this identical issue, and have not yet corrected it:
> 
> http://groups.google.com/groups?hl=en&safe=off&ic=1&th=7866b9324b3e2b97,2&seekm=002e01c0b710%24d3306da0%242ac67fd8_blah2%40ns.sol.net#p
> 
> The surmise is misconfigured libcap, but this is nullified by the user's
> claim that nmap functions over interfaces not covered by PPPoE, also my
> experience.
> 
> Please continue to consider this a PPPoE issue, but let me know if you'd
> like me to submit a PR regarding hping itself.
> 
> Thanks,
> Brad

-- 
Brian <brian@freebsd-services.com>                <brian@Awfulhak.org>
      http://www.freebsd-services.com/        <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour !      <brian@[uk.]OpenBSD.org>

On Sun, 15 Jul 2001, Brian Somers wrote:

> Hi,
>
> I've marked hping as BROKEN for the time being as email addressed to
> the maintainer bounces.

How come it bounces? I got _this_ mail, perhaps the other one was sent to
the wrong address?

So, what seems to be the problem?

--Roman Shterenzon, UNIX System Administrator and Consultant
[ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ]

> On Sun, 15 Jul 2001, Brian Somers wrote:
> 
> > Hi,
> >
> > I've marked hping as BROKEN for the time being as email addressed to
> > the maintainer bounces.
> 
> How come it bounces? I got _this_ mail, perhaps the other one was sent to
> the wrong address?
> 
> So, what seems to be the problem?

Hi,

I got this back from your mailer.  I'm happy to reverse my (maybe a 
bit hasty) BROKEN addition if you've got a compelling argument :)

: This message was created automatically by mail delivery software (Exim).
: 
: A message that you sent could not be delivered to one or more of its
: recipients. This is a permanent error. The following address(es) failed:
; 
:   roman@jamus.xpert.com
:     (generated from roman@xpert.com)
:     SMTP error from remote mailer after RCPT TO:<roman@jamus.xpert.com>:
:     host jamus.xpert.com [199.203.132.17]: 550-MAIL BLOCKED; See http://www.e-scrub.com/orbs/
:     550 mail from 199.203.132.1 rejected: administrative prohibition
: 
: ------ This is a copy of the message, including all the headers. ------
: 
: Return-path: <brian@Awfulhak.org>
: Received: from gw.awfulhak.org
: 	([217.204.245.18] helo=Awfulhak.org ident=root)
: 	by void.xpert.com with esmtp (Exim 3.20 #1)
: 	id 15LbAZ-0006wV-00
: 	for roman@xpert.com; Sun, 15 Jul 2001 04:58:04 +0300
: Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12])
: 	by Awfulhak.org (8.11.4/8.11.4) with ESMTP id f6F2xtY28153;
: 	Sun, 15 Jul 2001 03:59:57 +0100 (BST)
: 	(envelope-from brian@lan.Awfulhak.org)
: Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1])
: 	by hak.lan.Awfulhak.org (8.11.4/8.11.4) with ESMTP id f6F31vm91086;
: 	Sun, 15 Jul 2001 04:01:57 +0100 (BST)
: 	(envelope-from brian@hak.lan.Awfulhak.org)
: Message-Id: <200107150301.f6F31vm91086@hak.lan.Awfulhak.org>
: X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4
: To: brad@brad-x.com
: cc: FreeBSD-gnats-submit@FreeBSD.ORG, brian@Awfulhak.org, roman@xpert.com
: Subject: Re: kern/28974: PPPoE software fails when SOCK_RAW employed 
: In-Reply-To: Message from brad@brad-x.com 
:    of "Sat, 14 Jul 2001 16:52:50 EDT." <20010714205250.30F567B1D4@TMA-1.brad-x.com> 
: Mime-Version: 1.0
: Content-Type: text/plain; charset=us-ascii
: Date: Sun, 15 Jul 2001 04:01:56 +0100
: From: Brian Somers <brian@Awfulhak.org>
: 
: > >Number:         28974
: > >Category:       kern
: > >Synopsis:       PPPoE software fails when SOCK_RAW employed
: 
: Heh, I tried the hping port and found that it didn't work at all for 
: me.  After looking at the sources, it seems that it's misparsing the 
: results of the SIOCGIFCONF (patch attached), but after looking at the 
: sources for a bit longer, I really think this port should be marked 
: BROKEN -- see the rest of my rantings below.  I've cc'd the maintainer.
: 
: I've only looked at two functions.  The first is get_if_name() in 
: getifname.c:
: 
:   o It mis parses the ifreq array returned from SIOCGIFCONF (see 
:     patch below)
: 
:   o It's got a rather pessimistic idea that a machine will only 
:     have up to 16 interface addresses -- unlikely in my experience.
: 
:   o It doesn't find the most appropriate interface, it just picks the 
:     first one it finds that's UP.  This program doesn't look like it 
:     works on machines with more than one interface.
: 
:   o It doesn't handle non-AF_INET addresses.
: 
:   o It hard-codes the MTU at 1500
: 
: 
: The second function I looked at -- which prevents hping working for 
: PPPoE is get_linkhdr_size() in getlhs.c.
: 
: This function is ridiculous.  Not only does it hard-code lots of 
: interface names (leaving out tun*), but it even gets that wrong by 
: using strstr().
: 
: roman, is there any chance of fixing this port -- or should I just 
: mark it BROKEN ?
: 
: brad, it seems that when the above two functions are made to work 
: (with a little hard-coding in my case), hpinging an address that's 
: reached through the tun interface over a PPPoE link works.  I think 
: you should raise several bug reports, one for each of the programs 
: that you find doesn't work.  Let's leave this one as applying to 
: hping.  Is that ok ?
: 
: Cheers.
: 
: -- 
: Brian <brian@freebsd-services.com>                <brian@Awfulhak.org>
:       http://www.freebsd-services.com/        <brian@[uk.]FreeBSD.org>
: Don't _EVER_ lose your sense of humour !      <brian@[uk.]OpenBSD.org>
: 
: 
: --- getifname.c.orig	Thu Jul  6 18:06:10 2000
: +++ getifname.c	Sun Jul 15 02:52:01 2001
: @@ -52,7 +52,7 @@
:  	ifrp = ibuf;
:  	ifend = (struct ifreq*) ((char*)ibuf + ifc.ifc_len);
:  
: -	for (; ifrp < ifend; ifrp++) {
: +	for (; ifrp < ifend; ifrp = (char *)&ifrp->ifr_addr + ifrp->ifr_addr.sa_len) {
:  		strncpy(ifr.ifr_name, ifrp->ifr_name, sizeof(ifr.ifr_name));
:  
:  		if ( ioctl(fd, SIOCGIFFLAGS, (char*)&ifr) == -1) {
: 
: 

> --Roman Shterenzon, UNIX System Administrator and Consultant
> [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ]

-- 
Brian <brian@freebsd-services.com>                <brian@Awfulhak.org>
      http://www.freebsd-services.com/        <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour !      <brian@[uk.]OpenBSD.org>

err.. yes, I was aware of the fundamental iface brokenness of this
program. I produced some workarounds, but the real solution is to rewrite
some parts of it. I'll send it to the author, perhaps he'll fix it.

On Sun, 15 Jul 2001, Brian Somers wrote:

> > On Sun, 15 Jul 2001, Brian Somers wrote:
> >
> > > Hi,
> > >
> > > I've marked hping as BROKEN for the time being as email addressed to
> > > the maintainer bounces.
> >
> > How come it bounces? I got _this_ mail, perhaps the other one was sent to
> > the wrong address?
> >
> > So, what seems to be the problem?
>
> Hi,
>
> I got this back from your mailer.  I'm happy to reverse my (maybe a
> bit hasty) BROKEN addition if you've got a compelling argument :)
>
> : This message was created automatically by mail delivery software (Exim).
> :
> : A message that you sent could not be delivered to one or more of its
> : recipients. This is a permanent error. The following address(es) failed:
> ;
> :   roman@jamus.xpert.com
> :     (generated from roman@xpert.com)
> :     SMTP error from remote mailer after RCPT TO:<roman@jamus.xpert.com>:
> :     host jamus.xpert.com [199.203.132.17]: 550-MAIL BLOCKED; See http://www.e-scrub.com/orbs/
> :     550 mail from 199.203.132.1 rejected: administrative prohibition
> :
> : ------ This is a copy of the message, including all the headers. ------
> :
> : Return-path: <brian@Awfulhak.org>
> : Received: from gw.awfulhak.org
> : 	([217.204.245.18] helo=Awfulhak.org ident=root)
> : 	by void.xpert.com with esmtp (Exim 3.20 #1)
> : 	id 15LbAZ-0006wV-00
> : 	for roman@xpert.com; Sun, 15 Jul 2001 04:58:04 +0300
> : Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12])
> : 	by Awfulhak.org (8.11.4/8.11.4) with ESMTP id f6F2xtY28153;
> : 	Sun, 15 Jul 2001 03:59:57 +0100 (BST)
> : 	(envelope-from brian@lan.Awfulhak.org)
> : Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1])
> : 	by hak.lan.Awfulhak.org (8.11.4/8.11.4) with ESMTP id f6F31vm91086;
> : 	Sun, 15 Jul 2001 04:01:57 +0100 (BST)
> : 	(envelope-from brian@hak.lan.Awfulhak.org)
> : Message-Id: <200107150301.f6F31vm91086@hak.lan.Awfulhak.org>
> : X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4
> : To: brad@brad-x.com
> : cc: FreeBSD-gnats-submit@FreeBSD.ORG, brian@Awfulhak.org, roman@xpert.com
> : Subject: Re: kern/28974: PPPoE software fails when SOCK_RAW employed
> : In-Reply-To: Message from brad@brad-x.com
> :    of "Sat, 14 Jul 2001 16:52:50 EDT." <20010714205250.30F567B1D4@TMA-1.brad-x.com>
> : Mime-Version: 1.0
> : Content-Type: text/plain; charset=us-ascii
> : Date: Sun, 15 Jul 2001 04:01:56 +0100
> : From: Brian Somers <brian@Awfulhak.org>
> :
> : > >Number:         28974
> : > >Category:       kern
> : > >Synopsis:       PPPoE software fails when SOCK_RAW employed
> :
> : Heh, I tried the hping port and found that it didn't work at all for
> : me.  After looking at the sources, it seems that it's misparsing the
> : results of the SIOCGIFCONF (patch attached), but after looking at the
> : sources for a bit longer, I really think this port should be marked
> : BROKEN -- see the rest of my rantings below.  I've cc'd the maintainer.
> :
> : I've only looked at two functions.  The first is get_if_name() in
> : getifname.c:
> :
> :   o It mis parses the ifreq array returned from SIOCGIFCONF (see
> :     patch below)
> :
> :   o It's got a rather pessimistic idea that a machine will only
> :     have up to 16 interface addresses -- unlikely in my experience.
> :
> :   o It doesn't find the most appropriate interface, it just picks the
> :     first one it finds that's UP.  This program doesn't look like it
> :     works on machines with more than one interface.
> :
> :   o It doesn't handle non-AF_INET addresses.
> :
> :   o It hard-codes the MTU at 1500
> :
> :
> : The second function I looked at -- which prevents hping working for
> : PPPoE is get_linkhdr_size() in getlhs.c.
> :
> : This function is ridiculous.  Not only does it hard-code lots of
> : interface names (leaving out tun*), but it even gets that wrong by
> : using strstr().
> :
> : roman, is there any chance of fixing this port -- or should I just
> : mark it BROKEN ?
> :
> : brad, it seems that when the above two functions are made to work
> : (with a little hard-coding in my case), hpinging an address that's
> : reached through the tun interface over a PPPoE link works.  I think
> : you should raise several bug reports, one for each of the programs
> : that you find doesn't work.  Let's leave this one as applying to
> : hping.  Is that ok ?
> :
> : Cheers.
> :
> : --
> : Brian <brian@freebsd-services.com>                <brian@Awfulhak.org>
> :       http://www.freebsd-services.com/        <brian@[uk.]FreeBSD.org>
> : Don't _EVER_ lose your sense of humour !      <brian@[uk.]OpenBSD.org>
> :
> :
> : --- getifname.c.orig	Thu Jul  6 18:06:10 2000
> : +++ getifname.c	Sun Jul 15 02:52:01 2001
> : @@ -52,7 +52,7 @@
> :  	ifrp = ibuf;
> :  	ifend = (struct ifreq*) ((char*)ibuf + ifc.ifc_len);
> :
> : -	for (; ifrp < ifend; ifrp++) {
> : +	for (; ifrp < ifend; ifrp = (char *)&ifrp->ifr_addr + ifrp->ifr_addr.sa_len) {
> :  		strncpy(ifr.ifr_name, ifrp->ifr_name, sizeof(ifr.ifr_name));
> :
> :  		if ( ioctl(fd, SIOCGIFFLAGS, (char*)&ifr) == -1) {
> :
> :
>
> > --Roman Shterenzon, UNIX System Administrator and Consultant
> > [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ]
>
> --
> Brian <brian@freebsd-services.com>                <brian@Awfulhak.org>
>       http://www.freebsd-services.com/        <brian@[uk.]FreeBSD.org>
> Don't _EVER_ lose your sense of humour !      <brian@[uk.]OpenBSD.org>
>
>
>

--Roman Shterenzon, UNIX System Administrator and Consultant
[ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ]

Hi,

I've installed nmap here and it seems to work ok.  I have the 
following relevant interfaces:

wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 217.204.245.19 netmask 0xfffffff0 broadcast 217.204.245.31
        [.....]
tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1490
        inet 172.16.0.12 --> 172.16.0.1 netmask 0xffff0000 

and the following relevant routes:

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            217.204.245.17     UGSc        5       59    wi0
[.....]
172.16/24          172.16.0.1         UGSc        4        0   tun1
172.16.0.1         172.16.0.12        UH          8     3307   tun1

tun1 is a PPPoE tunnel into my LAN (the wireless gateway is outside 
my firewall).  It uses the wi0 interface as a transport.

I can run nmap on 172.16.0.1 and any of the 172.16.0.* machines in
side my LAN, as well as being able to run it on outside machines 
(which aren't going through the tunnel).

I'm running -current though - maybe that's the important difference ?

> Hping is an example of the tool I used to further troubleshoot the
> problem, not the problem itself; PPPoE is definitely broken, and has been
> reported as such on several occasions, but in the wrong place.
> 
> The problem is that what I used as a diagnostic is itself flawed to the
> point of not working with PPPoE based connections.
> 
> I would still like to further understand why programs such as nmap
> are having such a difficult time working with a networking
> implementation that should by all rights be transparent.
> 
> My only surmise to date is that since NetGraph is dealing with Raw
> Sockets to encapsulate PPPoE, it is interfering with userspace programs'
> ability to do same.
> 
> I am however glad to have been able to point out the problematic port,
> being overproductive is a good thing. :)
> 
> Here is an example of the problem as related by another person. I've had
> this identical issue, and have not yet corrected it:
> 
> http://groups.google.com/groups?hl=en&safe=off&ic=1&th=7866b9324b3e2b97,2&seekm=002e01c0b710%24d3306da0%242ac67fd8_blah2%40ns.sol.net#p
> 
> The surmise is misconfigured libcap, but this is nullified by the user's
> claim that nmap functions over interfaces not covered by PPPoE, also my
> experience.
> 
> Please continue to consider this a PPPoE issue, but let me know if you'd
> like me to submit a PR regarding hping itself.
> 
> Thanks,
> Brad
[.....]

-- 
Brian <brian@freebsd-services.com>                <brian@Awfulhak.org>
      http://www.freebsd-services.com/        <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour !      <brian@[uk.]OpenBSD.org>

Hmm..

If the difference is indeed the version of FreeBSD used, that definitely
does point to an issue with the system, and not with nmap itself.

The curiosity is this; nmap 'hostname of PPPoE IP' will stall out and say
host is down, but nmap -P0 'PPPoE IP' works. Oddly, simply nmap 'PPPoE IP'
stalls out as well.

I don't know what to make of it, all I know is that with each subsequent
CVS, I am having more and more network problems on a system I can't afford
to have degenerate. :(

Brad

On Sun, 15 Jul 2001, Brian Somers wrote:

> Hi,
>
> I've installed nmap here and it seems to work ok.  I have the
> following relevant interfaces:
>
> wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         inet 217.204.245.19 netmask 0xfffffff0 broadcast 217.204.245.31
>         [.....]
> tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1490
>         inet 172.16.0.12 --> 172.16.0.1 netmask 0xffff0000
>
> and the following relevant routes:
>
> Internet:
> Destination        Gateway            Flags    Refs      Use  Netif Expire
> default            217.204.245.17     UGSc        5       59    wi0
> [.....]
> 172.16/24          172.16.0.1         UGSc        4        0   tun1
> 172.16.0.1         172.16.0.12        UH          8     3307   tun1
>
> tun1 is a PPPoE tunnel into my LAN (the wireless gateway is outside
> my firewall).  It uses the wi0 interface as a transport.
>
> I can run nmap on 172.16.0.1 and any of the 172.16.0.* machines in
> side my LAN, as well as being able to run it on outside machines
> (which aren't going through the tunnel).
>
> I'm running -current though - maybe that's the important difference ?
>
> > Hping is an example of the tool I used to further troubleshoot the
> > problem, not the problem itself; PPPoE is definitely broken, and has been
> > reported as such on several occasions, but in the wrong place.
> >
> > The problem is that what I used as a diagnostic is itself flawed to the
> > point of not working with PPPoE based connections.
> >
> > I would still like to further understand why programs such as nmap
> > are having such a difficult time working with a networking
> > implementation that should by all rights be transparent.
> >
> > My only surmise to date is that since NetGraph is dealing with Raw
> > Sockets to encapsulate PPPoE, it is interfering with userspace programs'
> > ability to do same.
> >
> > I am however glad to have been able to point out the problematic port,
> > being overproductive is a good thing. :)
> >
> > Here is an example of the problem as related by another person. I've had
> > this identical issue, and have not yet corrected it:
> >
> > http://groups.google.com/groups?hl=en&safe=off&ic=1&th=7866b9324b3e2b97,2&seekm=002e01c0b710%24d3306da0%242ac67fd8_blah2%40ns.sol.net#p
> >
> > The surmise is misconfigured libcap, but this is nullified by the user's
> > claim that nmap functions over interfaces not covered by PPPoE, also my
> > experience.
> >
> > Please continue to consider this a PPPoE issue, but let me know if you'd
> > like me to submit a PR regarding hping itself.
> >
> > Thanks,
> > Brad
> [.....]
>
> --
> Brian <brian@freebsd-services.com>                <brian@Awfulhak.org>
>       http://www.freebsd-services.com/        <brian@[uk.]FreeBSD.org>
> Don't _EVER_ lose your sense of humour !      <brian@[uk.]OpenBSD.org>
>
>
>

Comment 10 Doug White 2002-07-01 23:44:36 UTC

State Changed
From-To: open->closed

Close requested by submitter -- impasse and system has moved on since.