Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 14 Jul 2001 20:10:02 -0700 (PDT)
From:      Brian Somers <brian@Awfulhak.org>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: kern/28974: PPPoE software fails when SOCK_RAW employed 
Message-ID:  <200107150310.f6F3A2L24497@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/28974; it has been noted by GNATS.

From: Brian Somers <brian@Awfulhak.org>
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 
Date: Sun, 15 Jul 2001 04:01:56 +0100

 > >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) {
 
 

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107150310.f6F3A2L24497>