Eric Boutilier | 1 Jul 18:20 2006
Picon

Overview (rollup) of recent activity on networking-discuss

For background on what this is, see:

     http://www.opensolaris.org/jive/message.jspa?messageID=24416#24416
     http://www.opensolaris.org/jive/message.jspa?messageID=25200#25200

===============================
networking-discuss 06/16 - 06/30
===============================

Threads or announcements originated by leaders during the period:

- Adding a new function to inet_pton family of things
     by Darren.Reed at Sun.COM (Darren Reed)

================================================================

Size of all threads during period:

Thread size     Topic
-----------     -----
       8       DLPI, GLDv3 nemo and bge
       8       DLPI Promisc ON OFF,
       6       backward bfu: nawk script to convert /etc/aggregation.conf
       6       Disable SCTP on Solaris 10
       5       Issues with the InDelivers MIB counter
       4       Is DNS/Server healthy on SXCR Build 41 ?
       4       Adding a new function to inet_pton family of things
       3       backward bfu: detecting when bfuing backwards
       3       Updated Public libdlpi documents
       3       DLPI packet loopback proposal
(Continue reading)

Paul Jakma | 3 Jul 17:44 2006
Picon

Re: Updated Public libdlpi documents

On Thu, 22 Jun 2006, sagun shakya - Sun Microsystems - Burlington United States wrote:

> An updated version of the libdlpi architecture document and proposed API 
> manpages of libdlpi.so are now available at :
>
> http://www.opensolaris.org/os/project/clearview/libdlpi
> and I would really appreciate your feedback on it by June 27th.

Apologies for the late reply.

The PSARC document in 1.7, probably ought to refer to event-driven 
applications with respect to dlpi_fd() uses.

Man pages:

dlpi_open and dlpi_set_timeout:

- Could we allow 0 timeout to really mean 0. I.e. could we provide a
   define of some other value to indicate "appropriate default", e.g. -2?

(0 timeout will need further interfaces added to work properly, but 
initial users can just use the FOO_DPLI_DEFAULT_TIMEOUT define..)

- libdpli is using poll behind the scenes, could we perhaps make the
   timeout be millisec (noting that libdpli is allowed to round-up to 1s
   precision if it wishes)

If we don't make these changes, extending libdlpi interfaces in future 
to allow user to handle control-flow will require above interfaces to be 
needlessly replicated.
(Continue reading)

Peter Memishian | 3 Jul 23:16 2006
Picon

Re: Updated Public libdlpi documents


 > Man pages:
 > 
 > dlpi_open and dlpi_set_timeout:
 > 
 > - Could we allow 0 timeout to really mean 0. I.e. could we provide a
 >    define of some other value to indicate "appropriate default", e.g. -2?
 > 
 > (0 timeout will need further interfaces added to work properly, but 
 > initial users can just use the FOO_DPLI_DEFAULT_TIMEOUT define..)

I agree we might use "0" to mean "non-blocking" in the future, and that
we'd be more future-proof with a DLPI_DEFAULT_TIMEOUT constant with some
out-of-range value.  However, since the vast majority of the callers will
want the default timeout, I'd vote to remove the timeout argument entirely
from dlpi_open(), and require use of dlpi_set_timeout() to change it (or
restore it to DLPI_DEFAULT_TIMEOUT).

 > - libdpli is using poll behind the scenes, could we perhaps make the
 >    timeout be millisec (noting that libdpli is allowed to round-up to 1s
 >    precision if it wishes)

I'm not sure I see the benefit in that.  DLPI control operations sometimes
lead to hardware initialization/reset or other slow operations; providing
a millisecond timeout encourages people to write code that may ultimately
prove unreliable across the set of network device drivers supported by
Solaris.  Instead of attempting to maintain the illusion that DLPI is
synchronous in small-timeout contexts, I would rather provide alternatives
that either remove the need for a small timeout, such as providing a
non-blocking mode.
(Continue reading)

Paul Jakma | 3 Jul 23:51 2006
Picon

Re: Updated Public libdlpi documents

On Mon, 3 Jul 2006, Peter Memishian wrote:

> want the default timeout, I'd vote to remove the timeout argument 
> entirely from dlpi_open(), and require use of dlpi_set_timeout() to 
> change it (or restore it to DLPI_DEFAULT_TIMEOUT).

Sounds good to me.

> device drivers supported by Solaris.  Instead of attempting to 
> maintain the illusion that DLPI is synchronous in small-timeout 
> contexts,

Ok.

> I would rather provide alternatives that either remove the need for a 
> small timeout, such as providing a non-blocking mode.

Yes, non-blocking is what I'd like.

regards,
--

-- 
Paul Jakma,
Network Approachability, KISS.           Sun Microsystems, Dublin, Ireland.
http://opensolaris.org/os/project/quagga tel: EMEA x19190 / +353 1 819 9190
Derek Morr | 5 Jul 21:27 2006
Picon

Re: Re: Does bge driver/Broadcom NetXtreme

Thanks much for this. It worked!

Out of curiosity, where did you find the answer? I havent' seen any good docs on jumbo frames on Solaris. It
seems like every driver has a different way of setting MTU.

 
This message posted from opensolaris.org
Peter Memishian | 6 Jul 01:19 2006
Picon

re: Re: Re: Does bge driver/Broadcom NetXtreme


 > Thanks much for this. It worked!
 > 
 > Out of curiosity, where did you find the answer? I havent' seen any
 > good docs on jumbo frames on Solaris. It seems like every driver has a
 > different way of setting MTU.

Indeed -- this hasn't yet been standardized.  Check out this thread
for some thoughts on how we might proceed:

    http://opensolaris.org/jive/thread.jspa?messageID=38984

Note that the link property mechanism mentioned by Nicolas was recently
approved by PSARC as part of the GLDv3/WiFi case (see [1]), but no
properties for manipulating the MTU have been proposed at this point.

[1] http://opensolaris.org/os/community/networking/wifi-dladm-design.pdf

--

-- 
meem
Paul Worrall | 6 Jul 17:27 2006
Picon

Cardbus driver does not work

Hi,

I am trying to get a wireless PCMCIA card to work on my notebook.  The
prerequisite to installing the wireless network drivers for Atheros 52xx
chipset support is the cardbus driver.  This is not working.

Details:

mc/: Dell Inspiron 8200

opensolaris version: SunOS Release 5.10 Version Generic_118844-26 32-bit

CardBus Bridge type: confirmed to be Texas Instruments (PCI ID:
pci104c,ac42.1028.d4.0 )

Down loaded and installed as instructed Version 0.3 of Cardbus Driver
with support for 32-bit PC cards.  When Linksys WPC55AG inserted machine
locks up.  If rebooted while inserted freezes on boot.  If removed boots
up OK.

Any ideas :-)

--

-- 
Paul Worrall
USE YOUR INTERITION
Java Open Source Software Services
w: www.interition.net
Sagun Shakya | 6 Jul 17:45 2006
Picon

Re: Updated Public libdlpi documents


Thank you Paul and Meem for your comments.

Peter Memishian wrote:

> > Man pages:
> > 
> > dlpi_open and dlpi_set_timeout:
> > 
> > - Could we allow 0 timeout to really mean 0. I.e. could we provide a
> >    define of some other value to indicate "appropriate default", e.g. -2?
> > 
> > (0 timeout will need further interfaces added to work properly, but 
> > initial users can just use the FOO_DPLI_DEFAULT_TIMEOUT define..)
>
>I agree we might use "0" to mean "non-blocking" in the future, and that
>we'd be more future-proof with a DLPI_DEFAULT_TIMEOUT constant with some
>out-of-range value.  However, since the vast majority of the callers will
>want the default timeout, I'd vote to remove the timeout argument entirely
>from dlpi_open(), and require use of dlpi_set_timeout() to change it (or
>restore it to DLPI_DEFAULT_TIMEOUT).
>  
>
Yes, it certainly makes sense to keep the timeout mechanism with the 
dlpi_set_timeout().

> > - libdpli is using poll behind the scenes, could we perhaps make the
> >    timeout be millisec (noting that libdpli is allowed to round-up to 1s
> >    precision if it wishes)
>
(Continue reading)

Paul Worrall | 6 Jul 19:02 2006
Picon

wificonfig doc wrong

Hi,

http://www.opensolaris.org/os/community/laptop/wireless/wificonfig/
instructs us to use :

# wificonfig -i ath0 createprofile essid=mywifi encryption=WEP wepkey1=12345

..to create a profile to accommodate WEP WLAN.  However the "-i" arg is
not required.

The command should be:

# wificonfig createprofile essid=mywifi encryption=WEP wepkey1=12345

mywifi and 12345 being replaced with your SSID and WEP key respectively.

Example:

# ./wificonfig createprofile essid=MYWLAN encryption=WEP
wepkey1=A25CFEF88643BB6262BC164BB1

..this creates a profile that you can refer to on subsequent occasions.
Like..

# ./wificonfig -i ath0 connect MYWLAN
./wificonfig: connecting to profile 'MYWLAN'

..this uses the profile created earlier to set the connection info.

#ifconfig ath0 plumb
(Continue reading)

Paul Worrall | 6 Jul 19:05 2006
Picon

wificonfig doc wrong

Hi,

http://www.opensolaris.org/os/community/laptop/wireless/wificonfig/
instructs us to use :

# wificonfig -i ath0 createprofile essid=mywifi encryption=WEP wepkey1=12345

..to create a profile to accommodate WEP WLAN.  However the "-i" arg is
not required.

The command should be:

# wificonfig createprofile essid=mywifi encryption=WEP wepkey1=12345

mywifi and 12345 being replaced with your SSID and WEP key respectively.

Example:

# ./wificonfig createprofile essid=MYWLAN encryption=WEP
wepkey1=A25CFEF88643BB6262BC164BB1

..this creates a profile that you can refer to on subsequent occasions.
Like..

# ./wificonfig -i ath0 connect MYWLAN
./wificonfig: connecting to profile 'MYWLAN'

..this uses the profile created earlier to set the connection info.

#ifconfig ath0 plumb
(Continue reading)


Gmane