Re: Detailed statistics on em(4) driver
Hi, I've got problems with increasing Ierrs on several machines with several em(4) interfaces. Is there a way to get *detailed* information on these? # netstat -I em3 -d NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls Drop em3 1500 Link de:ad:be:ef 95655063 435896 63427593 0 00 em3 1500 fe80::%em3/ fe80::xx:ff:ffe 95655063 435896 63427593 0 00 is not that verbose. We hacked the kernel. The interface(s) just miss packets, see screenshot: http://imageshack.us/f/96/fkad.png/ Customer urged to move from OpenBSD to Ubuntu for BGP routing. Thanks in advance, Bernd
Re: trunk-ing + carp-ing
Hi again, Thanks for your responses. I found a setup that satisfies me: * SRV: trunk in failover mode * O1, O2: trunk in broadcast mode As only one link at a time is active on SRV, I don't get duplicates. And as it is the only one being in failover mode, no need of ifstated. Best Regards Michel -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Ganguin Michel Sent: mercredi, 19. juin 2013 11:45 To: misc@openbsd.org Subject: trunk-ing + carp-ing Hi misc, I have the following setup: * O1 and O2: two openbsd firewall/routers with: * carp-ed client side interface * trunked server side interfaces + carp-ed trunk device * SRV: server with trunked interfaces (for testing I'm using one server, but there will be 2 servers cross connected to the switches) * s: two switches with no inter switch link capability ++ +---+ +--+ O1 +-+ s +--+ | |+--\ /--+ | | +-+ +-+ | ++ \ / +---+ +--+ SRV | | CLI +---+X +--+ | +-+ | ++ / \ +---+ | +-+ | | O2 +--/ \--+ s | | +--++-+ +--+ ++ +---+ So SRV uses carp ip address as route and CLI uses the external carp ip address as route to reach SRV. And my high availability setup is transparent for the client. Each hardware (cables, routers, switches) may fail and my service is still reachable. My questions are: * what trunk to use? Without inter switch aggregation support I tried failover and broadcast * failover works fine, but active/failover interfaces needs to be switched manually in case of failure to select to correct active path, if think it could be automated with ifstated but I didn't test it yet. * broadcast works fine too, but the client receives packets duplicated 4 times, I don't know if it is normal behavior, shouldn't duplicates be filtered by the trunk device? Or is there a way to filter them? * Is my design correct, or did I miss something? Is there another (simpler) way to achieve my high availability goal? Config: O1 ifconfig lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33196 priority: 0 groups: lo inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet 127.0.0.1 netmask 0xff00 vr0: flags=8b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST mtu 1500 lladdr 00:0d:b9:2d:0f:54 priority: 0 groups: egress media: Ethernet autoselect (100baseTX full-duplex) status: active inet6 fe80::20d:b9ff:fe2d:f54%vr0 prefixlen 64 scopeid 0x1 vr1: flags=8b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST mtu 1500 lladdr 00:0d:b9:2d:0f:55 priority: 0 trunk: trunkdev trunk0 media: Ethernet autoselect (100baseTX full-duplex) status: active inet6 fe80::20d:b9ff:fe2d:f54%vr1 prefixlen 64 scopeid 0x2 vr2: flags=8b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST mtu 1500 lladdr 00:0d:b9:2d:0f:55 priority: 0 trunk: trunkdev trunk0 media: Ethernet autoselect (100baseTX full-duplex) status: active inet6 fe80::20d:b9ff:fe2d:f54%vr2 prefixlen 64 scopeid 0x3 enc0: flags=0 priority: 0 groups: enc status: active pflog0: flags=141UP,RUNNING,PROMISC mtu 33196 priority: 0 groups: pflog trunk0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 lladdr 00:0d:b9:2d:0f:55 priority: 0 trunk: trunkproto broadcast trunkport vr2 active trunkport vr1 master,active groups: trunk media: Ethernet autoselect status: active inet 192.168.10.1 netmask 0xff00 broadcast 192.168.10.255 inet6 fe80::20d:b9ff:fe2d:f55%trunk0 prefixlen 64 scopeid 0x7 carp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:00:5e:00:01:01 priority: 0 carp: BACKUP carpdev trunk0 vhid 1 advbase 1 advskew 0 groups: carp status: backup inet6 fe80::200:5eff:fe00:101%carp0 prefixlen 64 scopeid 0x8 inet 192.168.10.10 netmask 0xff00 broadcast 192.168.10.255 carp1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:00:5e:00:01:02 priority: 0 carp: BACKUP carpdev vr0 vhid 2 advbase 1 advskew 0 groups: carp status: backup inet6 fe80::200:5eff:fe00:102%carp1 prefixlen 64 scopeid 0x9 inet 10.0.0.10 netmask 0xff00 broadcast 10.0.0.255 O1 netstat -rn -f inet Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default10.0.0.1 UGS02 - 8 vr0 10.0.0/24 link#1 UC 00
Re: Detailed statistics on em(4) driver
On Wed, Jun 19, 2013 at 11:38 PM, Bernd be...@kroenchenstadt.de wrote: I've got problems with increasing Ierrs on several machines with several em(4) interfaces. Is there a way to get *detailed* information on these? # netstat -I em3 -d NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls Drop em3 1500 Link de:ad:be:ef 95655063 435896 63427593 0 00 em3 1500 fe80::%em3/ fe80::xx:ff:ffe 95655063 435896 63427593 0 00 is not that verbose. We hacked the kernel. The interface(s) just miss packets, see screenshot: http://imageshack.us/f/96/fkad.png/ No dmesg (which would have included the output of your printfs, in text form!), fail to describe your kernel hacks, and then you *upload a picture of your console*?!? Customer urged to move from OpenBSD to Ubuntu for BGP routing. Good luck with that! Philip Guenther
Re: Detailed statistics on em(4) driver
On Thu, Jun 20, 2013 at 08:38:11AM +0200, Bernd wrote: Hi, I've got problems with increasing Ierrs on several machines with several em(4) interfaces. Is there a way to get *detailed* information on these? # netstat -I em3 -d NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls Drop em3 1500 Link de:ad:be:ef 95655063 435896 63427593 0 00 em3 1500 fe80::%em3/ fe80::xx:ff:ffe 95655063 435896 63427593 0 00 is not that verbose. We hacked the kernel. The interface(s) just miss packets, see screenshot: http://imageshack.us/f/96/fkad.png/ Customer urged to move from OpenBSD to Ubuntu for BGP routing. Thanks in advance, Bernd What does sysctl net.inet.ip.ifq say? On a side note: you are not sharing *any* details, so expect your emails to be ignored by most people here. And with good reason. -Otto
Re: Detailed statistics on em(4) driver
On 20 June 2013 08:38, Bernd be...@kroenchenstadt.de wrote: Hi, I've got problems with increasing Ierrs on several machines with several em(4) interfaces. Is there a way to get *detailed* information on these? # netstat -I em3 -d NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls Drop em3 1500 Link de:ad:be:ef 95655063 435896 63427593 0 00 em3 1500 fe80::%em3/ fe80::xx:ff:ffe 95655063 435896 63427593 0 00 is not that verbose. We hacked the kernel. The interface(s) just miss packets, see screenshot: http://imageshack.us/f/96/fkad.png/ Customer urged to move from OpenBSD to Ubuntu for BGP routing. Missed packets means the ring buffer is full and the card has to drop the packet. In other words, you're not fast enough. Send a dmesg, and we need an idea of the packet rate you're pushing, chances are you're hitting our stack limit.
Re: setting ttl
* Chris Smith obsd_m...@chrissmith.org [2013-06-19 16:20]: On Wed, Jun 19, 2013 at 6:43 AM, Henning Brauer lists-open...@bsws.de wrote: no Thanks. Any plans to implement this? no. -- 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, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: Squid3 in intercept mode
On 2013-06-19, Lars Nooden lars.noo...@gmail.com wrote: On Wed, 19 Jun 2013, Reyk Floeter wrote: Anyway, you should make sure to use divert-to instead of rdr-to in your pf.conf. rdr-to is considered to be obsolete for userland proxies (except for spamd). That solved it exactly. I had not seen the change and had been trying rdr-to instead of divert-to. Did you find any official instructions with out-of-date information? I have made sure that the pkg-readme and also Squid's wiki have correct information for interception proxies.
Re: USB temperature sensors
On 2013-06-19, rafaello konfekte peleekaiskardina...@gmail.com wrote: Hello, Thanks Barry, this was exactly what I was looking for. Been using it now for a couple of days with TEMPer sensor on both 5.3 stable and current by using this patch written by SASANO Takayoshi: http://www2192ue.sakura.ne.jp/~uaa/gomitext/2013/20130331/20130331.diff Any ideas when this could go into source tree? http://marc.info/?l=openbsd-techm=136472023131435w=2 http://marc.info/?l=openbsd-techm=136762807930749w=2 There is a newer version here, http://www.uaa.org.uk/gomitext/2013/20130513/20130513.diff mpi found a few more issues to fix, I have an additional diff to go over the top of the above which fixes some but not all of these: http://junkpile.org/ugold-20130513-patches.diff Though even with the issues it is still more reliable than uthum.
Re: pf looses skip on tun0 after OpenVPN startup
On 2013-06-19, Ryan Slack r...@evine.ca wrote:
In pf.conf I've got skip on {lo,tun0}, however after openvpn starts,
skip is removed from tun0. Is there a way to avoid this?
In the mean time I've added pass quick on tun0 to pf.conf.
You will probably need to reload pf.conf, I believe openvpn re-creates
the tun interface.
Re: Squid3 in intercept mode
On Thu, 20 Jun 2013, Stuart Henderson wrote: On 2013-06-19, Lars Nooden lars.noo...@gmail.com wrote: On Wed, 19 Jun 2013, Reyk Floeter wrote: Anyway, you should make sure to use divert-to instead of rdr-to in your pf.conf. rdr-to is considered to be obsolete for userland proxies (except for spamd). That solved it exactly. I had not seen the change and had been trying rdr-to instead of divert-to. Did you find any official instructions with out-of-date information? I have made sure that the pkg-readme and also Squid's wiki have correct information for interception proxies. No. It was my fault for going through the README but not catching 'divert-to' I had gotten the two confused with what I had once (last) set up with 4.2 or 4.1. I did notice that pf.conf(5) has several examples for rdr-to which seem on the surface to do what I was aiming for, but none for divert-to. Regards, /Lars
Re: CWM crash
Thanks Okan,
I use the selfont config, Just removed it, and worked! I will wait the
next snapshot.
Att,
2013/6/19 Okan Demirmen o...@demirmen.com
On Wed 2013.06.19 at 22:04 -0400, Okan Demirmen wrote:
On Wed 2013.06.19 at 22:34 -0300, Rodrigo Mosconi wrote:
Hello Misc,
The Jun18/19 snapshot have a break version of CWM
It`s always crash when I try to resize a window (just click M-M1, and
then
its segfaults).
Follow dmesg and GDB
Thanks
tales:mosconi {102} gdb cwm
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as i386-unknown-openbsd5.3...
(no debugging symbols found)
(gdb) run
Starting program: /usr/X11R6/bin/cwm
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
Program received signal SIGSEGV, Segmentation fault.
0x097a2574 in XftDrawStringUtf8 () from /usr/X11R6/lib/libXft.so.8.0
(gdb)
gah - do you have 'color selfont some color' defined in your .cwmrc?
fix just committed; thanks for the report. if you can't build -current,
just comment out color selfont until then.
thanks,
okan
carp hung at INIT after update to current snapshot--followup #2
Followup #2. I tried booting the older kernels available to me to see if I could narrow down the range of the time this problem began. The kernel from June 9 boots as expected and carp moves to master status as it should. The kernel from June 13 boots but carp stays stuck in INIT. The most recent snapshot also boots with carp staying in INIT. I hope that narrows the range down enough to provide a clue. Thanks again. Jeff Followup: When running sh -x /etc/netstart, I get the following on the firewall stuck in INIT: + ifmstart trunk svlan vlan carp ifconfig: SIOCAIFADDR: No buffer space available ifconfig: SIOCAIFADDR: No buffer space available The normally backup firewall running /etc/netstart from OpenBSD 5.3-current (GENERIC.MP) #148: Tue Apr 30 11:41:58 MDT 2013 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP shows this instead + ifmstart trunk svlan vlan carp gif gre pfsync pppoe tun bridge Hope that helps! Jeff Hi all, Tonight I updated to the June 17 snapshot on my primary firewall. Before updating carp has been working flawlessly, with this server the primary and its twin the secondary. When I'd reboot the primary the secondary would become master but only until the primary had finished rebooting. After updating and reboot the primary's carp0 and carp1 interfaces remain in INIT. I did run sysmerge and don't see anything apropos in the Running -current section of the FAQ. My secondary firewall took over as carp master on reboot but I'm a little leery of updating or even rebooting it to see if the primary will take over--I'm 650 miles from the server room :-) dmesg, ifconfig -a and /etc/hostname* follow. Thanks, Jeff Ross OpenBSD 5.3-current (GENERIC.MP) #7: Mon Jun 17 12:17:04 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Xeon(TM) CPU 3.20GHz (GenuineIntel 686-class) 3.21 GHz cpu0: FPU,V86,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,LONG,SSE3,DTES64,MWAIT,DS-CPL,CNXT-ID,CX16,xTPR,LAHF,PERF real mem = 3757490176 (3583MB) avail mem = 3684646912 (3513MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 03/29/05, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.3 @ 0xfa380 (61 entries) bios0: vendor American Megatrends Inc. version 080010 date 03/29/2005 bios0: SiMech R200 acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC OEMB acpi0: wakeup devices PXHA(S4) PXHB(S4) EPA0(S4) EPA1(S4) EPB0(S4) EPB1(S4) EPC0(S4) P0P1(S4) MC97(S4) USB1(S1) USB2(S1) EUSB(S4) PS2K(S4) PS2M(S4) P0PC(S4) SLPB(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 200MHz cpu1 at mainbus0: apid 6 (application processor) cpu1: Intel(R) Xeon(TM) CPU 3.20GHz (GenuineIntel 686-class) 3.21 GHz cpu1: FPU,V86,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,LONG,SSE3,DTES64,MWAIT,DS-CPL,CNXT-ID,CX16,xTPR,LAHF,PERF cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Xeon(TM) CPU 3.20GHz (GenuineIntel 686-class) 3.21 GHz cpu2: FPU,V86,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,LONG,SSE3,DTES64,MWAIT,DS-CPL,CNXT-ID,CX16,xTPR,LAHF,PERF cpu3 at mainbus0: apid 7 (application processor) cpu3: Intel(R) Xeon(TM) CPU 3.20GHz (GenuineIntel 686-class) 3.21 GHz cpu3: FPU,V86,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,LONG,SSE3,DTES64,MWAIT,DS-CPL,CNXT-ID,CX16,xTPR,LAHF,PERF ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins ioapic1 at mainbus0: apid 11 pa 0xfec1, version 20, 24 pins ioapic1: misconfigured as apic 9, remapped to apid 11 ioapic2 at mainbus0: apid 9 pa 0xfec8, version 20, 24 pins ioapic2: misconfigured as apic 10, remapped to apid 9 ioapic3 at mainbus0: apid 10 pa 0xfec80400, version 20, 24 pins ioapic3: misconfigured as apic 11, remapped to apid 10 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (EPA0) acpiprt2 at acpi0: bus 3 (PXHA) acpiprt3 at acpi0: bus 2 (PXHB) acpiprt4 at acpi0: bus 4 (EPA1) acpiprt5 at acpi0: bus 6 (P0P1) acpiprt6 at acpi0: bus 5 (P0PC) acpicpu0 at acpi0 acpicpu1 at acpi0 acpicpu2 at acpi0 acpicpu3 at acpi0 acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: SLPB bios0: ROM list: 0xc/0x8000 0xc8000/0x800 0xc8800/0x1000 0xc9800/0x1000 ipmi at mainbus0 not configured pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel E7320 Host rev 0x0c ppb0 at pci0 dev 2 function 0 Intel E7520 PCIE rev 0x0c pci1 at ppb0 bus 1 ppb1 at pci1 dev 0 function 0 Intel 6700PXH PCIE-PCIX rev 0x09 pci2 at ppb1 bus 3 mpi0 at pci2 dev 5 function 0 Symbios Logic 53c1030 rev 0xc1: msi scsibus0 at mpi0: 16 targets, initiator 7 ppb2 at pci1 dev 0 function 2
xl2tpd lost packets
help me. What i'm doing wrong? pkg_add xl2tpd (OK) pf - disabled vi /etc/xl2tpd/xl2tpd.conf [lac beeline] lns = vpn.dzer.b2b.local redial = yes autodial = yes vi /etc/ppp/options name user vi /etc/ppp/chap-secrets user * password vi /etc/ppp/pap-secrets user * password vi /etc/rc.conf.local pkg_scripts=xl2tpd route -n show -inet Routing tables Internet: Destination Gateway Flags Refs Use Mtu Prio Iface default 195.98.58.194 UGS 10 1509230 - 6 ppp0 default 10.55.254.65 UGS 1 1514844 - 8 em0 10.55.254.64/26 link#1 UC 1 0 - 4 em0 10.55.254.65 00:22:b0:2f:eb:34 UHLc 2 3109 - 4 em0 10.55.254.126 127.0.0.1 UG 0 0 33152 56 lo0 127/8 127.0.0.1 UGRS 0 0 33152 8 lo0 127.0.0.1 127.0.0.1 UH 3 2177215 33152 4 lo0 172.18.255.15 10.55.254.65 UGHS 0 2950 - 8 em0 192.168.10/24 link#2 UC 3 0 - 4 em1 192.168.10.50 f4:6d:04:dd:45:9a UHLc 3 11486133 - 4 em1 192.168.10.62 link#2 UHLc 1 94544 - 4 em1 192.168.10.255 link#2 UHLc 2 247 - 4 em1 195.98.58.194 XXX.XXX.XXX.XXX UH 1 3177 - 4 ppp0 224/4 127.0.0.1 URS 0 0 33152 8 lo0 # ifconfig em0: flags=8b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST mtu 1500 lladdr 00:1e:8c:f2:13:7a priority: 0 media: Ethernet autoselect (100baseTX full-duplex) status: active inet6 fe80::21e:8cff:fef2:137a%em0 prefixlen 64 scopeid 0x1 inet 10.55.254.126 netmask 0xffc0 broadcast 10.55.254.127 em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:1b:21:39:84:fb priority: 0 media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) status: active inet 192.168.10.1 netmask 0xff00 broadcast 192.168.10.255 inet6 fe80::21b:21ff:fe39:84fb%em1 prefixlen 64 scopeid 0x2 ppp0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1464 priority: 0 groups: ppp egress inet XXX.XXX.XXX.XXX -- 195.98.58.194 netmask 0xff00 Check link to gateway ISP(em0) and to vpn.dzer.b2b.local (172.18.255.15) - GOOD mtu (1472+28=1500) and when # ping -D -s 1472 10.55.254.65 PING 10.55.254.65 (10.55.254.65): 1472 data bytes 1480 bytes from 10.55.254.65: icmp_seq=0 ttl=255 time=2.028 ms 1480 bytes from 10.55.254.65: icmp_seq=1 ttl=255 time=2.225 ms 1480 bytes from 10.55.254.65: icmp_seq=2 ttl=255 time=2.060 ms 1480 bytes from 10.55.254.65: icmp_seq=3 ttl=255 time=2.073 ms # ping -D -s 1472 172.18.255.15 PING 172.18.255.15 (172.18.255.15): 1472 data bytes 1480 bytes from 172.18.255.15: icmp_seq=0 ttl=252 time=0.982 ms 1480 bytes from 172.18.255.15: icmp_seq=1 ttl=252 time=0.944 ms 1480 bytes from 172.18.255.15: icmp_seq=2 ttl=252 time=0.936 ms 1480 bytes from 172.18.255.15: icmp_seq=3 ttl=252 time=0.936 ms # tcpdump -i em0 icmp tcpdump: listening on em0, link-type EN10MB tcpdump: WARNING: compensating for unaligned libpcap packets 21:15:57.299040 10.55.254.126 10.55.254.65: icmp: echo request (DF) 21:15:57.301029 10.55.254.65 10.55.254.126: icmp: echo reply (DF) [tos 0x28] 21:15:58.303589 10.55.254.126 10.55.254.65: icmp: echo request (DF) 21:15:58.305759 10.55.254.65 10.55.254.126: icmp: echo reply (DF) [tos 0x28] 21:15:59.313555 10.55.254.126 10.55.254.65: icmp: echo request (DF) 21:15:59.315579 10.55.254.65 10.55.254.126: icmp: echo reply (DF) [tos 0x28] 21:16:00.323548 10.55.254.126 10.55.254.65: icmp: echo request (DF) 21:16:00.325562 10.55.254.65 10.55.254.126: icmp: echo reply (DF) [tos 0x28] 21:25:00.365887 10.55.254.126 172.18.255.15: icmp: echo request (DF) 21:25:00.366809 172.18.255.15 10.55.254.126: icmp: echo reply (DF) [tos 0x28] 21:25:01.368684 10.55.254.126 172.18.255.15: icmp: echo request (DF) 21:25:01.369586 172.18.255.15 10.55.254.126: icmp: echo reply (DF) [tos 0x28] 21:25:02.378666 10.55.254.126 172.18.255.15: icmp: echo request (DF) 21:25:02.379578 172.18.255.15 10.55.254.126: icmp: echo reply (DF) [tos 0x28] 21:25:03.388677 10.55.254.126 172.18.255.15: icmp: echo request (DF) 21:25:03.389563 172.18.255.15 10.55.254.126: icmp: echo reply (DF) [tos 0x28] === Check link to gateway ISP(ppp0) - BAD mtu (1436+28=1464) mtu (972+28=1000) but some sites does not open or slow open. mtu (548+28=576) site open (which in mtu 1000 does not). But internet slow and some pockets lost(i think so) and when # ping -D -s 1436 195.98.58.194 PING 195.98.58.194 (195.98.58.194): 1436 data bytes # tcpdump -i ppp0 icmp tcpdump: listening on ppp0, link-type PPP 21:29:54.656277 XXX.XXX.XXX.XXX 195.98.58.194: icmp: echo request (DF) 21:29:55.666047 XXX.XXX.XXX.XXX 195.98.58.194: icmp: echo request (DF) 21:29:56.676027 XXX.XXX.XXX.XXX 195.98.58.194: icmp: echo request (DF) 21:29:57.686021 XXX.XXX.XXX.XXX 195.98.58.194: icmp: echo request (DF) # ping -D -s 972 195.98.58.194 PING 195.98.58.194 (195.98.58.194): 972 data bytes 980 bytes from 195.98.58.194: icmp_seq=0 ttl=255 time=0.907 ms 980 bytes from 195.98.58.194: icmp_seq=1 ttl=255 time=0.910 ms 980 bytes from 195.98.58.194: icmp_seq=2 ttl=255 time=0.837 ms 980 bytes from
Re: Problem with icmp state creation on 5.3 PF
On 2013-06-18, Wiesław Herr hers...@makhleb.net wrote: Hi misc@! After deploying a new OpenBSD 5.3 firewall today I ran into a strange problem. The first rule in my ruleset is one NAT-ing ICMP packets from my host to Google's DNS IP (8.8.8.8): fw1a-spt # pfctl -sr -R0 pass out log quick inet proto icmp from 192.168.5.96 to 8.8.8.8 nat-to 195.182.23.4 I suspect you may have an issue where state is not being created where you expect it. It's now recommended (and we've changed the sample pf.conf to match) to start your ruleset with an explicit block (or block log) rule to ensure that you don't accidentally allow any traffic to pass without keeping state.
Re: pf looses skip on tun0 after OpenVPN startup
On 06/20/2013 09:03 AM, Stuart Henderson wrote:
On 2013-06-19, Ryan Slack r...@evine.ca wrote:
In pf.conf I've got skip on {lo,tun0}, however after openvpn starts,
skip is removed from tun0. Is there a way to avoid this?
In the mean time I've added pass quick on tun0 to pf.conf.
You will probably need to reload pf.conf, I believe openvpn re-creates
the tun interface.
I believe the persist-tun option in server.conf can help in this case.
- Aner
Re: smtpd aliases
Hi William, I would suggest trying these things first: - have you checked smtpd main page to Modify the current mailwrapper(8) settings? - stop smtpd and run it in foreground smtpd -d -v, so all the info will go to stderr - try to exclude dovecot and check that smtpd can deliver messages to local user's mbox first. This should give you enough info to find the root cause of your error, if not - I would be interested to see the output of above. I am using OpenSMTPD for almost a 6 months now, it rocks - nice powerful and simple program! Thank you and good luck with your mail setup, -- Sincerely yours, Denis = The Bible for command line people. http://www.read-and-think.org/kjv.html =
Re: Problem with icmp state creation on 5.3 PF
On 20 June 2013 16:53, Stuart Henderson s...@spacehopper.org wrote: On 2013-06-18, WiesÅaw Herr hers...@makhleb.net wrote: I suspect you may have an issue where state is not being created where you expect it. It's now recommended (and we've changed the sample pf.conf to match) to start your ruleset with an explicit block (or block log) rule to ensure that you don't accidentally allow any traffic to pass without keeping state. In case of a tproxy, which does no-evil and necessary IP spoofing, how will states be treated? My PF is in production, so I can not test now, but I had same issue (packets that bypass nat) with route-to from an interface to another and nat-to in the later. I have disabled states to test, and well... nat-to does not work without it... so I leave everything without states, only nat-to, but the same problem ocurred. By now in our ISP we have made a choice for the felxibility of FreeBSD IPFW, but I really like OpenBSD correctness and the shinny match PF rules, and ALTQ being removed/reconstructed in a new way.
Re: xl2tpd lost packets
and in /var/log/messages Jun 20 10:26:33 main pppd[19445]: Protocol-Reject for unsupported protocol 0xbe6b Jun 20 10:26:42 main last message repeated 2 times Jun 20 11:01:33 main pppd[19445]: Protocol-Reject for unsupported protocol 0xd0d2 Jun 20 11:27:51 main pppd[19445]: Protocol-Reject for unsupported protocol 0xba44 Jun 20 13:29:10 main pppd[19445]: Protocol-Reject for unsupported protocol 0xb694 Jun 20 13:29:16 main pppd[19445]: Protocol-Reject for unsupported protocol 0xb694 Jun 21 05:47:45 main pppd[19445]: Protocol-Reject for unsupported protocol 0x9e07
