headers
Sean Boudreau | 2 Jun 2006 18:55

ral endian issue


Hi:

The eeprom bits are shifted out in host order.

Regards,

-seanb

Index: dev/ic/ral.c
===================================================================
RCS file: /cvsroot/src/sys/dev/ic/ral.c,v
retrieving revision 1.6
diff -c -r1.6 ral.c
*** dev/ic/ral.c	18 Nov 2005 16:53:56 -0000	1.6
--- dev/ic/ral.c	2 Jun 2006 16:50:34 -0000
***************
*** 993,999 ****
  	RAL_EEPROM_CTL(sc, 0);
  	RAL_EEPROM_CTL(sc, RAL_EEPROM_C);

! 	return le16toh(val);
  }

  /*
--- 993,999 ----
  	RAL_EEPROM_CTL(sc, 0);
  	RAL_EEPROM_CTL(sc, RAL_EEPROM_C);

! 	return val;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rui Paulo | 3 Jun 2006 14:12

Re: ral endian issue

At Fri, 2 Jun 2006 12:55:36 -0400,
Sean Boudreau wrote:
> 
> 
> Hi:
> 
> The eeprom bits are shifted out in host order.
> 

Comitted, thanks!
Permalink | Reply | 0 comments |
headers
Konstantin KABASSANOV | 3 Jun 2006 18:04
Picon
Favicon

Mobile IPv6

Hi,

Does anybody know a working implementation of Mobile IPv6 for NetBSD?

Thanks.

_________________________________

Konstantin K. KABASSANOV

LIP6/CNRS
8, rue du Capitaine Scott
75015 Paris, France

Phone: +33 (0) 1 44 27 71 26
Fax:   +33 (0) 1 44 27 74 95

E-mail: konstantin <at> kabassanov.com
Web: http://www.kabassanov.com
_________________________________

IMPORTANT! If you have tried to reply to this mail and you received a
stupid message, announcing that the mail had been rejected as spam,
please, resend your reply to the address above. 

The certificate used to sign this e-mail can be verified at:
http://igc.services.cnrs.fr/CNRS-Standard/recherche.html

Mediocrity is the worst kind of failure...
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rui Paulo | 4 Jun 2006 15:47

Re: Mobile IPv6

AAt Sat, 3 Jun 2006 18:04:47 +0200,
Konstantin KABASSANOV wrote:
> 
> [1  <text/plain; US-ASCII (7bit)>]
> Hi,
> 
> Does anybody know a working implementation of Mobile IPv6 for NetBSD?

http://www.nautilus6.org/
Permalink | Reply | 0 comments |
headers
Kentaro A. Kurahone | 4 Jun 2006 20:41

Appropriate byte counting, revisited.

There was some discussion a while back regarding Appropriate Byte
Counting (RFC 3465).  As part of poking at HSTCP, I found a compelling
reason to implement this mechanism:

When a connection is in congestion avoidance, we currently grow the
window like thus:
  u_int cw = tp->snd_cwnd;
  u_int incr = tp->t_segsz;

  incr = incr * incr / cw;

The problem occurs when the congestion window grows past t_segsz
segments, since the increment is under a byte, the congestion window
won't be opened further.

Diff:
http://www.sigusr1.org/~kurahone/misc-hacks/tcp-abc-netbsd-3.99.20.diff.gz

The diff implements straight forward per-RFC ABC, with the "L" parameter
set at "1*SMSS".  As an additional bonus, I changed the header prediction
code to execute even when the connection is congestion window bound,
which should help overall performance.

Questions/Comments?

--

-- 
Kentaro A. Kurahone
SIGUSR1 Research and Development
Permalink | Reply | 36 comments |
headers
Rui Paulo | 5 Jun 2006 15:39

Re: Appropriate byte counting, revisited.

At Sun, 4 Jun 2006 18:41:54 +0000,
Kentaro A. Kurahone wrote:
> 
> There was some discussion a while back regarding Appropriate Byte
> Counting (RFC 3465).  As part of poking at HSTCP, I found a compelling
> reason to implement this mechanism:
> 
> When a connection is in congestion avoidance, we currently grow the
> window like thus:
>   u_int cw = tp->snd_cwnd;
>   u_int incr = tp->t_segsz;
> 
>   incr = incr * incr / cw;
> 
> The problem occurs when the congestion window grows past t_segsz
> segments, since the increment is under a byte, the congestion window
> won't be opened further.
> 
> Diff:
> http://www.sigusr1.org/~kurahone/misc-hacks/tcp-abc-netbsd-3.99.20.diff.gz
> 
> The diff implements straight forward per-RFC ABC, with the "L" parameter
> set at "1*SMSS".  As an additional bonus, I changed the header prediction
> code to execute even when the connection is congestion window bound,
> which should help overall performance.
> 
> Questions/Comments?

I found a typo ;-)
+                               /* Grow our congestion window if neccecary. */
(Continue reading)

Permalink | Reply | 35 comments |
headers
pancake | 5 Jun 2006 15:47

wistumbler3

Some time ago I've send a mail about the SoC proposal to achieve a wireless
stumbler for NetBSD. So, i was unable to join the SoC, but i'm getting good
advances on the new toy.

Wistumbler3 aims to run on top of libwist.

Libwist is a portable library that comes with wistumbler3 and aims for
portability and transparency over the operating system, interfaces, and
network.

So using libwist you'll able to manage local or remote network interfaces

About network interfaces i've implemented Ethernet and Wireless support, so
i'm planning to inject the bluetooth support transparently. So the same
frontend application, could be able to scan bluetooth devices or wireless
accesspoints (for example).

By now, there'r some stuff implemented by system(), yeah, that's ugly, but
ATM I want to spend more time thinking on the API design.

The current libwist runs on GNU/Linux (libiw) and NetBSD, but i'm planning
to port't to Free and OpenBSD soon.

The same library is planning to support a remoting protocol to allow to
manage the network stuff of remote hosts (default gateway, scan aps, launch
dhcp, etc..)

BTW the same library will implement a priviledge separation to allow
authorized users to communicate to a local daemon running as UID=0.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Liam J. Foy | 5 Jun 2006 16:03

Re: wistumbler3

Hello,

Firstly, it's great that you're still passionate about this
project.

You mentioned using some libs, however a WiFi browser
can be built in NetBSD without any new libs. I suggest
you read over some of the code in:

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/net80211/

and try and use that. You might also wish to speak to
David Young, he may be able to help you.

		---
		Liam J. Foy
		<liamjfoy <at> netbsd.org>
		BSDPortal.org
Permalink | Reply | 2 comments |
headers
pancake | 5 Jun 2006 17:01

Re: wistumbler3

libwist wraps the net80211 api for netbsd. So i've this already
implemented on Wistubler2. So I know how the wireless stuff works on BSD,

I understand that the netbsd stumbler doesn't needs to wrap anything. So
I think it could be pretty easy to adopt, or just inline the NetBSD part
of libwist inside the netbsd solution.

So, this will "dup" the work, but IMHO this is not a big problem. (maybe
a week of work). But wistumbler3 could be accessible thru pkgsrc instead
of the base system

I would like to discuss about the NetBSD implementation, so, I was thinking
to create a daemon providing an interface to authorized users to manage the
wireless stuff. BTW I could forget this and just write a ncurses based
stumbler and network selector for NetBSD that _must_ run as root.

--pancake

On Mon, 5 Jun 2006 15:03:43 +0100
"Liam J. Foy" <liamfoy <at> sepulcrum.org> wrote:

> Hello,
> 
> Firstly, it's great that you're still passionate about this
> project.
> 
> You mentioned using some libs, however a WiFi browser
> can be built in NetBSD without any new libs. I suggest
> you read over some of the code in:
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kentaro A. Kurahone | 5 Jun 2006 17:56

Re: Appropriate byte counting, revisited.

On Mon, Jun 05, 2006 at 02:39:42PM +0100, Rui Paulo wrote:
> At Sun, 4 Jun 2006 18:41:54 +0000,
> I found a typo ;-)
> +                               /* Grow our congestion window if neccecary. */

Thanks!

> What about a sysctl to disable/enable this ? As the RFC says:
> 
>    On the other hand, in some cases
>    the modified cwnd growth algorithm causes larger bursts of segments
>    to be sent into the network.  In some cases this can lead to a non-
>    negligible increase in the drop rate and reduced performance (see
>    section 4 for a larger discussion of the issues).

If my reading of the spec is correct this only really applies in cases
where L > 1*SMSS.  As it stands right now, I'm using L=1*SMSS, so
behavior durring slow start will either be identical to, or more
conservative than the traditional algorithm.  With that said, it may be
beneficial to provide the option for using L=2*SMSS and have a sysctl
for that.

--

-- 
Kentaro A. Kurahone
SIGUSR1 Research and Development
Permalink | Reply | 34 comments |

Gmane