How to select NAT port variations.
I'm dealing with old software that uses old NAT traversal techniques. I specifically need to select the NAT variation as defined by RFC 3489 (section 5). Generally I've used nat-to's 'static-port' option and gotten around this issue. After adding some clients host-side, it seems like NAT traversal isn't working. Suppose I have this NAT rule: pass out on $external_int from conenat nat-to $external_int static-port What NAT variation does OpenBSD implement by default? Wikipedia page on NAT variation (port translation): http://en.wikipedia.org/wiki/Network_address_translation#Methods_of_port_translation
Re: libfuse - is it real ?
On Tue, Aug 6, 2013 at 2:19 AM, Mike Korbakov mike-...@yandex.ru wrote: ot included in libs Makefile, is it functional ? Just want to try ntfs-3g. You can try it at your own risk, it is still in development and not yet completely bug free. You can also send me reports if you find some bugs. Cheers, -- Sylvestre Gallon
OT: domain registration
Does anybody know the website of the uk domain registration ? I am lokking for the uk's entity for domain registration, not thirdies that do it too ! Thanks
Re: OT: domain registration
On Tue, Aug 06, 2013 at 07:51:30AM -0300, Friedrich Locke wrote: Does anybody know the website of the uk domain registration ? I am lokking for the uk's entity for domain registration, not thirdies that do it too ! Thanks The entity responsible for managing .uk is Nominet. Their website - http://www.nominet.org.uk/ -- staticsafe O ascii ribbon campaign - stop html mail - www.asciiribbon.org Please don't top post. Please don't CC! I'm subscribed to whatever list I just posted on.
Re: libfuse - is it real ?
mike-...@yandex.ru writes: Hi! Now (in 5.4 and current) libfuse included in source tree, but does not included in libs Makefile, is it functional ? Just want to try ntfs-3g. Mike. libfuse isn't hooked up yet. it is a work in progress in active development which still not completely bug-free. feel free to hook up and build it yourself send us possible bugs reports thanks. Gleydson.
Re: libfuse - is it real ?
So this means time for ntfs-3g, zfs and more (maybe also xfs and jfs?) should be quite near : Il giorno 06/ago/2013 15:47, Gleydson Soares gsoa...@openbsd.org ha scritto: mike-...@yandex.ru writes: Hi! Now (in 5.4 and current) libfuse included in source tree, but does not included in libs Makefile, is it functional ? Just want to try ntfs-3g. Mike. libfuse isn't hooked up yet. it is a work in progress in active development which still not completely bug-free. feel free to hook up and build it yourself send us possible bugs reports thanks. Gleydson.
Re: libfuse - is it real ?
On Tue, Aug 06, 2013 at 04:04:51PM +0200, Paolo Aglialoro wrote: So this means time for ntfs-3g, zfs and more (maybe also xfs and jfs?) should be quite near : Il giorno 06/ago/2013 15:47, Gleydson Soares gsoa...@openbsd.org ha scritto: Some of us are actually curious to see eventual perf measurements of nfsv4-over-fuse... ;-)
i386 vs. amd64 OpenSSL performance
This came up on soekris-tech, but since I have the figures I might as well post them here, too. If you do lots of crypto by way of OpenSSL's libcrypto, a number of popular algorithms (AES, SHA256, RSA, DSA, ECDSA, ECDH) are significantly faster in amd64 mode than in i386 mode on the same hardware. The figures below are on the same Soekris net6501-50 (Intel Atom E640, 1 GHz). -- net6501-50, OpenBSD 5.4/i386 -- OpenSSL 1.0.1c 10 May 2012 built on: date not available options:bn(64,32) rc4(8x,mmx) des(ptr,risc1,16,long) aes(partial) idea(int) blowfish(idx) compiler: information not available The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md2 0.00 0.00 0.00 0.00 0.00 mdc2 1316.45k 1615.99k 1712.39k 1738.76k 1747.26k md4 4936.01k17990.31k54015.57k 108121.13k 154028.65k md5 3997.51k15227.37k47733.62k 102857.57k 155181.44k hmac(md5) 5154.34k18515.84k0.89k 111454.41k 158165.48k sha1 4546.58k15273.07k42995.41k78297.56k 103159.32k rmd1603883.51k11894.88k27480.88k40856.58k47965.38k rc4 52165.95k70481.37k76799.49k79048.72k79729.12k des cbc 16145.39k17089.11k17401.37k17477.06k17499.85k des ede3 5849.76k 5978.34k 6014.64k 6023.91k 6028.33k idea cbc 8713.12k 9162.16k 9276.64k 9305.81k 9316.02k seed cbc 0.00 0.00 0.00 0.00 0.00 rc2 cbc 7512.73k 7903.23k 7994.26k 8017.48k 8025.98k rc5-32/12 cbc0.00 0.00 0.00 0.00 0.00 blowfish cbc 25897.38k29496.75k30504.48k30706.78k30911.87k cast cbc 14125.50k15081.97k15407.46k15485.53k15510.37k aes-128 cbc 8900.38k 9524.60k 9745.44k 9801.82k 9787.00k aes-192 cbc 7336.21k 7803.41k 7963.81k 8004.21k 8017.82k aes-256 cbc 6495.05k 6845.30k 6951.63k 6978.51k 6986.33k camellia-128 cbc0.00 0.00 0.00 0.00 0.00 camellia-192 cbc0.00 0.00 0.00 0.00 0.00 camellia-256 cbc0.00 0.00 0.00 0.00 0.00 sha2564978.27k11987.99k21308.39k26482.61k28644.78k sha5121707.65k 6828.93k10107.92k13988.66k15758.03k whirlpool 2795.19k 6244.95k10795.29k13175.35k14149.57k aes-128 ige 8487.77k 8848.31k 8958.21k 8984.66k 8994.87k aes-192 ige 7056.14k 7304.10k 7373.99k 7402.06k 7402.74k aes-256 ige 6319.89k 6482.58k 6540.25k 6553.60k 6559.04k ghash26411.66k45536.45k55386.75k58784.40k59856.03k signverifysign/s verify/s rsa 512 bits 0.001879s 0.000190s532.3 5252.2 rsa 1024 bits 0.011058s 0.000625s 90.4 1599.8 rsa 2048 bits 0.076061s 0.002336s 13.1428.0 rsa 4096 bits 0.566111s 0.009109s 1.8109.8 signverifysign/s verify/s dsa 512 bits 0.001942s 0.002161s515.0462.7 dsa 1024 bits 0.006225s 0.007201s160.6138.9 dsa 2048 bits 0.023164s 0.027479s 43.2 36.4 signverifysign/s verify/s 160 bit ecdsa (secp160r1) 0.0011s 0.0045s873.3222.0 192 bit ecdsa (nistp192) 0.0015s 0.0063s683.9159.2 224 bit ecdsa (nistp224) 0.0019s 0.0085s535.0117.7 256 bit ecdsa (nistp256) 0.0024s 0.0111s425.2 90.1 384 bit ecdsa (nistp384) 0.0053s 0.0274s190.2 36.5 521 bit ecdsa (nistp521) 0.0113s 0.0646s 88.2 15.5 163 bit ecdsa (nistk163) 0.0034s 0.0121s290.4 82.5 233 bit ecdsa (nistk233) 0.0076s 0.0236s131.5 42.4 283 bit ecdsa (nistk283) 0.0117s 0.0417s 85.7 24.0 409 bit ecdsa (nistk409) 0.0308s 0.0955s 32.5 10.5 571 bit ecdsa (nistk571) 0.0787s 0.2176s 12.7 4.6 163 bit ecdsa (nistb163) 0.0035s 0.0132s289.6 76.0 233 bit ecdsa (nistb233) 0.0075s 0.0259s132.5 38.7 283 bit ecdsa (nistb283) 0.0117s 0.0465s 85.5 21.5 409 bit ecdsa (nistb409) 0.0309s 0.1078s 32.3 9.3 571 bit ecdsa (nistb571) 0.0788s 0.2478s 12.7 4.0 op op/s 160 bit ecdh (secp160r1) 0.0039s257.3 192 bit ecdh (nistp192) 0.0054s184.9 224 bit ecdh (nistp224) 0.0073s137.9 256 bit ecdh (nistp256) 0.0095s105.8 384 bit ecdh (nistp384) 0.0236s 42.5 521 bit ecdh (nistp521) 0.0545s 18.4 163 bit ecdh (nistk163) 0.0059s168.5 233 bit ecdh (nistk233) 0.0113s
BGPd filter puzzle
I logged in to an OpenBGPd router which I maintain remotely as I needed to check something from dmesg. The command dmesg|less resulted in 150 lines, none of which was what I expected to see. Here are some samples: cannot forward src fe80:0005::0420:77e7:f6bf:3550, dst 2406:a000::0006:0d08, nxt 6, rcvif sis0, outif vr1 cannot forward src fe80:0005::92f6:52ff:fe02:4734, dst 2406:a000::0005, nxt 17, rcvif sis0, outif vr1 cannot forward src fe80:0005::0420:77e7:f6bf:3550, dst 2406:a000::0006:0d08, nxt 17, rcvif sis0, outif vr1 cannot forward src fe80:0005::0224:21ff:fe29:eaca, dst 2406:a000::0005, nxt 17, rcvif sis0, outif vr1 The link-local address of the rcvif is inet6 fe80::200:24ff:feca:3ad4%sis0 prefixlen 64 scopeid 0x5 so it isn't involved. Furthermore the bgpd.conf ends with: deny from any prefix fe80::/10 prefixlen = 10 # link local unicast deny from any prefix fec0::/10 prefixlen = 10 # old site local unicast deny from any prefix ff00::/8 prefixlen = 8# multicast #EOF Simple(?) question first: Why is traffic coming via a transit provider getting past the link-local filter rule? Secondly what do the nxt 6 and nxt 17 mean? Mandatory dmesg from dmesg.boot: OpenBSD 5.2 (GENERIC) #1: Fri Nov 30 17:27:14 EST 2012 r...@nero.witworx.com:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Geode(TM) Integrated Processor by AMD PCS (AuthenticAMD 586-class) 500 MHz cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW real mem = 536408064 (511MB) avail mem = 516780032 (492MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 20/80/26, BIOS32 rev. 0 @ 0xfac40 pcibios0 at bios0: rev 2.0 @ 0xf/0x1 pcibios0: pcibios_get_intr_routing - function not supported pcibios0: PCI IRQ Routing information unavailable. pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc8000/0xa800 cpu0 at mainbus0: (uniprocessor) amdmsr0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (bios) io address conflict 0x6100/0x100 io address conflict 0x6200/0x200 pchb0 at pci0 dev 1 function 0 AMD Geode LX rev 0x33 glxsb0 at pci0 dev 1 function 2 AMD Geode LX Crypto rev 0x00: RNG AES vr0 at pci0 dev 6 function 0 VIA VT6105M RhineIII rev 0x96: irq 11, address 00:00:24:ca:d9:1c ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr1 at pci0 dev 7 function 0 VIA VT6105M RhineIII rev 0x96: irq 5, address 00:00:24:ca:d9:1d ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr2 at pci0 dev 8 function 0 VIA VT6105M RhineIII rev 0x96: irq 9, address 00:00:24:ca:d9:1e ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr3 at pci0 dev 9 function 0 VIA VT6105M RhineIII rev 0x96: irq 12, address 00:00:24:ca:d9:1f ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 ppb0 at pci0 dev 14 function 0 TI PCI2250 PCI-PCI rev 0x02 pci1 at ppb0 bus 1 sis0 at pci1 dev 0 function 0 NS DP83815 10/100 rev 0x00, DP83816A: irq 10, address 00:00:24:ca:3a:d4 nsphyter0 at sis0 phy 0: DP83815 10/100 PHY, rev. 1 sis1 at pci1 dev 1 function 0 NS DP83815 10/100 rev 0x00, DP83816A: irq 7, address 00:00:24:ca:3a:d5 nsphyter1 at sis1 phy 0: DP83815 10/100 PHY, rev. 1 sis2 at pci1 dev 2 function 0 NS DP83815 10/100 rev 0x00, DP83816A: irq 10, address 00:00:24:ca:3a:d6 nsphyter2 at sis2 phy 0: DP83815 10/100 PHY, rev. 1 sis3 at pci1 dev 3 function 0 NS DP83815 10/100 rev 0x00, DP83816A: irq 7, address 00:00:24:ca:3a:d7 nsphyter3 at sis3 phy 0: DP83815 10/100 PHY, rev. 1 glxpcib0 at pci0 dev 20 function 0 AMD CS5536 ISA rev 0x03: rev 3, 32-bit 3579545Hz timer, watchdog, gpio, i2c gpio0 at glxpcib0: 32 pins iic0 at glxpcib0 pciide0 at pci0 dev 20 function 2 AMD CS5536 IDE rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: SanDisk SDCFH-002G wd0: 1-sector PIO, LBA, 1907MB, 3906560 sectors wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 pciide0: channel 1 ignored (disabled) ohci0 at pci0 dev 21 function 0 AMD CS5536 USB rev 0x02: irq 15, version 1.0, legacy support ehci0 at pci0 dev 21 function 1 AMD CS5536 USB rev 0x02: irq 15 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 AMD EHCI root hub rev 2.00/1.00 addr 1 isa0 at glxpcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard pcppi0 at isa0 port 0x61 spkr0 at pcppi0 nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 9: GPIO VLM TMS gpio1 at nsclpcsio0: 29 pins npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 AMD OHCI root hub rev 1.00/1.00 addr 1 mtrr: K6-family MTRR support (2 registers) vscsi0 at root scsibus0 at vscsi0: 256 targets softraid0 at
Re: BGPd filter puzzle
On Wed, Aug 07, 2013 at 01:58:42PM +1000, Rod Whitworth wrote: I logged in to an OpenBGPd router which I maintain remotely as I needed to check something from dmesg. The command dmesg|less resulted in 150 lines, none of which was what I expected to see. Here are some samples: cannot forward src fe80:0005::0420:77e7:f6bf:3550, dst 2406:a000::0006:0d08, nxt 6, rcvif sis0, outif vr1 cannot forward src fe80:0005::92f6:52ff:fe02:4734, dst 2406:a000::0005, nxt 17, rcvif sis0, outif vr1 cannot forward src fe80:0005::0420:77e7:f6bf:3550, dst 2406:a000::0006:0d08, nxt 17, rcvif sis0, outif vr1 cannot forward src fe80:0005::0224:21ff:fe29:eaca, dst 2406:a000::0005, nxt 17, rcvif sis0, outif vr1 The link-local address of the rcvif is inet6 fe80::200:24ff:feca:3ad4%sis0 prefixlen 64 scopeid 0x5 so it isn't involved. Furthermore the bgpd.conf ends with: deny from any prefix fe80::/10 prefixlen = 10 # link local unicast deny from any prefix fec0::/10 prefixlen = 10 # old site local unicast deny from any prefix ff00::/8 prefixlen = 8# multicast #EOF Simple(?) question first: Why is traffic coming via a transit provider getting past the link-local filter rule? Secondly what do the nxt 6 and nxt 17 mean? This is from the network stack, it does not mean that bgpd added routes for this. For that you should check bgpctl show rib, bgpctl show fib and route(8) output. The problem here is that somebody on sis0 is sending you packets using link local addresses as source IP to a global IP as destination. This is not allowed since there is no way to send packets back. So if sis0 is upstream then something is seriously wrong on that upstream. neccessary IPv6 rant All went to shit when they added link local addressing to IPv6 in the ivory tower. All this because DHCP was considered bad. So we ended up with this mess that is worse by at least 50dB. /rant -- :wq Claudio
