Re: pf and torrenting
On Wed, Oct 31, 2012 at 11:08 PM, Matt M. cmorrow...@gmail.com wrote: I am trying to get torrenting to work but I can't seem to get any packets to go through. Tcpdump shows attempted activity and nothing blocked,but the torrent client itself doesn't seem to be receiving anything from any torrent I have tried. The torrent client is using port 58846 Which torrent client, what command line options used, what was in tcpdump, what version of OpenBSD. From the pf.conf: --- ext_if=rl0 pass in on $ext_if proto tcp from any to any port 58846 rdr-to 192.168.1.101 port 58846 Useless without complete pf.conf. You can trim out IPs for safety
Re: Upgrade to 5.2?
/ Tyler Morgan wrote on Wed 31.Oct'12 at 20:04:11 -0700 / Don't do it! Seriously, the upgrade process is easy, and is worth becoming familiar with. At least give it a shot since you're planning on reinstalling anyway. I think you'll be pleasantly surprised! For a long time I did fresh installs too since my average OpenBSD box is a router with ~15 files changed from default and little to no packages so it was trivial to recreate, and even then I should have been upgrading in hindsight. Yeah sure i'll give it go. It would make life a bit easier anyway if all goes to plan. Thanks for your comments. Jamie
Re: Upgrade to 5.2?
/ Tyler Morgan wrote on Wed 31.Oct'12 at 20:04:11 -0700 / Don't do it! Seriously, the upgrade process is easy, and is worth becoming familiar with. At least give it a shot since you're planning on reinstalling anyway. I think you'll be pleasantly surprised! Just out of curiosity, do you think the easiest method is to use the bds.rd method or should I use a CD to do the upgrade, is one method preferred or easier over the other?
Re: Upgrade to 5.2?
Den Thu, 1 Nov 2012 08:11:26 + skrev Jamie Paul Griffin ja...@kode5.net: / Tyler Morgan wrote on Wed 31.Oct'12 at 20:04:11 -0700 / Don't do it! Seriously, the upgrade process is easy, and is worth becoming familiar with. At least give it a shot since you're planning on reinstalling anyway. I think you'll be pleasantly surprised! Just out of curiosity, do you think the easiest method is to use the bds.rd method or should I use a CD to do the upgrade, is one method preferred or easier over the other? I always (well almost, I have some systems where I do the tar thing) use bsd.rd and it has worked perfect for me every time so far! I don't know if it's the official preferred way but it's the way I prefer!:-)
Re: Upgrade to 5.2?
Den Thu, 1 Nov 2012 09:34:50 +0100 skrev Anders Trobäck b...@troback.com: Den Thu, 1 Nov 2012 08:11:26 + skrev Jamie Paul Griffin ja...@kode5.net: / Tyler Morgan wrote on Wed 31.Oct'12 at 20:04:11 -0700 / Don't do it! Seriously, the upgrade process is easy, and is worth becoming familiar with. At least give it a shot since you're planning on reinstalling anyway. I think you'll be pleasantly surprised! Just out of curiosity, do you think the easiest method is to use the bds.rd method or should I use a CD to do the upgrade, is one method preferred or easier over the other? I always (well almost, I have some systems where I do the tar thing) use bsd.rd and it has worked perfect for me every time so far! I don't know if it's the official preferred way but it's the way I prefer!:-) Don't forget to buy something else or donate to support the project;-)
Re: Upgrade to 5.2?
On Thu, Nov 01, 2012 at 09:34:50AM +0100, Anders Trob?ck wrote: Den Thu, 1 Nov 2012 08:11:26 + skrev Jamie Paul Griffin ja...@kode5.net: / Tyler Morgan wrote on Wed 31.Oct'12 at 20:04:11 -0700 / Don't do it! Seriously, the upgrade process is easy, and is worth becoming familiar with. At least give it a shot since you're planning on reinstalling anyway. I think you'll be pleasantly surprised! Just out of curiosity, do you think the easiest method is to use the bds.rd method or should I use a CD to do the upgrade, is one method preferred or easier over the other? I always (well almost, I have some systems where I do the tar thing) use bsd.rd and it has worked perfect for me every time so far! I don't know if it's the official preferred way but it's the way I prefer!:-) Doing an upgrade running bsd.rd loaded from a disk is pretty much the same as loading bsd.rd from cd. It's actually the same file, so do what is most convenient for you. The cd has alls the sets, in some cases it is faster than using net. In other cases using the net is faster or more convenient. Decide for yourself. untarring the sets and copying the kernel by hand is not recommended. -Otto
pf block unwanted traffic
Hi, I saw this today on my firewall: Nov 01 12:51:10.857175 rule def/(short) pass in on vlanxxx: 74.206.235.92.0 xx.xx.xx.xx.0: FPE [bad hdr length] (DF) Nov 01 12:51:12.724286 rule def/(short) pass in on vlanxxx: 74.206.235.92.0 xx.xx.xx.xx.0: FPE 1137099714:1137099726(12) ack 0 win 6667 urg 0 (DF) Nov 01 12:51:14.027193 rule def/(short) pass in on vlanxxx: 74.206.235.92.0 xx.xx.xx.xx.0: SFR [bad hdr length] (DF) Nov 01 12:51:15.692047 rule def/(short) pass in on vlanxxx: 74.206.235.92.0 xx.xx.xx.xx.0: RPWE [bad hdr length] (DF) Nov 01 12:51:16.121181 rule def/(short) pass in on vlanxxx: 74.206.235.92.0 xx.xx.xx.xx.0: SFPW [bad hdr length] (DF) Nov 01 12:51:17.962807 rule def/(short) pass in on vlanxxx: 74.206.235.92.0 xx.xx.xx.xx.0: SE [bad hdr length] (DF) Nov 01 12:51:21.934774 rule def/(short) pass in on vlanxxx: 74.206.235.92.0 xx.xx.xx.xx.0: SFW [bad hdr length] (DF) Nov 01 12:51:26.985783 rule def/(short) pass in on vlanxxx: 74.206.235.92.0 xx.xx.xx.xx.0: SRPWE 1137099714:1137099730(16) win The internal addresses are changing so it's something like a port scan... I 've added first rule in pf block drop quick from 74.206.235.92 block drop quick to 74.206.235.92 @0 block drop quick inet from 74.206.235.92 to any [ Evaluations: 36837 Packets: 2 Bytes: 96 States: 0 ] [ Inserted: uid 0 pid 12234 State Creations: 0 ] @1 block drop quick inet from any to 74.206.235.92 [ Evaluations: 36743 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 12234 State Creations: 0 ] apparently something is blocked, but also something is passed since I still get these mesages on my pflog. pfctl -ss shows no state for 74.206.235.92 How can I block these? What is it exactly ? regards, Giannis
Re: Upgrade to 5.2?
Don't do it! Seriously, the upgrade process is easy, and is worth becoming familiar with. At least give it a shot since you're planning on reinstalling anyway. I think you'll be pleasantly surprised! Just out of curiosity, do you think the easiest method is to use the bds.rd method or should I use a CD to do the upgrade, is one method preferred or easier over the other? I always (well almost, I have some systems where I do the tar thing) use bsd.rd and it has worked perfect for me every time so far! I don't know if it's the official preferred way but it's the way I prefer!:-) I use installation scripts and test from scratch on a seperate system first. I guess it is a little more work especially initially but it is self documenting to a large degree and as I say makes it easy to conduct quick tests. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: Upgrade to 5.2?
/ Anders Trobäck wrote on Thu 1.Nov'12 at 9:40:43 +0100 / Den Thu, 1 Nov 2012 09:34:50 +0100 skrev Anders Trobäck b...@troback.com: Den Thu, 1 Nov 2012 08:11:26 + skrev Jamie Paul Griffin ja...@kode5.net: / Tyler Morgan wrote on Wed 31.Oct'12 at 20:04:11 -0700 / Don't do it! Seriously, the upgrade process is easy, and is worth becoming familiar with. At least give it a shot since you're planning on reinstalling anyway. I think you'll be pleasantly surprised! Just out of curiosity, do you think the easiest method is to use the bds.rd method or should I use a CD to do the upgrade, is one method preferred or easier over the other? I always (well almost, I have some systems where I do the tar thing) use bsd.rd and it has worked perfect for me every time so far! I don't know if it's the official preferred way but it's the way I prefer!:-) Don't forget to buy something else or donate to support the project;-) Absolutely. I am a CS student so funds currently are a bit limited but having used the OS for a short time, I love it and will certainly make a donation ASAP. My favourite OS by far which reads a bit arse-licky but so what. I'd be happy to support a project like this. Thanks for the help. Jamie
Re: Upgrade to 5.2?
Otto Moerbeek wrote: untarring the sets and copying the kernel by hand is not recommended. I used the perfect phrase for this in a presentation on PF a week ago: You wouldn't ever do this... unless maybe you hate yourself. --Kurt
Re: smtpd(8), aliases(5), forward(5): non-zero exit code causes deliveries abort
On Apr 14 19:48:24, mcmer-open...@tor.at wrote: hello (opensmtpd-) folks, I think OpenSMTPd aborts delivery to multiple aliased recipients as soon as a delivery attempt returns non-zero. I consider this unwanted: a super user defined delivery list in aliases(5) is not applied if some foolish luser messes up her/his .forward. How I found out about this: in aliases(5): foobar: b_user, a_user (Verbose log shows this get's reordered to a_user, b_user. I'm not sure that is good.) forward(5) of a_user (that's the one tried first) |/usr/local/bin/procmail after that delivery to b_user is not attempted. THis is relevant to my previous post: why is procmail failing here in the first place? I find that procmail always fails for me without the -f option. If I change a_user's forward(5) to |/usr/local/bin/procmail; exit 0 The same can be achieved, perhaps a bit more cleanly, by setting DELIVERED in your ~/.procmailrc If set to `yes' procmail will pretend (to the mail agent) the mail has been delivered. If mail cannot be delivered after having met this assignment (set to `yes'), the mail will be lost (i.e., it will not bounce).
OBSD51: using macros with reply-to
Hi, I had this pf rules int_if = trunk1 cosmo = 172.16.99.249 pass in on $int_if from VoIP to ! redeOscar route-to $cosmo@$int_if However, when I issue a pfctl -sr, I get pass in on trunk1 inet from VoIP to ! redeOscar flags S/SA route-to 172.16.99.249@$int_if Shouldn't this @$int_if be translated to trunk1 ? Is there another way to acomplish this ? Best regards, -- Fernando M. Braga +55 82 9636-2810
Re: pf and torrenting
*I am trying to get torrenting to work but I can't seem to get any packets to go through. Tcpdump shows attempted activity and nothing blocked,but the torrent client itself doesn't seem to be receiving anything from any torrent I have tried. The torrent client is using port 58846 From the pf.conf: --- ext_if=rl0 pass in on $ext_if proto tcp from any to any port 58846 rdr-to 192.168.1.101 port 58846* --- Thanks everyone who responded. I got it working by switching to transmission.
Re: Upgrade to 5.2?
On Thu, Nov 01, 2012 at 08:11:26AM +, Jamie Paul Griffin wrote: / Tyler Morgan wrote on Wed 31.Oct'12 at 20:04:11 -0700 / Don't do it! Seriously, the upgrade process is easy, and is worth becoming familiar with. At least give it a shot since you're planning on reinstalling anyway. I think you'll be pleasantly surprised! Just out of curiosity, do you think the easiest method is to use the bds.rd method or should I use a CD to do the upgrade, is one method preferred or easier over the other? I've been doing remote upgrades for almost 12 years, sometimes from thousands of miles away (i.e. no room for error). 5.2 will be maybe my 20th upgrade on my main server, give or take a few machine changes. I just carefully follow the upgrade guide: http://openbsd.org/faq/upgrade51.html
OpenBSD 5.2 Released
November 1, 2012. We are pleased to announce the official release of OpenBSD 5.2. This is our 32nd release on CD-ROM (and 33rd via FTP). We remain proud of OpenBSD's record of more than ten years with only two remote holes in the default install. As in our previous releases, 5.2 provides significant improvements, including new features, in nearly all areas of the system: - pthreads(3) support: o The most significant change in this release is the replacement of the user-level uthreads by kernel-level rthreads, allowing multithreaded programs to utilize multiple CPUs/cores. o Use PTHREAD_MUTEX_STRICT_NP as default mutex type. o Added pthread spinlock and barrier routines. o Added pthread_mutex_timedlock(3) and sem_timedwait(3). o Added pthread_condattr_setclock(3). o Added support for live multi-threaded debugging in gdb(1). o Improved handling for rusage totals and interval timers in threaded processes. o Changed the RLIMIT_NPROC rlimit to count processes instead of threads. o Added a new system limit kern.maxthread for the max number of threads. o Closed race conditions in thread creation, and in fork(2) and open(2) in a threaded process. o Improved handling of threaded processes in ps(1), top(1), and fstat(1). o Changed the lock around dlopen() to be recursive, so that dl*() operations from atexit() handlers don't deadlock. o Many fixes to pthread attribute and mutex error checking and cancellation handling. - Improved hardware support, including: o Added hibernation support on i386. Currently only working on pciide(4) and wd(4) disks. o Improved support for ALPS based touchpads in wsmouse(4) and the synaptics(4) X.Org input driver. o Performance improvements with ix(4) Intel 10Gb Ethernet NICs. o Support for i350 based devices in em(4). o Flow control support for bnx(4). o Hardware watchdog and HPET support for tcpcib(4) (Intel Atom E600) as found in some embedded x86 systems. o urndis(4) supports additional Android devices. o Support for Winbond W83627UHG has been added to wbsio(4). o Support for the SMBus controller of the AMD CS5536 in glxpcib(4) and the NVIDIA MCP89 in nviic(4). o Support for AX88772B based devices has been added to axe(4). o Support for MCS7832 based devices has been added to mos(4). o Support for the Roland UM-ONE has been added to umidi(4). o Support for the AMD Hudson-2 chipset has been added to azalia(4) and piixpm(4). o Support for NetMos NM9820 cardbus serial cards has been added to com(4). o Support for Huawei Mobile E303 has been added to umsm(4). o The sgi port now supports the R4000 Indigo (IP20), Indy (IP22), R4000 Indigo2 (IP24) and POWER Indigo2 R1 (IP28) families. - Generic network stack improvements: o Increased TCP initial window to 14600 bytes as proposed in draft-ietf-tcpm-initcwnd. o Cleanup handling of sockaddrs in degenerate use cases. o Improved handling of error and limit cases in file descriptor passing. o Improved socketbuffer handling for AF_UNIX sockets. o Fix yet another file descriptor leak in message passing. o Improved error handling in socket splicing. o IPv6 privacy addresses now appear alongside SLAAC addresses. o Support for Extended Sequence Numbers has been added to the IPsec stack and iked(8). o Bridging two IPv4 networks over an IPv6 link with gif(4) is now possible. - Routing daemons and other userland network improvements: o sndiod(1), bgpd(8), dvmrpd(8), ftp-proxy(8), iked(8), iscsid(8), ldapd(8), ldpd(8), nsd(8), ospf6d(8), ospfd(8), relayd(8), ripd(8), snmpd(8), spamd(8), sshd(8), tcpbench(1) and tmux(1) now rate limit their accepting of new connections when experiencing file descriptor exhaustion. o Allow route(8) destination/prefixlen syntax for IPv6 routes. o ASCII packet dumping support in tcpdump(8). o Better etherip and BGP protocol support in tcpdump(8). o isakmpd(8) and tcpdump(8) now recognize additional Internet Key Exchange DH groups. o Various improvements in iked(8) including support for retransmits. o ipsecctl(8) now allows SA lifetimes to be specified in its ipsec.conf(5) file. o tftpd(8) rewritten as a persistent, non-blocking daemon. o tftp(1) client now supports IPv6. o snmpd(8) now supports PF-MIB, UCD-DISKIO-MIB, and additional OIDs in HOST-RESOURCES-MIB. o bgpd(8) is now more robust when encountering network instability. o Adjust the bgpd(8) route decision code to cover checks needed due to route reflection. o Various fixes to improve error reporting in bgpd(8) including support of RFC 6608. o For debugging purposes bgpctl(8) can load MRT dumps into bgpd(8). o Fixed distribution of MPLS VPN routes in bgpd(8). o Introduced a new option selected to the bgpctl(8) show
Re: OBSD51: using macros with reply-to
the syntax should be like this: pass in on $int_if from VoIP to ! redeOscar route-to ($int_if $cosmo) On Thu, Nov 1, 2012 at 1:28 PM, Fernando Braga fermbr...@gmail.com wrote: Hi, I had this pf rules int_if = trunk1 cosmo = 172.16.99.249 pass in on $int_if from VoIP to ! redeOscar route-to $cosmo@$int_if However, when I issue a pfctl -sr, I get pass in on trunk1 inet from VoIP to ! redeOscar flags S/SA route-to 172.16.99.249@$int_if Shouldn't this @$int_if be translated to trunk1 ? Is there another way to acomplish this ? Best regards, -- Fernando M. Braga +55 82 9636-2810
Syslog to remote server and local file
Hi, A quick question on syslog to remote servers.. I would like to log my spamd logs localy and to a remote server, first I tried to ad a second row to syslog.conf pointing at the logserver: !!spamd daemon.err;daemon.warn;daemon.info /var/log/spamd daemon.err;daemon.warn;daemon.info @logserver daemon.debug/dev/null !* This does not work as the '!!spamd' makes syslog exit after the first match. Changing the first row to '!spamd' does make the logs go to both locations but will also make the log record go into /var/log/daemon as it matches those statements. And it seems like it is not possible to have multiple recipients of log records (except when sending log info to multiple logged on users according to the man page) so this does not work. !!spamd daemon.err;daemon.warn;daemon.info /var/log/spamd,@logserver daemon.debug/dev/null !* How shalt I do this? BR /Joakim
Re: OBSD51: using macros with reply-to
Le Thu, 1 Nov 2012 13:28:18 -0200, Fernando Braga fermbr...@gmail.com a écrit : Hello, pass in on $int_if from VoIP to ! redeOscar route-to $cosmo@$int_if However, when I issue a pfctl -sr, I get pass in on trunk1 inet from VoIP to ! redeOscar flags S/SA route-to 172.16.99.249@$int_if Shouldn't this @$int_if be translated to trunk1 ? I guess yes, or rejected. Is there another way to acomplish this ? I use route-to on 5.1 with something like route-to ($int_if $cosmo) Regards.
Re: OBSD51: using macros with reply-to
Hi Patrick, Thanks for your response. I've also been using this legacy format, but when I tried the new format, pfctl didn't complain, but didn't apply it. sperreault@ confirmed this is a known issue, and will be addressed in time. Thanks for you attention. On Thu, Nov 1, 2012 at 4:33 PM, Patrick Lamaiziere patf...@davenulle.orgwrote: Le Thu, 1 Nov 2012 13:28:18 -0200, Fernando Braga fermbr...@gmail.com a écrit : Hello, pass in on $int_if from VoIP to ! redeOscar route-to $cosmo@$int_if However, when I issue a pfctl -sr, I get pass in on trunk1 inet from VoIP to ! redeOscar flags S/SA route-to 172.16.99.249@$int_if Shouldn't this @$int_if be translated to trunk1 ? I guess yes, or rejected. Is there another way to acomplish this ? I use route-to on 5.1 with something like route-to ($int_if $cosmo) Regards. -- Fernando M. Braga +55 82 9636-2810
spammers getting less stupid?
After cleaning my spamdb on the first of last month, I see that there are 572 WHITE hosts now. Only a handfull of those are legitimate (my mailserver is very low traffic, basically just mail for my family). Looking at the logs, I see that most of them got themselves whitelisted by actually resending within greyexp. Here is a typical host: WHITE|2.139.201.210|||1351517497|1351518564|1354630766|2|1 which is 210.red-2-139-201.staticip.rima-tde.net. It tried to connect at Mon Oct 29 14:31:37 CET 2012, and got WHITE at Mon Oct 29 14:49:24 CET 2012. It is obviously a spammer: Oct 29 15:19:26 biblio smtpd[26924]: b4f049e1: from=@, relay=210.red-2-139-201.staticip.rima-tde.net [2.139.201.210], stat=LocalError (530 5.0.0 Recipient rejected: 7e8a5...@stare.cz) Strangely, the only occurence of 2.139.201.210 in the last month's maillog is just this; that's half an hour after it got WHITE. What happend at Mon Oct 29 14:49:24 CET 2012 that made it WHITE? Anyway, it seems (some) spambots got less demented and actually do resend, getting themselves whitelisted - thus working themselves around the whole premise of greylisting. Are people seeing something similar? Jan
Re: spammers getting less stupid?
Jan Stary wrote: Strangely, the only occurence of 2.139.201.210 in the last month's maillog is just this; that's half an hour after it got WHITE. What happend at Mon Oct 29 14:49:24 CET 2012 that made it WHITE? Anyway, it seems (some) spambots got less demented and actually do resend, getting themselves whitelisted - thus working themselves around the whole premise of greylisting. Are people seeing something similar? I'm seeing it. I recently tweaked my greyscanner settings to pick up some spammers getting through who shouldn't (they were staying just under the threshold for further scrutiny). But I've still been getting a couple a day, and they only just got themselves whitelisted. So, you are not alone... --Kurt
using macros with reply-to
Hi, I had this pf rules int_if = trunk1 cosmo = 172.16.99.249 pass in on $int_if from VoIP to ! redeOscar route-to $cosmo@$int_if However, when I issue a pfctl -sr, I get pass in on trunk1 inet from VoIP to ! redeOscar flags S/SA route-to 172.16.99.249@$int_if Shouldn't this @$int_if be translated to trunk1 ? Is there another way to acomplish this ? Best regards,
Re: Upgrade to 5.2?
On Thu, Nov 01, 2012 at 09:34:50AM +0100, Anders Trob?ck wrote: Den Thu, 1 Nov 2012 08:11:26 + skrev Jamie Paul Griffin ja...@kode5.net: / Tyler Morgan wrote on Wed 31.Oct'12 at 20:04:11 -0700 / Don't do it! Seriously, the upgrade process is easy, and is worth becoming familiar with. At least give it a shot since you're planning on reinstalling anyway. I think you'll be pleasantly surprised! Just out of curiosity, do you think the easiest method is to use the bds.rd method or should I use a CD to do the upgrade, is one method preferred or easier over the other? I always (well almost, I have some systems where I do the tar thing) use bsd.rd and it has worked perfect for me every time so far! I don't know if it's the official preferred way but it's the way I prefer!:-) Doing an upgrade running bsd.rd loaded from a disk is pretty much the same as loading bsd.rd from cd. It's actually the same file, so do what is most convenient for you. The cd has alls the sets, in some cases it is faster than using net. In other cases using the net is faster or more convenient. Decide for yourself. untarring the sets and copying the kernel by hand is not recommended. -Otto By the tar thing he probably means, http://www.openbsd.org/faq/faq4.html#Multiple
Re: Syslog to remote server and local file
Thus said Joakim Aronius on Thu, 01 Nov 2012 17:54:28 BST: !!spamd daemon.err;daemon.warn;daemon.info /var/log/spamd daemon.err;daemon.warn;daemon.info @logserver A careful reading of man syslog.conf would seem to indicate that you can do something like: !spamd daemon.err;daemon.warn;daemon.info /var/log/spamd !!spamd daemon.err;daemon.warn;daemon.info @logserver Andy
Re: spammers getting less stupid?
On Thu, 1 Nov 2012 20:49:39 +0100 Jan Stary h...@stare.cz wrote: After cleaning my spamdb on the first of last month, I see that there are 572 WHITE hosts now. Only a handfull of those are legitimate (my mailserver is very low traffic, basically just mail for my family). Looking at the logs, I see that most of them got themselves whitelisted by actually resending within greyexp. The number of compromised customer hosts lately have been increasing. It's more likely that your spammers are using normal well configured MTAs (postfix/exim/etc) on compromised servers which are going to eventually get through the greylist. I do agree though -- there are too many getting whitelisted lately. If anyone has recommended greyscanner tweaks I'd love to hear them.
Re: spammers getting less stupid?
On 1 November 2012 12:49, Jan Stary h...@stare.cz wrote: Here is a typical host: WHITE|2.139.201.210|||1351517497|1351518564|1354630766|2|1 which is 210.red-2-139-201.staticip.rima-tde.net. It tried to connect at Mon Oct 29 14:31:37 CET 2012, and got WHITE at Mon Oct 29 14:49:24 CET 2012. It is obviously a spammer: Oct 29 15:19:26 biblio smtpd[26924]: b4f049e1: from=@, relay=210.red-2-139-201.staticip.rima-tde.net [2.139.201.210], stat=LocalError (530 5.0.0 Recipient rejected: 7e8a5...@stare.cz) Strangely, the only occurence of 2.139.201.210 in the last month's maillog is just this; that's half an hour after it got WHITE. What happend at Mon Oct 29 14:49:24 CET 2012 that made it WHITE? The spammer must have successfully passed the greylisting with spamd on Mon Oct 29 14:49:24 CET 2012. The spamd setup requires at least two connections to spamd, prior to the connections being permitted to the real smtp server. This is different from the MTA-based greylisting, where mail can be delivered as soon as the second attempt. With spamd, at least three attempts are required for the initial delivery of mail, since spamd cannot hand-over an existing connection to the real smtp server when the greylisting requirements are satisfied. C.
Re: pppoe(4) slow for Annex M DSL connection
On 31/10/2012 18:49, Kaya Saman wrote: I've just got my dsl line reprovisioned for Annex M compatibility and the line speed showing currently on the modem is 20Mbps downstream with 2Mbps upstream. Upon the reprovisioning I got ask to do a speed test by my ISP and only ~5Mbps was shown for downstream while upstream was shown as ~700kbps. The system in place is VDSL2+/ADSL2+(Annex M) router running in RFC2684 ATM to Ethernet bridge mode, linked to a Sun Microsystems Netra T105 - 440MHz, 360MB RAM box. With the Netra I have tested various routing capacities including inter-vlan and dynamic running OSPF and it managed between 80-90Mbps transfer rates for large files. I don't think this is an OpenBSD issue From http://www.cisco.com/en/US/products/ps9565/index.html ADSl2/2+ over POTS, with annex M support for increased upstream throughput through Cisco 887M models Sevan / Venture37
carppeer and IPv6
OpenBSD 5.1 / i386, two boxes connected using CARP/pfsync. There are VLANs on the physical interfaces, and CARP interfaces on the VLAN interfaces. Both boxes run dual stack on VLAN and CARP interfaces. This all works fine. To get rid of multicast CARP traffic, I tried using the carppeer keyword in hostname.carpXX files, like this: inet 172.31.16.1 255.255.255.0 172.31.16.255 vhid 16 \ advskew 1 pass WouldntYouLikeToKnow carpdev vlan16 \ carppeer 172.31.16.3 inet6 2604:0:c2:10::1 64 vhid 16 advskew 1 pass \ WouldntYouLikeToKnow carpdev vlan16 carppeer 2604:0:c2:10::3 Problem is, after running 'sh /etc/netstart vlan16' and 'sh /etc/netstart/carp16' I still see multicast CARP packets, but now only from the link-local address. Questions: 1. Why would the command 'sh /etc/netstart carp16' return the error 'ifconfig: error in parsing address string: no address associated with name'? I can ping6 the carppeer 2604:0:c2:10::3 from this box. 2. Are multicast CARP frames from the link-local address expected behavior? 3. If so, is there any way to disable that behavior? Thanks! dn
Re: pppoe(4) slow for Annex M DSL connection
On 11/01/2012 11:12 PM, Sevan / Venture37 wrote: On 31/10/2012 18:49, Kaya Saman wrote: I've just got my dsl line reprovisioned for Annex M compatibility and the line speed showing currently on the modem is 20Mbps downstream with 2Mbps upstream. Upon the reprovisioning I got ask to do a speed test by my ISP and only ~5Mbps was shown for downstream while upstream was shown as ~700kbps. The system in place is VDSL2+/ADSL2+(Annex M) router running in RFC2684 ATM to Ethernet bridge mode, linked to a Sun Microsystems Netra T105 - 440MHz, 360MB RAM box. With the Netra I have tested various routing capacities including inter-vlan and dynamic running OSPF and it managed between 80-90Mbps transfer rates for large files. I don't think this is an OpenBSD issue From http://www.cisco.com/en/US/products/ps9565/index.html ADSl2/2+ over POTS, with annex M support for increased upstream throughput through Cisco 887M models Sevan / Venture37 Thanks for the response! That's the router I have; connecting directly to the router with it configured as NAT/Gateway produces good results. In addition to that I created a test where I used Packet Filter as a firewall then ran OSPF between the routers, so basically we had: (LAN) Cisco 1801 - OpenBSD - Cisco 887VA (WAN) Again I had the same speeds. However, hooking the Cisco's together Cisco 1801 - Cisco 887VA I now have 18Mbps downstream with 2Mbps upstream. It looks like the throughput on the Sun Netra isn't high for whatever reason?? Or that Packet Filter is simply slow to process? I have a spare Sun Fire V210 so I will try with that and see if the increased CPU power coupled with more memory increases speeds at all. Outside of that I'm slightly puzzled :-S
Re: spammers getting less stupid?
On Thu, Nov 01, 2012 at 08:49:39PM +0100, Jan Stary wrote:
After cleaning my spamdb on the first of last month,
I see that there are 572 WHITE hosts now.
Only a handfull of those are legitimate (my mailserver
is very low traffic, basically just mail for my family).
You and I have similar usage but wildly different traffic:
$ spamdb | awk -F '|' '/^WHITE/ {print $2}'|wc -l
19
I don't think this has anything to do with spamd.
You might try creating an SPF -all record; maybe some spammers cull such
domains from their lists. I also use the Spamhaus DROP list and Team
Cymru's fullbogons list and require FCrDNS. Domains that can't
be contacted, under a certain threshhold, eventually get culled from
some lists, and over time there's a dramatic benefit.
For instance on one mailserver I took over, I noticed that after adding
a Spamhaus sbl-xbl check, required rDNS, and other basic stuff like
requiring a legitimate HELO/EHLO, spam attempts dropped by perhaps a
factor of 100. It was shocking.
Anyway, it seems (some) spambots got less demented and actually do
resend, getting themselves whitelisted - thus working themselves
around the whole premise of greylisting.
Lots of spammers use snowshoe hosts now, which run normal MTA software.
Nicolai
Re: ttyC5, keyboard doesn't work
Le 2012-10-31 17:30, MERIGHI Marcus a écrit : I would try in .Xdefaults XTerm*loginShell:false OR you could do the following in .profile: pgrep -f -x /usr/X11R6/bin/X .* || /usr/X11R6/bin/xinit Hi, I tried both solutions. No error messages, but keyboard doesn't work. Cheers, Wesley
