Re: pfctl
On 10/13/06, Alexander Belikov [EMAIL PROTECTED] wrote: I want to fix a problem on one of my servers. The problem is 2 admins 1 server :( Both of us have a root access to it. It was a will of our Top Managment.. Social problems will never be wholly resolved by technical solutions. Speak to management about 'the problem' and then issue the following command upon approval of your plan to regain control of the network: # passwd Good luck.
Re: No Watchdog with Current snapshot/i386/ on Nokia IP120
On 10/7/06, Rolf Sommerhalder [EMAIL PROTECTED] wrote: As pointed out earlier, this does the trick. Now, I try to contribute a proper patch which discriminates between Geode CPUs in Nokia and WRAP Soekris boards in order to call an appropriate reset function. I have quite a few Nokia IP1x0 devices -- the original kernel 'fix' (workaround?) works as intended. I'm following this thread with moderate interest as this _was_ a major stumbling point to using these devices from remote with OpenBSD. Thanks!
Re: struggling with pf
On 8/27/06, Joachim Schipper [EMAIL PROTECTED] wrote: Actually, you got it the wrong way round - nmap assumes a port is filtered when it gets no response. You're correct, an oversight on my part. From the nmap man page (which I clearly failed to read): 'Filtered means that a firewall, filter, or other network obstacle is blocking the port so that Nmap cannot tell whether it is open or closed.' Perhaps Greg's suggestion has merit as well -- his ISP may be silently dropping services destined to those ports. Mine drops tcp/25 and tcp/80 that I'm aware of.
Re: Why no compiler on prod system [Was: Re: How to update httpd without a compiller]
On 8/24/06, Anton Karpov [EMAIL PROTECTED] wrote: Removing compiler doesn't bring much more security to your system, but it can make it a little bit safer. Very little bit, but safer. I mean, if your system has local root hole, for example, in this case cracker should compile his sploit somethere outside your box, and transfer binary file onto it, thus, it takes more time than cat /tmp/.slp01t.c gcc /tmp/.spl01t.c ./a.out. And usually, crackers limited in time resources. This patently futile measure contributes zero security to the system and it does not make the system even 'a little bit safer'. Please substantiate your claim based on the security record of a large Redmond-based OS that is distributed sans compiler.
Re: service monitoring and pf load balancing
On 8/4/06, Hasan USTUNDAG [EMAIL PROTECTED] wrote:
http://www.bsdforums.org/forums/showthread.php?t=33480
script works fine for me.
You can also use ping to check host availibilty or perl module
Net::Telnet to check port availibilty for other protocols.
That pf.conf looks ok, but his script isn't so great.
I tried this and it works in a lab scenario, with the slight advantage
that everything necessary is available within OpenBSD's default
distribution. The available table is populated by live nc'd entries
from the pool table using the script below, cron'd at your desired
test interval. One caveat is that your first load of pf.conf will
have an empty www_available table until the script executes. I
suppose you could mirror www_pool to www_available in pf.conf to
avoid that.
pf.conf:
-
table www_pool persist { 10.0.0.10 10.0.0.11 10.0.0.12 10.0.0.13 10.0.0.14 }
table www_available persist
rdr on $ext_if proto tcp from any to 172.16.10.100 port 80 - {
www_available } round-robin
pass in on $ext_if inet proto tcp from any to www_pool port 80 flags
S/SA synproxy state
-
test_avail.sh:
-
#!/bin/ksh
for host in `/sbin/pfctl -t www_pool -Ts`
do
/usr/bin/nc -z -w 1 $host 80 21 /dev/null action=add || action=delete
/sbin/pfctl -t www_available -T $action $host
done
-
Re: radioctl error on i386 Aug 1 snapshot; Inappropriate ioctl for device
On 8/4/06, Diana Eichert [EMAIL PROTECTED] wrote: I have a bktr(4) card with an onboard NTSC tuner. I can't control the bktr(4) setup channel and broadcast type because there is no radio(4) device attached, probably? because the auto-detect of the tuner failed? My plan is to pull the card, and verify what tuner is on it. Then build a new kernel based on GENERIC adding option BKTR_OVERRIDE_TUNER and possibly option BKTR_OVERRIDE_CARD to see if I can get a radio(4) device attached. As previously mentioned, I never had to go that far and under ideal circumstances it should just autodetect and attach; however, that the options exist hints that the developer(s) thought the autodetection routine was less than perfect. IMHO, it's a bit of a reach, but I would still make the attempt in a reversed situation. I can't help you much with video capture from a shell.
Re: radioctl error on i386 Aug 1 snapshot; Inappropriate ioctl for device
On 8/3/06, Diana Eichert [EMAIL PROTECTED] wrote: I'm getting the following error when I try to access my bktr(4) card. $ sudo radioctl -f /dev/bktr0 -a radioctl: RIOCGINFO: Inappropriate ioctl for device I was trying to set the tuner to cable/NTSC/channel#. OpenBSD 4.0-beta (GENERIC) #1036: Tue Aug 1 01:59:50 MDT 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC snip bktr0 at pci1 dev 14 function 0 Brooktree BT878 rev 0x02: irq 10 bktr0: Askey/Dynalink Magic TView, Temic NTSC tuner. Brooktree BT878 Audio rev 0x02 at pci1 dev 14 function 1 not configured The RIOCGINFO ioctl(2) is reserved for /dev/radioN(4) devices.. I didn't see it in your dmesg, but I seem to recall my ancient 848 enumerating radio0 at bktr0 for NTSC tuning purposes, barring memory problems (of the brain sort). I believe there are also some kernel config options to force manual enumeration of the device rather than relying on built-in autodetection code. I never had to worry about them, but you might give that a go if you're in the kernel-config neighbourhood.
Re: ralink rum(4) driver ?
On 8/2/06, Diana Eichert [EMAIL PROTECTED] wrote: On Tue, 1 Aug 2006, pedro la peu wrote: If that combination is necessary a ralink radio is likely a poor choice. I could do it with bi-quads only on either end but by using the parabolic I focus the radio signal minimimizing other radios seeing the signal from the sides. A bit off-topic from misc@, but you might consider purchasing a professional-grade antenna. I believe that pacwireless.com sells most in the 2.4GHz range at or under $65 USD that will more than suffice (I am unaffiliated). I advise against the headache of the homemade bi-quad (I've seen you mention it twice on the list now). You might minimize some of the signal backwash, but they are particularly sloppy when forward-facing and not exactly known for their strengths in maintaining a tight polarity. Worth a brief mention as well is the odd beamwidth pattern that scatters outward. Now, that being stated, if you're doing this for the 'neat' factor -- by all means! If for any other reason or if you're doing it in a heavily RF-saturated area, you're doing a grand disservice to others around you. It makes me cringe every time I hear about a cantenna, bi-quad, or other not-so-savory means of dispersing RF into the atmosphere (I've seen people cut holes in guttering drains and turn them vertical) -- it clutters the band with (usually) dirty signals for those who are responsible enough to use it efficiently. Thanks for avoiding the amplifiers!
Re: ralink rum(4) driver ?
On 8/2/06, Diana Eichert [EMAIL PROTECTED] wrote: Thank you for your concerns, but I can honestly say I have access to some of the best machine tools in the world. You're welcome, and I've blessed every last soothsayer's soul that has told me exactly that! Nevertheless, I suppose your ... response merits a reply. yeah, 'neat' factor, let's me play with things I also do at work. So using a USB device with an external connector and a biquad affixed to a DVB dish is considered production gear now-a-days? That's quite a configuration -- I was never able to reproduce such wonderful results as I was with well-manufactured equipment, but I'm certainly open to criticism of my methodology. Provide photos and testing results, there are others reading this list that would be most interested, certainly not excluding myself. Thanks for making the assumption that you are the expert and everyone else is irresponsible. Oh yeah, no linear amps for you? Some day, you will experience someone doing exactly what it was you described and successfully walking/stomping all over your well-engineered wireless network(s). Perhaps then, you'll reconsider this post as a stark reminder of what happens when someone's best intentions really should never have been [inappropriately] rendered as a personal attack. Certainly, if you're 'in the business', you must know that you won't always be the recipient of a friendly suggestion. Regardless, I have personally been through this experience several times. One decent incident still comes to mind. There were a couple of guys who wanted a PtP wireless link between their houses. Somehow, they managed to get enough height and select the right frequency/polarity to intermittently wash out my signal. Unfortunately, I wasn't in a position that I could make changes to my own gear (or not without coordinating with several other providers) so I finally tracked down the problem and traded two parabolic grid-dish antennas bought from my own pocket, some friendly networking suggestions, and proper cabling/connectors/sealing tapes/mastic for their 500mW amps and a promise that they would properly disable the aforementioned setup and the problem disappeared. Both links still operate today, in excess of 5 years later, save for upgraded radios by the two perpetrators. g.day g.luck!
Re: ralink rum(4) driver ?
On 8/2/06, Diana Eichert [EMAIL PROTECTED] wrote: We like to do things with commodity hardware, well let's just say that are interesting, right now we want to push wireless across a desert, with gear we don't care about losing. It sounds fascinating -- OnTopicdo keep us updated on how OpenBSD fits your application./OffTopic
Re: Watching daemons
On 7/28/06, Carlos A. Carnero Delgado [EMAIL PROTECTED] wrote: In the mean time, I'd like to keep ftp-proxy running most of the time. What do you guys use/recommend to watch if a process dies and restart it? More to the root of the problem, have you turned on verbose debugging output to see if there are any correlations to when it dies? Are any other processes dying unexpectedly? Try passing an additional flag '-D 7' and watch the logs. As a nasty interim hack, and a suggested last resort, you might use a cron job to restart it when it dies (for now) -- it won't be immediate, but you could check at 1 minute intervals. Per minute PID check and restart in root's crontab (ugly): * * * * * /usr/bin/pgrep ftp-proxy 21 /dev/null || /usr/sbin/ftp-proxy
Re: OpenBSD 3.9 (i386) on a Nortel Contivity 100
On 7/24/06, Steve Fairhead [EMAIL PROTECTED] wrote: In general terms, a watchdog is a hardware device that resets the CPU if it's not kicked regularly e.g. every few hundred milliseconds. It should not be disableable in software; i.e. the code going off in the weeds should not be able to disable the watchdog by accident. An embedded circuit running proprietary software from boot time can meet these requirements. Correct. However, in my experience PC-type boards with watchdogs (e.g. PC/104 boards) have a software-enabled watchdog. This is off by default, meaning that a standard OS can boot and run. It's conventional to allow the watchdog to be enabled under software control, so that a critical application can enable the device once running. Again in general terms, it makes little sense for the OS itself to kick the watchdog, since this does not prove that the application is running and in control. Understood, and I suppose I was lacking in my original description. The 'n0rwall' project, circa 2003, bluntly states that the watchdog trace (J14) must be opened in order to keep the unit from rebooting. I have not touched mine, nor is the kernel tickling the circuit -- at least that I know of. So, unless FreeBSD 4.11 enables the watchdog where OpenBSD 3.9 does not, I'm not sure what to make of it. I wasn't about to hack on the board until I gave OpenBSD a crack at detecting the watchdog device. So, it leads me to a few conclusions (in order of perceived liklihood): 1) it's disabled in the BIOS 2) The trace was cut by the manufacturer, and I didn't notice 999) OpenBSD is doing something good, but it isn't obvious (highly unlikely) I emphasize that these are general observations which may or may not be relevant to your platform. Certainly, and it does bring up a few more points for me to consider.
Re: OpenBSD 3.9 (i386) on a Nortel Contivity 100
On 7/23/06, NetNeanderthal [EMAIL PROTECTED] wrote: On my todo list are the following: Put in a PCI video card or attach to the onboard header to have a look at the BIOS information, but I don't have the necessary parts/pieces on-hand at the moment. For the record, I am posting a pinout of the VGA header (J16). Using a 2x8 female header and 0.1 leads attached to a 15-pin DSUB connector works great and was quite simple to construct. Pin 1 is closest to the front right corner of the chassis (or the rear corner of the PCI slot), in the event that its description is not silkscreened to the mainboard. I used a spare joystick mainboard connector (snip) soldered to a 15-pin female VGA DSUB connector (snip snip). 1 - RED (Red Video) 2 - GREEN (Green Video) 3 - BLUE (Blue Video) 4 - ID2 (Monitor ID Bit #2) 5 - GND (Ground) 6 - RGND (Red Ground) 7 - GGND (Green Ground) 8 - BGND (Blue Ground) 9 - unused (unused) 10 - SGND (Sync Ground) 11 - ID0 (Monitor ID Bit #0) 12 - ID1 (Monitor ID Bit #1) 13 - HSYNC (Horizontal Sync) 14 - VSYNC (Vertical Sync) 15 - ID3 (Monitor ID Bit #3) I haven't managed to get a pinout on what I *think* are the PS2 connectors so that's still a wash; however, I will have access to a USB PCI card soon -- perhaps I can glean more info from the BIOS using this. At the moment, I can tell that it's an Award BIOS version 4.51PG, with some kind of Nortel identifier under that: 'NII 100-A5-0108-BB'
OpenBSD 3.9 (i386) on a Nortel Contivity 100
I finally got my hands on one of these beasts after seeing it
'supported' by someone on the m0n0wall forums (circa 2003) and decided
to see what it takes to upgrade its hardware and retrofit it with a
modern operating system -- OpenBSD of course. I'm providing this
eMail as a bit of a prod for some extra information as well as to
share my extrapolations to a publicly archived list.
The Nortel Contivity 100 is a small gray computer measuring
approximately 36.5cm x 30.5cm x 7.0cm and weighs approximately 4.3KG.
Externally, there is a power connector and accompanying power switch,
115VAC/230VAC switch, 10/100 ethernet port (sis1), DB9 console port
(tty00), PCI slot, and 8-pin DIP Switch (SW1) in the rear. The front
houses seven 10/100 ethernet ports connected to an internal switch as
well as their corresponding status LEDs (10/100 Link/Activity and Full
Duplex) as well as a Power/HDD Activity LED and 8 proprietary LEDs
that are controlled by some odd SETLEDS.EXE program in the root of the
original Nortel software (Instant Internet Version 7.10 on this one).
After removing the chassis by pulling 3 phillips screws from the rear
of the unit and 4 from each side, the top of the chassis slides
rearward/upward to expose the mainboard, power supply, internal switch
and a single 3.5 HDD bay. The mainboard is a (super?) Socket7 with
two IDE ATA66 interfaces (one of which is occupied by an IDE - CF
converter, complete with 8MB of CF), a 168-pin PC100 SDRAM slot, a CPU
slot with a Cyrix 333 (clocked at 266MHz with a 66MHz FSB), two 10/100
ethernet interfaces (both sis(4), one external as mentioned earlier
and one is attached via a proprietary 10-pin connector jumped to the
internal 8-port switch -- it has internal connectivity/activity and
duplex LEDs(green)), 3 3-pin fan headers, one 15-pin VGA header (J16),
one 4-pin DIP Switch (SW3) that controls FSB, one 8-pin DIP Switch
(SW2) that controls CPU Multiplier and VCore, 12MB of on-board RAM, a
Via VT8501 north bridge, a Via VT82C686A south bridge, a PCI slot (PCI
Bios Revision 2.1), a header for ATX power, keylock, HDD activity,
reset switch (all unused by default), and a standard ATX power
connector. There is another header, J12, which is unidentified as
well as a watchdog trace that is identified by J14 just above the
CR2032 battery.
The Contivity 100 also houses a physically-separate 8-port 10/100
switch internally. 7 Ports are accessible via RJ45 connectors
externally, and one is connected to the mainboard via the same 10-pin
proprietary jumper mentioned earlier. The switch seems to be 'dumb',
using an Allayer AL104 standalone 8-port switch which utilizes a
Broadcom BCM5228 transciever. It is powered by a 6-pin connector from
the power supply.
The proprietary LEDs on the front of the unit are connected to a PCB
which is connected via ribbon cable to DAUG.LCD header on the
mainboard. I'm not sure how to interface this and disassembling the
SETLEDS.EXE didn't yield enough clues as to its operation, but it
would have been nice if Nortel had used a standard GPIO circuit.
The power supply is not much to mention, with no internal enclosure or
markings that depect its rated output.
There are three (relatively noisy) fans in the unit, one 40mm unit on
the side by the PCI slot, one 50mm unit on the CPU and one 60mm unit
in front of the PSU.
On to the OpenBSD part!
After installing OpenBSD 3.9 (Generic i386) to a 512MB CF card using a
CF- IDE adapter in another machine, I removed the default Nortel 8MB
CF card and installed 256MB of PC100 RAM. I also set the default
console to tty00 @ 9600bps. ('tip tty00' connects perfectly to the
Contivity from another machine). dmesg follows:
OpenBSD 3.9 (GENERIC) #617: Thu Mar 2 02:26:48 MST 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Cyrix 6x86MX (CyrixInstead 686-class) 267 MHz
cpu0: FPU,DE,TSC,MSR,CX8,PGE,CMOV,MMX,TM2,CNXT-ID
real mem = 280600576 (274024K)
avail mem = 248532992 (242708K)
using 3450 buffers containing 14131200 bytes (13800K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(bb) BIOS, date 01/05/01, BIOS32 rev. 0 @ 0xfb2e0
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 70102 dobusy 1 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xf/0xb768
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfddd0/144 (7 entries)
pcibios0: PCI Exclusive IRQs: 10 11 12
pcibios0: PCI Interrupt Router at 000:07:0 (VIA VT82C596A ISA rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0x9000! 0xd/0x2200! 0xd3000/0x2200
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 VIA VT8501 rev 0x04
ppb0 at pci0 dev 1 function 0 VIA VT8501 AGP rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 Trident CyberBlade i7 rev 0x5d
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 7 function 0 VIA VT82C686 ISA rev
Re: set skip on interface rule doesn't show up in pfctl -sr
On 7/3/06, Nick Guenther [EMAIL PROTECTED] wrote:
On 7/3/06, Giancarlo Razzolini [EMAIL PROTECTED] wrote:
pfctl -sI -vv shows you if an interface is skipped or not.
-w is not documented in pfctl(8). What does it do?
It most certainly is.
Try -vv ('v' 'v', as in 'victor' 'victor'), avoid typing your dmesg at
all costs! =)
Re: pf firewall - how to allow emails with big attachments ?
On 6/26/06, Ajith Kumar [EMAIL PROTECTED] wrote: I am able to send and receive mails . But if there is any attachment which is bigger than 64 KB, i am not able to send. I am pasting the pf snippet here. PF does not regulate the size of eMails. Did you see an entry in your PF log about a blocked eMail attachment? I seroiusly doubt it. pass in quick log on fxp0 from any to $mail_server pass out quick log on fxp1 from any to $mail_server pass in quick log on fxp1 from $mail_server to any pass out quick log on fxp0 from $mail_server to any 1) You're logging, but didn't give any log output 2) keep/modulate/synproxy state -- read about them, they will simplify your ruleset greatly 3) Please post the entire ruleset if you expect help 4) Traffic is permitted from any to your mailserver (any port, any protocol) -- is this desirable behaviour? 5) Why are you using the 'quick' keyword? Try this: pass in log on fxp0 proto tcp to $mail_server port 25 flags S/SA synproxy state pass out log on fxp1 proto tcp to $mail_server port 25 flags S/SA keep state Or, better yet: pass out quick tagged PERMITTED modulate state pass in on fxp0 inet proto tcp to $mail_server port 25 flags S/SA synproxy state tag PERMITTED If there is no attachments, I can send mails and receive mails. But only problem is there with attachments. What I need to do ? Is there anything to be done with scrub entry ? Now i have not added scrub entry in the fire wall. We would never know -- you didn't post your entire ruleset. Regards, Ajith Kumar U System Administrator trimmed extraneously long signature and _laughable_ disclaimer
Re: OpenBSD on Rackable Systems servers?
On 6/26/06, Kevin [EMAIL PROTECTED] wrote: an official CD set with each order). Anything else I should ask about? How about dmesg output?
Re: T1 and DSL failover? redundancy?
On 6/21/06, John Brahy [EMAIL PROTECTED] wrote: What are my other options? I'd like to have it automatically fail over but I'm not sure what is required to do that. Have you considered using a WAN card for your T1 natively on OpenBSD? As well, you might have a look at ifstated(8) if that's the case -- this would be a cinch to configure with PF. I believe there are several manufacturers of WAN cards, including art(4), lmc(4) and san(4). I have used the Sangoma cards before with good luck. Otherwise, depending on the router (Cisco?), you might be able to setup tracking on the T1 WAN interface to bring down the ethernet interface (assumption?) that points towards your OpenBSD firewall. This in turn would trigger an ifstated event that manages your pf.conf configuration(s). Or... routing metrics. There are so many ways to solve this with OpenBSD. Good luck!
Re: Hifn policy on documentation
On 6/13/06, Hank Cohen [EMAIL PROTECTED] wrote: Folks, There has been some discussion of late on this list about Hifn's policy with respect to releasing documentation to the general public. That discussion lead to a great deal of uninformed speculation and unflattering statement's about Hifn's unfriendliness towards the open source community. I would like to set the record straight. I agree with others, the tone was correct at this point. The simple fact is that anyone who wants access to Hifn's documentation need only log on to our extranet site (http://extranet.hifn.com/home/) The word simple implies no such thing in this instance. I went to the site and it asked for me to register. What is that about? to download as much as they like. This is true of the 795x Algorithm accelerator chips and the 7855 and 8155 HIPP chips. Some more restrictions may apply to our NP and flow through part documents. Specifically the documentation for 7954, 7955 and 7956 is available. The other chips that are supported by the Open BSD Crypto drivers hifn(4), lofn(4) and nofn(4) (7751, 7811,7951, 9751, 6500, 7814, 7851 and 7854) are legacy parts that are not recommended for new designs. The driver will also work for 7954 even though that is not listed. This does represent some liberalization of access in recent months. 'some liberalization' means that you must compromise personal information to gain access to docmentation used to sell your product? Do you realize hifn's target industry? Hifn is always monitoring its policy with respect to the confidentiality of documentation and other business information. Some information will probably always require a non-disclosure agreement. Information that falls into that category is generally of a sensitive competitive nature, contains trade secrets or is related to unanounced or unreleased products. Noone is asking for this information, why classify the other stuff like it is ultra-secretive? The only thing gained (lost) is a community that supports and sells your products for you. Software licenses are generally restricted in the disclosure or source code reproduction rights. Hifn reserves the right to keep our source code proprietary. This should not affect the hifn(4) driver since that driver is programmed directly to the hardware and does not use Hifn's enablement software library. Well, as you stated, it doesn't affect the hifn(4) driver, so why limit the disclosure of information? Registration at our extranet is required along with an email address that can be confirmed. We cannot support anonymous FTP or http downloads. The reason for this is that we are required by the conditions of our US export licenses to know who and where our customers are. If anyone objects to registration then we could not sell them chips anyway so it does not seem an unreasonable restriction to us. What terms must be agreed upon when 'logging in' to this site or even for registration? It clearly asks when 'registering' for access 'Does your company currently have an NDA/CDA with Hifn?' No. Luckily, it's not required, or so it says. After logging in, guess what is shown: Welcome new user. It normally requires several hours for our staff to receive your new user registration and assign the appropriate permissions to you. You will be unable to browse folders or access files until we upgrade your access. You will be notified via email as soon as your permissions have been set. Thank you for your patience. Regards, Brian Sparks (408) 399-3520 [EMAIL PROTECTED] Is this the link that you refer to for the documentation? http://extranet.hifn.com/home/content/documents/?id=1736 If so, why not just make it publicly available? There was NO information submitted that is verified other than eMail address, nor any agreements signed that bind anyone to anything. If anything, why not PROVIDE these 7956 Reference kits to developers? Hifn owes THEM that much for all the hard work they do. This is 'available documentation'? Are you seriously defending this on a public mailing list? Yes, free available documentation. What else lurks under these proprietary PDF formats strewn about the site? And if they're accessible by normal means, sans agreement, why can't they just be posted without regard to registration or agreement? There is no purpose for the compromise of personal information. I hope that this clears the air. It doesn't. You're asking for the OpenBSD community, and especially developers, to compromise the very values that have made OpenBSD what it is today. I used to buy hifn products because they were supported..and they 'just worked'. Now, I have no choice but to look elsewhere. Don't think for a second that for ever person who posts a complaint, there won't be a hundred thousand others who will read this thread at some point and wonder if hifn is really the right choice for their application. Hank, did you really think that the legalese was in hifn's
Re: How to enable hw crypto?
On 6/2/06, Winston [EMAIL PROTECTED] wrote: I have tried the following command to get the hw crypto to work: openssl speed des-cbc -engine cryptodev But the result I got is pretty much the same if I don't specify the cryptodev engine. The crypto card I have is hifn7956. Who made the card you have with a hifn7956 processor? Can you at least provide a bit more information/dmesg?
Re: What point does keep state take effect?
On 5/9/06, Ashley Moran [EMAIL PROTECTED] wrote:
I'm trying to put together a firewall for our DMZ and internal network. For
some reason, a server in the DMZ can only hit the external DNS server if it
has keep state on the DMZ interface. Basically the following (relvant
extract) blocks access:
You're way off on what you're trying to do and need to seriously
consider re-reading the PF FAQ and/or trying the examples. This being
said...
ext_if = vr0
dmz_if = em0
dmz_tcp_services_out = { http, https, ftp, ntp, domain }
dmz_tcp_services_in = { http, https, ssh }
dmz_udp_services_in = { ntp }
dmz_udp_services_out = { domain }
Avoid using lists until you know what purpose they serve and are ready
to aggregate rules!
webserv2_dmz_ad = { 10.0.0.4 }
webserv2_ext_ad= ...
tcp_opts = modulate state # gave up on synproxy state
synproxy works fine, but you need to know why you'd want to use it and
there's no point in using it for a connection that terminates to a
service at the host running the PF ruleset itself.
udp_opts = keep state
icmp_opts = keep state
These are just making the waters muddy -- if you use 'flags S/SA
modulate state' for all connections, PF will interpret what you mean
for udp and icmp connections -- try it out.
nat_proto = { tcp, udp, icmp }
ew? Don't do this.
scrub all reassemble tcp
scrub in all fragment reassemble
scrub out all random-id
nat on $ext_if proto $nat_proto \
from $webserv2_dmz_ad - $webserv2_ext_ad
rdr on { $ext_if, $int_if } proto tcp \
from any to $webserv2_ext_ad port www - $webserv2_dmz_ad port www
block in log (all) all
block out log (all) all
You can just use 'block log' to simplify this -- the rest is implied
and unnecessary.
antispoof log quick for $antispoof_if
$antispoof_if is undefined
pass out on $ext_if proto tcp \
from any to any $tcp_opts
pass out on $ext_if proto udp \
from any to any $udp_opts
pass out on $ext_if inet proto icmp \
from any to any $icmp_opts
Ok, so this whole mess could be rewritten as follows, though I wonder
why you would do it in such a fashion:
pass out on $ext_if proto {tcp, udp, icmp} from any to any modulate state
- or -
pass out on $ext_if proto {tcp, udp, icmp} modulate state
pass in on $dmz_if proto tcp \
from $dmz_ad to any port $dmz_tcp_services_out #$tcp_opts
pass in on $dmz_if proto udp \
from $dmz_ad to any port $dmz_udp_services_out #$udp_opts
pass in on $dmz_if proto icmp \
from $dmz_ad to any #$udp_opts
Blah, don't use complicating macros while you're learning PF!
Call dig with this setup and it times out; uncomment the options
(modulate/keep) state and you get a DNS result. I was under the impression
that the state should be created as the packets leave $ext_if, so why is it
necessary to put a state option in the DMZ interface rules?
Hope someone can clear this up
I'm just not sure what it is you're trying to accomplish. Is this
simply a two-interface firewall that is performing NAT for a web/dns
server to the outside world?
Here is a quick sample -- performs NAT on the external interface to
the dmz interface for http/https/dns and also permits dns/ntp queries
from the webserver to anyone.
#--{ Interface definitions }--
ext_if = vr0
dmz_if = em0
#--{ Host definitions }--
webserver_dmz = 10.0.0.4
webserver_ext = 4.3.2.1
#--{ scrub directives }--
scrub all reassemble tcp
scrub in all fragment reassemble
scrub out all random-id
#--{ NAT/RDR/BINAT }--
nat on $ext_if inet proto {tcp, udp, icmp} $webserver_dmz - $webserver_ext
rdr on $ext_if inet proto tcp to $webserver_ext port 80 -
$webserver_dmz port 80
rdr on $ext_if inet proto tcp to $webserver_ext port 443 -
$webserver_dmz port 443
rdr on $ext_if inet proto {tcp, udp} to $webserver_ext port 53 -
$webserver_dmz port 53
#--{ Default Deny }--
block log
#--{ Permit global SANITIZED traffic to exit opposing interface }--
pass out quick inet tagged SANITIZED modulate state
#--{ Permit anyone to reach the DMZ webserver with HTTP/HTTPS/DNS }--
pass in on $ext_if inet proto tcp to $webserver_dmz port {80, 443} \
flags S/SA synproxy state tag SANITIZED
pass in on $ext_if inet proto {tcp, udp} to $webserver_dmz port 53 \
flags S/SA synproxy state tag SANITIZED
#--{ Permit the DMZ webserver to make DNS and NTP queries }--
pass in on $dmz_if inet proto {tcp, udp} from $webserver_dmz to port 53 \
flags S/SA modulate state tag SANITIZED
pass in on $dmz_if inet proto udp from $webserver_dmz to port 123 \
keep state tag SANITIZED
#--{ Permit some ICMP from the webserver }--
pass in on $dmz_if inet proto icmp from $webserver_dmz \
tag SANITIZED icmp-type { echorep, echoreq, trace, timex } keep state
pfctl -sa is your friend -- examine the changes you make before and
after ruleset load so you can see how PF expands rules. The
policy-based routing tags will also simplify your life so you only
have to manage inbound traffic (excepting
Re: Compilers make a system less secure?
On 5/2/06, jared r r spiegel [EMAIL PROTECTED] wrote: i am not asserting that the compromise-pack did not have a precompiled sshd binary for openbsd ( the prior hop up the compromise chain in this case was a debianlinux ), but if it didn't, it may not have rooted machine B. This is a classic case of treating the symptoms rather than curing the disease. The trusted [sic] user accepted an unkonwn hostkey, was only using password-based authenticaiton, and was using the same usernames/passwords across systems. These things were compromise opportunities waiting to happen -- compiler existance is irrelevant.
OpenBSD 3.9 Installation onto a Nokia IP330
For those of you who are waiting on me to finish testing for OpenBSD 3.9 on the Nokia IP330 firewalls, it appears that the dirty hack that worked on 3.8 works on 3.9 as well. The main deterrent is that OpenBSD can't locate a serial port to use as its console, thus giving the dreaded 'entry point at 0x100120' message. This actually isn't an error, as it does see the keyboard, it's just not something that's physically connected on the IP330. These devices aren't generally powerful. I've personally run across two variants in the wild. The first has a 266MHz AMD K6-2 CPU with 64MB of RAM and an 8GB Western Digital hard drive. The second has a 400MHz AMD K6-2 CPU with 256MB of RAM and a 20GB Western Digital hard drive. There are a few cPCI cards for them and I've even gotten some others that didn't come with the devices to work, including a 4-port Znyx ZX414 (for a grand total of 7 interfaces). I'm not sure if you can replace the CPU or not, but there is a silkscreened multiplier/clock setting on the mainboard and it does look to be a Socket7 interface with a standard HSF/clip. It takes standard PC100, CL2, ECC SDRAM (I'm unsure of the maximum) and has a standard IDE interface with a single molex connector. There are 3 fxp(4) interfaces by default, mine have an additional 2 dc(4) interfaces on a single modular cPCI card. (Please note that the OpenBSD fxp(4) driver will not recognize the original MAC addresses of the controllers as they are not stored in a standard location -- you may wish to save these prior to wiping CheckPoint IPSO from the drive! This might be fixable by making some adjustments to /usr/src/sys/dev/ic/fxp.c or fxpreg.h, but then again, it's late and I could be way off my rocker.) There are 2 DB9 male serial ports (ns16550a) on the front. It uses an Award BIOS and has quite a few settings you can manipulate -- for most practical purposes, it seems to be simply a customized x86 machine. The power supply does not have a cover, so be careful if you get to the point where you're poking around -- use some common sense when working with 120/240 VAC, don't do anything stupid. Here is a brief synopsis of what needs to be done to get it running. - Order your OpenBSD 3.9 CD (http://www.openbsd.org/items.html#39) - Unseat the chassis cover by removing 24 phillips-head screws and pulling forward slightly, then upwards - Pull the hard drive by removing 4 phillips-head screws from underneath the chassis, the molex connector and an IDE connector - Install the hard drive into a surrogate PC - Install OpenBSD as you normally would to the drive, be sure to set your console to com0 when asked, 8N1 9600bps (or hack /etc/boot.conf and /etc/ttys later) - When the install finishes, do not reboot yet! - Chroot to the OpenBSD installation (/mnt/usr/sbin/chroot /mnt) - Mount the OpenBSD CD-ROM (mount /dev/cd0a /mnt) - Untar/gzip the kernel sources (tar -zxvf /mnt/sys.tar.gz -C /usr/src/) - Edit /sys/arch/i386/stand/libsa/bioscons.c (export term=vt100; vi /sys/arch/i386/stand/libsa/bioscons.c) Go to line 105 and apply the following patch (manually or using the following diff) ---8--- 105,106c105 n = 9; n = 7; --- n = 2; /* We know there are two com ports -- force it */ ---8--- - Recompile/reinstall the bootblocks (http://www.openbsd.org/faq/faq14.html#InstBoot) # cd /sys/arch/i386/stand/ # make make install # cd /usr/mdec; cp ./boot /boot # ./installboot /boot biosboot wd0 (or whatever device your hard disk is) - Ensure that your console is set for com0 (http://www.openbsd.org/faq/faq7.html#SerCon) # /etc/ttys:tty00 /usr/libexec/getty std.9600 vt100 on secure # /etc/boot.conf:set tty com0 - Halt the surrogate PC - Replace the drive into the IP330 and reconnect the molex and IDE connectors, don't forget to fasten it from below using the screws as well - Replace the chassis and tighten the screws - Connect your console cable at 9600bps, 8N1 and power up I've attached a dmesg and a quick openssl speed -evp test on aes-256-cbc for the curious. OpenBSD 3.9 (GENERIC) #617: Thu Mar 2 02:26:48 MST 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: AMD-K6(tm) 3D processor (AuthenticAMD 586-class) 399 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX real mem = 268017664 (261736K) avail mem = 237568000 (232000K) using 3297 buffers containing 13504512 bytes (13188K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(6e) BIOS, date 10/27/99, BIOS32 rev. 0 @ 0xfaa20 pcibios0 at bios0: rev 2.1 @ 0xf/0xae9c pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfd3c0/144 (7 entries) pcibios0: PCI Exclusive IRQs: 5 10 11 12 pcibios0: PCI Interrupt Router at 000:07:0 (Intel 82371SB ISA rev 0x00) pcibios0: PCI bus #1 is the last bus cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82439TX System rev 0x01 pcib0 at pci0 dev 7 function 0 Intel 82371AB PIIX4 ISA rev 0x02 pciide0 at pci0 dev 7 function 1 Intel
Re: pf/bridge/routing: packet sent out on wrong interface
On 4/24/06, patrick ~ [EMAIL PROTECTED] wrote: Since I didn't get any reply, I decided to do more digging on my own. Although, I didn't even get my pre-dawn misc digest either, so maybe something is wrong with the mailing list(s). Not likely; however, you failed to post your entire dmesg and your entire pf.conf. Sanitize the subnets you're uncomfortable posting publicly and try again.
Re: pppoe
On 4/18/06, Han Boetes [EMAIL PROTECTED] wrote: More ellegant is: if ! ifconfig -a | grep -q tun0; then Yet another way to write this: (Though not quite as readable?) ifconfig tun0 /dev/null 21 ifconfig $_ destroy
Re: PF and MS RDP trouble (help!)
On 4/9/06, Leonardo Rodrigues [EMAIL PROTECTED] wrote: Hello everyone! I'm having a bit of trouble trying to access a Windows 2003 server that is behind an OpenBSD 3.9 -current firewall. From the LAN, I can remote access the 2k3 server easily, by just opening the mstsc and entering the machine's IP (192.168.0.1). The problem is, I want to access the 2k3 server from home, and my PF rules aren't working =( I try to connect to the firewall's external IP via the ms terminal service client, but my connection times out... Here's my pf.conf snip ruleset What methods have you used to diagnose this? Read the FAQ page and the man pages. http://www.openbsd.org/faq/pf/logging.html /usr/bin/man pfctl pflogd tcpdump Turn on logging for all block rules and start pflogd. Then, try the following command and retest the connection attempt: /sbin/pflogd /sbin/ifconfig pflog0 up /usr/sbin/tcpdump -netttoi pflog0 port 3389 If you still can't find what's stopping the connection after examining pflog0, send the output of the following command back to the list: /sbin/pfctl -vvvsa
Re: PF and MS RDP trouble (help!)
On 4/9/06, Vijay Sankar [EMAIL PROTECTED] wrote: Leonardo Rodrigues wrote: Looks like you may want to do a rdr pass since otherwise you are doing a block drop in quick to all priv_nets and your W2K3 server is on one of those nets. Unless you're assuming the connection was sourced from $priv_nets, you are incorrect. block drop in quick on $ext_if from $priv_nets to any You would be correct if it were reversed: block drop in quick on $ext_if from any to $priv_nets Regardless, hand-holding people who pose PF questions prior to proper diagnosis is the worst thing someone could possibly do to help them.
Re: Dynamically update DNS info in DHCPD.CONF
On 3/29/06, Isaac Levy [EMAIL PROTECTED] wrote: On 3/28/06, NetNeanderthal [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] ~]$ man -k python python: nothing appropriate Is your python install broken? It must be. I checked four other default OpenBSD installs, it's broken on every one of them as well -- this must be a py5n1 epidemic of dangerous proportion.
Re: Dynamically update DNS info in DHCPD.CONF
On 3/28/06, Nick Guenther [EMAIL PROTECTED] wrote: Well you could always script it: #dhcpmeep.py chop after it. Of course, it does this in a very bad (and untested) way, but you get the idea. [EMAIL PROTECTED] ~]$ man -k python python: nothing appropriate
Re: NIC:s, interrupts and performance in High load environment
On 3/26/06, Per-Olov Sjvholm [EMAIL PROTECTED] wrote: My questions are: Is it normal for the above server to idle for 50-70% when there is 50Mbit network load and 25000 states? Is there a way to make it idle even more and lower the interrups? How? If the average network load increases to let's say 100Mbit, is the interrupt and cpu consumption linear? We do not want to have any production stops.. So are there any kernel knobs we should touch in this environment? Can PF make use of SMP? If so... How efficient is it? Why is it that network usage is still popularized by artificial measures, i.e. mbit/s? What kind of pps rates do you see per interface?
Re: dmesg for Phylon 627F-1G + AD3RTLANG
On 2/26/06, Josh Archambault [EMAIL PROTECTED] wrote: It appears that no one has tried OpenBSD on this board yet, but the prospect of a mini-itx board with 1G VIA chip and 4 Ethernet interfaces for less than $200 was interesting enough to me that I bought one anyway. Agreed, they have a small chassis (including the power supply) on that site as well that is relatively inexpensive. snip Dmesg output from a recent 3.9 snapshot kernel for a Phylon 627F-1G motherboard with addon module AD3RTLANG with BIOS optimized defaults is as follows: OpenBSD 3.9-beta (GENERIC) #608: Sat Feb 25 13:12:29 MST 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: VIA Nehemiah (CentaurHauls 686-class) 1 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,MTRR,PGE,CMOV,PAT,MMX,FXSR,SSE cpu0: RNG AES snip RNG AES -- would you mind posting some 'openssl speed -evp aes-128-cbc' and 'openssl speed -evp aes-256-cbc' test results?
Re: pf on bridge
On 2/25/06, Luke Eckley [EMAIL PROTECTED] wrote:
All documentation I have seen about configuring pf on a bridge states
to pass in/out all on one interface and filter in/out on the other.
Why not just 'set skip on { lo, $bridge_int_1 }', then filter on
$bridge_int_0?
Why not filter inbound on both, and pass all policy-based traffic out
unconditionally? That will keep your rules much cleaner.
Here's a quick example:
# Interface definitions
ext_if = bge0
int_if = bge1
# Server definitions
ssh_server = 172.16.30.30
smtp_server = 172.16.30.31
# Default deny
block drop log
# pass local traffic
pass quick on lo inet
# pass tagged traffic out
pass out quick inet tagged FILTERED modulate state
# filter rules for ext_if - int_if
pass in on $ext_if inet proto tcp to $ssh_server port 22 flags S/SA
modulate state tag FILTERED
pass in on $ext_if inet proto tcp to $smtp_server port 25 flags S/SA
modulate state tag FILTERED
# filter rules for int_if - ext_if
pass in on $int_if inet proto tcp to port {80,443} flags S/SA modulate
state tag FILTERED
pass in on $int_if inet proto {tcp,udp} to port 53 flags S/SA modulate
state tag FILTERED
pass in on $int_if inet proto tcp from $smtp_server to port 25 flags
S/SA modulate state tag FILTERED
Experimentation (in a non-production environment) will serve you well.
Re: Sudo
On 2/11/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Tobias Weingartner wrote: I'm outa my depth here, but seems that any implementation of something like sudo that belongs to the shell is an open invitation to security disasters. It takes a deliberate act to enable sudo for users in a default install; as such, this poses a security threat only to the [un|mis]informed. If you feel the default 300 second timeout is too long, or is generally unacceptable, you might consider the following in your /etc/sudoers file: # Defaults specification Defaults timestamp_timeout = 0 This policy will affect sudo users system-wide. You should use /usr/sbin/visudo to edit /etc/sudoers until you have a solid working knowledge of its syntax.
Re: Anonym.OS - OpenBSD-based live CD
On 1/22/06, Scott Francis [EMAIL PROTECTED] wrote: you mean, aside from including man38.tgz? What else are you looking for? There's some docs on their website, but why would you need anything beyond what ships with OpenBSD? There's a man page for everything, and while they don't include a we did the following steps in this order, and here's why we have privoxy and pf and how they're configured, it's easy enough to just read the config files and the relevant man pages. Keep in mind also that this is, at best, a beta release (if not alpha). 'They' as in you, sure.. and they didn't. Go to the site. Go to sf.net's doc page. Neither contain any documentation. My original statement stands as-is. OpenBSD is well documented, what was done to produce this image is not. In fact, it's about as safe as installing OpenBSD from some ISO pulled from a random site. Have a read for yourself, straight from the FAQ: http://openbsd.org/faq/faq3.html#ISO The source of an unofficial image may or may not be trustworthy; it is up to you to determine this for yourself. So, by my own determination, I choose not to trust it. You can find no fault with that logic, especially considering the purpose of your project. the packages are from the ports tree - are you saying they're somehow less trusted because you didn't install/build them yourself? The boot script is there for anybody to peruse who wants to; no trust is required - or at least, no more than is required for, say, flashdist or any other project based on a modified OpenBSD install. There's no secret sauce, no binary blobs, no closed source or NDAs. So, if it's just a group of ports and a boot script, the kernel was left untouched? I did notice some .dist files in /etc.. perhaps 'diff' is all the documentation required. The flashdist script isn't applicable, they don't hand out images of OpenBSD but show you how to 'roll your own' and provide a script. Sure, documentation there is loose as well, but it's more than the sparse peppering of a description provided by Anonym.OS. How do you plan to keep this patched? How are vulnerabilities handled? Errata? As far as unwilling or unable to use OpenBSD in its native form, keep in mind the purpose of the project and their target audience. Not everybody has the luxury of their own laptop, and it's always nice to have something relatively secure to fall back on when stuck with a less-than-sanitary public-use PC. Agreed, somewhat. This topic has been bludgeoned to death on misc, your reasoning fails -- search the list archives. Let's not denigrate unnecessarily; we should be encouraging wider uses and derivative projects, not biting the heads off of developers when they release new OpenBSD-based projects. If it's a waste of time, nobody will use it and it will disappear with no need for vitriol. On the other hand, if it's a good project, well, that kind of development is always a Good Thing. Copying a free OS and adding a few packages hardly constitutes the tag 'developer', perhaps .. installer? scripter? I'm quite certain OpenBSD developers really could care less if their project is taken from its natural habitat and bastardized for the consumption of a wider audience. By your own words, this project is really not much more than a HOWTO, sans end-user effort and the actual HOWTO document. Or did I miss something? This: It reeks of a clumsily-staged publicity stunt. definitely comes off more like sour grapes than any kind of valid criticism, IMO. Perhaps you didn't intend it that way. I never claimed it as valid criticism, it's my opinion and I've a right to it. This is *yet another* (failed) attempt at positive PR for this script+package project. Sour grapes would imply that I am pushing down your project to further my own agenda. I won't lose sleep over that one until I decouple myself from OpenBSD; until then, good luck with your PR campaign! Despite our philosophical differences, here's my constructive criticism: 1) If you're going to produce a bootable ISO image, also produce a siteXX.tgz file and make it available via your website for download during a 'regular' OpenBSD installation. http://openbsd.org/faq/faq4.html#site 2) Consider, perhaps, even a script that will generate the bootable CD ISO from that siteXX.tgz customization as well. 3) Documentation
Re: MRTG/RRD font size
On 1/20/06, Paul Connally [EMAIL PROTECTED] wrote: Box with pretty MRTG fonts and graphs: 1) OpenBSD 3.5 2) MRTG installed via package 3) RRDtool compiled locally (1.0.49) Box with UGLY MRTG fonts and graphics: 1) OpenBSD 3.8 2) MRTG installed via package 3) RRDtool installed via package Problem solving 101, isolate variables. At a bare minimum, there are three distinct differences between these two environments, based on the information you provided; yet, you present the problem as if there is only one. Forget OpenBSD 3.5; try to compile from ports.
Re: Anonym.OS - OpenBSD-based live CD
On 1/19/06, Scott Francis [EMAIL PROTECTED] wrote: Surprisingly, nobody else has mentioned this on-list yet (perhaps because it's been all over the news elsewhere): http://news.google.com/news?hl=enned=usq=anonym.osbtnG=Search+News It was reported on undeadly.org. I'm not in the least surprised that OpenBSD was chosen as the base for a live CD focused on privacy, anonymity and security - in fact, I can't really imagine doing what they did with any other platform (certainly not doing it as well). I'm less than impressed with it after mounting the iso and viewing the contents. Their documentation is poor, if not void of content altogether. Call Anonym.OS what it is, a coagulated lump of untrusted packages and scripts conveniently bundled for those who are unwilling or unable to use OpenBSD in its native form. It reeks of a clumsily-staged publicity stunt. I digress; OpenBSD is free.
Re: Need advice about VPN
On 1/18/06, Hans-Joerg Hoexer [EMAIL PROTECTED] wrote: On Wed, Jan 18, 2006 at 11:20:55AM +0100, Joachim Schipper wrote: Forget about openvpn, there's no need to fiddle around with third party stuff. OT: OpenVPN has its purposes, though this particular scenario shouldn't be one of them. On several occasions, I have run into scenarios where connectivity was limited, ALL IPs were behind NAT, endpoint IPs changed often and only specific TCP/UDP ports were permitted. (Many times in an attempt to specifically thwart IPSEC.) OpenVPN has proved robust and reliable in those environments. Just make sure to take a look at vpn(8). If ipsec does not suit your needs, take a look at tunneling using ssh(1) -w. Unfortunately, while I love the flexibility of SSH tunneling, I would still consider it an ad-hoc solution for most, a massive drawback being that it tunnels over TCP.
Re: pf-question: blocking nmap and dropping the IP of the src-host to a table?
On 1/14/06, Daniel Ouellet [EMAIL PROTECTED] wrote: I didn't spend to much time on this one, but I think the above should give you an idea as to how to go about it. Might work just as is if you add the ports you want to protect inside your LAN, or may need some minor changes, but it is sure very close to what you might need I think. (Sorry, Daniel, my first reply didn't hit the list.) I don't disagree with the approach, though I am not certain it will solve the NMAP issue unless NMAP completes the 3-way handshake. Default nmap behaviour (as observed executed with root privileges) will send a syn packet, which is returned by OpenBSD with an ack.. then either nmap or the host O/S on the far side returns a RST packet. No handshake, no connection. I ran nmap several times against four open ports (nc -k -l 25 (et al) listening) with this rule, here's what my state table shows: nmap.source.ip - 0.0.0.0 ( states 4, connections 0, rate 0.0/60s ) nmap.source.ip - 0.0.0.0 ( states 4, connections 0, rate 0.0/60s ) nmap.source.ip - 0.0.0.0 ( states 4, connections 0, rate 0.0/60s ) nmap.source.ip - 0.0.0.0 ( states 4, connections 0, rate 0.0/60s ) I'm not sure that will ever trigger an overload to a table. Documentation can be found at http://www.openbsd.org/faq/pf/filter.html#stateopts. I'm interested in hearing solutions from others as well.
Airlink 101 Super G USB 2.0 Adapter support
After searching through http://openbsd.org/i386.html#hardware and ath(4), I believe I have a currently (as of the latest snapshot) unsupported USB 2.0 802.11b/g adapter, the Airlink 101 Super G, based on the Atheros AR5523. The manufacturer's web site is located at http://www.airlink101.com/products/awll4030.html. I didn't see a specific request for the device on http://openbsd.org/want.html, but would like to send it to the appropriate developer to see if device support for this chipset can be added to OpenBSD.
GTGI PowerCrypt 5x Availability?
In http://openbsd.org/i386.html, I see that the GTGI PowerCrypt 5x is supported in OpenBSD, and based on the HiFn 7956 security processor. Does anyone know where to source one of these boards, or must I submit a quote and sign half a dozen NDAs from GTGI to get one? Soekris has had their HiFn 7956-based board (the VPN1461) listed on their site as an upcoming product in prototype status for over a year and a half -- vaporware? Where are the serious retail channels for performance crypto hardware?
Re: Nokia IP330 OpenBSD 3.8 Information and Installation Assistance
Here is the world's first (that I know of) Nokia IP330 dmesg from OpenBSD 3.8. Some parts are missing as I've been hacking on the kernel, boot, and biosboot all night so a real 'fix' will follow this message after I clean it up a bit and figure out exactly which of the nasty hacks I used made it proceed. ---8--- OpenBSD 3.8 (GENERIC) #2: Thu Dec 15 02:54:43 GMT 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: AMD-K6(tm) 3D processor (AuthenticAMD 586-class) 399 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX real mem = 268017664 (261736K) avail mem = 240664576 (235024K) using 3297 buffers containing 13504512 bytes (13188K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(6e) BIOS, date 10/27/99, BIOS32 rev. 0 @ 0xfaa20 pcibios0 at bios0: rev 2.1 @ 0xf/0xae9c pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfd3c0/144 (7 entries) pcibios0: PCI Exclusive IRQs: 5 10 11 12 pcibios0: PCI Interrupt Router at 000:07:0 (Intel 82371SB ISA rev 0x00) pcibios0: PCI bus #1 is the last bus cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82439TX System rev 0x01 pcib0 at pci0 dev 7 function 0 Intel 82371AB PIIX4 ISA rev 0x02 pciide0 at pci0 dev 7 function 1 Intel 82371AB IDE rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: WDC WD200EB-11CPF0 wd0: 16-sector PIO, LBA, 19092MB, 39102336 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 disabled (no drives) Intel 82371AB USB rev 0x01 at pci0 dev 7 function 2 not configured Intel 82371AB Power rev 0x02 at pci0 dev 7 function 3 not configured fxp0 at pci0 dev 13 function 0 Intel 82557 rev 0x05, i82558: irq 10, address ff:ff:ff:ff:ff:ff inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 0 fxp1 at pci0 dev 14 function 0 Intel 82557 rev 0x05, i82558: irq 12, address ff:ff:ff:ff:ff:ff inphy1 at fxp1 phy 1: i82555 10/100 PHY, rev. 0 fxp2 at pci0 dev 15 function 0 Intel 82557 rev 0x05, i82558: irq 5, address ff:ff:ff:ff:ff:ff inphy2 at fxp2 phy 1: i82555 10/100 PHY, rev. 0 ppb0 at pci0 dev 16 function 0 Intel S21154AE/BE PCI-PCI rev 0x00 pci1 at ppb0 bus 1 dc0 at pci1 dev 5 function 0 DEC 21142/3 rev 0x41: irq 10, address 00:c0:95:c7:cd:88 dcphy0 at dc0 phy 31: internal PHY dc1 at pci1 dev 6 function 0 DEC 21142/3 rev 0x41: irq 12, address 00:c0:95:c7:cd:89 dcphy1 at dc1 phy 31: internal PHY isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard pcppi0 at isa0 port 0x61 spkr0 at pcppi0 sysbeep0 at pcppi0 npx0 at isa0 port 0xf0/16: using exception 16 pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pccom0: console pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo biomask ebc5 netmask ffe5 ttymask ffe7 pctr: user-level cycle counter enabled mtrr: K6-family MTRR support (2 registers) dkcsum: wd0 matches BIOS drive 0x80 root on wd0a rootdev=0x0 rrootdev=0x300 rawdev=0x302 ---8---
Re: Nokia IP330 OpenBSD 3.8 Information and Installation Assistance - SOLVED
Ok, here's my quick and dirty hack to get OpenBSD operating on a Nokia IP330. Please bear in mind that this is not a fully correct solution, only a hard-coded workaround for legacy hardware. - relocate the Nokia hard drive into a surrogate machine - Install OpenBSD 3.8, be sure to include comp.tgz and misc.tgz. Reboot. - retrieve kernel sources and extract into /usr/src/sys - modify /usr/src/sys/arch/i386/stand/libsa/bioscons.c in the following manner: (force n = 2 instead of incorrectly discerning 0 from the com_probe (a small piece of assembly code could probably be debugged to make this work properly, but it is beyond the scope of this workaround '__asm __volatile(DOINT(0x11) : =a (n) : : %ecx, %edx, cc);')) ---8--- 105,106c105 n = 9; n = 7; --- n = 2; /* We know there are two com ports -- force it */ (http://www.openbsd.org/faq/faq14.html#InstBoot) - Set your console to com0 in /etc/boot.conf and tty00 in /etc/ttys (http://www.openbsd.org/faq/faq7.html#SerCon) - Remove the drive from the surrogate machine and reinstall into the IP330 I'll post a more thorough installation/caveat write-up on these devices soon enough, but for now the masses of you that eMailed me privately have a hack to get your OpenBSD fix on legacy Nokia hardware. Good luck.
Nokia IP330 OpenBSD 3.8 Information and Installation Assistance
Hi misc@, Background I am yet another Nokia IP330 owner seeking help to put a real OS/Firewall onto one of these devices. I have a handful of these at my disposal, all with AMD K6-2 400MHz CPUs, 1 SDRAM bank with 256MB of CAS2 PC100 ECC SDRAM (the other is empty), 2xdc NICs, 3xfxp NICs, Primary IDE, 20GB ATA33 IDE drive, and 2x16550 serial ports. The 2xdc NICs are on an independent cPCI card, but the rest is integrated. There is also a covered RJ11 port to the right of the third onboard NIC that seems to be used for modem connectivity, but I question its functionality on a lower-level. There is an empty header spot on the mainboard for floppy controller, which is detected, but no pins connected to the solder joints (Adding a floppy header looks like a trivial task for someone with any skill in microelectronics). USB (uhci) is detected by FreeBSD, but there are no visually identifiable headers. It uses an Award Modular BIOS, v4.51PG whose console is interfaced via the first serial port using a null-modem cable. (For archival information, a pure null-modem cable is required to see the BIOS -- those with incorrect CTS/RTS alignment won't show the BIOS, but will show an AT and then no output until the OS loads using the serial port. As well, a real serial program (!Hyperterminal) that doesn't send random garbage on device initialization is necessary.) The Problem When I load the generic OpenBSD 3.8 (i386) onto the factory 20GB drive from another i386 machine, specifying the com port as its default console, the other i386 machine boots perfectly with the correct output. When I relocate the drive to the IP330, it cannot detect the serial port on boot. As well, when it gets to the boot prompt and begins the boot process, it gets to the point where it says 'entry point at 0x100120' and then halts indefinitely, never loading the kernel. Here is the attempt from latest 3.8 Snapshot, The 3.8 from the release CD produces the same output, regardless of CD or HD boot source. ---8--- Verifying DMI Pool Data Boot from ATAPI CD-ROM : CD-ROM: 9F Loading /3.8/I386/CDBOOT probing: pc0 mem[639K 255M a20=on] disk: cd0 OpenBSD/i386 CDBOOT 1.04 boot set tty com0 switching console to com0 com0 console not present boot set tty com1 switching console to com1 com1 console not present boot machine memory Region 0: type 1 at 0x0 for 639KB Region 1: type 1 at 0x9fc00 for 1KB Region 2: type 2 at 0xf for 64KB Region 3: type 2 at 0x for 64KB Region 4: type 1 at 0x10 for 261120KB Low ram: 639KB High ram: 261120KB Total free memory: 261760KB boot machine diskinfo DiskBIOS# TypeCylsHeads SecsFlags Checksum hd0 0x80*none* 1024255 63 0x4 0x86b8cab0 cd0 0x9flabel 0 0 0 0xa 0x0 boot boot -c booting cd0a:/3.8/i386/bsd.rd: 4420484+740300 [52+154608+141206]=0x534480 entry point at 0x100120 ---8--- The 'machine diskinfo' command produces an output that is inconsistent with BIOS settings for the hard drive, is this normal? I would think this not to matter since I can't boot from the CDROM either. Attempted Resolutions I have tested the OpenBSD install on the other x86 to ensure that it detects and uses the serial console as well as proper booting. Everything works very well, and as documented. I have tried to edit the kernel configuration for the serial ports to match that of the bios, but had the same results. I have also tried to edit them (address, irq, flags) to match them to what FreeBSD 6 shows in its dmesg. I have also tried to set them in the BIOS to match what OpenBSD wants. I have tested different RAM. I have tested another drive. I have tried disabling DMA and forcing PIO modes in the BIOS. I have tried forcing hard drive C/H/S parameters and auto detection. I have tried setting the 'PCI IDE IRQ Map to : PCI (AUTO)' in the PNP/PCI Configuration menu. I have tested without the cPCI dual-NIC. I have tried to boot using the drive as a slave instead of master on the primary (single) IDE channel (and modifying /etc/fstab at the same time). I have configured and unconfigured several BIOS options (text screens provided below) I have tried using the second serial port for the console. I have tried booting using 'boot -c' (this yields no additional output). I have tried compiling a custom kernel with more debugging. I have tried booting from CD using bsd.rd. I have tried NOT using the serial port for a console. I have tried reinstalling the boot blocks on the alternate x86 machine. (on that note, I would like to try booting from floppy to reinstall the boot blocks, but this operation is currently impossible). I have installed FreeBSD using the same procedure and it works fine, detecting both serial ports, using the first as its console. (dmesg provided below) serial clip from dmesg, note the flags 0x10 (also attempted in kernel config in openbsd with no results) ---8--- sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0:
Re: Nokia IP330 OpenBSD 3.8 Information and Installation Assistance
On 12/13/05, NetNeanderthal [EMAIL PROTECTED] wrote: FreeBSD 6.0 dmesg ---8--- Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-RELEASE #0: Thu Nov 3 09:36:13 UTC 2005 The number of responses I've gotten to this message from people in the same situation is astounding. As such, I'll keep information I find contained to this thread for simple location and archival rather than relaying my findings and progress privately. Here is a NetBSD 3.0RC6 dmesg I managed last night using 'consdev com0' at the boot prompt. I looked for a 'verbose' option briefly, but didn't see anything that stands out with what I'm familiar with in OpenBSD. Please note that all fxp NICs are assigned an initial MAC address of ff:ff:ff:ff:ff:ff and must be manually set to operate correctly. Your best bet for reliable (and uninterferable) operation is probably to assign the originally specified MACs from Nokia; however, you may do as you please as long as you are aware of other devices on your network. For this specific device to be the only exhibitor of this problem, a 'patch' against the fxp driver isn't warranted since a healthy 'workaround' exists. Note that NetBSD labels the additional two NICs as tlp instead of dc (in FreeBSD 6), though the drivers are of the same family. (disclaimer: Some of my dmesgs may differ slightly in terms of hardware (optical drive mostly) as I have multiple units I am working with in different locations. If someone has a 266MHz version with 64MB of RAM and 8GB drive, I would like to collect some BIOS information, possibly hardware versions as well if it is no longer under a service contract or in production use.) ---8--- BIOS32 rev. 0 found at 0xfaa20 mainbus0 (root) cpu0 at mainbus0: (uniprocessor) cpu0: AMD K6-2 (586-class), 398.65 MHz, id 0x58c cpu0: features 8021bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 cpu0: features 8021bfPGE,MMX cpu0: AMD-K6(tm) 3D processor cpu0: I-cache 32 KB 32B/line 2-way, D-cache 32 KB 32B/line 2-way cpu0: ITLB 64 4 KB entries direct-mapped cpu0: DTLB 128 4 KB entries 2-way cpu0: 4 page colors pci0 at mainbus0 bus 0: configuration mode 1 pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok pchb0 at pci0 dev 0 function 0 pchb0: vendor 0x8086 product 0x7100 (rev. 0x01) pcib0 at pci0 dev 7 function 0 pcib0: vendor 0x8086 product 0x7110 (rev. 0x02) piixide0 at pci0 dev 7 function 1 piixide0: Intel 82371AB IDE controller (PIIX4) (rev. 0x01) piixide0: bus-master DMA support present piixide0: primary channel wired to compatibility mode piixide0: primary channel interrupting at irq 14 atabus0 at piixide0 channel 0 piixide0: secondary channel wired to compatibility mode piixide0: secondary channel interrupting at irq 15 atabus1 at piixide0 channel 1 uhci0 at pci0 dev 7 function 2: vendor 0x8086 product 0x7112 (rev. 0x01) uhci0: interrupting at irq 11 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 uhub0: vendor 0x8086 UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered vendor 0x8086 product 0x7113 (miscellaneous bridge, revision 0x02) at pci0 dev 7 function 3 not configured fxp0 at pci0 dev 13 function 0: i82558 Ethernet, rev 5 fxp0: interrupting at irq 10 fxp0: failed to detect EEPROM size fxp0: Ethernet address ff:ff:ff:ff:ff:ff inphy0 at fxp0 phy 1: i82555 10/100 media interface, rev. 0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1 at pci0 dev 14 function 0: i82558 Ethernet, rev 5 fxp1: interrupting at irq 12 fxp1: failed to detect EEPROM size fxp1: Ethernet address ff:ff:ff:ff:ff:ff inphy1 at fxp1 phy 1: i82555 10/100 media interface, rev. 0 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp2 at pci0 dev 15 function 0: i82558 Ethernet, rev 5 fxp2: interrupting at irq 5 fxp2: failed to detect EEPROM size fxp2: Ethernet address ff:ff:ff:ff:ff:ff inphy2 at fxp2 phy 1: i82555 10/100 media interface, rev. 0 inphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ppb0 at pci0 dev 16 function 0: vendor 0x8086 product 0xb154 (rev. 0x00) pci1 at ppb0 bus 1 pci1: i/o space, memory space enabled, rd/line, wr/inv ok tlp0 at pci1 dev 5 function 0: DECchip 21143 Ethernet, pass 4.1 tlp0: QS6611 PHY tlp0: interrupting at irq 10 tlp0: Ethernet address 00:c0:95:c7:cd:88 tlp0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto tlp1 at pci1 dev 6 function 0: DECchip 21143 Ethernet, pass 4.1 tlp1: QS6611 PHY tlp1: interrupting at irq 12 tlp1: Ethernet address 00:c0:95:c7:cd:89 tlp1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isa0 at pcib0 com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo com0: console com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo pckbc0 at isa0 port 0x60-0x64 pcppi0 at isa0 port 0x61 sysbeep0 at pcppi0 isapnp0 at isa0 port 0x279: ISA Plug 'n Play device support npx0 at isa0 port 0xf0-0xff: using
Re: Nokia IP330 OpenBSD 3.8 Information and Installation Assistance
Would it be possible to modify the following values in /usr/src/sys/arch/i386/conf/GENERIC to match that of FreeBSD's GENERIC.hints, then recompile? The biggest challenge is the lack of debugging/diagnostic information or a way to get to it. From OpenBSD - #option KGDB_DEVNAME=\pccom\,KGDBADDR=0x2f8,KGDBRATE=9600 pccom0 at isa? port 0x3f8 irq 4# standard PC serial ports pccom1 at isa? port 0x2f8 irq 3 - From FreeBSD GENERIC.hints - hint.sio.0.at=isa hint.sio.0.port=0x3F8 hint.sio.0.flags=0x10 hint.sio.0.irq=4 - I know I can config the kernel to match the flags option to 0x10 instead of 0x0, but if it doesn't detect it in the first bootstrap, it won't accept the specifications in /etc/boot.conf either. Are there ways to make changes to /usr/mdec/biosboot in how com0 is detected? Am I on the right track or WAY off base?
