Re: kern/165305: [ip6] [request] Feature parity between IP_TOS and IPV6_TCLASS

The following reply was made to PR kern/165305; it has been noted by GNATS. From: Mark Andrews To: bug-follo...@freebsd.org, ma...@isc.org Cc: Subject: Re: kern/165305: [ip6] [request] Feature parity between IP_TOS and IPV6_TCLASS Date: Wed, 20 Mar 2013 10:05:41 +1100 As a further followup

Re: kern/165305: [ip6] [request] Feature parity between IP_TOS and IPV6_TCLASS

The following reply was made to PR kern/165305; it has been noted by GNATS. From: Mark Andrews To: bug-follo...@freebsd.org, ma...@isc.org Cc: Subject: Re: kern/165305: [ip6] [request] Feature parity between IP_TOS and IPV6_TCLASS Date: Wed, 20 Mar 2013 10:01:49 +1100 Thanks for adding

Re: kern/177362: [netinet] [patch] Wrong control used to return TOS

The following reply was made to PR kern/177362; it has been noted by GNATS. From: Mark Andrews To: Michael Tuexen Cc: bug-follo...@freebsd.org Subject: Re: kern/177362: [netinet] [patch] Wrong control used to return TOS Date: Wed, 27 Mar 2013 22:54:06 +1100 In message <25eb2335-645c-42ed-b

Re: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device not configured, where 199.7.83.42 is RANDOM IP address

if it helps: > > # BEFORE: named mpd should also be fixed as the error code being returned is not approprate. network unreachable is what should be returned. > Doug > > -- > > This .signature sanitized for your protection > ___ > freeb

Re: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device notconfigured, where 199.7.83.42 is RANDOM IP address

if it helps: > > # BEFORE: named mpd should also be fixed as the error code being returned is not approprate. network unreachable is what should be returned. > Doug > > -- > > This .signature sanitized for your protection > ___ > freeb

Re: udp fragmentation with pf/ipf

This should be rejected as "keep frags" is meaningless here. pass out log quick on bge0 proto udp from xxx.xxx.xxx.113/32 to any port = 53 keep state keep frags You need pass in quick from any to any with frag keep frag -- Mark Andrews, ISC 1

Re: udp fragmentation with pf/ipf

keep frag The reason is that "ip" fragments not have next level headers. > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St.

Re: RES_INSECURE and CHECK_SRVR_ADDR in resolver functions (IPv6 anycast response problem)

mplications ? > > PS: RES_DEFAULT appears in "resolv.h" > > Best Regards. > > -- > JFRH. > IPv6 anycast addresses are a joke as they are currently defined. Don't bother with them until there behaviour gets redefined by the IETF.

Re: RES_INSECURE and CHECK_SRVR_ADDR in resolver functions (IPv6 anycast response problem)

Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > [EMAIL PROTECTED] -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742

Re: RES_INSECURE and CHECK_SRVR_ADDR in resolver functions (IPv6 anycast response problem)

on where the tools using stub resolver "work" but the nameserver doesn't. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] To Unsubscribe: send mail t

Re: RES_INSECURE and CHECK_SRVR_ADDR in resolver functions (IPv6 anycast response problem)

implications ? > > PS: RES_DEFAULT appears in "resolv.h" > > Best Regards. > > -- > JFRH. > If you have to set it then do it in /etc/resolv.conf. options insecure1 Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dun

Re: rc.order wrong (ipfw)

t > said, I think you and I have expressed our opinions pretty clearly on > these points, so I'd suggest that we let someone else have a turn. > > Doug I concur with Doug. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871