compiling Snort(Sam) Plugin
Hi When compiling snort after the patching the source I get following error: plugbase.o(.text+0x5ea): In function `InitOutputPlugins': /root/snort-2.4.1/src/plugbase.c:595: undefined reference to `AlertFWsamSetup' collect2: ld returned 1 exit status *** Error code 1 Stop in /root/snort-2.4.1/src (line 295 of Makefile). *** Error code 1 Stop in /root/snort-2.4.1/src (line 334 of Makefile). *** Error code 1 Stop in /root/snort-2.4.1 (line 303 of Makefile). *** Error code 1 Stop in /root/snort-2.4.1 (line 180 of Makefile). Without the patch it is no problem :-( Any ideas ? Thanks for help PS.: OpenBSD 3.6, Snort 2.4.1, SnortSam 2.40
Catching WINCH signal during sleep...
Hi, I'm running the following simple test script: #!/bin/ksh -x trap 'eval $(resize)' WINCH while true; do sleep 10 done What I'm noticing is that the WINCH signal action is not actually carried out until at the end of the sleep, should the signal be sent during the sleep period. I'm wondering if this is the behaviour I should expect or not. I initially expected the signal to interrupt the sleep. The SUSv3 documentation for the sleep(1) utility says The sleep utility shall take the standard action for all other signals [other than ALRM]. (for the ALRM signal, there is a number of things that could happen, which is not interesting right now). (the WINCH signal is delivered when the terminal window changes size) Any thoughts? Regards, Andreas -- Andreas Kahari
Re: Catching WINCH signal during sleep...
Andreas Kahari wrote: (the WINCH signal is delivered when the terminal window changes size) SIGWINCH is ignored by default, otherwise your sleep(1) would exit if you changed the size of your xterm. See signal(3) for the full list. So it is doing the right thing wrt your quote of SUSv3: The SUSv3 documentation for the sleep(1) utility says The sleep utility shall take the standard action for all other signals [other than ALRM]. -d
Re: Catching WINCH signal during sleep...
On 19/09/05, Damien Miller [EMAIL PROTECTED] wrote:
Andreas Kahari wrote:
(the WINCH signal is delivered when the terminal window changes size)
SIGWINCH is ignored by default, otherwise your sleep(1) would exit if
you changed the size of your xterm. See signal(3) for the full list.
Ok, so sleep(1) is explicitly ignoring the signal. Can I get it be
interrupted by the signal instead? No, maybe that won't solve my
problem because the installed handler ('eval $(resize)') wouldn't be
run, I guess.
So it is doing the right thing wrt your quote of SUSv3:
Yes, that's probably right. I'll work around it somehow.
Thanks,
Andreas
--
Andreas Kahari
Re: ftp-proxy(8) and pf question
Hi, Matt Rowley wrote: As far as I know, this only applies to _active_ ftp, about which I am not concerned at the moment. Ah yes... that's what I get for doing e-mail at 6am. :-/ no bother. Your problem description seems to imply that you have a block out all and that you're only allowing selet outbound traffic. In which case you would Yes, that is true. need to either open (for outbound, stateful traffic) all the ephemeral ports that is what I was afraid of. To be honest, I would not like to do that. that ftp-proxy uses for outbound stateful traffic, or you could probably reverse the rule I gave you and do pass out from user proxy keep state. The problem here (at least to my understanding) is that not the proxy tries to handle all the connections, but the client still needs to contact the ftp server directly. This seems different to how 'frox' works, for example, where the client actually established one connection to the proxy and anything else is then done by the proxy exclusively. One workaround I was thinking of is to use a pf-route-to rule to route all ftp traffic to a separate frox server. However, I thought there must be a way seting up a transparent ftp proxy with native openbsd tools... Thanks, -- Stephan A. Rickauer Institut f|r Neuroinformatik Universitdt / ETH Z|rich Winterthurerstriasse 190 CH-8057 Z|rich Tel: +41 44 635 30 50 Sek: +41 44 635 30 52 Fax: +41 44 635 30 53 http://www.ini.ethz.ch
Re: Device not configured (APM, sound, modem)
Z L [EMAIL PROTECTED] wrote: For APM I tried to set the apmd_flags=YES in rc.conf. For sound and modem I tried the things that are described in the FAQ and manpages. Correct usage is apmd_flags= or with some valid flags between the apmd_flags=-q YES is for binary options like pf=YES
pOf
Is there any way of limiting access to pptpd from pocket pc clients ? I cant find any fingerprints for pocket pc in pf.os ? Steve
snort / promiscuous mode
Hey all: OBSD3.7 SNORT2.3.3 I have a machine with 4 nics running 4 instances of snort: /usr/local/bin/snort -u sguil -g sguil -l /nsm/em0 -c /etc/snort/em0.snort.conf -U -A none -m 122 -i em0 -D /usr/local/bin/snort -u sguil -g sguil -l /nsm/em1 -c /etc/snort/em1.snort.conf -U -A none -m 122 -i em1 -D /usr/local/bin/snort -u sguil -g sguil -l /nsm/em2 -c /etc/snort/em2.snort.conf -U -A none -m 122 -i em2 -D /usr/local/bin/snort -u sguil -g sguil -l /nsm/em3 -c /etc/snort/em3.snort.conf -U -A none -m 122 -i em3 -D One of the 4 nics has an ip address, the others do not. When I start up the 4 instances of snort, the nic (em0) with the ip address shows up in promiscuous mode, the others do not. # ifconfig -a lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33224 inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 em0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 address: 00:04:23:bd:ab:d6 media: Ethernet autoselect (1000baseT full-duplex) status: active inet 10.1.1.3 netmask 0xff00 broadcast 10.1.1.255 inet6 fe80::204:23ff:febd:abd6%em0 prefixlen 64 scopeid 0x1 em1: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 address: 00:04:23:bd:ab:d7 media: Ethernet autoselect (1000baseT full-duplex) status: active em2: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 address: 00:14:22:0f:84:2b media: Ethernet autoselect (1000baseT full-duplex) status: active em3: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 address: 00:14:22:0f:84:2c media: Ethernet autoselect (100baseTX full-duplex) status: active pflog0: flags=0 mtu 33224 pfsync0: flags=0 mtu 2020 enc0: flags=0 mtu 1536 # How do I get the other 3 ip-less nics to run in promiscuous mode in OBSD? Any help would be appreciated. Sean
PF ALTQ
Hi @ all,
I try to limit the Bandwidth on my OpenBSD 3.7 (Release). But there is
something wrong.
On my box run a ftp-server (10.0.0.1) without proxy.
and I try to copy from/to it from 10.0.0.20 via FTP
The traffic walk through the rules (log with tcpdump...), but there isn't a
limit of the inbound-Traffic. If I add keep state to it, then there is a
limit, but not the right (about factor 5 wrong).
Does anyone know this problem? Or know anything else to try?
my pf.conf looks like this
Thanks a lot and have a nice evening...
Raphy
# $OpenBSD: pf.conf,v 1.27 2004/03/02 20:13:55 cedric Exp $
#
# See pf.conf(5) and /usr/share/pf for syntax and examples.
# Aliases werden erzeugt
# Netzwerkkarten
ext_if=rl1
int_if=rl0
dmz_if=vr0
# Sub-Netzwerke
ext_net=192.168.1.0/8
int_net=10.0.0.0/8
dmz_net=172.16.0.0/8
# Rechner-IP's
int_ip_modem=192.168.1.1
ext_ip_mickey=192.168.1.2
int_ip_mickey=10.0.0.1
dmz_ip_mickey=172.16.0.1
dmz_ip_www=172.16.0.2
dmz_port_www=80
#table spamd persist
#table spamd-white persist
# einige Definitionen
set limit { states 1, frags 5000 }
set block-policy drop
# Pakete zusammenbauen
scrub in on {$ext_if,$dmz_if} all fragment reassemble
# Bandwidth Control
# LAN-Interface
altq on $int_if cbq bandwidth 100Mb queue {lan_in, lan_out}
queue lan_in bandwidth 50% cbq {lan_misc_in, ftp_lan_in, ssh_lan_in}
queue lan_misc_in bandwidth 50Kb cbq
queue ftp_lan_in bandwidth 1Mb cbq
queue ssh_lan_in bandwidth 50Kb priority 7 cbq
queue lan_out bandwidth 50% cbq {lan_misc_out, ftp_lan_out, ssh_lan_out}
queue lan_misc_out bandwidth 50Kb cbq(default)
queue ftp_lan_out bandwidth 2Mb cbq
queue ssh_lan_out bandwidth 8Mb priority 7 cbq
# NAT Regeln
nat on $ext_if from !($ext_if) - ($ext_if:0)
# Redirect-Rules...
#rdr pass on $int_if proto tcp to port ftp - 127.0.0.1 port 8021
#rdr pass on $ext_if proto tcp from spamd to port smtp \
# - 127.0.0.1 port spamd
#rdr pass on $ext_if proto tcp from !spamd-white to port smtp \
# - 127.0.0.1 port spamd
# fuer WWW-Server
#rdr on $ext_if proto {tcp,udp} from any to port $dmz_port_www - #$dmz_ip_www
port $dmz_port_www
# Firewall-Rules
# Base-Rules
block drop in log all
block drop out log all
pass quick on { lo lo0 }
antispoof quick for { lo lo0 $ext_if $int_if $dmz_if }
# ***
# the LAN
# inbound
pass in on $int_if proto tcp from $int_net to $int_ip_mickey port {20, 21}
queue ftp_lan_in # FTP
pass in on $int_if proto tcp from $int_net to $int_ip_mickey port 22 queue
ssh_lan_in # SSH
# outbound
pass out on $int_if proto tcp from $int_ip_mickey port {20,21} to $int_net
queue ftp_lan_out # FTP
pass out on $int_if proto tcp from $int_ip_mickey port 22 to $int_net queue
ssh_lan_out # SSH
Re: Live dc
I want to thank all of you who replied on my previous mail about the live
cd. I've seen many of those links you sent me which talk on how you can
create a live cd. I would have done it my self but unfortunatelly I cant due
to tech reasons right now. Also I dont know if it would have been good since
i am an openbsd noob ! As i said I study at the American College of Greece
and the head of dept agreed to use obsd for the teaching of unix instead of
the crapy linux and asked me to get it to him. So if someone can create this
live cd and upload it on the web just to download it and dist to all college
I would really apriciate it. I know that time is precious for everybody so
if noone can do it I will understand. But if you can you will help openbsd
grow not only in many ppl but in the educational system of c.i.s as well.
Thank you all very much again !
Best Regards
Alex
Okay here is my own REAL EASY Step-by-Step howto for an OpenBSD live CD
Sorry for the possible bad english, my english is not the best at 2am, but I
wanted to help you quick.
The original (much better) How-To is in German, thus if you can speak German I
could mail you the much better version.
(If anybody is interested in a Live CD I could also translate it 1 : 1 )
Since I really love to show off my OpenBSD Live CD to friends.
anti_flame_request
IMHO Knoppix sucks compared to an OpenBSD live cd
/anti_flame_request
(If you can't understand something just ASK and I will answer ASAP because I'm
just to darn tired to even READ through it again)
Here we go:
The easy way (don't even ask for the complicated way):
NOTE YOU NEED TO ADJUST THE SIZE OF THE MFS PARTITIONS TO YOUR NEEDS!
You need a current system with the right (current) source code for it.
Best thing is to make a release
man 8 release
Grab a virgin harddrive and put it into a spare i386 box, install openbsd onto
this harddrive.
DON'T make Partitions (actually you could BUT IMHO it makes everything much more
complicated )
Configure it ( with X, packages, configs ) the way it should
boot from the CD later on. Although you COULD use a DVD as medium, I would
RECOMMEND you not to get over the size of a normal CD for the complete install.
Once you have the System exactly the way you want it to be read on:
Rip the harddrive out of the test box and put it into another box ( with cd/dvd
burner ). Mount the drive somewhere and tar it up
cd /mnt/ tar pczf ~/livecd_root.tar.gz *
Create a directory, this will be the root directory on the CD.
# Of course you need a large enough /usr/ Partition
mkdir -p /usr/livecd/backups/dev
Untar the Stuff into the above livecd directory.
cd /usr/livecd tar pxzf ~/livecd_root.tar.gz
We need some backup directories that will be used later
cp -pR /usr/livecd/{var,etc,root,home} /usr/livecd/backups/
cp -pR /usr/livecd/dev/MAKEDEV /usr/livecd/backups/dev/
We need MFS partitions in order to be able to make config changes ...
the content of the backup directories will be copied into them.
For this purpose we use a modified etc/rc script
--- /usr/livecd/etc/rc -
# ...
# After:rm -f /fastboot # XXX (root
now writeable)
echo 'mounting mfs'
mount_mfs -s 51200 -o async,nosuid,nodev,noatime swap /var
mount_mfs -i 4096 -s 6144 -o async,nosuid,nodev,noatime swap /etc
mount_mfs -i 128 -s 2048 -o async,noatime swap /dev
mount_mfs -s 6144 -o async,nosuid,nodev,noatime swap /tmp
mount_mfs -s 8192 -o async,nosuid,nodev,noatime swap /home
mount_mfs -s 8192 -o async,nosuid,nodev,noatime swap /root
sleep 2
echo -n 'copying files: var '
cp -pR /backups/var/* /var
echo -n 'etc '
cp -pR /backups/etc/* /etc
echo -n 'dev '
cp -pR /backups/dev/* /dev
echo -n 'home '
cp -pR /backups/home/* /home
echo 'root'
cp -pR /backups/root/.[a-z]* /root
echo 'creating device nodes'
cd /dev sh MAKEDEV all
# ...
# After:if [ -f
/sbin/kbd -a -f /etc/kbdtype ]; then
# We need a root Password
echo 'Need to set a root password'
passwd
We need some basic devices (just create all) on the temporary boot /dev
cd /usr/livecd/dev ./MAKEDEV all
Now we create the custom kernel (not much customization!)
cd /usr/src/sys/arch/i386/conf
mv RAMDISK_CD RAMDISK_CD.old cp GENERIC RAMDISK_CD
--- /usr/src/sys/$arch/conf/RAMDISK_CD -
...
# config bsd swap generic- was commented OUT!
option RAMDISK_HOOKS
option MINIROOTSIZE=3800
config bsd root on cd0a
...
Compile the new RAMDISK kernel
config RAMDISK_CD cd ../compile/RAMDISK_CD/ make clean make depend \
make
Copy the new ramdisk kernel to the livecd folder:
cp bsd /usr/livecd
We need to patch the Makefile.inc
NOTE:
YOU JUST NEED TO FIND THE
Re: PF performance question
On Mon, Sep 19, 2005 at 03:13:33PM -0300, Vinicius Pavanelli Vianna wrote: I tried to disable pf (pfctl -d) and it continues to loss packets ... The count on in and out are different because the pf is blocking some packets (?) those seem to contradict one another., just a typo? didn't resolve the packet lost i begin to suspect something on the bridge code, as i don't see any error on the interface. welp.. you could turn the bridge off and then run binat in pf, or perhaps split the subnet. i could see two ways to do this, one being kinda hackish and perhaps outright wrong, but i believe either would work. 1) hackish: ( this would work, but involves a lot of ugly crap and proxy-arp, so i decided to not even bring it up because i don't want people to yell and puke at me ). 2) assuming the ISP and you have both chosen IPs from the beginning of the subnet, have your ISP change their iface to you to be a /26 instead of a /25. so, if they're .1/25, ask them to be .1/26. then change the subnet mask on your end to match a /26 also ( 255.255.255.192 ). so assume you're 200.xx.xx.2 netmask 0xffc0; have them now static route 200.xx.xx.64/26 to 200.xx.xx.2. if you and the ISP are high IPs, ( eg, .125, .126 ), sure, doesn't matter, just make sure you're both in the same subnet, and then in the next paragraph, use the lower subnet for the lan instead of the higher: this will make it so that you still get what amounts to the same /25, but can put the lower /26 on the external iface and the upper /26 on your internal iface. so then take an IP from the .64/26 and put it on the internal em(4) card, renumber any hosts behind that as needed, and try to see if you still have the same packet loss ( assuming you have changed nothing thus far other than the IP subnetting ). if you have the IPs setup that way, you can remove the bridge from existance and rely on normal net.inet.ip.forwarding=1. but the big problem is that some packets doesn't get even on the interface, my setup is like add em0 add em1 up on bridgename.bridge0 i checked the thread again but didn't see it mentioned. where are you losing the packets? are you losing packets on the link between ISP-You or You-YourLan ? if you're losing them on ISP-You, is that to the other end of the external iface, ( eg, whatever you put for a default gateway on your bridge box, their end of your /25 ) or to some other host beyond that? i also enabled STP as my ISP told me it would help their redundancy. STP on a bridge seems like a Good Thing, but i don't think the ISP side of it is going to matter much... i mean.. if they require people to have the customer side of the link be either A) one single host or B) something running spanning tree, then yeah, it seems logical, but if not (eg - they do not make a certain requirement of what you attach to their link), i would wager that spanning tree is not going to be part of the solution to your problem. in other words, if they're not running STP-aware bridges between the interface that is their side of your /25 and the cable hitting your side of your /25, you running spanning tree isn't going to mean dick for them. for now, the check autoneg/speed-duplex settings seems to be a good place to start. make each physical link agree (autoneg or forced) on both ends, if they don't already. if that doesn't pan out, consider trying the 1x/25- 2x/26 thing i mention above. ps - given the dmesg you showed, the performance of pf is likely to not be part of the question. smells like something else is happening here. jared -- [ openbsd 3.8 GENERIC ( sep 10 ) // i386 ]
Re: Wireless Strangeness
First, I apologize for the delay -- I had a very long, hectic day at work. Meanwhile, thank you for replying. wi0 at pci0 dev 12 function 0 National Datacomm Corp NCP130 Rev A2 rev 0x01: irq 9 wi0: PRISM2 HWB3163 rev.B, Firmware 0.3.0 (primary), 1.7.1 (station), address 00:80:c6:e3:72:2c It's ancient but it should work. It was the most current I could find for this particular chipset. If you know of any more modern versions that are supported for this card, I'll happily install them. :-) ...my wireless configuration: No obvious problem there. Glad to see I'm not totally brain-dead. Meanwhile, running tcpdump -n -i wi0 gives me absolutely zip on the OpenBSD host system, and the dhcpd that's listening there is getting no requests whatsoever. Tcpdump is not your friend here. I suspect the problem lies in a crucial file you did not tell us anything about, your hostname.wi0. Use this: inet 192.168.1.42 255.255.255.0 NONE nwid kirknet mediaopt hostap (also, don't use non-alphanumeric characters in your nwid) This file did not exist. I created it exactly as above and rebooted the machine, and still had no luck getting my XP client to connect (the Mac system is currently unavailable). Restart the machine and if your clients still can't connect put the wireless interface into debug mode: ifconfig wi0 debug And send us the wi driver's debug output, your hostname.wi0, and a full dmesg in addition to wicontrol and ifconfig output. Certainly, here you go: debug output (taken from /var/log/messages, I'll supply other info on demand if it exists): Sep 19 20:10:59 shorty /bsd: wihap_shutdown: sc=0xd0816000 whi=0xd0816fa8 Sep 19 20:10:59 shorty /bsd: Sending disassoc to sta ff:ff:ff:ff:ff:ff Sep 19 20:10:59 shorty /bsd: Sending deauth to sta ff:ff:ff:ff:ff:ff Sep 19 20:10:59 shorty /bsd: Sending disassoc to sta ff:ff:ff:ff:ff:ff Sep 19 20:10:59 shorty /bsd: Sending deauth to sta ff:ff:ff:ff:ff:ff Sep 19 20:10:59 shorty /bsd: Sending disassoc to sta ff:ff:ff:ff:ff:ff Sep 19 20:10:59 shorty /bsd: Sending deauth to sta ff:ff:ff:ff:ff:ff Sep 19 20:10:59 shorty /bsd: Sending disassoc to sta ff:ff:ff:ff:ff:ff Sep 19 20:10:59 shorty /bsd: Sending deauth to sta ff:ff:ff:ff:ff:ff Sep 19 20:10:59 shorty /bsd: Sending disassoc to sta ff:ff:ff:ff:ff:ff Sep 19 20:10:59 shorty /bsd: Sending deauth to sta ff:ff:ff:ff:ff:ff Sep 19 20:10:59 shorty /bsd: wihap_init: sc=0xd0816000 whi=0xd0816fa8 Sep 19 20:11:00 shorty /bsd: wihap_data_input: no TODS src=00:e0:98:db:02:52 Sep 19 20:11:10 shorty last message repeated 47 times Sep 19 20:11:10 shorty /bsd: wihap_data_input: no TODS src=00:04:23:4b:38:fd Sep 19 20:11:10 shorty /bsd: wihap_data_input: no TODS src=00:e0:98:db:02:52 Sep 19 20:11:10 shorty /bsd: wihap_data_input: no TODS src=00:04:23:4b:38:fd Sep 19 20:11:10 shorty /bsd: wihap_data_input: no TODS src=00:e0:98:db:02:52 Sep 19 20:11:10 shorty /bsd: wihap_data_input: no TODS src=00:04:23:4b:38:fd Sep 19 20:11:10 shorty /bsd: wihap_data_input: no TODS src=00:e0:98:db:02:52 Sep 19 20:11:10 shorty /bsd: wihap_data_input: no TODS src=00:04:23:4b:38:fd Sep 19 20:11:10 shorty /bsd: wihap_data_input: no TODS src=00:e0:98:db:02:52 Sep 19 20:11:10 shorty /bsd: wihap_data_input: no TODS src=00:04:23:4b:38:fd Sep 19 20:11:11 shorty /bsd: wihap_data_input: no TODS src=00:e0:98:db:02:52 Sep 19 20:11:11 shorty /bsd: wihap_data_input: no TODS src=00:e0:98:db:02:52 Sep 19 20:11:11 shorty /bsd: wihap_data_input: no TODS src=00:04:23:4b:38:fd Sep 19 20:11:11 shorty /bsd: wihap_data_input: no TODS src=00:04:23:4b:38:fd Sep 19 20:11:11 shorty /bsd: wihap_data_input: no TODS src=00:e0:98:db:02:52 Sep 19 20:11:11 shorty /bsd: wihap_data_input: no TODS src=00:04:23:4b:38:fd Sep 19 20:11:11 shorty /bsd: wihap_data_input: no TODS src=00:e0:98:db:02:52 Sep 19 20:11:11 shorty /bsd: wihap_data_input: no TODS src=00:04:23:4b:38:fd Sep 19 20:11:11 shorty /bsd: wihap_data_input: no TODS src=00:e0:98:db:02:52 Sep 19 20:11:12 shorty /bsd: wihap_data_input: no TODS src=00:04:23:4b:38:fd Sep 19 20:11:12 shorty /bsd: wihap_data_input: no TODS src=00:e0:98:db:02:52 Sep 19 20:11:43 shorty last message repeated 147 times Sep 19 20:12:29 shorty last message repeated 217 times Sep 19 20:12:30 shorty /bsd: wihap_data_input: no TODS src=00:04:23:4b:38:fd Sep 19 20:12:30 shorty /bsd: wihap_data_input: no TODS src=00:e0:98:db:02:52 Sep 19 20:12:30 shorty /bsd: wihap_data_input: no TODS src=00:04:23:4b:38:fd Sep 19 20:12:30 shorty /bsd: wihap_data_input: no TODS src=00:e0:98:db:02:52 Sep 19 20:12:30 shorty /bsd: wihap_data_input: no TODS src=00:04:23:4b:38:fd Sep 19 20:12:30 shorty /bsd: wihap_data_input: no TODS src=00:e0:98:db:02:52 Sep 19 20:12:30 shorty /bsd: wihap_data_input: no TODS src=00:04:23:4b:38:fd Sep 19 20:12:30 shorty /bsd: wihap_data_input: no TODS src=00:e0:98:db:02:52 Sep 19 20:12:30 shorty /bsd: wihap_data_input: no TODS src=00:04:23:4b:38:fd Sep 19 20:12:30 shorty /bsd: wihap_data_input: no TODS
Changing kernels from i386 to amd64
How do I change my kernel from i386 to amd64? Do I have to do a reinstall or upgrade? I tried simply copying the bsd file from the amd64 directory off an ftp site but I got a unrecognized binary format error from the boot loader.
Re: PF ALTQ
On Tue, Sep 20, 2005 at 01:16:19AM +0100, Stuart Henderson wrote: You can only queue outgoing traffic with altq, not incoming. You can sometimes achieve the same effect by queuing outgoing traffic on a different interface (e.g. to queue internet-LAN bandwidth, queue on the LAN interface), though that doesn't help for services running on the box with altq. If that's a real requirement, you may need some alternative (pure-ftpd, perhaps? or run altq on a different machine to the services?) if that wasn't clear for any reason (though it should be), then this will either be clear or it will not make any sense: http://marc.theaimsgroup.com/?l=openbsd-miscm=109736589107739w=2 / for puppies. jared -- [ openbsd 3.8 GENERIC ( sep 10 ) // i386 ]
Re: logging blocked connections in pf, but no line noise
On Mon, Sep 19, 2005 at 08:59:48PM +0200, -f wrote:
hmm, on Mon, Sep 19, 2005 at 10:01:58AM -0600, j knight said that
i was thinking of making another rule, just below this one:
block in
block in log from any to $ext_if
Another alternative:
block in quick to $ext_if:broadcast
block in log
eew quick
this doesn't seem to have the disired effect...
the rule got translated into
block drop in quick inet from any to xxx.xxx.xxx.255
and is not stopping all the noise...
heh.. cable modem? (arparparparparparparparp.. :P)...
what is the noise exactly?
give tcpdump pflog0, make known what is/isn't your IP
( xxx out the middle 2 octets or whatever makes you happy ).
i understand you mean 'noise' to be a lot of traffic that shows up
on my line that is full of valid CRCs but not intended for me or of
no interest to me, but what is it, exactly?
You either do something like this or you filter your logs when viewing
them/running reports to exclude line noise.
small disk, old machine, why keep the noise? ;)
i use:
---
e = sis2
adsl_up = 700Kb
TCP_NOISE = { 135 139 445 1080 1433 3128 }
UDP_NOISE = { 1026 1027 }
set block-policy return
altq on $e hfsc bandwidth $adsl_up queue{ exthi extlo extLAN }
queue exthi on $e bandwidth 20% priority 6 hfsc( upperlimit
$adsl_up )
queue extlo on $e bandwidth 20% priority 0 hfsc( upperlimit
$adsl_up default )
queue extLANon $e bandwidth 20% { u192.168.7.X }
queue u192.168.7.X on $e bandwidth 192b { u192.168.7.Xd u192.168.7.Xa }
queue u192.168.7.Xd on $e bandwidth 64b priority 2 hfsc( upperlimit
$adsl_up )
queue u192.168.7.Xa on $e bandwidth 128b priority 4 hfsc( upperlimit
$adsl_up )
block log all
block on $e proto tcp from any to (carp0:0) port $TCP_NOISE queue( extlo )
block on $e proto udp from any to (carp0:0) port $UDP_NOISE queue( extlo )
---
please don't flame for the lameass use of HFSC, i'm always in the
middle of playing with it G.
anyway, this makes it so that anything blocked matching the {TCP,UDP}_NOISE
macros doesn't spam up my pflog.
jared
--
[ openbsd 3.8 GENERIC ( sep 10 ) // i386 ]
Re: Wireless Strangeness
It was the most current I could find for this particular chipset The chipset is ancient. shorty.kirknet.net:~$ dmesg OpenBSD 3.4-stable (GENERIC) #0: Sun Sep 18 18:29:41 EDT 2005 I'm bailing here. I don't remember 3.4 well enough.
Re: PF performance question
jared r r spiegel wrote: On Mon, Sep 19, 2005 at 03:13:33PM -0300, Vinicius Pavanelli Vianna wrote: I tried to disable pf (pfctl -d) and it continues to loss packets ... The count on in and out are different because the pf is blocking some packets (?) those seem to contradict one another., just a typo? I just disabled pf for a moment to check if it would be the cause of the loss, but pf isn't the cause. didn't resolve the packet lost i begin to suspect something on the bridge code, as i don't see any error on the interface. welp.. you could turn the bridge off and then run binat in pf, or perhaps split the subnet. To disable the bridge i will have to change the topology with my ISP, since their are using some layer2 protocols over this link to do some stuffs between their firewall and their switches, beside this, they take too long to do something like a topology change like this. i could see two ways to do this, one being kinda hackish and perhaps outright wrong, but i believe either would work. 1) hackish: ( this would work, but involves a lot of ugly crap and proxy-arp, so i decided to not even bring it up because i don't want people to yell and puke at me ). 2) assuming the ISP and you have both chosen IPs from the beginning of the subnet, have your ISP change their iface to you to be a /26 instead of a /25. so, if they're .1/25, ask them to be .1/26. then change the subnet mask on your end to match a /26 also ( 255.255.255.192 ). so assume you're 200.xx.xx.2 netmask 0xffc0; have them now static route 200.xx.xx.64/26 to 200.xx.xx.2. I think i can do something better with some routing policy on their firewall/router, will check this, but again it will need a topology change :( The big problem here is that i have to run this machine on bridge, and pf doesn't perform synproxy in bridge too, what is a bad thing to me, so i will try to avoid this bridge setup asap. if you and the ISP are high IPs, ( eg, .125, .126 ), sure, doesn't matter, just make sure you're both in the same subnet, and then in the next paragraph, use the lower subnet for the lan instead of the higher: this will make it so that you still get what amounts to the same /25, but can put the lower /26 on the external iface and the upper /26 on your internal iface. so then take an IP from the .64/26 and put it on the internal em(4) card, renumber any hosts behind that as needed, and try to see if you still have the same packet loss ( assuming you have changed nothing thus far other than the IP subnetting ). if you have the IPs setup that way, you can remove the bridge from existance and rely on normal net.inet.ip.forwarding=1. The problem is i'm having this loss in the link ISP = OpenBSD Firewall, so i don't think this would resolve it, but i will give it a try as soon as i can make then change the topology, when i tcpdump on the em0 interface (that is connected to the ISP) i can't get some packets i send from the internet, or even pings between me and the ISP, so i begin to suspect it's a wire problem, my netstat gives me some errors on the interface, but nothing that is getting bigger all the time, i will begin to check more ofter this errors to trace it. but the big problem is that some packets doesn't get even on the interface, my setup is like add em0 add em1 up on bridgename.bridge0 i checked the thread again but didn't see it mentioned. where are you losing the packets? are you losing packets on the link between ISP-You or You-YourLan ? if you're losing them on ISP-You, is that to the other end of the external iface, ( eg, whatever you put for a default gateway on your bridge box, their end of your /25 ) or to some other host beyond that? The loss is to my gateway, and reflect on all hosts because of it. i also enabled STP as my ISP told me it would help their redundancy. STP on a bridge seems like a Good Thing, but i don't think the ISP side of it is going to matter much... i mean.. if they require people to have the customer side of the link be either A) one single host or B) something running spanning tree, then yeah, it seems logical, but if not (eg - they do not make a certain requirement of what you attach to their link), i would wager that spanning tree is not going to be part of the solution to your problem. in other words, if they're not running STP-aware bridges between the interface that is their side of your /25 and the cable hitting your side of your /25, you running spanning tree isn't going to mean dick for them. for now, the check autoneg/speed-duplex settings seems to be a good place to start. make each physical link agree (autoneg or forced) on both ends, if they don't already. They say all their ifaces are forced to 100 full duplex, when i try to autoneg with their switches i always got 100 half duplex, and the
Re: Wireless Strangeness
shorty.kirknet.net:~$ dmesg OpenBSD 3.4-stable (GENERIC) #0: Sun Sep 18 18:29:41 EDT 2005 I'm bailing here. I don't remember 3.4 well enough. I was afraid of that. I've been meaning to upgrade to 3.7 for a while -- is it likely to make that big of a difference if I upgrade? If I were to still experience this problem with 3.7, might you be able to offer further assistance (I can understand not wanting to have to dredge through memory for something not particularly relevant or exciting for someone else's benefit)? Meanwhile, does anyone else have a clue what might be going on here? Thanks, Alex Kirk
Re: PF performance question
--- Quoting Vinicius Pavanelli Vianna on 2005/09/19 at 22:24 -0300: They say all their ifaces are forced to 100 full duplex, when i try to autoneg with their switches i always got 100 half duplex, and the speed is bad, so i forced all to 100 full duplex so i can get some speed, don't ask me why they switch didn't autoneg to full duplex since they asked me to put all my machines in full duplex... That's exactly what should happen. You can't have one side set to autoneg and one hard set. If you do, you'll get a duplex mismatch. .joel
Re: Problems compiling kernel on 3.7 / amd64
On Mon, 19 Sep 2005, John N. Brahy wrote: cd /usr cvs -t -z9 update -rOPENBSD_3_ -P src 1. there is no OPENBSD_3_ tag. 2. don't retype commands unless you can do it flawlessly. 3. you forgot the -d option to update. -- And that's why he won't get my vote.
Re: PF performance question
From: Vinicius Pavanelli Vianna [mailto:[EMAIL PROTECTED] They say all their ifaces are forced to 100 full duplex, when i try to autoneg with their switches i always got 100 half duplex, and the speed is bad, so i forced all to 100 full duplex so i can get some speed, don't ask me why they switch didn't autoneg to full duplex since they asked me to put all my machines in full duplex... Your ISP asked you to set full duplex because they are explicitly forcing full duplex on their end of the link. You can't have one side of a link forced and one side set to autonegotiate and expect them to negotiate. One side will try to negotiate, the other side will not, so the first one settles for half-duplex. It's referred to as a duplex mismatch. Either force both sides or negotiate both sides. DS
Re: Changing kernels from i386 to amd64
On Mon, 19 Sep 2005, John N. Brahy wrote: How do I change my kernel from i386 to amd64? Do I have to do a reinstall or upgrade? I tried simply copying the bsd file from the amd64 directory off an ftp site but I got a unrecognized binary format error from the boot loader. reinstall. despite the obvious similarity that they can run on the same hardware, you should consider them as different as sparc and powerpc. -- And that's why you believe it isn't simple.
Re: Wireless Strangeness
From: Alex Kirk [mailto:[EMAIL PROTECTED] I'm bailing here. I don't remember 3.4 well enough. I was afraid of that. I've been meaning to upgrade to 3.7 for a while -- is it likely to make that big of a difference if I upgrade? If I were to still experience this problem with 3.7, might you be able to offer further assistance (I can understand not wanting to have to dredge through memory for something not particularly relevant or exciting for someone else's benefit)? Yes. Review CVS history so you can see how many changes have happened since 3.4, particularly in the ieee80211 stuff. Strictly speaking, upgrading from 3.4 (per the documented upgrade procedure, as in 3.4-3.5, 3.5-3.6, 3.6-3.7) will be a likely difficulty. Making the jump from 3.4 might be easier if you just install 3.7 and restore backups. DS
