On 2011-11-30, Douglas Maus <dm...@speakeasy.net> wrote: > Followup: > (sorry for unconventional thread posting and the delay - > learning OpenBSD is my very late night hobby > so I'm not subscribed to the misc list)
If you post from gmane's web interface, it will keep the references etc intact, which makes it easier to follow the thread. > stu wrote: >>no dmesg. > > okay - sorry - I've put it at the bottom of this post > (always seems to me like a waste of electrons) That is less important than the time of people who are trying to help. :) >>I suspect some re(4) don't do multicast correctly. does it start >>working if you leave tcpdump running on the interface? > > When I let tcpdump run for a couple minutes before to snag the route > solicitation and advertisement - no help. > How long of a time are you suggesting? Yes that would do the trick (in some cases the nic may need to be in promiscuous mode while the advertisement is received; also in some other cases it may be necessary that it is *not* in promiscuous mode)... > bios0: Supermicro X7SLA ...but I can confirm the realtek nic on those does handle multicast OK with the OpenBSD re(4) driver. >>for your obfuscated MAC addresses, did you just change them in the >>email or did you set them on the nic with ifconfig lladdr? > > no, I did not set them with ifconfig > I just fudged them in the email to hide my MAC > (don't most people do that - make up DEAD:BEEF:CAFE:BABE etc?) Only people who want to make it a bit harder for others to help them ;) (sometimes people use lladdr or similar to change the actualy address on the nice and might inadvertently flip the U/L or multicast bits of the address). (and if you're using IPv6 SLAAC, you'll likely be sending that mac address to all sorts of places anyway...) > here's my rtsol > $ sudo rtsol -d re0 > checking if re0 is ready... > re0 is ready > send RS on re0, whose state is 2 > received RA from fe80::00a1:b1ff:fea1:b1e1 on re0, state is 2 > stop timer for re0 > there is no timer that looks right > It seems to see the RA > however, this doesn't say anything about processing the prefix. > Is there any toggle/flag to get it to output debug info about the prefix? I would watch output from 'tcpdump -nire0 -s1500 -Xvvv icmp6' while doing the rtsol -d re0, you should see something like this:- # tcpdump -nitrunk0 -s1500 -Xvvv icmp6 tcpdump: listening on trunk0, link-type EN10MB tcpdump: WARNING: compensating for unaligned libpcap packets 12:29:33.242725 fe80::21b:21ff:fe2d:f70c > ff02::2: icmp6: router solicitation (src lladdr: 00:1b:21:2d:f7:0c) (len 16, hlim 255) 0000: 6000 0000 0010 3aff fe80 0000 0000 0000 `.....:......... 0010: 021b 21ff fe2d f70c ff02 0000 0000 0000 ..!..-.......... 0020: 0000 0000 0000 0002 8500 4a84 0000 0000 ..........J..... 0030: 0101 001b 212d f70c ....!-.. 12:29:33.727694 fe80::20d:b9ff:fe17:cc4 > ff02::1: icmp6: router advertisement(chlim=64, router_ltime=1800, reachable_time=0, retrans_time=0)(src lladdr: 00:0d:b9:17:0c:c4)(prefix info: LA valid_ltime=2592000, preferred_ltime=604800, prefix=2001:4b10:1002:100::/64) (len 56, hlim 255) 0000: 6000 0000 0038 3aff fe80 0000 0000 0000 `....8:......... 0010: 020d b9ff fe17 0cc4 ff02 0000 0000 0000 ................ 0020: 0000 0000 0000 0001 8600 1fa5 4000 0708 ............@... 0030: 0000 0000 0000 0000 0101 000d b917 0cc4 ................ 0040: 0304 40c0 0027 8d00 0009 3a80 0000 0000 ..@..'....:..... 0050: 2001 4b10 1002 0100 0000 0000 0000 0000 .K............. > mherrb further suggested: >>But you may have a crappy ethernet switch or hub in the path that >>blocks or damages multicast frames. I've had such a device it the >>past. Replacing it by a little more expensive switch fixed my v6 SLAAC >>issues. ...and sometimes the expensive switches need special config ;)
