Re: Authenticating WiFi hotspot users
fivering...@yahoo.com.au (Steve), 2014.01.25 (Sat) 05:34 (CET): I use AuthPF a fair bit to limit acces to external ports that I dont want globally accessible. The users that utilise this I I can plan for so they have an ssh client installed on the device I am now trying to authenticate unknown users that likey will not have an SSH client. The users will just need to browse the web. They need to be initially directed to a web page of terms and conditions and once accepted given permission to browse. Is there a simple answer to this problem ? I was thinking maybe a web based ssh client www/ajaxterm Bye, Marcus that can be loaded with apache or maybe an option to do something with relayd. I have a manual workaround by just changing wpa pass phrase periodically but any ideas to automate this would be appreciated.
[patch] /bin/mt print current file and block numbers
Hello misc,
Here's a tiny patch for bin/mt/mt.c to allow the command mt status to
print current file and block numbers, like it does in most other Unixes.
The information was already available in struct mtget, so only two printf
lines was needed.
I have verified that the current file number is reported as expected using
a HP DAT72 USB tape drive.
Index: bin/mt/mt.c
===
RCS file: /cvs/src/bin/mt/mt.c,v
retrieving revision 1.36
diff -u -p -r1.36 mt.c
--- bin/mt/mt.c 12 Nov 2013 04:36:02 - 1.36
+++ bin/mt/mt.c 23 Jan 2014 20:42:12 -
@@ -281,6 +281,8 @@ status(struct mtget *bp)
(void)putchar('\n');
(void)printf(blocksize: %d (%d)\n, bp-mt_blksiz, bp-mt_mblksiz);
(void)printf(density: %d (%d)\n, bp-mt_density, bp-mt_mdensity);
+ (void)printf(current file number: %d\n, bp-mt_fileno);
+ (void)printf(current block number: %d\n, bp-mt_blkno);
}
/*
athn weirdness with two subnets
Hi: I'm using 5.4 stable on an ALIX 2D13 with Compex WLM200NX My internal network is 192.168.12.0/24 My ISP gives me 181.40.100.8 nm 255.255.255.0 gw 181.40.100.1 via DHCP with reserved IP address. This is on vr0 No problems here. I wanted to set up two internal networks on vr1: 192.168.12.0/25 and on vr2: 192.168.12.128/25 athn0 is also supposed to be on 192.168.12.0/25 The intended /etc/hostname.athn0 is: inet 192.168.12.2 255.255.255.128 /etc/hostname.vr0 dhcp /etc/hostname.vr1 inet 192.168.12.1 255.255.255.128 /etc/hostname.vr2 inet 192.168.12.129 255.255.255.128 The weirdness is as follows: according to ifconfig all interfaces are active BUT athn0 does not want to be on the same subnet with vr1 I cannot ping the internal IP 192.168.12.1 as long as athn0 is on 192.168.12.2 or any other address up to 192.168.12.126 that is in the subnet 192.168.12.128/25. I have to change athn0 to the other subnet with /etc/hostname.athn0 inet 192.168.12.130 255.255.255.128 In this case I can ping 192.168.12.1 and 192.168.12.130 (ping from inside the ALIX that is) I pfctl -d to see if my PF rules have an influence, but no ... You see that I followed the Book of PF 2nd edition to eventually being able to set up a DMZ on vr2 while WLAN on athn0 and wired vr1 are on the same subnet. Is the weirdness in what I'm trying to do or is there some subtle bug? Is there a reason that two different interfaces on the same system must not be on the same subnet? As a sidenote for the record: If one brings network interfaces down and up and down and up and changes the hostnames in between eventually the ALIX wants a hard reset - reboot is not enough; it will leave one with all kinds of weird behaviour - mostly interfaces being active according to ifconfig but not being pingable nor from inside nor outside. I hope someone can help. Cheers Eike my dmesg: OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 12:05:01 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Geode(TM) Integrated Processor by AMD PCS (AuthenticAMD 586- class) 499 MHz cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW real mem = 267976704 (255MB) avail mem = 252145664 (240MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 11/05/08, BIOS32 rev. 0 @ 0xfd088 pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: pcibios_get_intr_routing - function not supported pcibios0: PCI IRQ Routing information unavailable. pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xe/0xa800 cpu0 at mainbus0: (uniprocessor) pci0 at mainbus0 bus 0: configuration mode 1 (bios) 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 9 function 0 VIA VT6105M RhineIII rev 0x96: irq 10, address 00:0d:b9:2d:cf:20 ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr1 at pci0 dev 10 function 0 VIA VT6105M RhineIII rev 0x96: irq 11, address 00:0d:b9:2d:cf:21 ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr2 at pci0 dev 11 function 0 VIA VT6105M RhineIII rev 0x96: irq 15, address 00:0d:b9:2d:cf:22 ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 athn0 at pci0 dev 12 function 0 Atheros AR9280 rev 0x01: irq 9 athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:06:22:c4 glxpcib0 at pci0 dev 15 function 0 AMD CS5536 ISA rev 0x03: rev 3, 32-bit 3579545Hz timer, watchdog, gpio, i2c gpio0 at glxpcib0: 32 pins iic0 at glxpcib0 maxtmp0 at iic0 addr 0x4c: lm86 pciide0 at pci0 dev 15 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: ULTIMATE CF CARD wd0: 1-sector PIO, LBA48, 15247MB, 31227840 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 ignored (disabled) ohci0 at pci0 dev 15 function 4 AMD CS5536 USB rev 0x02: irq 12, version 1.0, legacy support ehci0 at pci0 dev 15 function 5 AMD CS5536 USB rev 0x02: irq 12 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 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 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) nvram: invalid checksum vscsi0 at root scsibus0 at vscsi0: 256 targets softraid0 at root scsibus1 at softraid0: 256 targets root on wd0a (7fe077bfcb51b299.a) swap on wd0b dump on wd0b clock: unknown CMOS layout
athn(4) questions about Tx power, Rx gain, and setting media (AR9220)
Hi misc@,
I have an Alix 2d3 board with a RouterBoard R52Hn miniPCI wireless card,
featuring an AR9220 chip (full dmesg and debug messages are included in my mail
later), and I'm running it in hostap mode.
# dmesg | grep athn
athn0 at
pci0 dev 12 function 0 Atheros AR9280 rev 0x01: irq 9
athn0: AR9280 rev 2 (2T2R), ROM rev 22, address xx:xx:xx:xx:xx:xx
# uname -a
OpenBSD host.domain 5.4 GENERIC#37 i386
This is a high power card, with 25dBm output power @802.11g 6Mbit and 22dBm
@802.11g 54Mbit, and is connected to a pair of 8dBi omnidirectional antennae.
However, both its range and its signal level at the same distance is similar to
those of my generic wireless router provided by my ISP. An other interesting
aspect is that when I connect to it either with an Android phone or with a
laptop (Kubuntu or Linux Mint), they correctly connect with 802.11g 54Mbit, but
tend to randomly downgrade the connection to as low as 802.11g 1Mbit, despite
the fact that they are in less than 2m distance with direct visibility to the
antennae. Using wget on the laptop, I couldn't get transfer speeds above
~1.5MBps (~12Mbit).
Similarly, when I use my card to scan the neighboring networks, I get similar
readings as with my laptop, however I suspect that this hardware should be
capable of more.
At first, I tried to force the media setting in hostname.athn0 to 802.11g
54Mbit, however it seems that the media is in fact in autoselect mode:
# cat /etc/hostname.athn0
inet x.x.x.x y.y.y.y
media OFDM54 mode 11g mediaopt hostap
nwid xxx
wpakey xxx
chan 3
wpaciphers ccmp
wpaprotos wpa2
# ifconfig athn0
athn0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr xx:xx:xx:xx:xx:xx
priority: 4
groups: wlan
media: IEEE802.11 OFDM54 mode 11g hostap (autoselect mode 11g hostap)
status: active
ieee80211: nwid xxx chan 3 bssid xx:xx:xx:xx:xx:xx wpakey xxx
wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher tkip
inet x.x.x.x netmask xxx broadcast x.x.x.x
inet6 xxx%athn0 prefixlen 64 scopeid 0x4
Is this the correct behaviour?
As the next step, I looked for a way to set the txpower setting manually.
Unfortunately, athn(4) doesn't support this feature, so I can't perform this
test.
Sidenote: the manual of ifconfig(8) doesn't state that not all drivers support
the txpower option, and, by looking at the source code ieee80211_ioctl.c it
turns out that the same error message is given in this case and in case of an
out of bound value:
if ((ic-ic_caps IEEE80211_C_TXPMGT) == 0) {
error = EINVAL;
break;
}
if (!(IEEE80211_TXPOWER_MIN = txpower-i_val
txpower-i_val = IEEE80211_TXPOWER_MAX)) {
error = EINVAL;
break;
}
While this is logically correct, I think it would be more informative to provide
a different error, or to note this behaviour in the man page.
For the next step, I started looking around at the source code of the athn
driver, but I'm not familiar nor with driver programming nor with wireless
cards, although I realized that the debug messages may be informative. So I have
compiled a new kernel, which differs from 5.4 GENERIC only that it is compiled
with the ATHN_DEBUG option, and athn_debug is set to a high value in athn.c.
Before the debug findings, some netstat:
# netstat -I athn0
NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls
athn0 1500 Link xx:xx:xx:xx:xx:xx78063 238708 119145 6479 0
athn0 1500 x.x.x.x/x x.x.x.x 78063 238708 119145 6479 0
athn0 1500 xxx%athnxxx 78063 238708 119145 6479 0
Is it normal to have this amount of errors?
# netstat -W athn0
ieee80211 on athn0:
0 input packets with bad version
0 input packets too short
0 input packets from wrong bssid
551 input packet duplicates discarded
0 input packets with wrong direction
0 input multicast echo packets discarded
173 input packets from unassociated station discarded
0 input encrypted packets without wep/wpa config discarded
48768 input unencrypted packets with wep/wpa config discarded
0 input wep/wpa packets processing failed
65 input packet decapsulations failed
0 input management packets discarded
124996 input control packets discarded
0 input packets with truncated rate set
0 input packets with missing elements
0 input packets with elements too big
20 input packets with elements too small
0 input packets with invalid channel
989693 input packets with mismatched channel
0 node allocations failed
54151 input packets with mismatched ssid
0 input packets with unsupported auth algorithm
0 input authentications failed
0 input associations from wrong bssid
0 input associations without authentication
0 input associations with mismatched capabilities
0 input
sysmerge complains about not valid etcXX.tgz set
Hello, today I updated to the latest snapshot on sparc64 (from 22nd january). When I run sysmerge after that I got $ sudo sysmerge -s etc55.tgz -x xetc55.tgz *** ERROR: /var/tmp/sysmerge.Hwq1ImlHSs/etc55.tgz is not a valid etcXX.tgz set Any ideas what might go wrong here? Regards, Markus
Re: sysmerge complains about not valid etcXX.tgz set
On Sat, Jan 25, 2014 at 6:18 PM, Markus Lude markus.l...@gmx.de wrote: Hello, today I updated to the latest snapshot on sparc64 (from 22nd january). When I run sysmerge after that I got $ sudo sysmerge -s etc55.tgz -x xetc55.tgz *** ERROR: /var/tmp/sysmerge.Hwq1ImlHSs/etc55.tgz is not a valid etcXX.tgz set Try downloading it again. And/or try to unpack it somewhere else than /. Is it a valid tar archive? -- chs
Re: sysmerge complains about not valid etcXX.tgz set
On Sat, Jan 25, 2014 at 06:18:58PM +0100, Markus Lude wrote: Hello, today I updated to the latest snapshot on sparc64 (from 22nd january). When I run sysmerge after that I got $ sudo sysmerge -s etc55.tgz -x xetc55.tgz *** ERROR: /var/tmp/sysmerge.Hwq1ImlHSs/etc55.tgz is not a valid etcXX.tgz set Any ideas what might go wrong here? sysmerge from -current doesn't complain here and works normal. Regards, Markus
Re: sysmerge complains about not valid etcXX.tgz set
Use sysmerge -S -s etc55.tgz -x xetc55.tgz And verify the etc archives manually as described in the signify manpage. Looks like there is a problem with sysmerge and signify. Fritjof Markus Lude markus.l...@gmx.de wrote: Hello, today I updated to the latest snapshot on sparc64 (from 22nd january). When I run sysmerge after that I got $ sudo sysmerge -s etc55.tgz -x xetc55.tgz *** ERROR: /var/tmp/sysmerge.Hwq1ImlHSs/etc55.tgz is not a valid etcXX.tgz set Any ideas what might go wrong here? Regards, Markus -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: sysmerge complains about not valid etcXX.tgz set
On Sat Jan 25 2014 18:18, Markus Lude wrote: Hello, today I updated to the latest snapshot on sparc64 (from 22nd january). When I run sysmerge after that I got $ sudo sysmerge -s etc55.tgz -x xetc55.tgz *** ERROR: /var/tmp/sysmerge.Hwq1ImlHSs/etc55.tgz is not a valid etcXX.tgz set Any ideas what might go wrong here? try specifying the full (absolute) path to the sets. It's a regression, where sysmerge doesn't handle implicit paths correctly. ajacout@ has already fixed it in -current after Jan, 22.
pkg_add fails on clean snapshot install
Is it related to what is mentioned here and I should wait for updated snapshots? http://marc.info/?l=openbsd-techm=139064668614680w=2 $ sudo pkg_add minicom Fatal error: Ustar [ftp://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/quirks-1.109.tgz][+CONTENTS]: Error while reading header at /usr/libdata/perl5/OpenBSD/Ustar.pm line 83. $ pkg_info iwn-firmware-5.10p0 firmware binary images for iwn(4) driver uvideo-firmware-1.2p1 firmware binary images for uvideo(4) driver $ dmesg OpenBSD 5.5-beta (GENERIC.MP) #279: Fri Jan 24 11:50:37 MST 2014 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error ffclock_battery,ROM_cksum,config_unit,memory_size,fixed_disk,invalid_time real mem = 3127304192 (2982MB) avail mem = 3035901952 (2895MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xbb8c4000 (22 entries) bios0: vendor Hewlett-Packard version 68PDD Ver. F.16 date 10/21/2010 bios0: Hewlett-Packard HP Compaq 6730b (GB987ET#AK8) acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET APIC MCFG ASF! TCPA SSDT SLIC DMAR SSDT SSDT SSDT acpi0: wakeup devices LANC(S5) HDEF(S4) RP02(S5) WNIC(S5) RP03(S5) ECF0(S5) RP05(S5) ECF0(S5) RP06(S5) NIC_(S5) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz, 2261.39 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF cpu0: 3MB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges cpu0: apic clock running at 265MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz, 2261.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF cpu1: 3MB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 1 acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus -1 (PEGP) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP02) acpiprt3 at acpi0: bus 3 (RP03) acpiprt4 at acpi0: bus 68 (RP05) acpiprt5 at acpi0: bus 133 (RP06) acpiprt6 at acpi0: bus 134 (PCIB) acpiprt7 at acpi0: bus 0 (PCI0) acpiec0 at acpi0 acpicpu0 at acpi0: C2, C1, PSS acpicpu1 at acpi0: C2, C1, PSS acpipwrres0 at acpi0: APPR, resource for HDEF acpipwrres1 at acpi0: COMP, resource for COM1 acpipwrres2 at acpi0: LPP_, resource for LPT0 acpipwrres3 at acpi0: PFN0, resource for FAN0 acpipwrres4 at acpi0: PFN1, resource for FAN1 acpipwrres5 at acpi0: PFN2, resource for FAN2 acpipwrres6 at acpi0: PFN3, resource for FAN3 acpipwrres7 at acpi0: PFN4, resource for FAN4 acpitz0 at acpi0: critical temperature is 256 degC acpitz1 at acpi0: critical temperature is 110 degC acpitz2 at acpi0: critical temperature is 105 degC acpitz3 at acpi0: critical temperature is 110 degC acpitz4 at acpi0: critical temperature is 110 degC acpibat0 at acpi0: BAT0 model Primary serial 04335 2009/01/20 type LIon oem Hewlett-Packard acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: LID_ acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD02 cpu0: Enhanced SpeedStep 2261 MHz: speeds: 2267, 2266, 1600, 800 MHz memory map conflict 0xfff8/0x7000 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel GM45 Host rev 0x07 vga1 at pci0 dev 2 function 0 Intel GM45 Video rev 0x07 intagp0 at vga1 agp0 at intagp0: aperture at 0xc000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1280x800 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) Intel GM45 Video rev 0x07 at pci0 dev 2 function 1 not configured uhci0 at pci0 dev 26 function 0 Intel 82801I USB rev 0x03: apic 1 int 16 uhci1 at pci0 dev 26 function 1 Intel 82801I USB rev 0x03: apic 1 int 17 uhci2 at pci0 dev 26 function 2 Intel 82801I USB rev 0x03: apic 1 int 18 ehci0 at pci0 dev 26 function 7 Intel 82801I USB rev 0x03: apic 1 int 19 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 82801I HD Audio rev 0x03: msi azalia0: codecs: Analog Devices AD1984A audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 82801I PCIE rev 0x03: msi pci1 at ppb0 bus 1 ppb1 at pci0 dev 28 function 1 Intel 82801I PCIE rev 0x03: msi pci2 at ppb1 bus 2 iwn0 at pci2 dev 0 function 0 Intel WiFi Link
Re: pkg_add fails on clean snapshot install
On Sat, Jan 25, 2014 at 07:24:21PM +0100, Markus Bergkvist wrote: Is it related to what is mentioned here and I should wait for updated snapshots? http://marc.info/?l=openbsd-techm=139064668614680w=2 $ sudo pkg_add minicom Fatal error: Ustar [ftp://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/quirks-1.109.tgz][+CONTENTS]: Error while reading header at /usr/libdata/perl5/OpenBSD/Ustar.pm line Yes.
Re: athn(4) questions about Tx power, Rx gain, and setting media (AR9220)
If not, I'd like to ask what should be done to fix the errors. Thank you in advance, Marton Try to offer your hardware as donation and maybe a developer will pick it up and make it shine. That dependes of his/her time and priorities. It may be that athn driver is not fully reay yet for usage. But as I said, it may be.
Re: NAT reliability in light of recent checksum changes
On 22/01/2014, at 7:19 PM, Henning Brauer wrote: * Richard Procter richard.n.proc...@gmail.com [2014-01-22 06:44]: This fundamentally weakens its usefulness, though: a correct checksum now implies only that the payload likely matches what the last NAT router happened to have in its memory huh? we receive a packet with correct cksum - NAT - packet goes out with correct cksum. we receive a packet with broken cksum - NAT - we leave the cksum alone, i. e. leave it broken. Christian said it better than me: routers may corrupt data and regenerating the checksum will hide it. That's more than a theoretical concern. The article I referenced is a detailed study of real-world traces co-authored by a member of the Stanford distributed systems group that concludes Probably the strongest message of this study is that the networking hardware is often trashing the packets which are entrusted to it[0]. More generally, TCP checksums provide for an acceptable error rate that is independent of the reliability of the underlying network[*] by allowing us to verify its workings. But it's no longer possible to verify network operation if it may be regenerating TCP checksums, as these may hide network faults. That's a fundamental change from the scheme Cerf and Khan emphasized in their design notes for what became known as TCP: The remainder of the packet consists of text for delivery to the destination and a trailing check sum used for end-to-end software verification. The GATEWAY does /not/ modify the text and merely forwards the check sum along without computing or recomputing it.[1] It doesn't seem you know what you are talking about. the cksum is dead simple, if we had bugs in claculating or verifying it, we really had a LOT of other problems. I'm not saying the calculation is bad. I'm saying it's being calculated from the wrong copy of the data and by the wrong device. And it's not just me saying it: I'm quoting the guys who designed TCP. There is no undetected error rate, nothing really changes there. I disagree. Every TCP stream containing aribitrary data may have undetected errors as checksums cannot detect all the errors networks may make (being shorter than the data they cover). The engineer's task is to make network errors reliably negligible in practice. As network regenerated checksums may hide any amount of arbitrary data corruption I believe it's correct to say the network error rate undetected by TCP is then unknown and unbounded. best, Richard. [*] Under reasonable assumptions of the error modes most likely in practice. And some applications require lower error rates than TCP checksums can provide. [0] http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf Jonathan Stone and Craig Partridge. 2000. When the CRC and TCP checksum disagree. In Proceedings of the conference on Applications, Technologies, Architectures, and Protocols for Computer Communication (SIGCOMM '00). ACM, New York, NY, USA, 309-319. DOI=10.1145/347059.347561 http://doi.acm.org/10.1145/347059.347561 [1] A Protocol for Packet Network Intercommunication V. Cerf, R. Khan, IEEE Trans on Comms, Vol Com-22, No 5 May 1974 Page 3 in original emphasis.
Re: NAT reliability in light of recent checksum changes
From owner-misc+M137142=deraadt=cvs.openbsd@openbsd.org Sat Jan 25 12:41:53 2014 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=utWhBX3niMM2LVtE8mfHlY/ky3wCOdmsmIjoMdLaY5Q=; b=EDAHtMzwKNWiAeY56T7Fkl0Q29kOMAMn5QUkTmADQG5qZJ7k9mOWDRnjlN0DLClrDO TpAA7OUGMfA55tXh/dEkKgtjb3inl7IMNyhUahJrETz0uHedS9xyZSTKBbDi9zVWfey1 V3broKdxZP3MA6jmF0aT4jdkaDfC/Hj7UhSX79Qc6zMkr3wZMN6e3sA+31RCnrCj/hwf 8oDhmqPtNYVGBZMm9hyhX1x/FTp/3Ra6tWzUnDtnKozUq2ZeovgLwG3JjcFooQ5572Ef w1uIA4w2em5DRlUSdDtome8dVVewRb25ZeNkPMe8Gul6azVh2zqNNYx7a9b71mLTwGML YXwA== X-Received: by 10.68.204.4 with SMTP id ku4mr21464025pbc.66.1390678851934; Sat, 25 Jan 2014 11:40:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) Subject: Re: NAT reliability in light of recent checksum changes From: Richard Procter richard.n.proc...@gmail.com In-Reply-To: 20140122061907.gk15...@quigon.bsws.de Date: Sun, 26 Jan 2014 08:40:44 +1300 Content-Transfer-Encoding: 8bit References: 8d493091-c15d-46a2-8004-32dd59395...@gmail.com 20140122061907.gk15...@quigon.bsws.de To: misc@openbsd.org X-Mailer: Apple Mail (2.1085) List-Help: mailto:majord...@openbsd.org?body=help List-ID: misc.openbsd.org List-Owner: mailto:owner-m...@openbsd.org List-Post: mailto:misc@openbsd.org List-Subscribe: mailto:majord...@openbsd.org?body=sub%20misc List-Unsubscribe: mailto:majord...@openbsd.org?body=unsub%20misc X-Loop: misc@openbsd.org Precedence: list Sender: owner-m...@openbsd.org On 22/01/2014, at 7:19 PM, Henning Brauer wrote: * Richard Procter richard.n.proc...@gmail.com [2014-01-22 06:44]: This fundamentally weakens its usefulness, though: a correct checksum now implies only that the payload likely matches what the last NAT router happened to have in its memory huh? we receive a packet with correct cksum - NAT - packet goes out with correct cksum. we receive a packet with broken cksum - NAT - we leave the cksum alone, i. e. leave it broken. Christian said it better than me: routers may corrupt data and regenerating the checksum will hide it. That's more than a theoretical concern. The article I referenced is a detailed study of real-world traces co-authored by a member of the Stanford distributed systems group that concludes Probably the strongest message of this study is that the networking hardware is often trashing the packets which are entrusted to it[0]. More generally, TCP checksums provide for an acceptable error rate that is independent of the reliability of the underlying network[*] by allowing us to verify its workings. But it's no longer possible to verify network operation if it may be regenerating TCP checksums, as these may hide network faults. That's a fundamental change from the scheme Cerf and Khan emphasized in their design notes for what became known as TCP: The remainder of the packet consists of text for delivery to the destination and a trailing check sum used for end-to-end software verification. The GATEWAY does /not/ modify the text and merely forwards the check sum along without computing or recomputing it.[1] It doesn't seem you know what you are talking about. the cksum is dead simple, if we had bugs in claculating or verifying it, we really had a LOT of other problems. I'm not saying the calculation is bad. I'm saying it's being calculated from the wrong copy of the data and by the wrong device. And it's not just me saying it: I'm quoting the guys who designed TCP. There is no undetected error rate, nothing really changes there. I disagree. Every TCP stream containing aribitrary data may have undetected errors as checksums cannot detect all the errors networks may make (being shorter than the data they cover). The engineer's task is to make network errors reliably negligible in practice. As network regenerated checksums may hide any amount of arbitrary data corruption I believe it's correct to say the network error rate undetected by TCP is then unknown and unbounded. best, Richard. [*] Under reasonable assumptions of the error modes most likely in practice. And some applications require lower error rates than TCP checksums can provide. [0] http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf Jonathan Stone and Craig Partridge. 2000. When the CRC and TCP checksum disagree. In Proceedings of the conference on Applications, Technologies, Architectures, and Protocols for Computer Communication (SIGCOMM '00). ACM, New York, NY, USA, 309-319. DOI=10.1145/347059.347561 http://doi.acm.org/10.1145/347059.347561 [1] A Protocol for Packet Network Intercommunication V. Cerf, R. Khan, IEEE Trans on Comms, Vol Com-22, No 5 May 1974 Page 3 in original emphasis.
Re: athn weirdness with two subnets
On Saturday 25 January 2014 11:11:43 you wrote: if you want athn0 and vr1 to be on the same network, bridge them together then assign an IP address to only one of the two. -ken Thanks Ken for the hint! I reckon that assigning IP addresses to both interfaces in the same network is not the correct approach. I tried your hint and at least the ALIX 2d13 is routing again. Just for the record: athn0 is the interface to assign the IP address. Otherwise it gets status no network and will not come up. # cat /etc/hostname.athn0 inet 192.168.12.1 255.255.255.128 chan 108 mediaopt hostap nwid mywlanid wpakey somelongkey # cat /etc/hostname.vr1 up media autoselect # cat /etc/hostname.bridge0 add athn0 add vr1 up And for the record again because somebody else had problems with this card: I can now connect via WiFi with my MACbook-Air on 5GHz (channel 108) but my Samsung Galaxy3 does not want to connect although it sees the network and the field strength is -39dBm @ 5540MHz. Trying the same on channel 6 results in nothing but a timeout error on both the MAC and the Samsung phone. No idea if this is due to the Compex card, the athn driver or the Samsung phone. On Sat, Jan 25, 2014 at 10:46 AM, Eike Lantzsch zp6...@gmx.net wrote: I'm using 5.4 stable on an ALIX 2D13 with Compex WLM200NX My internal network is 192.168.12.0/24 My ISP gives me 181.40.100.8 nm 255.255.255.0 gw 181.40.100.1 via DHCP with reserved IP address. This is on vr0 No problems here. I wanted to set up two internal networks on vr1: 192.168.12.0/25 and on vr2: 192.168.12.128/25 athn0 is also supposed to be on 192.168.12.0/25 The intended /etc/hostname.athn0 is: inet 192.168.12.2 255.255.255.128 /etc/hostname.vr0 dhcp /etc/hostname.vr1 inet 192.168.12.1 255.255.255.128 /etc/hostname.vr2 inet 192.168.12.129 255.255.255.128 The weirdness is as follows: according to ifconfig all interfaces are active BUT athn0 does not want to be on the same subnet with vr1 I cannot ping the internal IP 192.168.12.1 as long as athn0 is on 192.168.12.2 or any other address up to 192.168.12.126 that is in the subnet 192.168.12.128/25. I have to change athn0 to the other subnet with /etc/hostname.athn0 inet 192.168.12.130 255.255.255.128 In this case I can ping 192.168.12.1 and 192.168.12.130 (ping from inside the ALIX that is) [rest snipped for brevity]
Cannot make state when using 'user' option in pf.conf
Hello, I'm trying to understand why there's no PF state for a outgoing rule dedicated to dnscrypt-proxy (668) daemon. pf.conf says 'user' option needs effective ID... # ps -axo uid,ruid,gid,rgid,pid,args | grep dnscrypt 688 688 688 688 16665 /usr/local/sbin/dnscrypt-proxy -d --local-address=127.0.0.1:5331 --user=_dnscrypt-proxy # pfctl -sr block drop out log quick on egress from ! (egress:0) to any anchor test-out all pass out log quick on egress inet proto udp from any to 208.67.220.220 port = 443 user = 688 pass out log quick on egress inet proto tcp from any to 208.67.220.220 port = 443 user = 688 flags S/SA pass out log quick on egress inet proto icmp all icmp-type echoreq block drop in log quick from no-route to any block drop in log quick from urpf-failed to any block drop out log quick all block drop in log quick on egress inet from any to 255.255.255.255 anchor test-in all pass in log quick on egress inet proto icmp from any to (egress:0) icmp-type echoreq code 0 pass in log quick on egress inet proto tcp from any to (egress:0) port = 22 flags S/SA block drop in log quick all Now when dnscrypt-proxy tries to make a connection it is blocked. Interestingly there's even no logged outgoing connection, but just blocked return. # tcpdump -i pflog0 -n -e -ttt -vv tcpdump: WARNING: snaplen raised from 116 to 160 tcpdump: listening on pflog0, link-type PFLOG Jan 26 00:41:00.884036 rule 7/(match) [uid 0, pid 23524] block out on iwn0: [uid 0, pid 16665] 192.168.1.100.10976 208.67.220.220.443: udp 512 (ttl 64, id 9876, len 540, bad cksum 208! differs by e108) (from anchor) # pfctl -ss all tcp 192.168.1.100:16505 - 66.7.199.108:22 ESTABLISHED:ESTABLISHED Well it works if I add dnscrypt-proxy rule for root but why? jirib
Re: Cannot make state when using 'user' option in pf.conf
2014/1/26 Jiri B ji...@devio.us: Hello, I'm trying to understand why there's no PF state for a outgoing rule dedicated to dnscrypt-proxy (668) daemon. pf.conf says 'user' option needs effective ID... # ps -axo uid,ruid,gid,rgid,pid,args | grep dnscrypt 688 688 688 688 16665 /usr/local/sbin/dnscrypt-proxy -d --local-address=127.0.0.1:5331 --user=_dnscrypt-proxy # pfctl -sr block drop out log quick on egress from ! (egress:0) to any anchor test-out all pass out log quick on egress inet proto udp from any to 208.67.220.220 port = 443 user = 688 pass out log quick on egress inet proto tcp from any to 208.67.220.220 port = 443 user = 688 flags S/SA pass out log quick on egress inet proto icmp all icmp-type echoreq block drop in log quick from no-route to any block drop in log quick from urpf-failed to any block drop out log quick all block drop in log quick on egress inet from any to 255.255.255.255 anchor test-in all pass in log quick on egress inet proto icmp from any to (egress:0) icmp-type echoreq code 0 pass in log quick on egress inet proto tcp from any to (egress:0) port = 22 flags S/SA block drop in log quick all Now when dnscrypt-proxy tries to make a connection it is blocked. Interestingly there's even no logged outgoing connection, but just blocked return. # tcpdump -i pflog0 -n -e -ttt -vv tcpdump: WARNING: snaplen raised from 116 to 160 tcpdump: listening on pflog0, link-type PFLOG Jan 26 00:41:00.884036 rule 7/(match) [uid 0, pid 23524] block out on iwn0: [uid 0, pid 16665] 192.168.1.100.10976 208.67.220.220.443: udp 512 (ttl 64, id 9876, len 540, bad cksum 208! differs by e108) (from anchor) # pfctl -ss all tcp 192.168.1.100:16505 - 66.7.199.108:22 ESTABLISHED:ESTABLISHED Well it works if I add dnscrypt-proxy rule for root but why? Because the socket (hint: 1024) was opened with root rights, and therefore the uid=0 was saved there. -- WBR, Vadim Zhukov
Re: athn weirdness with two subnets
Em 25-01-2014 19:15, Eike Lantzsch escreveu: On Saturday 25 January 2014 11:11:43 you wrote: if you want athn0 and vr1 to be on the same network, bridge them together then assign an IP address to only one of the two. -ken Thanks Ken for the hint! I reckon that assigning IP addresses to both interfaces in the same network is not the correct approach. I tried your hint and at least the ALIX 2d13 is routing again. Just for the record: athn0 is the interface to assign the IP address. Otherwise it gets status no network and will not come up. # cat /etc/hostname.athn0 inet 192.168.12.1 255.255.255.128 chan 108 mediaopt hostap nwid mywlanid wpakey somelongkey # cat /etc/hostname.vr1 up media autoselect # cat /etc/hostname.bridge0 add athn0 add vr1 up And for the record again because somebody else had problems with this card: I can now connect via WiFi with my MACbook-Air on 5GHz (channel 108) but my Samsung Galaxy3 does not want to connect although it sees the network and the field strength is -39dBm @ 5540MHz. Trying the same on channel 6 results in nothing but a timeout error on both the MAC and the Samsung phone. No idea if this is due to the Compex card, the athn driver or the Samsung phone. On Sat, Jan 25, 2014 at 10:46 AM, Eike Lantzsch zp6...@gmx.net wrote: I'm using 5.4 stable on an ALIX 2D13 with Compex WLM200NX My internal network is 192.168.12.0/24 My ISP gives me 181.40.100.8 nm 255.255.255.0 gw 181.40.100.1 via DHCP with reserved IP address. This is on vr0 No problems here. I wanted to set up two internal networks on vr1: 192.168.12.0/25 and on vr2: 192.168.12.128/25 athn0 is also supposed to be on 192.168.12.0/25 The intended /etc/hostname.athn0 is: inet 192.168.12.2 255.255.255.128 /etc/hostname.vr0 dhcp /etc/hostname.vr1 inet 192.168.12.1 255.255.255.128 /etc/hostname.vr2 inet 192.168.12.129 255.255.255.128 The weirdness is as follows: according to ifconfig all interfaces are active BUT athn0 does not want to be on the same subnet with vr1 I cannot ping the internal IP 192.168.12.1 as long as athn0 is on 192.168.12.2 or any other address up to 192.168.12.126 that is in the subnet 192.168.12.128/25. I have to change athn0 to the other subnet with /etc/hostname.athn0 inet 192.168.12.130 255.255.255.128 In this case I can ping 192.168.12.1 and 192.168.12.130 (ping from inside the ALIX that is) [rest snipped for brevity] Or even better, bridge them and a vether(4) and assign the ip address to it, instead of one of the physical interfaces. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
