usb/149039: [uhso] Binding problem with uhso

[Fredrik Lindberg]

The following reply was made to PR usb/149039; it has been noted by GNATS.

From: Fredrik Lindberg <fli at shapeshifter.se>
To: perryh at pluto.rain.com
Cc: pilzableiter at web.de, bug-followup at freebsd.org, 
 freebsd-net at freebsd.org, freebsd-usb at freebsd.org
Subject: Re: usb/149039: [uhso] Binding problem with uhso
Date: Mon, 02 Aug 2010 08:54:12 +0200

 On 08/01/2010 04:37 AM, perryh at pluto.rain.com wrote:
 >> The following reply was made to PR usb/149039; it has been noted
 >> by GNATS.
 >>
 >> From: Fredrik Lindberg<fli at shapeshifter.se>
 >> To: bug-followup at FreeBSD.org, pilzableiter at web.de
 >> Cc: Hans Petter Selasky<hselasky at c2i.net>
 >> Subject: Re: usb/149039: [uhso] Binding problem with uhso
 >> Date: Sat, 31 Jul 2010 15:00:07 +0200
 >>
 >>   I apparently missed some interface flags (that really doesn't make
 >>   sense for this device, it's configured with a /32 mask so broadcast
 >>   etc can only be to itself) that the network stack wants to work
 >>   properly.
 >
 > Is a /32 mask even legal?  Unless there's a special case involved,
 > it ought to mean that there are no interfaces on the subnet other
 > than this one, thus this interface has no peer to communicate with
 > and might as well not exist.
 >
 > Adding net@ in hopes someone there knows what should happen.
 >
 
 Yes, technically a /32 mask defines only one single address, but it's
 the only mask that really makes sense for this device.  /32 masks are
 "legal" and commonly used for the loopback address of routers.
 
 But this is is indeed a very special case.  The device has a
 USB interface that accepts raw IP-packets (with no other
 encapsulation).  Once you have told the device to connect, it will
 tell you what IP-address you have and what DNS-servers to use, but
 that's it.  My best guess is that the devices does PPP internally in
 firmware and abstracts the point-to-point link with a IP-packet
 interface.  But since none of these details are available the only (as
 far as I know) viable thing is to set a /32 mask and set 0.0.0.0
 (default route) to be directly reachable through the interface (route
 add -interface).
 
 
 Fredrik Lindberg