Re: forwarding didn't work if wlan0 is member of a bridge

[J.R. Oldroyd]

On Mon, 11 Jan 2016 23:52:47 +0100 Olivier Cochard-Labbé  
wrote:
>
> After weeks of troubleshooting, at last I found how to reproduce this
> problem ;-)
> 
> Here is the setup:
> 
> LAN0 <--> [(re0) fbsd router (bridge0 addm re1 addm wlan0)] <--> Wireless
> LAN
> 
> If interface re1 (bridge0 member with wlan0) is in "active" status
> (=ethernet cable plugged to something): I don't have any problem, all is
> working great for my wireless clients connected to wlan0: They can ping
> devices in LAN0.
> But once I've unplug the ethernet cable connected to re1 (bridge member
> with wlan0) and re1 state switch to "no carrier", Wireless LAN clients are
> not able to reach LAN0.
> 
> Here is my rc.conf with simple subnetting for Adrian ;-)
> 
> wlans_ath0="wlan0"
> ifconfig_wlan0="hostap channel 6"
> create_args_wlan0="wlanmode hostap"
> cloned_interfaces="bridge0"
> ifconfig_re0="inet 1.0.0.1/24"
> ifconfig_re1="up"
> ifconfig_bridge0="inet 1.1.1.1/24 addm re1 addm wlan0 up"
> gateway_enable="YES"
> 
> And an example with re1 in "no carrier" status:
> 
> root@fbsd-router:~ # ifconfig bridge0
> bridge0: flags=8843 metric 0 mtu
> 1500
> ether 02:6b:c0:de:b8:00
> inet 1.1.1.1 netmask 0xff00 broadcast 1.1.1.255
> nd6 options=9
> groups: bridge
> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
> maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
> root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
> member: wlan0 flags=143
> ifmaxaddr 0 port 5 priority 128 path cost 3
> member: re1 flags=143
> ifmaxaddr 0 port 2 priority 128 path cost 55
> 
> 
> root@fbsd-router:~ # ifconfig re1
> re1: flags=8943 metric 0
> mtu 1500
> 
> options=82099
> ether 00:0d:b9:3c:ae:25
> nd6 options=29
> media: Ethernet autoselect (none)
> status: no carrier
> 
> => from a wireless LAN client (1.1.1.2) I'm trying to ping a host on LAN0
> (1.0.0.2):
> 
> root@fbsd-router:~ # tcpdump -pni re0
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes
> 23:38:04.466866 ARP, Request who-has 1.0.0.2 tell 1.0.0.1, length 28
> 23:38:04.467052 ARP, Reply 1.0.0.2 is-at 00:08:a2:09:c4:a2, length 46
> 23:38:04.467090 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 72, seq 1,
> length 64
> 23:38:04.467226 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 72, seq 1, length
> 64
> 23:38:04.467300 IP 1.0.0.1 > 1.0.0.2: ICMP host 1.1.1.2 unreachable, length
> 36
> 23:38:05.483053 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 72, seq 2,
> length 64
> 23:38:05.483259 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 72, seq 2, length
> 64
> 23:38:05.483318 IP 1.0.0.1 > 1.0.0.2: ICMP host 1.1.1.2 unreachable, length
> 36
> 23:38:06.387304 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 72, seq 3,
> length 64
> 23:38:06.387466 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 72, seq 3, length
> 64
> 23:38:06.387514 IP 1.0.0.1 > 1.0.0.2: ICMP host 1.1.1.2 unreachable, length
> 36
> ^C
> 11 packets captured
> 11 packets received by filter
> 0 packets dropped by kernel
> root@fbsd-router:~ # arp -na
> ? (1.1.1.1) at 02:6b:c0:de:b8:00 on bridge0 permanent [bridge]
> ? (1.1.1.2) at fc:64:ba:97:c0:ff on bridge0 expires in 1168 seconds [bridge]
> ? (1.0.0.1) at 00:0d:b9:3c:ae:24 on re0 permanent [ethernet]
> 
> => The FreeBSD router answers "unreacheable" to the host: My wireless LAN
> client never get the ICMP reply.
> 
> => Now I plug eth1 to a dummy machine (just for changing its status):
> 
> root@fbsd-router:~ # ifconfig re1
> re1: flags=8943 metric 0
> mtu 1500
> 
> options=82099
> ether 00:0d:b9:3c:ae:25
> nd6 options=29
> media: Ethernet autoselect (1000baseT )
> status: active
> 
> => and I restart the same ping from the wireless LAN client:
> 
> root@fbsd-router:~ # tcpdump -pni re0
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on re0, link-type EN10MB (Ethernet), capture size 262144 bytes
> 23:44:08.597429 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 74, seq 1,
> length 64
> 23:44:08.597660 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 74, seq 1, length
> 64
> 23:44:09.604447 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 74, seq 2,
> length 64
> 23:44:09.604683 IP 1.0.0.2 > 1.1.1.2: ICMP echo reply, id 74, seq 2, length
> 64
> 23:44:10.609711 IP 1.1.1.2 > 1.0.0.2: ICMP echo request, id 74, seq 3,
> length 64
> 

Re: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)

[J.R. Oldroyd]

On Tue, 03 Mar 2015 23:33:23 +0100 Jean-Sébastien Pédron dumbb...@freebsd.org 
wrote:

 Hi!
 
 Here is a new patch to based on HEAD r279508:
 https://people.freebsd.org/~dumbbell/graphics/drm-update-38.i.patch
 
 You can apply it to a Subversion checkout using the following command:
 svn patch drm-update-38.i.patch
 
 There are few changes:
 o  The panic reported by J.R. Oldroyd is fixed, but not the CP init
problem.
 o  A lock assert was added, suggested by Konstantin Belousov
 

Tested as requested: svn update to r279508 and applied the 38i patch.
Mixed results.

The first boot, done as a warm reboot command while running 10-stable
shows that the CP init failed again and I am back to the mtx_lock panic.

I then let it auto-reboot back into 10-stable (this is an old
10-stable at the time of r271969 10.1-BETA2 but it is one in which the
ring CP init still works).  That shows it boots fine and ring CP inits
OK - even as a warm reboot after the previous failure.

I then thought to try a power-off cold reboot into r279508.  This works,
both ring CP inits OK and no mtx_lock panic.  In fact, I am using it
now to send this report.

So, perhaps the previous fix for the mtx_lock panic wasn't right, but
just seemed to work because I happened to cold-boot those times.

The pattern that's emerging here is that older (mid-2014) kernels
boot and init fine, warm or cold.  The CP init problem started
somewhere mid-2014.  The mtx_lock panic is new, so I am guessing
related to the drm2-38 update.  BOTH CP init and mtx_lock problems
go away when cold booting.

I've uploaded info here:

http://opal.com/jr/freebsd/panic/r279508M/dmesg.txt
http://opal.com/jr/freebsd/panic/r279508M/core.txt.7

The dmesg shows the three boot sequences with annotations to make it
clear which is which.

Above is system with ATI Radeon RS690 X1270 IGP, RS690.

BTW, I now also have the ring CP init failure on a second system
that was just updated to 10.1-RELEASE-p6.  It has ATI Radeon HD 4200
which is RS780 and it also shows the ring init failure at CAFEDEAD
but in r600_ting_test().  Unfortunately, this system is a production
one so I can't easily play with it.  Note, no mtx_lock panic here.
Fortunately, the graphics not working isn't a problem on this system.

-jr


pgpZ9qNOg7N2y.pgp
Description: OpenPGP digital signature

Re: [Call for testers] DRM device-independent code update to Linux 3.8

[J.R. Oldroyd]

On Fri, 20 Feb 2015 15:49:44 +0100 Anders Bolt-Evensen andersb...@icloud.com 
wrote:
 
 I saw that you had updated your patchfile to drm-update-38.h.patch, and 
 ...
 applied the patch, it seemed to be more successful, but on 22 occations 
 the patch still fails (the following list contains all the fails; the 
 entire output can be seen here: 
 
 Hunk #2 failed at 29.
 1 out of 3 hunks failed--saving rejects to sys/dev/drm2/drm_agpsupport.c.rej
 Hunk #2 failed at 31.
 1 out of 4 hunks failed--saving rejects to sys/dev/drm2/drm_auth.c.rej
 Hunk #2 failed at 31.
 1 out of 26 hunks failed--saving rejects to sys/dev/drm2/drm_bufs.c.rej
 Hunk #2 failed at 31.
 1 out of 17 hunks failed--saving rejects to sys/dev/drm2/drm_context.c.rej
 Hunk #1 failed at 21.
 1 out of 39 hunks failed--saving rejects to sys/dev/drm2/drm_crtc.h.rej
 Hunk #2 failed at 31.
 1 out of 5 hunks failed--saving rejects to sys/dev/drm2/drm_dma.c.rej
 Hunk #1 failed at 0.
 1 out of 1 hunks failed--saving rejects to sys/dev/drm2/drm_drawable.c.rej
 Hunk #2 failed at 44.
 1 out of 8 hunks failed--saving rejects to sys/dev/drm2/drm_drv.c.rej
 Hunk #1 failed at 19.
 1 out of 5 hunks failed--saving rejects to sys/dev/drm2/drm_edid.h.rej
 Hunk #1 failed at 21.
 1 out of 17 hunks failed--saving rejects to 
 sys/dev/drm2/drm_edid_modes.h.rej
 Hunk #1 failed at 26.
 1 out of 7 hunks failed--saving rejects to sys/dev/drm2/drm_fb_helper.h.rej
 Hunk #2 failed at 32.
 1 out of 9 hunks failed--saving rejects to sys/dev/drm2/drm_fops.c.rej
 Hunk #1 failed at 19.
 1 out of 3 hunks failed--saving rejects to sys/dev/drm2/drm_fourcc.h.rej
 Hunk #1 failed at 0.
 1 out of 1 hunks failed--saving rejects to sys/dev/drm2/drm_internal.h.rej
 Hunk #2 failed at 31.
 1 out of 4 hunks failed--saving rejects to sys/dev/drm2/drm_ioctl.c.rej
 Hunk #2 failed at 27.
 1 out of 50 hunks failed--saving rejects to sys/dev/drm2/drm_irq.c.rej
 Hunk #2 failed at 31.
 1 out of 3 hunks failed--saving rejects to sys/dev/drm2/drm_lock.c.rej
 Hunk #2 failed at 31.
 1 out of 2 hunks failed--saving rejects to sys/dev/drm2/drm_memory.c.rej
 Hunk #1 failed at 25.
 1 out of 10 hunks failed--saving rejects to sys/dev/drm2/drm_mm.h.rej
 Hunk #1 failed at 22.
 1 out of 11 hunks failed--saving rejects to sys/dev/drm2/drm_mode.h.rej
 Hunk #1 failed at 0.
 1 out of 1 hunks failed--saving rejects to sys/dev/drm2/drm_sman.c.rej
 Hunk #1 failed at 0.
 1 out of 1 hunks failed--saving rejects to sys/dev/drm2/drm_sman.h.rej
 ___

Same errors here.  Applying patch to r279092 from svn master.

Did you diff against the github source and is there perhaps some
divergence between that and the svn master?

I worked through the rejects and applied them manually.

But, booting does not go well:

Feb 20 21:58:22 xx kernel: panic: mtx_lock() of destroyed mutex @ 
/usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_irq.c:1036
Feb 20 21:58:22 xx kernel: cpuid = 0
Feb 20 21:58:22 xx kernel: KDB: stack backtrace:
Feb 20 21:58:22 xx kernel: db_trace_self_wrapper() at 
db_trace_self_wrapper+0x2b/frame 0xfe00b2966600
Feb 20 21:58:22 xx kernel: vpanic() at vpanic+0x189/frame 0xfe00b2966680
Feb 20 21:58:22 xx kernel: kassert_panic() at kassert_panic+0x132/frame 
0xfe00b29666f0
Feb 20 21:58:22 xx kernel: __mtx_lock_flags() at __mtx_lock_flags+0x14a/frame 
0xfe00b2966740
Feb 20 21:58:22 xx kernel: drm_vblank_post_modeset() at 
drm_vblank_post_modeset+0x3f/frame 0xfe00b2966770
Feb 20 21:58:22 xx kernel: atombios_crtc_dpms() at 
atombios_crtc_dpms+0x208/frame 0xfe00b29667b0
Feb 20 21:58:22 xx kernel: atombios_crtc_commit() at 
atombios_crtc_commit+0x14/frame 0xfe00b29667e0
Feb 20 21:58:22 xx kernel: drm_crtc_helper_set_mode() at 
drm_crtc_helper_set_mode+0x480/frame 0xfe00b2966a30
Feb 20 21:58:22 xx kernel: drm_crtc_helper_set_config() at 
drm_crtc_helper_set_config+0x9c1/frame 0xfe00b2966b00
Feb 20 21:58:22 xx kernel: vt_restore_fbdev_mode() at 
vt_restore_fbdev_mode+0x4e/frame 0xfe00b2966b20
Feb 20 21:58:22 xx kernel: taskqueue_run_locked() at 
taskqueue_run_locked+0xf0/frame 0xfe00b2966b80
Feb 20 21:58:22 xx kernel: taskqueue_thread_loop() at 
taskqueue_thread_loop+0x9b/frame 0xfe00b2966bb0
Feb 20 21:58:22 xx kernel: fork_exit() at fork_exit+0x84/frame 
0xfe00b2966bf0
Feb 20 21:58:22 xx kernel: fork_trampoline() at fork_trampoline+0xe/frame 
0xfe00b2966bf0
Feb 20 21:58:22 xx kernel: --- trap 0, rip = 0, rsp = 0xfe00b2966cb0, rbp = 
0 ---
Feb 20 21:58:22 xx kernel: Uptime: 37s
Feb 20 21:58:22 xx kernel: Dumping 236 out of 2915 
MB:..7%..14%..21%..34%..41%..55%..61%..75%..82%..95%
Feb 20 21:58:22 xx kernel: Dump complete
Feb 20 21:58:22 xx kernel: Automatic reboot in 15 seconds - press a key on the 
console to abort
Feb 20 21:58:22 xx kernel: Rebooting...

I can also see earlier that the cp still did not init... same old
CAFEDEAD in r100_cp_init.

Chip is ATI Radeon RS690 X1270 IGP.

-jr

boot panic r278740: Most recently used by acpica

[J.R. Oldroyd]

Hi,

Just built 11-CURRENT in order to debug a radeon initialization
problem.

Clean svn source download of r278740.

Followed make buildworld/make buildkernel etc procedure.

System panics during boot of kernel with several LOR indications.

Haven't run -CURRENT on this system for a while so can't say from
which commit point this problem started, however:

- System boots fine (but with radeon init problem) on 10-STABLE.

- System boots fine and radeon inits OK on 10-STABLE r269271.

Detailed panic info here:

http://opal.com/jr/freebsd/panic/r278740/dmesg.txt
http://opal.com/jr/freebsd/panic/r278740/info.2
http://opal.com/jr/freebsd/panic/r278740/core.txt.2

-jr


pgpCW53kupojC.pgp
Description: OpenPGP digital signature

timezone for 100.chksetuid

[J.R. Oldroyd]

I would like to propose that a timezone setting be possible for the

src/etc/periodic/security/100.chksetuid

script.  Either fix it at something like UTC, or add an rc.conf setting
that specifies what timezone to use.  Or both, default to UTC but allow
a timezone setting in rc.conf.

Reason for this is that for folk who travel, the 100.chksetuid script
generates and diffs find -ls output and this output changes if you
change timezones and update the system timezone setting while you are
away.  It then changes back again when you return.  If you travel a lot,
the two timezone changes cause this script to flag every setuid file as
having changed (twice), when all that changed is the time display.  This
means that real changes during the same period will likely be overlooked
and the frequent non-real diffs tend to make one likely to ignore this
section.

-jr
___
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: timezone for 100.chksetuid

[J.R. Oldroyd]

On Fri, 16 May 2014 16:09:37 +0100 Tom Evans tevans...@googlemail.com wrote:
 
 Do you mean you are changing /etc/localtime whenever you move to
 another timezone?
 
Yes, precisely.

 I would suggest stopping doing that! Instead just set TZ in your user
 environment to whatever TZ you want. That way, your programs will all
 be localised correctly, and scripts which run as root will remain
 consistent.
 
Good suggestion, but that would cause those scripts run as root to be run
at the wrong time of day, cron jobs for example, or to reflect the wrong
time and timezone, e.g., sendmail timestamps, syslog messages, etc.  No
big deal for short trips, but it's not what you want on longer, extended
trips.

-jr


signature.asc
Description: PGP signature

Re: DTrace of radeonkms on 9.1

[J.R. Oldroyd]

On Mon, 1 Apr 2013 14:36:52 +0200 Alexander Leidinger alexan...@leidinger.net 
wrote:

 On Wed, 27 Mar 2013 18:07:14 -0400
 J.R. Oldroyd f...@opal.com wrote:
 
  Is there any known magic involved in getting DTrace to do its thing on
  9.1-release?
  
  I am trying to use it to debug a memory leak problem with the
  radeonkms driver under 9.x.
 
 Can you check if you have the same dtrace-problem with -current? I
 would expect that 9.1 already has some dtrace-fixes regarding new
 probes in run-time loaded modules, this is just to verify this
 assumption.
 
 Assuming there is some kind of dead-lock in this module-load interaction
 with dtrace, you could modify the radeonkms module to do it's
 initialization magic once a sysctl is set to 1, instead of doing this
 magic at module-load time. This way you could load the module, start
 the dtrace script and then issue the magic sysctl.
 
 Bye,
 Alexander.
 

Thanks for the suggestion.

The problem I was hoping to use DTrace to debug turned out to be
an incompletely back-ported vm_alloc_page_contig() function.  This
was discovered using careful code analysis.  Having improved the
back-port of this function, the radeonkms driver is now running
fine on 9.1-release.  The need for DTtrace has therefore gone away
for the time being.

That said, the back-port of the VM function is not 100%, yet.
I've had to put this on hold due to other commitments, but when
I get back to this, I probably need to talk to our VM experts to
get a list of commits that will be needed to properly merge that
function into 9-stable.

-jr


signature.asc
Description: PGP signature

DTrace of radeonkms on 9.1

[J.R. Oldroyd]

Is there any known magic involved in getting DTrace to do its thing on
9.1-release?

I am trying to use it to debug a memory leak problem with the radeonkms
driver under 9.x.

Firstly, the following sequence works normally:

boot system
kldload drm2
kldload radeonkms
start xorg
stop xorg
kldunload radeonkms
kldunload drm2

The problem is that, when using xterm, there is a memory leak which
shows as the Free mem counter in top reducing rapidly.

The usual printf debugging isn't helping because we are in a heavily
multi-threaded part of the driver and the printfs are being
interleaved in the kernel buffer.  DTrace's function boundary probes
would be a big help if I could only get them to work.

I've built a dtrace kernel per the instructions in the handbook and
on the DTrace wiki page.  I would now like to do this:

boot system
kldload dtraceall
kldload drm2
dtrace -o dtrace.log -s script.d
(the script will use fbt probes on various
functions currently in the drm2 module)
kldload radeonkms
start xorg and do various things that provoke the leak
stop xorg
kldunload radeonkms
kill the dtrace script
kldunload drm2
kldunload dtraceall

then go look at the log results.

But, the system is stopping dead shortly after the radeonkms load.
It also stops dead if I load radeonkms without starting the dtrace
script.  The presence of the dtraceall module appears to be causing
the radeonkms module load to fail.

Now the radeonkms module does initialize and switch the console to
the graphics mode before the system stops.  There is about 5-10 sec
of what looks like the normal driver init sequence before the system
stops.  When the system stops there is no panic.  It just stops dead.
No keyboard/mouse, no netowrk/ssh - dead.  A hard power-off and reboot
is needed afterwards.

It's perhaps worth mentioning that the leak I am trying to trace is
probably not a simple malloc/free leak.  There are no leak messages
in the log after the normal module load/unload sequence.  This driver
also does VM allocs and manages its own pages and the problem could
be there.

Any suggestions on how to persuade DTrace to work would be great.
Thanks,
-jr
___
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: r247835: drm2 code breaks buildkernel

[J.R. Oldroyd]

On Tue, 05 Mar 2013 15:13:12 +0100 Jean-Sébastien Pédron dumbb...@freebsd.org 
wrote:

 On 05.03.2013 13:30, Glen Barber wrote:
  dev/drm2/ttm/ttm_lock.h:208: warning: redundant redeclaration of 
  'ttm_write_unlock' [-Wredundant-decls]
  dev/drm2/ttm/ttm_lock.h:134: warning: previous declaration of 
  'ttm_write_unlock' was here
  dev/drm2/ttm/ttm_lock.h:220: warning: redundant redeclaration of 
  'ttm_write_lock' [-Wredundant-decls]
  dev/drm2/ttm/ttm_lock.h:146: warning: previous declaration of 
  'ttm_write_lock' was here
 
 Those redundant declarations weren't spotted by clang.
 
 Konstantin, would you like me to commit the fix for this? And we need to
 upstream it too.
 
A fix for these is in my big get it to compile patch that I emailed
you both the other day.

  dev/drm2/ttm/ttm_page_alloc.c:122: warning: declaration does not declare 
  anything
  dev/drm2/ttm/ttm_page_alloc.c:123: warning: declaration does not declare 
  anything
 
 These errors and the following are caused by unnamed structs and unions
 inside another struct:
 
 struct ttm_pool_manager {
 ...
 
 union {
 struct ttm_page_poolpools[NUM_POOLS];
 struct {
 ...
 } ;
 };
 };
 
 With default options, clang accepts this but apparently, not gcc.

Experimentation shows that this warning is triggered because we use
-std=iso9899:1999.  It can be turned off again by adding --ms-extensions
too.

Alternatively, my big patch replaces all these anon unions with
named ones.  There are lots of these in this code, though.  Doing
this adds lots of patch bloat.

 I would like an opinion from the toolchain gurus, because I don't know
 what's the proper way to fix this one.
 
 J.R. Oldroyd CC'd, because he started to work on radeonkms backport to 9
 and faced exactly those issues.
 
There is a further problem not mentioned here.  Three of the files
make use of a pointer to a volatile int but later cast this to a
(void *).  Because we also have -Wcast-qual, this cast triggers
cast discards qualifier on pointer target type warnings and because
of -Werror, this then aborts.  What's the best way to fix that?

-jr


signature.asc
Description: PGP signature

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

[J.R. Oldroyd]

On Mon, 08 Aug 2011 10:46:16 +1000, Mattia Rossi mro...@swin.edu.au wrote:
 
 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.
 

Yes, you'll need the openresolv config in this case.

Keep in mind that the resolver only queries at most MAXNS nameservers
where MAXNS is usually 3.  Using the openresolv name_servers_append,
you need to make sure that your static servers are listed within the
first MAXNS entries.  If you have more than MAXNS dynamic servers,
your statically configured ones will be ignored.

I would just point out though that, in general, you shouldn't need
static nameservers just because you have a manual IPv4 configuration.
Nameservers will return both IPv4 and IPv6 addresses regardless of
whether they were queried over 4 or 6.  Of course, if you have an
internal nameserver that has private info not available from the
dynamically learned nameservers, then you will need a static config.
 
 Is there any chance that you could create a patch for 8.2 based on the 
 commits in HEAD?
 That would be great!
 
Better would be to ask hrs@ to MFC his commits to 8-stable.

-jr


signature.asc
Description: PGP signature

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

[J.R. Oldroyd]

On Thu, 04 Aug 2011 23:52:54 -0700, Doug Barton do...@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.

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 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.

-jr


signature.asc
Description: PGP signature