Re: urtwm -> rtwm

[Mattia Rossi]

Hi!

rtwn_usb(4) depends on rtwn(4) module; you can try to
1) add them to the kernel config;
2) check / fix WITHOUT_MODULES and MODULES_OVERRIDE make.conf(5) variables
3) compile / install them manually

P.S. There is no 'rtwm' module in the tree; what is the exact error message
where it was?

the problem was that if_rtwn.ko was not compiled!
all the others where, i.e. if_rtwn_[pci,usb].ko.
I added all of them to the config, and now it seems to work

so the problem is that the loadable module if_rtwn.ko is NOT compiled
by default, while all the others are,
what is the magic to have it compiled?
From my experience you always have to specify all modules and the 
modules they depend on. I for example had to specify this for zfs 
support in the config file:


makeoptions MODULES_OVERRIDE="zfs opensolaris acl_nfs4"

I actually only wanted zfs, which depends on opensolaris which then 
again depends on acl_nfs4 (probably because I sepcified nfs4 support in 
the config file)


I only found out after a few tries. It's really not ideal, that module 
dependencies are not resolved.

But once you know about it, you can live with it :-)



BTW, I tried this on RPI2, and now will try on an orangepi one.

Is that the SDIO based internal WiFi? Let me know if it works!

Cheers,

Mat


On 30 Oct 2016, at 14:07, Daniel Braniss  wrote:

hi,
between r30666 and r30808 i lost my wireless,

s/r30666/r306333/ and s/r30808/r308087/


so reading UPDATE clarified why, I also did a mergemaster so now devd et.all. 
seem to be in sync,
but now devd complains that if_rtwn_usb depends on rtwm and there is no rtwn, 
instead there are
several rtwn-rtl8…., the closest being rtwn-rt18188eufw.ko

this is what the old urtwn has to say:
...
Starting devd.
wlan: <802.11 Link Layer>
urtwn0 on uhub1
urtwn0:  on usbus0
urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R
urtwn0: enabling 11n
urtwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
urtwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 
36Mbps 48Mbps 54Mbps
urtwn0: 1T1R
urtwn0: 11ng MCS 20MHz
urtwn0: MCS 0-7: 6.5Mbps - 65Mbps

please help

thanks,
danny

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-wirel...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r268621: panic: shadowed tmpfs v_object [with dump]

[Mattia Rossi]

Got the same panic, is this fix getting committed? Or has it already
been committed?

r269053

Thanks, confirming that it fixes the panic as well :-)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: r268621: panic: shadowed tmpfs v_object [with dump]

[Mattia Rossi]

Got the same panic, is this fix getting committed? Or has it already 
been committed?


Mat

On 23/07/14 18:12, Bryan Drewery wrote:

On 7/23/14, 7:11 AM, Konstantin Belousov wrote:

On Tue, Jul 22, 2014 at 02:53:56PM -0700, Bryan Drewery wrote:

On 7/22/14, 2:26 PM, Bryan Drewery wrote:

On 7/22/14, 2:07 PM, Bryan Drewery wrote:

Meant to send to current@, moving there.

On 7/22/14, 2:07 PM, Bryan Drewery wrote:

On r268621:


panic: shadowed tmpfs v_object 0xf807a7f96600
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe1247d67390
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1247d67440
vpanic() at vpanic+0x126/frame 0xfe1247d67480
kassert_panic() at kassert_panic+0x139/frame 0xfe1247d674f0
vm_object_deallocate() at vm_object_deallocate+0x236/frame
0xfe1247d67550
tmpfs_free_node() at tmpfs_free_node+0x138/frame 0xfe1247d67580
tmpfs_reclaim() at tmpfs_reclaim+0x17d/frame 0xfe1247d675c0
VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xf7/frame 0xfe1247d675f0
vgonel() at vgonel+0x1a1/frame 0xfe1247d67660
vrecycle() at vrecycle+0x3e/frame 0xfe1247d67690
tmpfs_inactive() at tmpfs_inactive+0x4c/frame 0xfe1247d676b0
VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xf7/frame 
0xfe1247d676e0

vinactive() at vinactive+0xc6/frame 0xfe1247d67730
vputx() at vputx+0x27a/frame 0xfe1247d67790
tmpfs_rename() at tmpfs_rename+0xf5/frame 0xfe1247d67860
VOP_RENAME_APV() at VOP_RENAME_APV+0xfc/frame 0xfe1247d67890
kern_renameat() at kern_renameat+0x3ef/frame 0xfe1247d67ae0
amd64_syscall() at amd64_syscall+0x25a/frame 0xfe1247d67bf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247d67bf0
--- syscall (128, FreeBSD ELF64, sys_rename), rip = 0x80088b74a, 
rsp =

0x7fffe238, rbp = 0x7fffe710 ---
Uptime: 6d4h0m3s

Dump failed. Partition too small.


Unfortunately I have no dump to debug.




Running poudriere again after boot hit the issue right away:



(kgdb) bt
#0  doadump (textdump=1) at pcpu.h:219
#1  0x809122a7 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:445
#2  0x809127e5 in vpanic (fmt=value optimized out, 
ap=value

optimized out) at /usr/src/sys/kern/kern_shutdown.c:744
#3  0x80912679 in kassert_panic (fmt=value optimized 
out) at

/usr/src/sys/kern/kern_shutdown.c:632
#4  0x80ba7996 in vm_object_deallocate (object=value
optimized out) at /usr/src/sys/vm/vm_object.c:562
#5  0x820a75a8 in tmpfs_free_node (tmp=0xf800b5155980,
node=0xf802716ba740) at
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:335
#6  0x820a363d in tmpfs_reclaim (v=value optimized out) at
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1276
#7  0x80e48717 in VOP_RECLAIM_APV (vop=value optimized out,
a=value optimized out) at vnode_if.c:2017
#8  0x809c1381 in vgonel (vp=0xf802716b61d8) at
vnode_if.h:830
#9  0x809c18be in vrecycle (vp=0xf802716b61d8) at
/usr/src/sys/kern/vfs_subr.c:2655
#10 0x820a61cc in tmpfs_inactive (v=value optimized out) at
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1242
#11 0x80e485b7 in VOP_INACTIVE_APV (vop=value optimized 
out,

a=value optimized out) at vnode_if.c:1951
#12 0x809bfd36 in vinactive (vp=0xf802716b61d8,
td=0xf80187e29920) at vnode_if.h:807
#13 0x809c012a in vputx (vp=0xf802716b61d8, func=2) at
/usr/src/sys/kern/vfs_subr.c:2267
#14 0x820a47c5 in tmpfs_rename (v=value optimized out) at
/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:1023
#15 0x80e47d3c in VOP_RENAME_APV (vop=value optimized out,
a=value optimized out) at vnode_if.c:1544
#16 0x809cc77f in kern_renameat (td=value optimized out,
oldfd=value optimized out, old=value optimized out, newfd=value
optimized out, new=value optimized out,
 pathseg=value optimized out) at vnode_if.h:636
#17 0x80d280fa in amd64_syscall (td=0xf80187e29920,
traced=0) at subr_syscall.c:133
#18 0x80d0a64b in Xfast_syscall () at
/usr/src/sys/amd64/amd64/exception.S:407
(kgdb) p *(vm_object_t)0xf8027169f500
$1 = {lock = {lock_object = {lo_name = 0x80fe89f6 vm 
object,

lo_flags = 90374144, lo_data = 0, lo_witness = 0xfe6e7680},
rw_lock = 18446735284191271200}, object_list = {
 tqe_next = 0xf8027169f400, tqe_prev = 0xf8027169f620},
shadow_head = {lh_first = 0xf801b8489e00}, shadow_list = {le_next
= 0x0, le_prev = 0x0}, memq = {tqh_first = 0xf811d966bc08,
 tqh_last = 0xf811d966bc18}, rtree = {rt_root =
18446735354278362121, rt_flags = 0 '\0'}, size = 1, generation = 1,
ref_count = 1, shadow_count = 1, memattr = 6 '\006', type = 1 '\001',
   flags = 528, pg_color = 0, paging_in_progress = 0,
resident_page_count = 1, backing_object = 0x0, 
backing_object_offset =

0, pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = {
 lh_first = 0x0}, cache = {rt_root = 0, rt_flags = 0 '\0'}, 

No devices/nodes/files in /dev after building and installing world

[Mattia Rossi]

Hi all,

I'm currently stuck on the following. Haven't built HEAD in a while, and 
now after a


make buildworld kernel installworld distrib-dirs distribution

I don't have any nodes in /dev at all. As far as I remember there was 
always a minimum set of nodes in there, like ttys etc.


What happened? Which changes did I miss?

Cheers,

Mat
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Installing ports without info files

[Mattia Rossi]

Hi all,

I've build a world with the following constraints: -DWITHOUT_INFO 
-DWITHOUT_MAN -DWITHOUT_SHAREDOCS -DWITHOUT_EXAMPLES -DWITHOUT_HTML


as I don't need that stuff. Turns out, this prevents tools like 
install-info being built.
Now trying to build devel/gettext I can't get it installed, as it always 
wants to install info files using install-info, which of course fails.


How do I tell the system not to build info files (or manpages or all of 
the stuff above I don't want in the first place) when building ports?


I've tried with make -DWITHOUT_INFO install as well as with putting 
WITHOUT_INFO=yes in make.conf.


Gettext will still fail to install.
Is this a gettext problem? Or a generic ports problem?

I'm running current on arm (thanks again to freebsd-arm people for 
fixing it):

FreeBSD dreamplug 10.0-ALPHA1 FreeBSD 10.0-ALPHA1 #15 r255499M:

It's also not possible to make index for INDEX-10 if you use a 
stripped-down ports tree (none of the language ports), as there are some 
dependencies in the tree to french (cad-astk) and russian (stardict-*) 
which obviously can't be resolved.


Help is appreciated!

Cheers,

Mat
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: IPv6 accept_rtadv + bfe0

[Mattia Rossi]

On 19/10/2011 08:16, Bjoern A. Zeeb wrote:


On 18. Oct 2011, at 20:00 , Johann Hugo wrote:


Hi

The only way that I can get bfe0 to enable ACCEPT_RTADV is to manually do it
with ifconfig bfe0 inet6 accept_rtadv. Even if I add it to ifconfig_bge0 in
rc.conf it does nothing.

grep bfe /etc/rc.conf
ifconfig_bfe0=DHCP accept_rtadv


ifconfig_bfe0=DHCP
ifconfig_bfe0_ipv6=inet6 accept_rtadv


So the _ipv6 bit doesn't take care of passing inet6 to ifconfig 
automatically?


Does passing two options work, or do I have to pass them separately?
E.g.:

ifconfig_bfe0_ipv6=inet6 accept_rtadv -ifdisable

or

ifconfig_bfe0_ipv6=inet6 accept_rtadv
ifconfig_bfe0_ipv6=inet6 -ifdisable

Mat
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: resolvconf script overwrites entries in resolv.conf - RDNSS/DNSSL related

[Mattia Rossi]

On 10/08/2011 17:29, Hajimu UMEMOTO wrote:

Hi,


On Mon, 08 Aug 2011 16:42:06 +1000
Mattia Rossimro...@swin.edu.au  said:


mrossi  Anyhow, the manpage is really not clear about name_servers_append, and
mrossi  it's not working as expected either:

mrossi  1) If I put in a comma separated list of nameservers, I'll find that
mrossi  comma separated list in /etc/resolv.conf under a single nameserver
mrossi  tag. That doesn't work, as it's not a valid entry. Each nameserver
mrossi  needs to have a nameserverhost entry.

name_servers and name_servers_append is a space separated list of
nameserver.


Ahh, okay, that works. Might be worth mentioning in the manpage though. 
Maybe an example wouldn't be too bad either




mrossi  2) If I use multiple name_servers_append entries in
mrossi  /etc/resolvconf.conf, then only the last entry is used. I don't want
mrossi  only one DNS server there though, I want all three of them, as I
mrossi  already had the problem that one or the other didn't work properly.

You can specify multiple nameservers in name_servers and/or
name_servers_append.


Of course, once 1) is solved 2) is redundant.


mrossi  3) If I read the description for name_servers in resolvconf.conf(5), I
mrossi  understand that this tag prepends the nameserver to my list. This is
mrossi  not what happens. Still not sure what actually happens there...

It is strange to me.  If you specify name_servers, it should be
prepended to the nameserver list.  I've just tried name_servers, and
it did the job as expected, here.


Hmm, not sure what happened last time here, but I've tried it now with a 
single nameserver, a space separated list of nameservers and a mix of 
name_servers and name_servers_append entries and it worked perfectly.
It also eliminated duplicate entries in name_servers and 
name_servers_append, preferring the one in name_servers. Again, maybe 
worthwhile mentioning in the manpage.




mrossi  How do I get my 3 manual DNS entries properly into my resolv.conf ?

Please specify your 3 servers as space separated list in name_servers
or name_servers_append.



Yes, got it. All good! Thanks to all!

Mat
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: resolvconf script overwrites entries in resolv.conf - RDNSS/DNSSL related

[Mattia Rossi]

On 05/08/2011 16:52, Doug Barton wrote:

On 08/04/2011 22:59, Mattia Rossi wrote:

Hi all,

I've finally patched my 8.2 IPv6 gateway with the RDNSS/DNSSL patches
and I'm distributing DNS servers that way now. Works fine, my box
running CURRENT picks up the DNS servers and search domains and writes
them into /etc/resolv.conf using the resolvconf script.

The script anyhow overwrites my previous manual entries in
/etc/resolv.conf which I need for my manual IPv4 setup...

I think it's an easily fixable bug - haven't looked into it that close
atm., but given that the resolvconf script is going to be
rewritten/enhanced anyways, that's something to keep in mind.
I think that manual entries should always be preferred.


Check 'man resolvconf.conf' for information on name_servers_append. It
would probably be nice if there was a _prepend equivalent.



Okay, finally got around to read that manpage (which I didn't realise 
that it existed). So For RDNSS/DNSSL we have now the following manpages 
related to resolv.conf: resolvconf(8), resolv.conf(5) (aka. resolver(5)) 
and resolvconf.conf(5)... Lot's of resolvconfs :-)


Anyhow, the manpage is really not clear about name_servers_append, and 
it's not working as expected either:


1) If I put in a comma separated list of nameservers, I'll find that 
comma separated list in /etc/resolv.conf under a single nameserver 
tag. That doesn't work, as it's not a valid entry. Each nameserver needs 
to have a nameserver host entry.


2) If I use multiple name_servers_append entries in 
/etc/resolvconf.conf, then only the last entry is used. I don't want 
only one DNS server there though, I want all three of them, as I already 
had the problem that one or the other didn't work properly.


3) If I read the description for name_servers in resolvconf.conf(5), I 
understand that this tag prepends the nameserver to my list. This is not 
what happens. Still not sure what actually happens there...


How do I get my 3 manual DNS entries properly into my resolv.conf ?

Mat

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: resolvconf script overwrites entries in resolv.conf - RDNSS/DNSSL related

[Mattia Rossi]

On 05/08/2011 20:30, J.R. Oldroyd wrote:

On Thu, 04 Aug 2011 23:52:54 -0700, Doug Bartondo...@freebsd.org  wrote:


On 08/04/2011 22:59, Mattia Rossi wrote:

I've finally patched my 8.2 IPv6 gateway with the RDNSS/DNSSL patches
The script anyhow overwrites my previous manual entries in
/etc/resolv.conf which I need for my manual IPv4 setup...


Check 'man resolvconf.conf' for information on name_servers_append. It
would probably be nice if there was a _prepend equivalent.



Mattia, when you say you have the patches, which ones?

To be clear, the RDNSS/DNSSL support that was committed to head was
very heavily modified from that which I proposed and which is on my
web site.  In particular, the resolvconf(8) tool that I offered was
not used at all; the version in head is the openresolv tool by Roy
Marples.  Doug's response is in regard to the resolvconf version
in head.


I'm using the patches from your website on my 8.2 box, which is the IPv6 
gateway and runs rtadvd. The problem with the resolv.conf is happening 
on my client though, which is a box running HEAD, so I'll try to follow 
Doug's advice, thanks.


FWIW, the resolvconf version from my site will use the most recent
nameservers received by from either dhclient-script or rtadvd but you
can also add static entries using standard resolv.conf syntax in the
/var/db/resolv.db file; see the man page with that version.


I'll remember to read the manpages more thoroughly :-)


I will update my RDNSS/DNSSL web page now to add a warning that my
patches have been superseded and that folk should use the committed
versions where possible.

Is there any chance that you could create a patch for 8.2 based on the 
commits in HEAD?

That would be great!

Thanks,

Mat

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

resolvconf script overwrites entries in resolv.conf - RDNSS/DNSSL related

[Mattia Rossi]

Hi all,

I've finally patched my 8.2 IPv6 gateway with the RDNSS/DNSSL patches 
and I'm distributing DNS servers that way now. Works fine, my box 
running CURRENT picks up the DNS servers and search domains and writes 
them into /etc/resolv.conf using the resolvconf script.


The script anyhow overwrites my previous manual entries in 
/etc/resolv.conf which I need for my manual IPv4 setup...


I think it's an easily fixable bug - haven't looked into it that close 
atm., but given that the resolvconf script is going to be 
rewritten/enhanced anyways, that's something to keep in mind.

I think that manual entries should always be preferred.

Mat
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: IPv6 tunnel problem

[Mattia Rossi]

On 15/04/11 23:58, Marcin Cieslak wrote:

Mattia Rossimro...@swin.edu.au  wrote:

I have accept_rtadv enabled if it's not a router. See my post.


I think I have a similar setup (only using sixxs-aiccu). Since
my machine is a gateway to the outside IPv6 world (via www.sixxs.net)
I am not accepting router adverisements there, but I'm running
rtadvd and sending them to other hosts on the LAN:

nd6 options=21PERFORMNUD,AUTO_LINKLOCAL



Having ACCEPT_RTADV doesn't change anything. I can disable it by hand, 
so my options are 21PERFORMNUD,AUTO_LINKLOCAL as well and it doesn't work.



ifconfig with tunnel up is:

ifconfig
bge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST  metric 0 mtu 1500

options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE
  ether 00:0d:9d:51:d4:7e
  inet 136.186.229.112 netmask 0xff00 broadcast xxx.xxx.xxx.xxx
  inet6 fe80:::::%bge0 prefixlen 64 scopeid 0x5
  inet6 ::::: prefixlen 64 duplicated

 **
  what's up here?

  nd6 options=23PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL
  media: Ethernet autoselect (1000baseTfull-duplex)
  status: active


Why is this address duplicated? If this machine *is* the gateway
to the outside IPv6 world, should *not* it be accepting rtadv
and have a global IPv6 address configured statically

There's no duplicate, maybe obfuscating the IPv6 address was not so 
smart.. There's a link local address (scopeid 0x5) starting with fe80 
installed by auto_linklocal, and the proper address set by the tunnel





tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST  metric 0 mtu 1280
  options=8LINKSTATE
  inet6 fe80:::::%tun0 prefixlen 64 scopeid 0x9
  inet6 :::: --  :::: prefixlen 128
  nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL

  **
  Does ifconfig tun0 inet6 -ifdisabled 
help?

I don't know why gateway6 (I don't use this software) leaves it as IFDISABLED

Haven't realized there was an ifdisabled set. But it doesn't change 
anything unsetting it. Still no IPv6



This is /etc/rc.conf from my tunnel gateway machine (two tunnels, tun0 and
tun1) - it runs a few-month-old -CURRENT:

ipv6_gateway_enable=YES
rtadvd_enable=YES
# Internal WLAN
rtadvd_interfaces=wlan0
ifconfig_wlan0_ipv6=inet6 a::::1/64
# Tunnel via tun0 is configured automatically by aiccu
# and has NO /etc/rc.conf entry at all
# Tunnel via tun1 is configured statically (it serves only some networks)
ifconfig_tun1_ipv6=inet6 a:::8000::1

//Marcin

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

IPv6 tunnel problem

[Mattia Rossi]

Hi all,

I'm having some trouble with my IPv6 tunnel lately (net/gateway6 port).

I'm running revision 220613.

The tunnel runs fine on 8.2, I can ping6 ipv6.google.com from all 
interfaces using all IPv6 addresses. Route Advertisements are sent, 
Linux Machines, Mac OS X machiens and FreeBSD 8.2/8.1 machines are all 
receiveing the advertisements and are able to ping and use the IPv6 network.


On the machines running CURRENT anyhow, route advertisements don't work. 
They arrive at the interface, but nothing happens.
If i set up an IPv6 address and route by hand, I don't get anywhere, as 
it's permanently marked as tentative, and trying to use that address 
as source address in ping6 results in:


ping6: bind: Can't assign requested address

This brings me to my main problem: the tunnel. If I set up a tunnel on a 
CURRENT machine, the tunnel gets set up (because it's IPv4) but the IPv6 
part does not work. I'm not able to send pings (which means KEEPALIVES 
are not sent either), so it just doesn't work.


I'm using IPv6 in UDP over IPv4 tunneling, as that's what I use on the 
8.2 machine as well.


The error when trying to ping on the CURRENT machine where the tunnel 
runs( for the short period the tunnel is up) is:


ping6: sendmsg: Network is down

Route advertisements are not sent either, as again, the IPv6 address 
assigned to the interface by the tunnel is marked as tentative, so 
rtadvd refuses to work.


Something is badly broken with IPv6 and/or NDP.

More info about the systems:

Interfaces in use on the machines running CURRENT:

bge0 and em0

Interfaces on the working 8.2 machine:

fxp0 and em0

sysctls on the broken machines when in router mode:

net.inet6.ip6.forwarding: 1
net.inet6.ip6.redirect: 1
net.inet6.ip6.hlim: 64
net.inet6.ip6.maxfragpackets: 6400
net.inet6.ip6.accept_rtadv: 0
net.inet6.ip6.keepfaith: 0
net.inet6.ip6.log_interval: 5
net.inet6.ip6.hdrnestlimit: 15
net.inet6.ip6.dad_count: 1
net.inet6.ip6.auto_flowlabel: 1
net.inet6.ip6.defmcasthlim: 1
net.inet6.ip6.gifhlim: 30
net.inet6.ip6.kame_version: FreeBSD
net.inet6.ip6.use_deprecated: 1
net.inet6.ip6.rr_prune: 5
net.inet6.ip6.v6only: 1
net.inet6.ip6.rtexpire: 3600
net.inet6.ip6.rtminexpire: 10
net.inet6.ip6.rtmaxcache: 128
net.inet6.ip6.use_tempaddr: 0
net.inet6.ip6.temppltime: 86400
net.inet6.ip6.tempvltime: 604800
net.inet6.ip6.auto_linklocal: 1
net.inet6.ip6.prefer_tempaddr: 0
net.inet6.ip6.use_defaultzone: 0
net.inet6.ip6.maxfrags: 6400
net.inet6.ip6.mcast_pmtu: 0
net.inet6.ip6.mcast.loop: 1
net.inet6.ip6.mcast.maxsocksrc: 128
net.inet6.ip6.mcast.maxgrpsrc: 512
security.jail.param.ip6.saddrsel: 0
security.jail.param.ip6.: 0

on the working machine router mode:

net.inet6.ip6.forwarding: 1
net.inet6.ip6.redirect: 1
net.inet6.ip6.hlim: 64
net.inet6.ip6.maxfragpackets: 6400
net.inet6.ip6.accept_rtadv: 0
net.inet6.ip6.keepfaith: 0
net.inet6.ip6.log_interval: 5
net.inet6.ip6.hdrnestlimit: 15
net.inet6.ip6.dad_count: 1
net.inet6.ip6.auto_flowlabel: 1
net.inet6.ip6.defmcasthlim: 1
net.inet6.ip6.gifhlim: 30
net.inet6.ip6.kame_version: FreeBSD
net.inet6.ip6.use_deprecated: 1
net.inet6.ip6.rr_prune: 5
net.inet6.ip6.v6only: 1
net.inet6.ip6.rtexpire: 3600
net.inet6.ip6.rtminexpire: 10
net.inet6.ip6.rtmaxcache: 128
net.inet6.ip6.use_tempaddr: 0
net.inet6.ip6.temppltime: 86400
net.inet6.ip6.tempvltime: 604800
net.inet6.ip6.auto_linklocal: 1
net.inet6.ip6.prefer_tempaddr: 0
net.inet6.ip6.use_defaultzone: 0
net.inet6.ip6.maxfrags: 6400
net.inet6.ip6.mcast_pmtu: 0
net.inet6.ip6.mcast.loop: 1
net.inet6.ip6.mcast.maxsocksrc: 128
net.inet6.ip6.mcast.maxgrpsrc: 512

If they're not routers:

net.inet6.ip6.forwarding: 0
net.inet6.ip6.redirect: 0
net.inet6.ip6.accept_rtadv: 1

And on the interfaces

ifconfig em0 inet6 accept_rtadv

And finally I have a question:

Why is there a net.inet6.ip6.accept_rtadv sysctl?
If we have to enable/disable route advertisements per interface, this 
sysctl shouldn't be there at all.
Immagine a system (like mine) where you have multiple interfaces, and 
which acts as IPv6 router amongst other stuff.


Shouldn't you be able to deactivate route advertisements on one 
interface, which is where route advertisements are sent from, but enable 
it on the other ones, so you don't need to statically configure them? If 
there's a sysctl, you'll disable and enable route advertisements for the 
whole machine, so the per interface stuff is useless, or am I wrong?


Mat
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: IPv6 tunnel problem

[Mattia Rossi]

I have accept_rtadv enabled if it's not a router. See my post.

ifconfig with tunnel up is:

ifconfig
bge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500

options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE
ether 00:0d:9d:51:d4:7e
inet 136.186.229.112 netmask 0xff00 broadcast xxx.xxx.xxx.xxx
inet6 fe80:::::%bge0 prefixlen 64 scopeid 0x5
inet6 ::::: prefixlen 64 duplicated
nd6 options=23PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL
media: Ethernet autoselect (1000baseT full-duplex)
status: active
fxp0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500

options=4219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO
ether 00:02:b3:eb:28:b0
media: Ethernet autoselect (none)
status: no carrier
plip0: flags=8810POINTOPOINT,SIMPLEX,MULTICAST metric 0 mtu 1500
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384
options=3RXCSUM,TXCSUM
inet 127.0.0.1 netmask 0xff00
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8
nd6 options=21PERFORMNUD,AUTO_LINKLOCAL
tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST metric 0 mtu 1280
options=8LINKSTATE
inet6 fe80:::::%tun0 prefixlen 64 scopeid 0x9
inet6 :::: -- :::: prefixlen 128
nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
Opened by PID 17726


I canceled the address in case you wonder.

Mat
On 15/04/2011 17:54, Marcin Cieslak wrote:

Mattia Rossimro...@swin.edu.au  wrote:

fxp0 and em0


Can you show us what does ifconfig say on
your interfaces? There are few parameters
for the ICMPv6 Neighbor Discovery Protocol
that might be needed:
  ifconfig em0 inet6 accept_rtadv

Those are nicely documented in ifconfig(8).

This is usually handled by the /etc/rc.d/*
stuff IF you have a current version of
/etc/rc.conf settings. (They changed a bit
in the meantime).

//Marcin


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: HEADS UP: OFED stack merge tonight.

[Mattia Rossi]

On 21/03/11 18:36, Jeff Roberson wrote:
[..]

I would not expect any instability in non ofed systems from this import.



Hi Jeff,

I've tried to compile netstat, and it bails out immediately if I try to 
make obj:


/usr/src/usr.bin/netstat/Makefile, line 21: Malformed conditional 
(${MK_OFED} != no)

/usr/src/usr.bin/netstat/Makefile, line 23: if-less endif
make: fatal errors encountered -- cannot continue

Mat
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Is nvidia-driver 256.53 expected to work on -current?

[Mattia Rossi]

On 18/10/2010 10:18, Ralph Ellis wrote:

Doug Barton wrote:

Y'all will probably recall that I had a lot of problems with the
nvidia-driver, and video generally (esp. flash) on i386 -current. Well
I haven't had any problems recently because I haven't been using
FreeBSD. :) But I have things I need to catch up on, so here's what I
did:

1. Bought a new hard drive, and installed a snapshot of amd64 -current
(this was actually done a while ago).
2. Yesterday I started configuring stuff, updated my source and ports
trees, rebuilt the world, customized the kernel, etc.
3. With a newly up to date system I built the latest version of the
nvidia-driver port, and started using it.

My experience with it has been exactly the same as older versions of
the port on previous versions of i386 -current. Sometimes it runs fine
for a while, but whe n I exit the window manager (openbox) the system
hangs and I never get back to the command prompt. (I'm using startx to
try and minimize the number of variables.) Sometimes it will work fine
for an hour, maybe two, then the whole thing just hangs. All the stuff
is displayed on the screen, but the mouse won't move, I can't zap X,
or even switch to the console. I have to power off. This is
particularly frustrating because I haven't even loaded flash (or for
that matter firefox) yet.

Windows and linux (ubuntu, with the nvidia driver) work great on this
same hardware, so I'm pretty thoroughly convinced that the problem is
with freebsd/current somewhere. In addition to the -current partition
I also installed amd64 8.1-RELEASE so I'll give that a go next, but I
wanted to ask here first if anyone else was having problems on -current.


Doug


I am currently running the Nvidia 195 driver on amd64 9 - current from
the ports tree. It works without problems.
When I tried to compile the 256 driver, it would not compile and said
that it was not meant to work with 9 - current.
Hope this helps.
Ralph Ellis
ralphell...@netscape.ca




I have not had any trouble with the new Nvidia drivers at all - but I'm 
running i386, so it might be an amd64 issue.

No compilation issues at all, no problems running, switching to VT etc.

(and yes, I had the same problems as Doug a while ago)

Kernel and world are not from today, but fairly recent though:
FreeBSD 9.0-CURRENT #48 r213491M: Thu Oct  7

See:

(--) PCI:*(0:1:0:0) 10de:06e4:1458:349c nVidia Corporation G98 [GeForce 
8400 GS] rev 161, Mem @ 0xf200/16777216, 0xe000/268435456, 
0xf000/33554432, I/O @ 0x2100/128, BIOS @ 0x/65536

(II) extmod will be loaded by default.
(II) dbe will be loaded by default.
(II) glx will be loaded. This was enabled by default and also 
specified in the config file.

(II) record will be loaded by default.
(II) dri will be loaded by default.
(II) dri2 will be loaded by default.
(II) LoadModule: glx
(II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so
(II) Module glx: vendor=NVIDIA Corporation
compiled for 4.0.2, module version = 1.0.0
Module class: X.Org Server Extension
(II) NVIDIA GLX Module  256.53  Fri Aug 27 20:49:59 PDT 2010
(II) Loading extension GLX
(II) LoadModule: extmod
(II) Loading /usr/local/lib/xorg/modules/extensions/libextmod.so
(II) Module extmod: vendor=X.Org Foundation
compiled for 1.7.5, module version = 1.0.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 2.0
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: dbe
(II) Loading /usr/local/lib/xorg/modules/extensions/libdbe.so
(II) Module dbe: vendor=X.Org Foundation
compiled for 1.7.5, module version = 1.0.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 2.0
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: record
(II) Loading /usr/local/lib/xorg/modules/extensions/librecord.so
(II) Module record: vendor=X.Org Foundation
compiled for 1.7.5, module version = 1.13.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 2.0
(II) Loading extension RECORD
(II) LoadModule: dri
(II) Loading /usr/local/lib/xorg/modules/extensions/libdri.so
(II) Module dri: vendor=X.Org Foundation
compiled for 1.7.5, module version = 1.0.0
ABI class: X.Org Server Extension, version 2.0
(II) Loading extension XFree86-DRI
(II) LoadModule: dri2
(II) Loading /usr/local/lib/xorg/modules/extensions/libdri2.so
(II) Module dri2: vendor=X.Org Foundation
compiled for 1.7.5, module version = 1.1.0
ABI class: X.Org Server Extension, version 2.0
(II) Loading extension DRI2
(II) LoadModule: nvidia
(II) Loading /usr/local/lib/xorg/modules/drivers/nvidia_drv.so
(II) Module nvidia: vendor=NVIDIA Corporation
compiled