Re: Assigning source addresses with IPV6_PKTINFO
On Thu, Aug 04, 2011 at 11:23:44PM +0200, Alexander Bluhm wrote: On Thu, Aug 04, 2011 at 05:06:24PM +0200, Mike Belopuhov wrote: I'm not sure it's a desired behavior and afaik it's not possible to achieve this with IPv4 sockets without the need to be a root. Do we want to change that? Yes. KAME fixed that, too. The following change restricts it to the locally configured addresses. Is it a way to go? I would prefer to take as much as possible from the KAME solution. No need to introduce more differently implemented code. Ugh, you want to take the zone crap from KAME? It is just yet another layer of steaming bullshit added on top of an already huge dunghill. -- :wq Claudio
carp ipv6 ndp issue
Feature or bug? Latest snapshot /bsd kernel (03. Aug. 11) does not react to neighbor discovery requests for inet6 address on carp master interface, here. -Florian
Re: Assigning source addresses with IPV6_PKTINFO
* Claudio Jeker cje...@diehard.n-r-g.com [2011-08-05 08:46]: On Thu, Aug 04, 2011 at 11:23:44PM +0200, Alexander Bluhm wrote: On Thu, Aug 04, 2011 at 05:06:24PM +0200, Mike Belopuhov wrote: I'm not sure it's a desired behavior and afaik it's not possible to achieve this with IPv4 sockets without the need to be a root. Do we want to change that? Yes. KAME fixed that, too. The following change restricts it to the locally configured addresses. Is it a way to go? I would prefer to take as much as possible from the KAME solution. No need to introduce more differently implemented code. Ugh, you want to take the zone crap from KAME? It is just yet another layer of steaming bullshit added on top of an already huge dunghill. and, seriously, don't diverge from KAME is bullshit anyways, given how much we diverged already. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: carp ipv6 ndp issue
Are you using global IPv6 addresses for your test or link-local addresses for your test? I have found that you sometimes need to ping6 the link-local address on a carp interface from a workstation before it will respond to ndp. For reference, this scenario happens if you run rtadvd against a carp interface for fail-over routers to advertise the carp address for routing. Thanks, Penned by Florian Fuessl on 20110805 7:00.21, we have: | Feature or bug? | | | | Latest snapshot /bsd kernel (03. Aug. 11) does not react to neighbor | discovery requests for inet6 address on carp master interface, here. | | | | -Florian -- Todd Fries .. t...@fries.net _ | \ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC \ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX) | 2525 NW Expy #525, Oklahoma City, OK 73112 \ sip:freedae...@ekiga.net | ..in support of free software solutions. \ sip:4052279...@ekiga.net \\ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt
Re: Assigning source addresses with IPV6_PKTINFO
i've looked at it again and although it's a bit more involved,
it's better (it calles selectroute) than what i was going to
do by calling rtalloc in place in the other solution.
so just everyone understands, it works by figuring out the
destination interface (by looking at ipi6_ifindex or doing
an route lookup) and looking up the provided address in the
interface address tree. if needed it embeds the scope from
the outgoing interface. while doing that it does several
additional checks (route is available, address is unicast,
etc).
this fixes jeremy's test case and solves a bunch of problems
with assigning addresses that don't belong us.
opinions?
On Thu, Aug 04, 2011 at 23:29 +0200, Mike Belopuhov wrote:
i saw what kame did. be my guest and try to port that.
On Thu, Aug 4, 2011 at 11:23 PM, Alexander Bluhm
alexander.bl...@gmx.net wrote:
On Thu, Aug 04, 2011 at 05:06:24PM +0200, Mike Belopuhov wrote:
I'm not sure it's a desired behavior and afaik it's not possible
to achieve this with IPv4 sockets without the need to be a root.
Do we want to change that?
Yes. KAME fixed that, too.
The following change restricts it to the locally configured
addresses. Is it a way to go?
I would prefer to take as much as possible from the KAME solution.
No need to introduce more differently implemented code.
bluhm
Index: in6_src.c
===
RCS file: /home/cvs/src/sys/netinet6/in6_src.c,v
retrieving revision 1.25
diff -u -p -u -p -r1.25 in6_src.c
--- in6_src.c 7 May 2010 13:33:17 - 1.25
+++ in6_src.c 5 Aug 2011 18:00:00 -
@@ -86,6 +86,8 @@
#include netinet6/ip6_var.h
#include netinet6/nd6.h
+int in6_selectif(struct sockaddr_in6 *, struct ip6_pktopts *,
+struct ip6_moptions *, struct route_in6 *, struct ifnet **);
int selectroute(struct sockaddr_in6 *, struct ip6_pktopts *,
struct ip6_moptions *, struct route_in6 *, struct ifnet **,
struct rtentry **, int);
@@ -110,11 +112,41 @@ in6_selectsrc(struct sockaddr_in6 *dstso
/*
* If the source address is explicitly specified by the caller,
-* use it.
+* check if the requested source address is indeed a unicast address
+* assigned to the node, and can be used as the packet's source
+* address. If everything is okay, use the address as source.
*/
if (opts (pi = opts-ip6po_pktinfo)
- !IN6_IS_ADDR_UNSPECIFIED(pi-ipi6_addr))
+ !IN6_IS_ADDR_UNSPECIFIED(pi-ipi6_addr)) {
+ struct ifnet *ifp = NULL;
+ struct sockaddr_in6 sa6;
+
+ /* get the outgoing interface */
+ if ((*errorp = in6_selectif(dstsock, opts, mopts, ro,
+ ifp)) != 0)
+ return (NULL);
+
+ bzero(sa6, sizeof(sa6));
+ sa6.sin6_family = AF_INET6;
+ sa6.sin6_len = sizeof(sa6);
+ sa6.sin6_addr = pi-ipi6_addr;
+
+ if (ifp !(ifp-if_flags IFF_LOOPBACK))
+ sa6.sin6_addr.s6_addr16[1] =
+ htons(in6_addr2scopeid(ifp, sa6.sin6_addr));
+
+ ia6 = (struct in6_ifaddr *)
+ ifa_ifwithaddr((struct sockaddr *)sa6, 0);
+ if (ia6 == NULL ||
+ (ia6-ia6_flags (IN6_IFF_ANYCAST | IN6_IFF_NOTREADY))) {
+ *errorp = EADDRNOTAVAIL;
+ return (NULL);
+ }
+
+ pi-ipi6_addr = sa6.sin6_addr; /* XXX: this overrides pi */
+
return (pi-ipi6_addr);
+ }
/*
* If the source address is not specified but the socket(if any)
@@ -480,6 +512,51 @@ selectroute(struct sockaddr_in6 *dstsock
*retrt = rt;/* rt may be NULL */
return (error);
+}
+
+int
+in6_selectif(struct sockaddr_in6 *dstsock, struct ip6_pktopts *opts,
+struct ip6_moptions *mopts, struct route_in6 *ro, struct ifnet **retifp)
+{
+ int error, clone;
+ struct rtentry *rt = NULL;
+
+ clone = IN6_IS_ADDR_MULTICAST(dstsock-sin6_addr) ? 0 : 1;
+ if ((error = selectroute(dstsock, opts, mopts, ro, retifp,
+ rt, clone)) != 0)
+ return (error);
+
+ /*
+* do not use a rejected or black hole route.
+* XXX: this check should be done in the L2 output routine.
+* However, if we skipped this check here, we'd see the following
+* scenario:
+* - install a rejected route for a scoped address prefix
+* (like fe80::/10)
+* - send a packet to a destination that matches the scoped prefix,
+* with ambiguity about the scope zone.
+* - pick the outgoing interface from the route, and disambiguate the
+* scope zone with the interface.
+* - ip6_output() would try to get another route with the new
+* destination, which may be valid.
+* -
Re: carp ipv6 ndp issue
On Fri, Aug 05, 2011 at 02:00:21PM +0200, Florian Fuessl wrote: Feature or bug? Sounds like a bug, but I cannot reproduce it. Latest snapshot /bsd kernel (03. Aug. 11) does not react to neighbor discovery requests for inet6 address on carp master interface, here. With this kernel kern.version=OpenBSD 5.0 (GENERIC) #30: Wed Aug 3 16:08:44 MDT 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC and this carp device carp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:00:5e:00:01:01 priority: 0 carp: MASTER carpdev ne3 vhid 1 advbase 1 advskew 0 groups: carp status: master inet6 fdd7:e83e:66bc:7:200:5eff:fe00:101 prefixlen 64 inet6 fe80::200:5eff:fe00:101%carp0 prefixlen 64 scopeid 0x5 ndp and ping6 fdd7:e83e:66bc:7:200:5eff:fe00:101 works for me. To figure out what is going on I need more information: - Is this a regression? Did it work before? - Please set sysctl net.inet6.icmp6.nd6_debug=1 and look for errors in dmesg. - What icmp6 packets do you see with tcpdump? - How is your configuration and setup? bluhm
Comunicacion no verbal
CAPACITACION TEORICO- PRACTICA EN LENGUAJE CORPORAL,LECTURA DEL ROSTRO Y COMUNICACISN NO VERBAL Curso en un CD para realizar desde su casa u oficina en su tiempo libre sin necesidad de asistir a clases ni seminarios Incluye archivos de word,pdf , didacticos videos explicativos y software para aplicar lo aprendido Temario: Expresion digital(qui decimos) y expresion analsgica (csmo lo decimos). El verdadero significado de cada movimiento y cada gesto corporal de nuestro interlocutor Gestos que delatan la mentira Como detectar la mentira el ambito laboral,de los negocios en la politica y en la vida diaria a traves de los gestos de nuestro interlocutor Posturas corporales, distancias hacia los demas, gestos con manos y brazos, expresiones faciales, tono y volumen de voz, mirada, dilatacisn de pupila Como descifrar el verdadero mensaje que estamos recibiendo Como descifrar el estado, la actitud y algunas emociones en las demas personas. Conceptos de Kinesia,Paralingumstica y Proxemia Gestos y expresiones faciales Csmo interpretar y csmo utilizar la Comunicacisn No verbal Solicitelo a capacit...@gmail.com por $150 indicando nombre direccisn, localidad y csdigo postal. Envios sin cargo por Correo Argentino contra reembolso. Envmos a Capital por mensajeria (indicando el horario de su preferencia)
Re: carp ipv6 ndp issue
On Sat, Aug 06, 2011 at 12:47:27AM +0200, Alexander Bluhm wrote:
To trigger the bug, you need two adresses in the same network on
the carp and on the parent interface. One of them has the route,
the other cannot do ndp.
The bridge has the same problem there, bridge and carp can be fixed
in the same way.
In my experience ipv6 bridge has always been broken and has more
issues. Do we want this larger diff in release mode?
bluhm
Index: netinet6/in6.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet6/in6.c,v
retrieving revision 1.91
diff -u -p -r1.91 in6.c
--- netinet6/in6.c 26 Jul 2011 21:19:51 - 1.91
+++ netinet6/in6.c 6 Aug 2011 05:04:18 -
@@ -61,6 +61,9 @@
* @(#)in.c8.2 (Berkeley) 11/15/93
*/
+#include bridge.h
+#include carp.h
+
#include sys/param.h
#include sys/ioctl.h
#include sys/errno.h
@@ -1945,7 +1948,16 @@ in6_ifpprefix(const struct ifnet *ifp, c
if (rt == NULL)
return (0);
if ((rt-rt_flags (RTF_CLONING | RTF_CLONED)) == 0 ||
- rt-rt_ifp != ifp) {
+ (rt-rt_ifp != ifp
+#if NBRIDGE 0
+ (rt-rt_ifp-if_bridge == NULL || ifp-if_bridge == NULL ||
+ rt-rt_ifp-if_bridge != ifp-if_bridge)
+#endif
+#if NCARP 0
+ (ifp-if_type != IFT_CARP || rt-rt_ifp != ifp-if_carpdev)
+ (rt-rt_ifp-if_type != IFT_CARP || rt-rt_ifp-if_carpdev != ifp)
+#endif
+ 1)) {
RTFREE(rt);
return (0);
}
