Re: PF + ATLQ on openbsd 4.4
Damian Higgins wrote: Hi Stuart, First off, thank you for the feedback you provided. Unfortunately, you misunderstood the issue I'm encountering because you haven't read my entire post. So, I'll try to make a brief post of the previous message, to make it easier to read, and hope you will have the patience to read it this time :). Perhaps you are misunderstanding how pf works. Instead of trying to solve *your* problem, I will try to describe how pf+altq works, and it will be up to you to figure out how to accomplish what you want to do. First, some concepts of queueing/policing I learned from my previous experience in other environments(correct me if I'm wrong) : First forget about other environments, especially Linux. I have deleted the rest of your post, since it does not really matter what you or other environments think about how traffic shaping should be done. If you are using OpenBSD, try to understand how it is done with pf+altq. Here are the basic rules for pf. You may already know some of them, but please bear with me. You may learn something new: # Filtering is stateful in pf, and it is strongly recommended to keep it that way (ie. use 'no state' only if you really know what you are doing). The S/SA flags being default also have strong reasons. # Think of 'state' as a 'connection'. This is especially true for TCP. Use systat(1) or pftop (from ports) to see the states. A state *sees* packets in *both* directions that belong to a particular traffic. # If a packet matches a state, no rules are evaluated *hint* # If a packet does not match an existing state but matches a rule, a state is created. Further packets of this 'connection' will just match the state, and bypass ruleset evaluation. # Loading pf rules with 'pfctl -f pf.conf' does not clear existing states (unless you also use the proper flush command line switch) *hint* # A connection that traverses an OpenBSD router usually enters pf twice (at inbound and outbound interface) and provided there are appropriate pass rules, it will create states on both interfaces. That is, every packet of a connection both inbound and outbound will have two states associated with it. # A connection that originates from or terminates on an OpenBSD box will have a single state associated with it. # NAT/RDR rules are evaluated before filter rules, and address translation happens *before* rules are evaluated, so rules are always checked against translated packets (NAT on incoming, RDR on outgoing). And the basic rules for altq: # altq *only* filters *outbound* packets on an interface. This is usually not related to the direction of the connection itself. ## Example: if you want to restrict internal hosts HTTP downloads from outside servers, these *incoming* HTTP payloads have to be filtered at the interface facing the hosts. This also means there is no way to apply altq to limit downloads that are initiated from the OpenBSD gateway itself. ## Example: if you want to increase the priority of the e-mails that your mail server sends, use the interface facing your ISP. # Each packet, as it passes through the network stack can be assigned a 'queue-id'. This queue id determines which queue the packet is placed as it *leaves* the box. If a packet has no queue-id, then it is assigned to the default queue. # The queue ids are mapped to queue names, that is, queues that carry the same name have the same id. And this is how PF assigns packets to queues: # Each rule has two queue ids, one for normal one for high-priority packets as specified by the rule definition (see pf.conf for details). If you specified a single queue in your rule definition, that means both ids are equal. # By default the packet has no queue-id assigned. # If a packet matches a rule, and that rule specifies a queue, the packet queue-id is replaced by the queue id specified by the rule. If the rule has no queue specified, the packet queue-id is not changed (does not revert back to default). # If a packet matches a state, the rule that created the state is consulted (as above). # Since a packet can match up to two rules/states as it traverses a router, the last assigned queue wins (as the queues only take effect as the packet exits the router). # Note that, since a state matches packets in both directions, packets in both directions will be assigned queue ids by a given state. That makes it possible to create a state with a rule on one interface, and have the reply packets assigned to the same queue specified by that rule on a different interface. Finally, here are some additional things to think about or investigate: # You can do a lot of creative and flexible stuff with 'tag' and 'tagged' keywords in your ruleset. Assigning queues by 'pass quick tagged XYZZY queue MAGIC' type of rules is much easier to keep track of. # What happens if you change the ruleset while traffic is flowing? Hint: existing
Re: tcpdump: WARNING: snaplen raised from 96 to 116
soko.tica Wrote: Hello, list When I tried to see pf log of my recently installed OpenBSD 4.4 desktop box, I've got the message that snaplen has been raised from 96 to 116, even when I did give it a try with -s 96. That is normal. The snaplen is only used for listening on an interface. When reading a capture file, tcpdump uses the snaplen recorded in the file, regardless of the snaplen setting. 116 is what pflogd(8) uses for recording pflog traffic. Since pflog interface headers are bigger than ethernet headers, 116 is the minimum you can use that can reliably capture all pflog interface headers plus IP and TCP/UDP headers. $ sudo tcpdump -n -e -ttt -r /var/log/pflog -s 96 Password: tcpdump: WARNING: snaplen raised from 96 to 116 Any thoughts how to reduce it to examine the logs? Aside, could that be a symptom of a break-in? You can not, and even if you did, you would be truncating TCP/UDP headers so the information you see would be incomplete. Where did 96 come from anyway? Some obscure policy written for ethernet interfaces? Now, if somebody broke into your system, they would want to disable logging, or reduce the amount logged, not increase it. Can
Re: PF: very simple question...
On 2008-11-06, Stuart Henderson wrote: On 2008-11-05, Limaunion [EMAIL PROTECTED] wrote: Hi, for some reason my OpenBSD 4.4 firewall is been able to negotiate dhcp request although there are no rules that allow this operation. dhcp uses BPF (like tcpdump does), this is below PF and is not restricted by PF. Fortunately, the OpenBSD dhclient goes into a lot of pains to reduce the impact of a security vulnerability in itself. It employs privilege separation, using two processes one privileged and one running with no privileges, chrooted to an empty directory. The privileged process does configuration of IP addresses, routes, DNS configuration etc, by communicating with the unprivileged process. The unprivileged process has a connection (file descriptor) to the BPF interface. Before dropping privileges, it first sets up filters that restrict the kind of packets it can receive *and send* through the BPF interface, and locks in these filter settings so that they can not be changed. If the unprivileged process gets compromised while doing its dirty work of parsing network packets it can only send and receive DHCP packets on a specific interface, as restricted by the filter (it can not even spoof its MAC address). This is much better than full network sniffing and arbitrary packet injection on *any* interface, that an unfiltered/unlocked BPF descriptor allows. A compromised process can also modify interface settings, routes or DNS configuration through the privileged process, but by using DHCP you already give this power over to some unauthenticated entity on your local network anyway. Enjoy Can PS: We tried to restrict (and audit) every BPF using program in the base system using the mechanisms described above. Even tcpdump requires root to run so that it can properly drop privileges. Parsing raw network data, even from a file, provides an opportunity to inject incredible amounts of malicious input to the parser. That is also one reason we do not have ethereal/wireshark in ports. The last time I looked, they had a lot of parsers and an incredible amount of complex code tied to that stream of malicious input.
Re: PPPoE(4) Two ADSL modems (identical LCP session issue)
I have previously used two PPPoE links succesfully. The sys/net/if_pppoe.c:pppoe_find_softc_by_session() is correct as long as the devices are attached to different ethernet devices. Since you have not provided any information about your configuration, I can only make a guess. I would say that you are using the same ISP and credentials (username/password) for both pppoe interfaces. If this is the case, most probably your ISP prevents more than one connection from a given account. If this is not the case, please provide more information about your setup. Thanks, Can PS: I (and a lot of other developers) do not follow misc@ and it is hard to reply to mails that one did not receive. Please try to submit a proper bug report next time.
Re: transparent firewall doesn't filter anything
Joaquin Fernandez Piqueras wrote: The problem is that the bridge doesn't filter anything. I tried to put rules that block everything but only filter administration interfaces. The trafic still go through the bridge. Are you perhaps using VLANs on the network you are bridging? Are you bridging the ports marked as trunk on the switches? If so, either do not use a trunk port on the switch or define the respective VLANs on the firewall and use the vlan(4) interfaces for bridging. Also look at the blocknonip option of bridge(4) Can
Re: pf tag goes missing post sshd tcp decapsulization
Hey so now I changed the tagging from tcp_output to ip_output. I also put an pf_tag_unref to so_free and sosetopt (in case that there is allready a tag set). I couldn't see a reason for a pf_tag_unref in the so_accept because the socket could be reused. Thanks to Henning for the ideas! Any further ideas ? I'm in a good run :) Nice, you probably want to keep the application/kernel tag name spaces distinct though. Otherwise it would be easy for any local user/program to mess with pf.conf generated tags and bypass filtering etc. It could be as easy as adding a prefix (APP_ ?) to all application generated tags. Can
Re: pf tag goes missing post sshd tcp decapsulization
Nice, you probably want to keep the application/kernel tag name spaces distinct though. Otherwise it would be easy for any local user/program to mess with pf.conf generated tags and bypass filtering etc. It could be as easy as adding a prefix (APP_ ?) to all application generated tags. Can I'm not sure if this is necessary. If a user tag his pakets via pf.conf there is no need, so why should it be diffrent via socketoption. However, should be there a reasson, I would recommend to do this with kernel-tags (KERNEL_), or to mention a recommendation for setting tags via setsockopt with (for example APP_). If I'm wrong with my thoughts, its not to hard to change that. :) Changing pf.conf and setting/changing the filter in the kernel requires root permissions. Therefore, only users/processes with root privileges can modify the rules and change the tagging/filtering policy. Setting a socket option does not require a privilege. Any user or process can do it. If they mistakenly or deliberately set the same tags specified in pf.conf they could potentially mess with the filtering policy of the box, and may be able to bypass some restrictions that are set against them in pf.conf. To be more clear, if the user/application sets the tag to MYTAG with setsockopt, it should be reflected to pf and filter rules as APP_MYTAG. The prefix to use is obviously open to discussion (what about @MYTAG). I am not sure how you could to change the 'kernel' tag names and become transparent/compatible at the same time. Since this is a new feature, it should make every effort to not break existing configurations and rulesets. Can -- Who is tagging the taggers?
Re: lookup option in /etc/resolv.conf ignored
Darrin Chandler wrote: On Wed, Oct 24, 2007 at 11:46:34PM -0400, Brian wrote: Make sure you have restarted Firefox after making changes to /etc/resolv.conf. Specifically, the application-level DNS cache will contain old data if you have not restarted it. This bit me for 3 minutes straight after needing to redirect an address. I dislike Firefox's caching behavior. My nameservers cache just fine and they are speedy enough by themselves. Firefox's cache is just another level of expirations to go through. So I disable it completely. Here's the cross-platform method, if you should wish to do so: In about:config, two new integer entried: network.dnsCacheExpiration - 0 network.dnsCacheEntries - 0 DNS caching in browsers is (was) meant to provide 'DNS pinning' in order to prevent malicious sites from bypassing browser 'same domain' policy when accessing other/internal servers. Since there are several ways to bypass this protection [1] perhaps it is not that critical to disable it. It is good to be aware of the implications though. Can [1] http://crypto.stanford.edu/dns/
Re: About Xen: maybe a reiterative question but ..
L. V. Lammert wrote: At 05:12 PM 10/24/2007 +0200, Henning Brauer wrote: * L. V. Lammert [EMAIL PROTECTED] [2007-10-24 16:46]: Virtualization provides near absolute security - DOM0 is not visible to the user at all, only passing network traffic and handling kernel calls. The security comes about in that each DOMU is totally isolated from the the others, while the core DOM0 is isolated from any attacks. dream on. that is what marketing wants to tell you. in fact the isolation is incredibly poor. Sorry, the kernel hacking world is pretty far removed from 'enterprise reality' not that it's a bad thing - I often wish it were that simple!! In reality, there are tons of SMEs out there using MS Crap and other risky software! The few security risks you cite for XEN are negligable by comparison. When all this crap/risky software is running on separate boxes, you only have the network as an attack path to the other crap. This path is well understood, and there are established policies, best practices, tools that you can use to control and monitor your network. Now, when you put all this crap onto the same hardware, you remove the well known and trusted hardware from underneath the already crappy setups, and introduce a (possibly crappy/unknown) software layer that claims to provide isolation. Advantages: 1. buzzword compliance 2. some 'cool features' like snapshots and migration 3. perhaps better utilize the (high performance/ultra expensive) hardware you just bought to gain 1 2. Disadvantages: 1. isolation between the systems is in fact *reduced* 2. whole new attack paths through the VM system are introduced: you get access to the host OS, not necessarily through a guest, you compromise ALL guests. 3. A compromised guest could, at the very least cause stability problems and DoS affecting ALL the guests, at worst compromising the host OS. Anything we can do to increase security, *including* setting up VMs (of any flavor) is an improvement [that also increased hardware utilization]. You do not get security improvements out of using a VM system at all. Look at the list above. This is *not* some kernel hackers' out of the world scenario. This is just common sense and security best practices that every enterprise should be aware of. You do have some benefits in terms of management and flexibility, and perhaps faster recovery. VMs are invaluable for development/testing. But there is absolutely *no* security improvement at all. You may accept the risks in favor of the benefits to your business, but do not claim that you are actually improving the security. Can
Re: About Xen: maybe a reiterative question but ..
L. V. Lammert [EMAIL PROTECTED] wrote: If not, then security issues compound due to multiple guest OSs and each set of inherent vulnerabilities. security issues and protections do not add up like numbers. Sure they do. If I'm running Windoze as a guest OS, there are hundreds or thousands of possible vulnerabilities. If I'm runng OBSD as a guest OS, guess what (I hope you don't have to??) - few to none. There is no way to 'compound threat [interaction]', but that doesn't detract from the basic truth - the lower the risk/number of vulnerabilities of the OS, the better off you are. As a corollary, you might also say that there is no way to improve the security of a server without improving the security of the OS. This has *nothing* to do with VM security. The issue with VM security is that: 1. if any guest is compromised you all guests and the host are in danger. 2. if any user or admininstrator of a guest is malicious, all guests and the host is in danger. This threat is NOT because of any possible interaction (network/services etc.) between the guests and/or the host. It is because of a completely different attack vector, the VM system. The 'virtual hardware' that *all* host and guest OS systems implicitly trust to behave well can be subverted. You should NEVER trust a virtual machine to properly isolate the guests. It is a good approximation to having separate boxes, but it is NOT a security barrier. No matter how you twist the logic, however, a VM provides a good level of application domain security, from the standpoint that each set of domain users and applications can only see the services provided within that domain guest OS. The phrase application domain security is a cover-up statement that means I have already decided to run the multiple things on one box because I am cheap, and I need to invent reasons why I can continue doing so. Huh?? Do you know what an application domain is? Guess not - here's a definition: Application + Users + Access Method = Application Domain Examples: File/Print, httpd, DB, . . . The more discrete the security model (i.e. File/Print users are not valid on the httpd server) the better. What you try to describe in a somewhat clumsy and round about way corresponds to moving different applications to their respective/isolated machines. This is actually a good thing to do for security. However, depending on the applications and the interactions between them, you may sometimes end up being with a more complex/less secure architecture. But this is not the point. What you fail to realize is that, when you try to implement this using a VM system, you actually break the isolation. The fact that well behaved applications and OS's work peacefully side by side under a VM setup DOES NOT mean that a malicious program and/or user is not able to break that isolation. Consider a web application login form with an SQL injection vulnerability. It validates the users and works perfectly fine %100 of the time, passes all tests. Denies incorrect passwords etc. UNTIL one malicious user decides to enter ' or 1=1;-- as his password. In a VM system the security of the *entire* system depends on the weakest link in only one of the OS's. To continue your example, you can install as many OpenBSD guests as you like. It takes one windows/linux whatever guest to break them all. That is why the protections do not 'add up'. Can
Re: em(4) - IFCAP_VLAN_MTU IFCAP_VLAN_HWTAGGING ?
Tony Sarendal [EMAIL PROTECTED] wrote: On 10/21/07, Henning Brauer [EMAIL PROTECTED] wrote: * Tony Sarendal [EMAIL PROTECTED] [2007-10-21 14:50]: stateless is poop. What will happen when the limit of maximum concurrent states is reached ? Will it stop forwarding new flows ? depends on the way you write your ruleset. if you do nothing, exactly that happens. An incoming packet is either dropped or not, I don't see how the router can do nothing. Besides that, the environment I am looking at is as an edge/peering router. Basic filtering to protect infrastructure and where possible prevent spoofing, I do not consider such an environment a suitable place for a statelful device as they normally change behaviour when the limit of states is exceeded. A router that has a major performance drop when a certain limit of flows is reached is something I normally stay away from, a router that stops forwarding of new flows when a flow limit is reached is worse. That is my reasoning for using stateless filters in my case. If OpenBSD/pf has a solution that solves these stateful limitations I would be very interested in understanding it. There are several mechanisms for handling overload in OpenBSD/pf They are designed to improve the stateful filtering experience, and usually non-stateful traffic suffers in case of overload. One of them is adaptive timeouts. This lets 'old/not-established' states to be expired quickly, letting new states to be established. You need to set suitable values for your traffic requirements, together with max number of states. This is much more useful than a best effort forwarding where packets belonging to valid states are equally likely to be dropped. Another mechanism is congestion handling. If an interface input queue is full, that means your CPU is not able to keep up with the incoming packets (or that you need to increase the queue size). In this case, pf stops ruleset evaluation altogether, and ONLY passes packets matching to states. Note that, in this case we are already dropping packets. Having pf choose only stateful traffic to pass is an improvement over not being able to pass any. Considering the fact that state matching is faster per packet when you have some less-than-trivial ruleset. Using stateful filtering is better in almost all cases (ie. except asymmetric routing as you pointed out earlier). Can
Re: em(4) - IFCAP_VLAN_MTU IFCAP_VLAN_HWTAGGING ?
Tony Sarendal [EMAIL PROTECTED] wrote: To design a reliable IP network I would need the devices to be able to handle the desired pps rate even when that state limit is exceeded. Many routing devices have over the years achieved good performance by different flow caching methods, we have over the years also learnt that this is a bad thing in uncontrolled environments like the Internet. A reliable IP router is wirespeed and stateless. There is no getting around that. It is also that much boring :) The ability to preserve existing and valid connections in case of overloaded traffic (think DoS) is more useful for me. As Henning suggested, you can always make the ruleset fail (stateless) open and get the best of both worlds. In my case I would verify that the box is wirespeed in the environment I put it in, the fact that it can be faster under certain conditions is less interesting. For such a strict view and/or requirement, your options are somewhat limited. I would suggest: 1. Test with the same ruleset that you would use in production. In the stateless case, the number of rules directly influences the amount of work done for each packet, there is no state/caching. 2. To reduce the ruleset evaluation overhead for large number of addresses (usually more than four or five) use tables instead of single rules. The ruleset optimizer in pfctl usually does this for you, but look at the generated rules instead of the ones you wrote when comparing different rulesets. Can
Re: OpenBSD XSS ;)
Anton Karpov [EMAIL PROTECTED] wrote: 2007/10/10, Stuart Henderson [EMAIL PROTECTED]: On 2007/10/10 20:43, [EMAIL PROTECTED] wrote: Nice to hide your local network IP ;) Do not show it anyone! On 10/10/07, Anton Karpov [EMAIL PROTECTED] wrote: It's a kind of useless and funny XSS... in OpenBSD ;) Well, it's fixed in -current. There are better ways to report a bug than misc@, though. I posted it here because I don't seriously think it's a [useful] bug All bugs are useful :) In this case, if you have some web application on the same *domain name* then the XSS can be used to take control of the user session on the application. Especially fun for isp/hosting kind of settings where you have customer management and troubleshooting (looking glass etc.) services side by side. Can
Re: Network install over a PPPoE connection
On 9/6/07, asdf [EMAIL PROTECTED] wrote: --- Can Erkin Acar [EMAIL PROTECTED] wrote: pppoe is not included in the installation kernels. You have a few choices, in order of preference: But the GENERIC kernel that is installed does contain support for PPPoE? Sure. 3. if you have a spare disk, on your PC, place the sets there, formatted as a FAT filesystem, then install from the disk. Does the spare partition have to be FAT? What if I download all the file sets to a spare ffs partition - will that work? Just checked, and the installation media has ext2fs support, so you can do that too.
Re: Network install over a PPPoE connection
asdf wrote: Is it possible to install OpenBSD on a machine connected to a DSL modemusing the PPPoE network connection? I have an old PC I'd like to use as a router for my new DSL internet service and I am pretty sure that its CD-ROM drive is non-functional. pppoe is not included in the installation kernels. You have a few choices, in order of preference: 1. set up your DSL modem as a router and complete the installation. Then you can configure pppoe and set the modem to bridge mode. 2. download installation sets to a different machine, setup a web or ftp server and install over the local network. 3. if you have a spare disk, on your PC, place the sets there, formatted as a FAT filesystem, then install from the disk.
Re: pppoe problems
Umaxx wrote: hi, after upgrading my router to -current the dsl pppoe connection does not work anymore. userland ppp connects fine but freezes after K 30 seconds. freeze means the connection is still there no errors shown in logs and ifconfig state is normal but there is no more incoming traffic. the provider and modem hardware is ok since i'm connected now through a netscreen to write this mail. i changed nothing in ppp configuration since years and disabled pf for testing... same problem. as i can see in source changes: not much has changed in userland ppp and nfe code since 4.1. I would suggest you try with a different ethernet card if possible just to rule out that possibility. Have you checked your cables? You can also try to experiment with media settings (speed/duplex) of your card. i read in some forums that it would be better to user kernel pppoe... so i tried to use kernel pppoe as workaround, but its does not connect. i used following configuration in /etc/hostname.pppoe0: inet 0.0.0.0 255.255.255.255 0.0.0.1 pppoedev nfe1 \ authproto pap authname authkey up !/sbin/route add default 0.0.0.1 Please read pppoe(4) for -current, you need to add -ifp pppoe0 in -current to your route command. First test using a kernel from the latest snapshot. With and without MP. This will make sure we are testing/debugging the same thing. If your problem persists, please send me the debug outputs from /var/log/messages after ifconfig pppoe0 debug and the binary tcpdump of a session: tcpdump -w pppoe.dump -i nfe1 not ip Thanks Can and of course: up in /etc/hostname.nfe1 if i enable debug i see a lot of outgoing packages... and then a timeout after a while. reconnect and again the same... it stays in the sppp phase of establish connection using pap authname I'm located in germany using arcor as provider. anyone else using dsl pppoe (kernel/userland) in current or latest snapshots - maybe in germany with arcor? any hints are really welcome. dmesg follows regards, joerg OpenBSD 4.2 (GENERIC.MP) #0: Wed Aug 8 17:31:49 CEST 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2145972224 (2046MB) avail mem = 2072682496 (1976MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf (78 entries) bios0: vendor Phoenix Technologies, LTD version ASUS M2N32-SLI DELUXE ACPI BIOS Revision 0603 date 06/27/2006 bios0: ASUSTeK Computer INC. M2N32-SLI DELUXE acpi0 at mainbus0: rev 0 acpi0: tables DSDT FACP SSDT MCFG APIC acpitimer at acpi0 not configured acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Athlon(tm) 64 X2 Dual Core Processor 4600+, 2411.34 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: apic clock running at 200MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Athlon(tm) 64 X2 Dual Core Processor 4600+, 2410.98 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative ioapic0 at mainbus0 apid 2 pa 0xfec0, version 11, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 2 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 5 (HUB0) acpicpu at acpi0 not configured acpicpu at acpi0 not configured acpitz at acpi0 not configured acpibtn at acpi0 not configured cpu0: PowerNow! K8 2410 MHz: speeds: 2400 2200 2000 1800 1000 MHz pci0 at mainbus0 bus 0: configuration mode 1 NVIDIA C51 Host rev 0xa2 at pci0 dev 0 function 0 not configured NVIDIA C51 Memory rev 0xa2 at pci0 dev 0 function 1 not configured NVIDIA C51 Memory rev 0xa2 at pci0 dev 0 function 2 not configured NVIDIA C51 Memory rev 0xa2 at pci0 dev 0 function 3 not configured NVIDIA C51 Memory rev 0xa2 at pci0 dev 0 function 4 not configured NVIDIA C51 Memory rev 0xa2 at pci0 dev 0 function 5 not configured NVIDIA C51 Memory rev 0xa2 at pci0 dev 0 function 6 not configured NVIDIA C51 Memory rev 0xa2 at pci0 dev 0 function 7 not configured ppb0 at pci0 dev 3 function 0 NVIDIA C51 PCIE rev 0xa1 pci1 at ppb0 bus 1 ppb1 at pci0 dev 4 function 0 NVIDIA C51 PCIE rev 0xa1 pci2 at ppb1 bus 2 ppb2 at pci2 dev 0 function 0 Intel IOP332 PCIE-PCIX rev 0x07 pci3 at ppb2 bus 3 arc0 at pci3 dev 14 function 0 Areca ARC-1210 rev 0x00: apic 2
Re: tcpdump segfaults on enc0 interface
Jurjen Oskam wrote: Hi there, I'm using OpenBSD 4.1-stable/amd64 (dmesg below). I'm setting up ipsec to secure my wireless network, and that seems to work great. (Great job on the new way to configure ipsec, by the way!) When using tcpdump on the enc0 interface, I noticed that it segfaults after a few seconds of continuous traffic on enc0. The weird thing is, I can't get it to produce a coredump to post a bugreport (unfortunately, I'm no programmer so I don't think I can diagnose and fix it myself). The enc0 handling code in tcpdump looks fine, so the problem is most probably related to some particular traffic in your network. The inability to get a coredump is normal. Tcpdump uses privilege separation and the part that drops its privileges segfaults. Since it was a privileged program, and is no longer root, it is not allowed to coredump even with kern.nosuidcoredump=0 I'm probably missing something here, so a nudge in the right direction would be much appreciated. ulimit -c is unlimited, I have the default login.conf, I set kern.nosuidcoredump=0, and executed tcpdump from /tmp. Still no corefile. As Stuart Henderson also pointed out, your best bet is to use gdb. If you could get us a backtrace, that would be nice. An other alternative is to run a simultaneous tcpdump, writing to a file: tcpdump -p -w crash.dmp -i enc0 since is does not parse the packets, it should not crash. Once the other tcpdump crashes, stop it, and test the dump: tcpdump -n -r crash.dmp If the problem is with the input stream it should crash. You can then send the dump to an intrested developer ie. me ([EMAIL PROTECTED]). I do not recommend posting it to a public list/website since the binary dump might contain sensitive information (although, since the default snap length is low, it will mostly be packet headers only) If the input file does not crash tcpdump, you might have a problem with your setup possibly a kernel/userland mismatch. I would suggest trying to reproduce with a GENERIC kernel from a recent snapshot. Let me know how it turns out. Can
Re: 4.0-stable panic with pppoe(4)
On 2007-03-28 Tamas TEVESZ wrote:
ok, so i'm not *entirely* sure it's with pppoe(4), but as far as i can
put bits and pieces together, it's always happening after ifconfig
pppoe0 down; ifconfig pppoe0 destroy and then either sh
/etc/netstart pppoe0 or (the second case) starting ppp(8).
[snip]
This is fixed post 4.0 in v1.152 of sys/net/if.c
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/if.c
The patch is not in -stable though.
You could:
* Try not to destroy the interface, which triggers the bug.
* Use a snapshot
* Update to 4.1 when it comes out,
* Apply the change manually (see below)
Can
Index: if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.149
diff -u -p -u -p -r1.149 if.c
--- if.c29 Aug 2006 17:19:43 - 1.149
+++ if.c28 Mar 2007 16:16:20 -
@@ -568,10 +568,8 @@ do { \
/*
* Deallocate private resources.
-* XXX should consult refcnt and use IFAFREE
*/
- for (ifa = TAILQ_FIRST(ifp-if_addrlist); ifa;
- ifa = TAILQ_FIRST(ifp-if_addrlist)) {
+ while ((ifa = TAILQ_FIRST(ifp-if_addrlist)) != NULL) {
TAILQ_REMOVE(ifp-if_addrlist, ifa, ifa_list);
#ifdef INET
if (ifa-ifa_addr-sa_family == AF_INET)
@@ -582,7 +580,7 @@ do { \
if (ifa == ifnet_addrs[ifp-if_index])
continue;
- free(ifa, M_IFADDR);
+ IFAFREE(ifa);
}
for (ifg = TAILQ_FIRST(ifp-if_groups); ifg;
@@ -591,7 +589,7 @@ do { \
if_free_sadl(ifp);
- free(ifnet_addrs[ifp-if_index], M_IFADDR);
+ IFAFREE(ifnet_addrs[ifp-if_index]);
ifnet_addrs[ifp-if_index] = NULL;
free(ifp-if_addrhooks, M_TEMP);
@@ -1001,9 +999,9 @@ link_rtrequest(int cmd, struct rtentry *
((ifp = ifa-ifa_ifp) == 0) || ((dst = rt_key(rt)) == 0))
return;
if ((ifa = ifaof_ifpforaddr(dst, ifp)) != NULL) {
+ ifa-ifa_refcnt++;
IFAFREE(rt-rt_ifa);
rt-rt_ifa = ifa;
- ifa-ifa_refcnt++;
if (ifa-ifa_rtrequest ifa-ifa_rtrequest != link_rtrequest)
ifa-ifa_rtrequest(cmd, rt, info);
}
Re: snort bpf file problems
Dan Farrell wrote: I'm running Snort 2.4.5 (the pkg) on OpenBSD 4.0 and I use a bpf filter file to have Snort ignore certain hosts altogether. The command I'm using is 'snort -D -i dc1 -F bpfile' The kernel has a limit for the maximum number of filter instructions. Currently it is set to 512. This is the limit you are hitting with your filter definition. Since the buffers are not allocated until you set a filter, it seems safe to increase the limit it is defined in src/sys/net/bpf.h #define BPF_MAXINSNS 512 you will have to compile a new kernel When I have the single line of- not host 192.168.1.69 Snort runs fine. But when I lengthen the bpf filter file to- not host 192.168.1.69 and not host 10.1.1.1 and not host 4.2.2.2 ... 60 more addresses ... and not host 6.6.6.6 Snort chokes with the following error- snort: FATAL ERROR: OpenPcap() setfilter: BIOCSETF: Invalid argument The BPF file I'm using is one I pulled from another snort installation I have running on -gasp- Fedora (I mention this because it has no problems parsing the same file.) Is there a way to have multiple entries in the BPF file that I'm missing... am I using the wrong syntax (is there an alternative to 'and not host' that I need to use)? Dan Farrell Applied Innovations [EMAIL PROTECTED]
Re: Squid 2.6 transparent proxy with pf
On Thu, Dec 21, 2006 at 03:29:51PM +0200, Dominik Zalewski wrote: On Thursday 21 December 2006 15:04, Peter N. M. Hansteen wrote: Dominik Zalewski [EMAIL PROTECTED] writes: I have OpenBSD 4.0 firewall and I would like to redirect all outgoing http requests to my squid web proxy. Daniel Hartmeier wrote about this a while back, his article can be found at http://www.benzedrine.cx/transquid.html In this article squid is running on the same machine as OpenBSD firewall. In my case I have squid running on different machine connected to LAN interface. My question is can redirect traffic on $int_if to another machine connected to the same interface? Does this rule is corrrect ? rdr pass on $int_if proto tcp from any to any port 80 - $squid port 8080 pfctl doesnt complain about nothing but its simply doesnt work. This is reflecting a connection back to the same interface The squid proxy tries to reply to the sender, bypassing the firewall. The sender resets the connection since it did not send a packet to the proxy in the first place. This is all discussed in the pf guide: http://www.openbsd.org/faq/pf/rdr.html#reflect with different ways to solve it. Can
Re: Squid 2.6 transparent proxy with pf
On Thu, Dec 21, 2006 at 02:39:50PM +, Stuart Henderson wrote: On 2006/12/21 15:29, Dominik Zalewski wrote: In this article squid is running on the same machine as OpenBSD firewall. In my case I have squid running on different machine connected to LAN interface. My question is can redirect traffic on $int_if to another machine connected to the same interface? Does this rule is corrrect ? No, you can't redirect back out the interface the packet came from. Maybe vlans could help, if there are no spare physical interfaces. Or you could run a small transparent proxy (e.g. tinyproxy) on the firewall and have that use $squid as a parent. unless you nat the connection back, but it is an ugly solution see the pf guide. rdr pass on $int_if proto tcp from any to any port 80 - $squid port 8080 Even if you arrange $squid to be on an interface other than $int_if, I don't think this will work: iirc Squid needs to query /dev/pf for the untranslated addresses; in that case you need route-to on the firewall and fwd - 127.0.0.1 on the proxy. squid needs to query /dev/pf only for HTTP/1.0 connections with no Host: header. Otherwise, it will happily use the Host: header to connect to the remote server.
Re: Bridge PF with spamd but getting RST packet
Edy [EMAIL PROTECTED] wrote: Hi, I am trying to configure spamd on the current bridge PF firewall which is running on OpenBSD 4.0 fxp0 and fxp1 both are setup as bridge interfaces the following is the rdr rule for spamd ## Spamd Stuff # Table that spamd updates table spamd persist table spamd-white persist file /etc/whitelist.txt # If not on whitelist, redirect to spamd rdr pass on $ext_if inet proto tcp from !spamd-white to any \ port smtp - 127.0.0.1 port spamd # Because this is a bridge, explicit route to this machine pass out route-to lo0 proto tcp from any to 127.0.0.1 port spamd try this fragment instead, note that there is no pass in rdr and the route-to is applied to an incoming packet. Using tags to match nat/rdr rules to filter rules is much easier. # If not on whitelist, redirect to spamd rdr on $ext_if inet proto tcp from !spamd-white to any \ port smtp tag SPAMD - 127.0.0.1 port spamd pass in route-to lo0 tagged SPAMD keep state Can
Re: OpenBSD PCI ADSL Cards
On Sat, Sep 02, 2006 Nick Holmes wrote: I'm currently in the position where I have an OpenBSD firewall (standard issue x86 affair), a Zyxel 660H-61 ADSL router, and two 3COM WLAN devices providing the necessary services. I'd very much like to consolidate and get one box doing the lot (avoiding the need for extra plug sockets, extra cabling etc.) I have been looking through the archives for info on what success people have had with various PCI ADSL cards with OpenBSD. I understand that in the past the Sangoma cards were used (albeit with binary drivers) but are now unsupported, same with a couple of other vendors' products. [FWIW, I have written to Sangoma to ask if they would be prepared to release the tech docs so a free driver can be written.] Are there *any* PCI ADSL cards which people have working properly with 3.9/4.0? Or am I stuck with needing external ADSL routers bridging to my OpenBSD box? No PCI ADSL cards are supported I'm afraid. I have had some success with Eagle chipset USB modems, using the ueagle(4) driver. Can
Re: Splitting xbaseXY.tgz - stupid idea?
On Monday 22 May 2006 Liviu Daia wrote: On 22 May 2006, Lars Hansson [EMAIL PROTECTED] wrote: On Monday 22 May 2006 17:27, Liviu Daia wrote: Ok, let me rephrase this. How realistic will be to run an OpenBSD firewall or router without xbase a few years from now? Extremely realistic. Base install of OpenBSD is an excellent firewall and router platform, without the need for X. what is *your* definition of a router or a firewall? [snip] packages of console applications now depend on X at run time even though that could be avoided with minimal fuss (example: mrtg), It's even easier to *not* run mrtg *on* the router/firewall. SNMP, symon and pfstatd exist for a reason. Sure, but that's not what I'm asking. Sure, but that is not how it works in OpenBSD. *You* submit patches, and make sure that these patches *work* not only on your setup, but for everyone and every supported achitecture. *You* work to get these patches committed. And everyone gets a better system as a result. Not contributing and only whining only gets you this far. Also, so far I've only seen 1 console application that requires X at runtime. [...] Mrtg, rrdtools, pftop, everything else depending on GD. I am sure pftop does _not_ depend on GD. Regards Can -- Can E. Acar, PhD, CISSP
Re: Trouble with pppoe(4) on O3.7 RELEASE
On 10/02/06, Damon McMahon [EMAIL PROTECTED] wrote: Greetings, I'm having trouble getting pppoe(4) to establish a connection from my OpenBSD 3.7 RELEASE (+ errata patches) box to my ISP through a Netgear DG632 in bridge mode. I can successfully establish a connection using pppoe(8) although it is a bit hit-and-miss. The in-kernel pppoe(4) is not hit-and-miss, however, it's just miss. While it may not be related to your particular problem, please note that there have been considerable changes to pppoe and sppp layer since 3.7 you should consider upgrading. It looks from the trace like you have established a pppoe session. But no traffic flows? Have you actually tried pinging some remote IP? you may have problems with name resolution. pppoe(4) does not negotiate DNS. you should enter a valid DNS resolver address to /etc/resolv.conf manually. also, from the trace, it looks like the peer asks for CHAP authentication but then falls back to PAP, due to your settings. Using 'myauthproto=chap' might help. Also it is strange that the peer offers an IP then NAK's it and offers another one. You could try debugging this with your ISP. if all fails, dumps from a successful pppoe(8) session might help. please add '-e' switch to tcpdump. it helps identifying peers. Can
Re: in-kernel pppoe and automatic reconnect
Claudio Jeker wrote: On Wed, Nov 02, 2005 at 04:42:12PM +0100, Henning Brauer wrote: * Dulmandakh Sukhbaatar [EMAIL PROTECTED] [2005-11-02 05:25]: I'm new to OBSD, and configured in-kernel pppoe as my internet gateway. I found out that with userland pppoe automatic reconnect is posible, but with in-kernel pppoe everytime pppoe connection lost, I need to reboot the system. I don't know how to manually reconnect the connection. Any suggestions? Please help. huh? kernel PPPoE just reconnects when it loses the session No only if you add -link1. Infact -link1 (ie. disable link1 == disable dial on demand) is the default behaviour. The manpage summarizes it quite nicely. By default it tries to keep the connection open at all times. Which includes trying to reconnect if the session is lost. There were a couple of problems in 3.7 with auto reconnection, which resulted in all kinds of workarounds being proposed/developed. In 3.8 none of them are necessary. It just works by default. Can
Re: in-kernel pppoe and fixed address
Antoine Jacoutot wrote: Jason McIntyre wrote: my hostname.pppoe0 file does this without problem. i guess the problem is you specify an exact ip, but a wildcard for your gateway. Sorry about that. I was not very clear. In fact, I also tried to set the gateway to a fixed IP, but it does not change anything, I still can't connect. pppoe allows setting of local and peer addresses, and will request/require these values when it negotiates the address. 0.0.0.0 and 0.0.0.1 are special in that they allow the addresses sent by the peer to be accepted. whether it will fix your problem (app binding in rc.local) i don't know. Actually I know it does since even when not connected yet, the pppoe0 interface has already an IP assigned and the application can start without a problem. Anyway, this particular thing is not very important, I just want to know if there's a way to set a fixed IP/gateway in hostname.pppoe0 and be able to connect. It is probably a problem with your ISP. It wants to give you a (fixed) address. It does not allow you to specify an address, even if they are the same. As a workaround, if you are using -current, you can use ifstated. In -current pppoe brings its link state 'up' when the IP layer is open (ie. has an address). Can
Re: kernel pppoe problem : pppoe0 : timeout
You possibly have other/previous pppoe sessions not being terminated correctly. The reason is that, the kernel pppoe does not terminate unknown sessions (ie. not handled by itself). see pppoe(4) manual page for details, compiling a kernel with PPPOE_TERM_UNKNOWN_SESSIONS option may help. Can
Re: in-kernel PPPoE doesn't like my authname
Talmage wrote: I'm planning on implementing a OpenBSD all-in-one router/firewall/ PPPoE_client/VPN_server and have been having issues getting the in- kernel PPPoE to work which is the first thing I'm working on. I've checked the pppoe(4) manpages but still haven't been able to get it to work. Your hostname.pppoe0 is bad. See below: [snip] $ cat /etc/hostname.pppoe0 pppoedev em1 !/sbin/ifconfig em1 up !/usr/sbin/spppcontrol \$if myauthproto=pap there is no line continuation character at the end, so the next line is passed to ifconfig as a new command. either join the lines or use: !/usr/sbin/spppcontrol \$if myauthproto=pap \ to connect the lines. [EMAIL PROTECTED] myauthkey=SECRET !/sbin/ifconfig \$if inet 0.0.0.0 0.0.0.1 netmask 0x !/sbin/route add default XXX.XXX.XXX.80 up For debugging pppoe authentication, you can use spppcontrol -v pppoe0 to check see the current auth settings, and tcpdump to watch what credentials are being sent. an example tcpdump command would be: tcpdump -nevX -s 1500 -i em1 no ip
Re: PPPoE Download Performance Woes
Melameth, Daniel D. wrote: I've looked into this further and still cannot determine where the issue lies. Based on some advice, I unplugged the OpenBSD machine and setup a Windows XP machine instead. The Windows native PPPoE client was able to download at 5.5Mb/s and the OpenBSD machine was still stuck at 1.5Mb/s. My ADSL connection where I do my testing is only 256Kb, so I set up a second OpenBSD machine on the same LAN as a pppoe server and did some tests. I get almost the same performance with or without pppoe. ie. up to 70Mbps, after increasing the socket buffer size in iperf. This is -current, so Marco's comments about idle loop may also apply. Note that, if debugging is turned on, it would not go above 1.5Mb/s, due to excessive amount of logging, make sure that you do not somehow turn debug on by default. Another thing to try would be to replace your ethernet card. The xl(4) said to be quite crappy. Can
Re: auvia and the VT8233/VT8235 for AC97 audio
Josh Grosse wrote: [snip] I have a VT8235 southbridge chip, providing integrated AC97 audio.I just want 2-channel (stereo) output, but am only able to obtain left-channel output from the soundcard. I'm running 3.7-release, and of course its using the auvia(4) driver. [snip] ac97: codec id 0x41445368 (Analog Devices AD1888) ac97: codec features headphone, 20 bit DAC, No 3D Stereo I have a patch for this. It will be fixed in -current soon. Can
Re: kernel pppoe problems
Jason Ackley wrote: Can you try turning on the debug flag to pppoe0 ? Good advice, debug mode gives lots of useful output also tcpdump on the parent interface, eg. 'tcpdump -nei fxp0 no ip' helps. I just tested this in a lab setup and it would not connect unless the debug flag was set on the interface. The other side was a cisco and it seems that they could not get out of the configuration negotiation phase (cisco was never getting far enough along to authenticate via RADIUS server). If I had 'debug' set on the interface, it came up instantly. now, this is not what the debug flag is intended for. it is also not good for system logs, so instead of discussing such 'workarounds' which, unfortunately live much longer than the bugs themselves. I suggest we try to identify the problem. This was tested on 3.7-release kernel and a -current as of a day or so ago on i386 and amd64. I am checking my setup now to make sure all my boxes are in sync. I can't see any problem report about this in my inbox (which is quite a mess nowadays, so it is equally likely that I missed it), If you can spare some time to send me pppoe debug outputs, tcpdumps with without the debug flag, and if possible logs/dumps from the cisco side, I we can do something about the problem. Can
