John Klos | 1 Jun 2008 23:41

Can't use gif in -current

Hi,

Does anyone know what's changed which might've broken gif in -current? 
After switching from NetBSD-4 to current, I get this:

ifconfig gif0 inet6 2610:1f8::1:10:d86 2610:1f8::1:10:d85 prefixlen 128
ifconfig: SIOCAIFADDR_IN6: Invalid argument

My /etc/ifconfig.gif0 looks like this:

create
tunnel 192.80.49.1 209.212.68.38
inet6 2610:1f8::1:10:d86 2610:1f8::1:10:d85 prefixlen 128

But it configures to this:

gif0: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 1280
         tunnel inet 192.80.49.1 --> 209.212.68.38

...and now all of my IPv6 is gone... Any ideas?

John Klos

Jeremy C. Reed | 4 Jun 2008 01:31

USB and RNDIS?

I have a AT&T Tilt phone (aka HTC TyTN II) device that is recognized as

ugen1 at uhub1 port 1
ugen1: HTC Generic RNDIS, rev 2.00/0.00, addr 3

And with usbdevs -v

addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), ATI 
Technologie(0x1002), rev 1.00
 port 1 addr 3: full speed, self powered, config 1, Generic RNDIS(0x0b0b), 
HTC(0x0bb4), rev 0.00, serial 3fbf5000-7351-0801-3543-840138922290

It can be used for sharing network.

http://www.microsoft.com/whdc/device/network/ndis/rmndis.mspx

Any ideas on how to have an rndis network device?

Is this related to cdce(4)?

(I wonder if OpenBSD's cdce(4) has code to be pulled into NetBSD's.)

Petar Bogdanovic | 4 Jun 2008 15:03

ipfilter, return-icmp and RFC1122

Hi,

I recently noticed that ipfilter with `block return-icmp' is returning
ICMP Type 3 Code 0 (Network unreachable) to the sender of a blocked
broadcast:

	130.3.3.3 ---------[UDP <at> 130.3.3.255]--------> 130.3.3.4
	130.3.3.3 <----[ICMP Network unreachable]---- 130.3.3.4

This seems wrong, considering RFC1122, page 39:

         An ICMP error message MUST NOT be sent as the result of
         receiving:

         *    an ICMP error message, or

         *    a datagram destined to an IP broadcast or IP multicast
              address, or

         *    a datagram sent as a link-layer broadcast, or

         *    a non-initial fragment, or

         *    a datagram whose source address does not define a single
              host -- e.g., a zero address, a loopback address, a
              broadcast address, a multicast address, or a Class E
              address.

Is this desired behaviour?

(Continue reading)

Petar Bogdanovic | 4 Jun 2008 16:46

Re: ipfilter, return-icmp and RFC1122

On Wed, Jun 04, 2008 at 03:03:06PM +0200, Petar Bogdanovic wrote:
> Hi,
> 
> I recently noticed that ipfilter with `block return-icmp' is returning
> ICMP Type 3 Code 0 (Network unreachable) to the sender of a blocked
> broadcast:
> 
> 	130.3.3.3 ---------[UDP <at> 130.3.3.255]--------> 130.3.3.4
> 	130.3.3.3 <----[ICMP Network unreachable]---- 130.3.3.4
> 
> 
> This seems wrong, considering RFC1122, page 39:
> 
>          An ICMP error message MUST NOT be sent as the result of
>          receiving:
> 
>          *    an ICMP error message, or
> 
>          *    a datagram destined to an IP broadcast or IP multicast
>               address, or
> 
>          *    a datagram sent as a link-layer broadcast, or
> 
>          *    a non-initial fragment, or
> 
>          *    a datagram whose source address does not define a single
>               host -- e.g., a zero address, a loopback address, a
>               broadcast address, a multicast address, or a Class E
>               address.
> 
(Continue reading)

der Mouse | 4 Jun 2008 17:16
Picon

Re: ipfilter, return-icmp and RFC1122

>> I recently noticed that ipfilter with `block return-icmp' is
>> returning ICMP Type 3 Code 0 (Network unreachable) to the sender of
>> a blocked broadcast:

>> 	130.3.3.3 ---------[UDP <at> 130.3.3.255]--------> 130.3.3.4
>> 	130.3.3.3 <----[ICMP Network unreachable]---- 130.3.3.4

>> This seems wrong, considering RFC1122, page 39:

>>          An ICMP error message MUST NOT be sent as the result of
>>          receiving:
[...]
>>          *    a datagram destined to an IP broadcast or IP multicast
>>               address, [...]

> 	+block return-icmp in proto udp

I would say that the resulting behaviour is, strictly, wrong, but that
it's not ipf's fault: it's doing exactly what you told it to do.

I do not see any reason why ipf - or most other pieces of software, for
that matter - have to make it impossible, or even difficult, to violate
standards.  Just as I don't expect to be prevented from deleting the
postmaster alias in my mailer, or running 127.0.5.0/24 as an "ordinary"
Ethernet if I try, I don't expect ipf to impose all the Host
Requirements on me.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse <at> rodents.montreal.qc.ca
(Continue reading)

Steven M. Bellovin | 5 Jun 2008 03:22

Re: ipfilter, return-icmp and RFC1122

On Wed, 4 Jun 2008 15:03:06 +0200
Petar Bogdanovic <petar <at> smokva.net> wrote:

> Hi,
> 
> I recently noticed that ipfilter with `block return-icmp' is returning
> ICMP Type 3 Code 0 (Network unreachable) to the sender of a blocked
> broadcast:
> 
> 	130.3.3.3 ---------[UDP <at> 130.3.3.255]--------> 130.3.3.4
> 	130.3.3.3 <----[ICMP Network unreachable]---- 130.3.3.4
> 
> 
> This seems wrong, considering RFC1122, page 39:
> 
>          An ICMP error message MUST NOT be sent as the result of
>          receiving:
> 
>          *    an ICMP error message, or
> 
>          *    a datagram destined to an IP broadcast or IP multicast
>               address, or
> 
>          *    a datagram sent as a link-layer broadcast, or
> 
>          *    a non-initial fragment, or
> 
>          *    a datagram whose source address does not define a single
>               host -- e.g., a zero address, a loopback address, a
>               broadcast address, a multicast address, or a Class E
(Continue reading)

John Nemeth | 5 Jun 2008 10:34
Picon
Favicon

Re: ipfilter, return-icmp and RFC1122

On Oct 25,  3:57pm, "Steven M. Bellovin" wrote:
} On Wed, 4 Jun 2008 15:03:06 +0200
} Petar Bogdanovic <petar <at> smokva.net> wrote:
} 
} > I recently noticed that ipfilter with `block return-icmp' is returning
} > ICMP Type 3 Code 0 (Network unreachable) to the sender of a blocked
} > broadcast:
} > 
} > 	130.3.3.3 ---------[UDP <at> 130.3.3.255]--------> 130.3.3.4
} > 	130.3.3.3 <----[ICMP Network unreachable]---- 130.3.3.4
} > 
} > 
} > This seems wrong, considering RFC1122, page 39:
} > 
} >          An ICMP error message MUST NOT be sent as the result of
} >          receiving:
} > 
} >          *    an ICMP error message, or
} > 
} >          *    a datagram destined to an IP broadcast or IP multicast
} >               address, or
} > 
} >          *    a datagram sent as a link-layer broadcast, or
} > 
} >          *    a non-initial fragment, or
} > 
} >          *    a datagram whose source address does not define a single
} >               host -- e.g., a zero address, a loopback address, a
} >               broadcast address, a multicast address, or a Class E
} >               address.
(Continue reading)

Petar Bogdanovic | 5 Jun 2008 14:08

Re: ipfilter, return-icmp and RFC1122

On Thu, Jun 05, 2008 at 01:34:26AM -0700, John Nemeth wrote:
> On Oct 25,  3:57pm, "Steven M. Bellovin" wrote:
> } On Wed, 4 Jun 2008 15:03:06 +0200
> } Petar Bogdanovic <petar <at> smokva.net> wrote:
> } 
> } > I recently noticed that ipfilter with `block return-icmp' is returning
> } > ICMP Type 3 Code 0 (Network unreachable) to the sender of a blocked
> } > broadcast:
> } > 
> } > 	130.3.3.3 ---------[UDP <at> 130.3.3.255]--------> 130.3.3.4
> } > 	130.3.3.3 <----[ICMP Network unreachable]---- 130.3.3.4
> } > 
> } > 
> } > This seems wrong, considering RFC1122, page 39:
> } > 
> } >          An ICMP error message MUST NOT be sent as the result of
> } >          receiving:
> } > 
> } >          *    an ICMP error message, or
> } > 
> } >          *    a datagram destined to an IP broadcast or IP multicast
> } >               address, or
> } > 
> } >          *    a datagram sent as a link-layer broadcast, or
> } > 
> } >          *    a non-initial fragment, or
> } > 
> } >          *    a datagram whose source address does not define a single
> } >               host -- e.g., a zero address, a loopback address, a
> } >               broadcast address, a multicast address, or a Class E
(Continue reading)

Jim Wise | 5 Jun 2008 15:33
Gravatar

Re: ipfilter, return-icmp and RFC1122


On Wed, 4 Jun 2008, Petar Bogdanovic wrote:

>Hi,
>
>I recently noticed that ipfilter with `block return-icmp' is returning
>ICMP Type 3 Code 0 (Network unreachable) to the sender of a blocked
>broadcast:
>
>	130.3.3.3 ---------[UDP <at> 130.3.3.255]--------> 130.3.3.4
>	130.3.3.3 <----[ICMP Network unreachable]---- 130.3.3.4
>
>
>This seems wrong, considering RFC1122, page 39:

Note that IPF makes the return ICMP code configurable.  Try:

	block return-icmp-as-dest(port-unr) 

As noted down-thread, the default return value is perfectly appropriate 
for a router, but less so for an end host.

By the way, I think it's a bad idea to configure IPF to return 
'administratively prohibited' for blocked ports -- doing so allows a 
remote host to easily differentiate between blocked ports and open ports 
on which no daemon is currently running.

--

-- 
				Jim Wise
				jwise <at> draga.com
(Continue reading)

Petar Bogdanovic | 5 Jun 2008 15:41

Re: ipfilter, return-icmp and RFC1122

On Thu, Jun 05, 2008 at 09:33:05AM -0400, Jim Wise wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wed, 4 Jun 2008, Petar Bogdanovic wrote:
> 
> >Hi,
> >
> >I recently noticed that ipfilter with `block return-icmp' is returning
> >ICMP Type 3 Code 0 (Network unreachable) to the sender of a blocked
> >broadcast:
> >
> >	130.3.3.3 ---------[UDP <at> 130.3.3.255]--------> 130.3.3.4
> >	130.3.3.3 <----[ICMP Network unreachable]---- 130.3.3.4
> >
> >
> >This seems wrong, considering RFC1122, page 39:
> 
> Note that IPF makes the return ICMP code configurable.  Try:
> 
> 	block return-icmp-as-dest(port-unr) 
> 
> As noted down-thread, the default return value is perfectly appropriate 
> for a router, but less so for an end host.

I don't think that changing the return code would make ipfilter stop
responding to broadcasts. Or did you mean something else?

Petar

(Continue reading)


Gmane