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 on the size issue. It should be possible to = accept either int or char as the kernel checks the size.= ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
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 this. It appears to work with FreeBSD 8.4-BETA1 #25 = r248493M. The only point of contention is using sizeof(char) rather than = sizeof(int). Using char is extending the exception from recvmsg and IP_TOS. = sendmsg/recvmsg/setsockopt should all be using the same size. I had to read the kernel code to = work out that it was a 'char' as the header files say 'int' and that is what setsockopt = uses. Mark= ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
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-b90a-6d07a3328...@freebsd.org>, Michael Tuexen w rites: > It was not done by accident. The returned cmsg_type is IP_RECVTOS instead > of IP_TOS to keep it consistent with the handling of the IP_RECVTTL socket > option. > I found it more important to be consistent within the same protocol family > than across different ones. > I think that unfortunately IP_RECVTOS is not defined in any standard. > > Best regards > Michael And Linux uses IP_TOS to return the value. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
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
In message <497b9ff4.30...@freebsd.org>, Doug Barton writes: > Lev Serebryakov wrote: > > Hello, Freebsd-stable. > > > > BIND on my new router (7.1-STABLE, BIND 9.4.3-P1) shows bunch of > > errors on every start and doesn't answer on requests for 30-60 seconds > > after that. Errors are like this: > > It's not necessary or desirable to paste in so many examples of the > same message. It's also not good to cross post the same message to > multiple lists. > > > Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib > /bind9/lib/isc/unix/socket.c:1567: unexpected error: > > Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device > not configured > > That message is fairly clear, the system has told named that it can > talk to the outside world, but there isn't anything there for named to > talk to. As you already pointed out in another message, the IP > addresses are for the root name servers. The first thing named does > when it starts up is to verify the information in the hints file. > > > Main problem is, that mount_nfs failed on startup on this router > > because bind is not ready due to these errors and all system goes to > > single-user mode :( > > Any time you are using NFS you should maintain the addresses of the > critical hosts in /etc/hosts. Yes, I realize that's anachronistic > (especially for a DNS guy) but it works. Obviously you should make > sure to update them as needed. Or keep a local copy of the zone which contains them. If you have a copy in /etc/hosts there should be procedures to keep /etc/hosts in sync with the DNS. > > Computer is Soekris net5501, with 6 network interfaces (vr0-vr3 on > > board, em0 and ath0 attached). Only vr0 and vr1 are used, but adding > > fake addresses to vr2 and vr3 doesn't help at all. > > > > Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect t > o two > > providers. > > > > But previous installation (on faster hardware) doesn't show these > > errors at all! > > I've never used mpd myself, but you might want to try adding the > following line to /usr/local/etc/rc.d/mpd and see 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 > ___ > freebsd-sta...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: BIND 9.4.3-P1: internal_send: 199.7.83.42#53: Device notconfigured, where 199.7.83.42 is RANDOM IP address
In message <497b9ff4.30...@freebsd.org>, Doug Barton writes: > Lev Serebryakov wrote: > > Hello, Freebsd-stable. > > > > BIND on my new router (7.1-STABLE, BIND 9.4.3-P1) shows bunch of > > errors on every start and doesn't answer on requests for 30-60 seconds > > after that. Errors are like this: > > It's not necessary or desirable to paste in so many examples of the > same message. It's also not good to cross post the same message to > multiple lists. > > > Jan 24 12:18:12 gateway named[1455]: /usr/src/lib/bind/isc/../../../contrib > /bind9/lib/isc/unix/socket.c:1567: unexpected error: > > Jan 24 12:18:12 gateway named[1455]: internal_send: 193.0.14.129#53: Device > not configured > > That message is fairly clear, the system has told named that it can > talk to the outside world, but there isn't anything there for named to > talk to. As you already pointed out in another message, the IP > addresses are for the root name servers. The first thing named does > when it starts up is to verify the information in the hints file. > > > Main problem is, that mount_nfs failed on startup on this router > > because bind is not ready due to these errors and all system goes to > > single-user mode :( > > Any time you are using NFS you should maintain the addresses of the > critical hosts in /etc/hosts. Yes, I realize that's anachronistic > (especially for a DNS guy) but it works. Obviously you should make > sure to update them as needed. Or keep a local copy of the zone which contains them. If you have a copy in /etc/hosts there should be procedures to keep /etc/hosts in sync with the DNS. > > Computer is Soekris net5501, with 6 network interfaces (vr0-vr3 on > > board, em0 and ath0 attached). Only vr0 and vr1 are used, but adding > > fake addresses to vr2 and vr3 doesn't help at all. > > > > Also, mpd5 creates two NG interfaces (ng0 and ng1) on startup to connect t > o two > > providers. > > > > But previous installation (on faster hardware) doesn't show these > > errors at all! > > I've never used mpd myself, but you might want to try adding the > following line to /usr/local/etc/rc.d/mpd and see 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 > ___ > freebsd-sta...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ freebsd-sta...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
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 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
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 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., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RES_INSECURE and CHECK_SRVR_ADDR in resolver functions (IPv6 anycast response problem)
> > Hello: > > I need to make some tests with IPv6 anycast addresses, > and I've found out that when /etc/resolv.conf has an > IPv6 anycast address, the DNS response isn't accepted because > it comes from an unicast IPv6 address. > > I've been digging into the source code of > /usr/src/lib/libc/net/res_* > and I've found these constants: > > RES_INSECURE1 > RES_INSECURE2 > > and a compilation option called: > > CHECK_SRVR_ADDR > > > What I would like to do is re-compile > the resolver library to accept DNS responses > coming from a unicast IPv6 address to solve > the problem mentioned above. > > What's better... to *un*define CHECK_SRVR_ADDR > or to include RES_INSECURE1 into RES_DEFAULT ? > Do you think it's a good idea to do this ? > what are the security implications ? > > 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. 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 to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: RES_INSECURE and CHECK_SRVR_ADDR in resolver functions (IPv6 anycast response problem)
> >>>>> On Fri, 20 Sep 2002 08:59:54 +1000, > >>>>> [EMAIL PROTECTED] said: > > > IPv6 anycast addresses are a joke as they are currently > > defined. Don't bother with them until there behaviour > > gets redefined by the IETF. > > (I'm just asking,) what is the "joke" part of the current definition? > The restriction that an anycast address must not be used as a packet's > source address? Yes, and I know why the restriction is in RFC 1884 and it is a reasonable restriction. A client application shouldn't have to care if a packet is sent to a anycast address and the reply should appear to come from the anycast address from the point of view of the application. Until anycast addresses meet the above they will be a joke. With multicast and broadcast you know in advance that you will get return a traffic from a different address. Anycast addresses appear to the client application as unicast addresses. They should behave like unicast addresses for the client application. Server applications may need additional smarts to cope with anycast addresses. But really the IP stack should deal with 99% of this. Mark > > JINMEI, Tatuya > 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 INTERNET: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: RES_INSECURE and CHECK_SRVR_ADDR in resolver functions (IPv6 anycast response problem)
> > Yes, and I know why the restriction is in RFC 1884 and it
> > is a reasonable restriction.
>
> I don't think so,
Are you saying we should source packets from the anycast address?
If not you should quote better.
> IP source address is easy to forge and it does not
> add any meaning protection. DNSSEC is the only way if you want trusted
> responsees. therefore, i agree with enabling RES_INSECURE1 by default.
>
> itojun
Source addresses can be used to seperate multiple queries with the
same query id. While the stub resolver rarely needs to do this
a nameserver will to this all the time. Enabling RES_INSECURE1
just hides the real problem that IPv6 anycast is broken,
encourages broken nameserver implementations and leaves you with
the situation 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 to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: RES_INSECURE and CHECK_SRVR_ADDR in resolver functions (IPv6 anycast response problem)
> > Hello: > > I need to make some tests with IPv6 anycast addresses, > and I've found out that when /etc/resolv.conf has an > IPv6 anycast address, the DNS response isn't accepted because > it comes from an unicast IPv6 address. > > I've been digging into the source code of > /usr/src/lib/libc/net/res_* > and I've found these constants: > > RES_INSECURE1 > RES_INSECURE2 > > and a compilation option called: > > CHECK_SRVR_ADDR > > > What I would like to do is re-compile > the resolver library to accept DNS responses > coming from a unicast IPv6 address to solve > the problem mentioned above. > > What's better... to *un*define CHECK_SRVR_ADDR > or to include RES_INSECURE1 into RES_DEFAULT ? > Do you think it's a good idea to do this ? > what are the security 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., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: rc.order wrong (ipfw)
> Therefore I believe strongly that the default behavior should be
> changed to load all firewalls (and rules) before netif, and that those
> who want to do firewall-related things that require netif or routing
> to be up should be the ones who have to opt in to the new script. That
> 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 4742 INTERNET: [EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
