OpenBSD ignoring RFC-compliant IPv6 neighbor solicitation?
All, I got my first non-tunneled IPv6 uplink a while ago, and now I have issues with NDP. Over the same shared LAN, the ISP apparently serves several (more than one, but as far as I can see not neccessarily more than two) customer routers, with a logical /125 transfer network for each customer. What I currently see, is this: 1) 2001:db8:1234:5678::08/125 - Someone else's transfer network 2) 2001:db8:1234:5678::10/125 - My transfer network What happens now is that the ISP router sometimes sends neigbor solicitation requests for my OpenBSD router using a source IP from its proper physical interface, but a different logical network. In this case: 2001:db8:1234:5678::9 When the NDP solicitations from 2001:db8:1234:5678::9 come in, OpenBSD does not respond to them, apparently because their source IP doesn't match the OpenBSD router's own prefix. The ISP router receives no neighbor advertisement from my OpenBSD router, and deems it unreachable. IPv6 is now down until a while later, when the solicitations happen to come from 2001:db8:1234:5678::11 again. RFC4861 says about the source IP for neighbor solicitations, that it has to be an address assigned to the interface from which this message is sent. The ISP router firmware interprets this to mean any address from the interface, thus using an IP from a different logical subnet. OpenBSD, in turn, does not seem to be willing to respond to requests from a different subnet. This was reproduced with OpenBSD 5.2-release, with pf turned off. It also happens on the production router, which happens to still run OpenBSD 4.6. To try to better understand the issue, I also set up a Linux system (Debian 6), which does in fact send advertisements in response to those wrong-prefix solicitations. What I understand is that either OpenBSD or the ISP router interpret the RFC in a way that leads to unintended results. Is this a bug in OpenBSD? Is there a workaround, e.g. in the form of a sysctl or a pf.conf hack that will make OpenBSD's NDP more liberal? Thanks for all input, -martin
Re: OpenBSD ignoring RFC-compliant IPv6 neighbor solicitation?
Am 11.02.2013 12:12, schrieb Stefan Sperling:
I believe the code path you're hitting is this one in netinet6/nd6_nbr.c,
in nd6_ns_input():
} else {
/*
* Make sure the source address is from a neighbor's address.
*/
if (!in6_ifpprefix(ifp, saddr6)) {
nd6log((LOG_INFO, nd6_ns_input:
NS packet from non-neighbor\n));
goto bad;
}
}
Thanks for your quick response!
The ISP has now worked around the issue by adding a fixed NDP entry for
my router's address so I can't really test with it, but I have added
another address on the interface, which gives me this, after sysctl
net.inet6.icmp6.nd6_debug=1:
nd6_ns_input: src=2001:0db8:1234:5678::0009
nd6_ns_input: dst=ff02:0001::0001:ff00:0015
nd6_ns_input: tgt=2001:0db8:1234:5678::0015
nd6_ns_input: NS packet from non-neighbor
Have you tried using a /64 netmask at your end of the transfer link,
instead of the /125?
I had already tried /123, which made it work. Such a workaround comes
across a bit desperate, because with further expansion of the ISP's IPv6
customer base, further widening of the prefix will be required. I'm not
sure whether this is how the uplink is intended to work and if it has
the potential to do any damage.
How is your understanding of NDP? Do you think OpenBSD is at fault for
ignoring these solicitations, or do you think the ISP router's OS
selects the wrong source IP? The wording in the RFC is really very terse
and leaves room for interpretation.
-martin
[demime 1.01d removed an attachment of type application/pgp-signature which had
a name of signature.asc]
PPPoE for IPv6
Now I'm in trouble! ;-) I've been using IPv6 via tunnel for a while, with decent success. Lately, I have found an ISP here in Germany who hands out free native IPv6 access, which is to be used on top of the existing DSL line. And I already have an account with them. How do I configure PPPoE for IPv6? Is the example from pppoe(4), with the 0.0.0.0 etc. dummy addresses, also valid for a pure IPv6 connection, or do I have to set it up in a different way? (I have never before configured PPPoE on OpenBSD.) Kind regards, -martin -- Martin Schmitt / Schmitt Systemberatung / www.scsy.de -- http://www.pug.org/index.php/Benutzer:Martin -- [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Postprocessing pf label data
Hi all! Now that pfctl -sl gives me a neat lot of detailed traffic stats, I'm wondering: Is there some tool around that can handle this data right out of the box, similar to what Cacti does for interface statistics? -martin -- Martin Schmitt / Schmitt Systemberatung / www.scsy.de -- http://www.pug.org/index.php/Benutzer:Martin --
Re: alix help
Kendall Shaw schrieb: If I were able to upgrade the bios, I don't know how I will actually install openbsd on the disk. Aside from transfering files using Xmodem, what is the procedure for actually installing an image onto the CF card? I have tried two methods for installing OpenBSD, and haven't decided yet which one of the two I like better. First, there's Flashdist from http://www.nmedia.net/flashdist/ which is well optimized for flash enviroments and is installed by writing out an image to a CF card. This has a somewhat bullet-proof appearance, but it's not simple to customize. Second, I have recently received a shipment of Microdrives, allowing for a regular install that doesn't need to be optimized for read-only operation. The PXE environment needs to be set up as described in http://www.openbsd.org/faq/faq6.html#PXE and the bsd.rd kernel needs to be booted for installation. This has the big advantage that it works just like any OpenBSD installer. Kind regards, -martin -- Martin Schmitt / Schmitt Systemberatung / www.scsy.de -- http://www.pug.org/index.php/Benutzer:Martin --
PPP / demand-dial / failing first outbound connection
Hi all! I have the -current snapshot from Sep. 10 on my ALIX board, and have configured pppd for demand-dialing on a UMTS modem. # cat /etc/ppp/peers/umts cuaU0 7372800 debug noauth nocrtscts :10.11.12.13 ipcp-accept-local defaultroute demand user none persist idle 600 holdoff 300 connect /usr/sbin/chat -v -f /etc/ppp/tmobile-chat The first outbound connection causes pppd to successfully pull up the connection. However, the connecting client runs into a TCP timeout and needs to be started again. On subsequent dials (after the line was pulled down due to idle), the behaviour is the same and the initiating connection times out. I recall that this was a very common problem many years ago when I used to dial into ISDN with my Linux boxes, but I can't quite recall how we used to get rid of this back then. How do I fix this little problem? Your suggestions are greatly appreciated. Thanks for your time, -martin -- Martin Schmitt / Schmitt Systemberatung / www.scsy.de -- http://www.pug.org/index.php/Benutzer:Martin --
Huawei E220 on ALIX
Hi all! I'm trying to use a Huawei E220 UMTS USB modem on an ALIX, using OpenBSD Flashdist 20080504. I have extended the GEODE configuration as follows: # diff -c /opt/flashdist-20080504/GEODE /usr/src/sys/arch/i386/conf/GEODE *** /opt/flashdist-20080504/GEODE Sun May 4 21:32:07 2008 --- /usr/src/sys/arch/i386/conf/GEODE Wed Jul 16 21:36:15 2008 *** *** 87,93 --- 87,95 uhub* at usb? # USB Hubs uhub* at uhub?# USB Hubs umodem* at uhub?# USB Modems/Serial + umsm* at uhub?# Qualcomm MSM EVDO ucom* at umodem? + ucom* at umsm? #ubsa*at uhub?# Belkin serial adapter #ucom*at ubsa? #uftdi* at uhub?# FTDI FT8U100AX serial adapter With the kernel built from this configuration, Flashdist sees the Huawei thing as ugen0, while I expected to see it as ucom0. Is there anyone in here who can weigh in with some advice regarding initialization of the Huawei E220? I do know that the E220 needs some trickery to kill off its mass storage part in order to make the serial part available. However, I have never worked with this myself, neither on OpenBSD nor on Linux where the procedure appears to be fairly common. Also, how can I tell if the kernel built from the above configuration really has support for umsm? Thanks for your time, -martin [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: Huawei E220 on ALIX
Stuart Henderson schrieb: Please try this with the GENERIC kernel, and report back to us if you still have a problem. Make sure it's -current or a snapshot, not 4.3, for E220. If it still fails, send output from dmesg and usbdevs -v. I plugged it into my development box (4.3) where it misbehaved as expected (the umass driver is not in the GEODE kernel from Flashdist): umass0 at uhub0 port 1 configuration 1 interface 2 HUAWEI Technologies HUAWEI Mobile rev 1.10/0.00 addr 2 umass0: using SCSI over Bulk-Only scsibus2 at umass0: 2 targets umass0: BBB reset failed, STALLED umass0: BBB reset failed, STALLED I'll read up on checking out and building a -current kernel. Judging from the commit log for umsm.c, it's the only way to go. -martin [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: Huawei E220 on ALIX
Got it! # cu -s 115200 -l /dev/ttyU0 ati Manufacturer: huawei Model: E220 Revision: 11.110.05.00.00 IMEI: 355083018404928 +GCAP: +CGSM,+DS,+ES OK This is not on the ALIX yet, I'll get to that later. Thanks, -martin [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
