Re: I'm trying to make a 6rd pseudo-device

Ignatios Souvatzis <is <at> netbsd.org> writes:

> On Mon, Jan 24, 2011 at 08:30:02AM -0500, Patrick Klos wrote:
>
>> the rest to work.  I'm considering merging my code into the stf
>> driver rather then to have a separate sixrd driver?
>
> As far as I read 6RD, it's just like 6to4, just with a different
> (and normally longer) prefix than 2002::/16 ?
>
> 6to4 should certainly be implementable as a special case of a 6rd
> driver, or stf should be easily extandable. Note however, that for
> 6to4 the intrinsic prefix length is always (16+32)==48, while for
> 6rd it can be anything from (in theory) 3+32 to 32+32. So there's 
> a small integer parameter more - the position of the embedded
> IPv4 relay address.

More than that -- 6RD allows for removing some bits from the beginning
of the IPv4 address.  So if a provider is delivering v6 service to
172.19.0.0/16, they could set IPv4MaskLen as high as 16 and use a prefix
like 2001:db8:beef::/48.  Or a shorter prefix than that.  So there are
two small integer parameters here, as well as those bits of the v4
address that are masked off.

(In fact, from my first read through it, RFC 5969 doesn't explicitly
forbid giving each v4 address a prefix smaller than a /64; that will
break stateless autoconfiguration of the end network, of course, but it
is possible.  The only restriction like that that I'm seeing is that the
resulting prefix must be at least a /128 -- for obvious reasons.)

Re: working against 5.99.44: AR8131/2 driver

On Sun, Jan 30, 2011 at 01:04:19AM -0500, fire crow wrote:

>    added
> 
>    #alc driver for Atheros L1E Gigabit Ethernet
>    alc*    at pci? dev ? function ?        # Atheros L1 Gigabit Ethernet (EXP)
>    atphy*  at mii? phy ?                   # Attansic/Atheros PHYs
>    compile MONOLITHIC kernel
> 
>     and commented out hdaudio becuase it causes my laptop to crashes
> 
> 
> worked after running commands in test_alc.sh

For the record: with 5.99.43 MONOLITHIC, on the eeepc 1008HA, I only
get timeout reading phy registers. Lots of timeouts. And Status:
no network"., whether I use atphy or disable it with boot -c to
fall back to ukphy

	-is

Re: working against 5.99.44: AR8131/2 driver

On Wed, Feb 02, 2011 at 12:40:20AM +0100, Ignatios Souvatzis wrote:

> For the record: with 5.99.43 MONOLITHIC, on the eeepc 1008HA, I only
> get timeout reading phy registers. Lots of timeouts. And Status:
> no network"., whether I use atphy or disable it with boot -c to
> fall back to ukphy

20110129 0000 5.99.44 shows the same error. I'll append the dmesg output
below. Can you post your /var/run/dmesg.boot for comparison, please?

	-is

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008, 2009, 2010, 2011
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 5.99.44 (MONOLITHIC) #2: Wed Feb  2 20:48:07 CET 2011
	ignatios <at> random87:/var/itch/obj/cur/i386/sys/arch/i386/compile/MONOLITHIC
total memory = 1015 MB
avail memory = 985 MB
timecounter: Timecounters tick every 10.000 msec
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
ASUSTeK Computer INC. 1008HA (x.x)
mainbus0 (root)
cpu0 at mainbus0 apid 0: Intel(R) Atom(TM) CPU N280    <at>  1.66GHz, id 0x106c2
cpu1 at mainbus0 apid 1: Intel(R) Atom(TM) CPU N280    <at>  1.66GHz, id 0x106c2
ioapic0 at mainbus0 apid 2: pa 0xfec00000, version 20, 24 pins

Re: working against 5.99.44: AR8131/2 driver

I booted with alcdebug set to 1. Firecrow - can you do that, too, please?

On Wed, Feb 02, 2011 at 09:22:44PM +0100, Ignatios Souvatzis wrote:
...
> ppb1 at pci0 dev 28 function 1: vendor 0x8086 product 0x27d2 (rev. 0x02)
> ppb1: PCI Express 1.0 <Root Port of PCI-E Root Complex>
> pci2 at ppb1 bus 2
> pci2: i/o space, memory space enabled, rd/line, wr/inv ok
> alc0 at pci2 dev 0 function 0: Attansic/Atheros L1E Ethernet
> alc0: ioapic0 pin 17

alc0: Read request size : 128 bytes.
alc0: TLP payload size : 128 bytes.
alc0: PCI device revision : 0x00c0
alc0: Chip id/revision : 0xc002
alc0: 15872 Tx FIFO, 15360 Rx FIFO

> alc0: Ethernet address 00:26:18:15:30:39
> atphy0 at alc0 phy 0: L1 10/100/1000 PHY, rev. 11
> atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto

Re: working against 5.99.44: AR8131/2 driver

On Wed, Feb 2, 2011 at 4:19 PM, Ignatios Souvatzis <is <at> netbsd.org> wrote:
> I booted with alcdebug set to 1. Firecrow - can you do that, too, please?
>
> On Wed, Feb 02, 2011 at 09:22:44PM +0100, Ignatios Souvatzis wrote:
> ...
>> ppb1 at pci0 dev 28 function 1: vendor 0x8086 product 0x27d2 (rev. 0x02)
>> ppb1: PCI Express 1.0 <Root Port of PCI-E Root Complex>
>> pci2 at ppb1 bus 2
>> pci2: i/o space, memory space enabled, rd/line, wr/inv ok
>> alc0 at pci2 dev 0 function 0: Attansic/Atheros L1E Ethernet
>> alc0: ioapic0 pin 17
>
> alc0: Read request size : 128 bytes.
> alc0: TLP payload size : 128 bytes.
> alc0: PCI device revision : 0x00c0
> alc0: Chip id/revision : 0xc002
> alc0: 15872 Tx FIFO, 15360 Rx FIFO
>
>> alc0: Ethernet address 00:26:18:15:30:39
>> atphy0 at alc0 phy 0: L1 10/100/1000 PHY, rev. 11
>> atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto
>
>

lost my current, partition, being my reckelss self, so I'll need to
set it back up to get those results,

but I did run into one of the error conditions you mentioned earlier
while putting it back together,

route can't change flags

Hi,

Anything against commiting rtsock.c patch from PR/40455 ?

--

-- 
Mihai

Re: route can't change flags

On Tue, Feb 08, 2011 at 09:41:56AM +0200, Mihai Chelaru wrote:
> Hi,
> 
> Anything against commiting rtsock.c patch from PR/40455 ?

It looks fine to me.

Dave

--

-- 
David Young             OJC Technologies
dyoung <at> ojctech.com      Urbana, IL * (217) 344-0444 x24

wi(4) with AirPort only half working

Hi!

Before I try to debug the code on my PowerBook G3 (Pismo) I would like to
know if there is a general, maybe known, problem with wi(4), or if it is a
problem in the macppc if_wi_obio.c frontend.

WLAN with wi(4) seems to work for me, when I configure it with
# ifconfig wi0 inet a.b.c.d ssid myname mkey mykey up

But:

- "ifconfig wi0" does not display the right channel when connected
- "ifconfig wi0 list scan" hangs
- "wlanctl wi0" only displays my own interface

Did anybody else see that on anything other than macppc hardware?

--

-- 
Frank Wille

Re: wi(4) with AirPort only half working

Frank Wille wrote:

> [...]
> - "ifconfig wi0" does not display the right channel when connected
> - "ifconfig wi0 list scan" hangs
> - "wlanctl wi0" only displays my own interface
>
> Did anybody else see that on anything other than macppc hardware?

Seems I have to rephrase my question:

Is anybody using wi(4) on non-macppc hardware? Then please tell me if
"ifconfig wi0 list scan" works for you and which firmware you are using.

Now I remember that macallan <at>  told me the behaviour might be firmware
dependant. Does it mean this firmware
  wi0: Lucent Firmware: Station (8.70.1)
does not provide the possibility for "list scan" or showing the correct
channel? Then there would be nothing to debug for me.

--

-- 
Frank Wille

Re: wi(4) with AirPort only half working

frank <at> phoenix.owl.de (Frank Wille) writes:

>Is anybody using wi(4) on non-macppc hardware? Then please tell me if
>"ifconfig wi0 list scan" works for you and which firmware you are using.

On netbsd-5/i386:  ifconfig wi0 list scan  just waits infinitely and
the interface shows "status: no network". You can interrupt ifconfig,
then down and up the interface to restore operation. dmesg sometimes
shows a "wi0: wi_cmd: busy bit won't clear".

wi0 at pcmcia1 function 0: <Lucent Technologies, WaveLAN/IEEE, Version 01.01, >
wi0: Lucent Firmware: Station (8.10.1)

N.B. wiconfig wi0 -D seems to work and doesn't kill the interface.

-- 
--

-- 
                                Michael van Elst
Internet: mlelstv <at> serpens.de
                                "A potential Snark may lurk in every tree."