Re: Bug in ksh // Improvement for tar ?
Otto Moerbeek <[EMAIL PROTECTED]> wrote: > The ustar format is defined by POSIX and does not allow for filename > larger than 100 chars or path names larger than 255 chars. > > GNU choose to provide an extension, at the cost of reduced interoperability. BTW, GNU tar changed the extension back in ~1992. The old scheme has still been supported for reading ever since, but somebody recently discovered a path traversal vulnerability there and in response any support for the old scheme will be removed from gtar 1.16.1. (It's already disabled in our gtar-1.16p0 package.) While I don't expect many people to still need to access archives that are that old and use the extension, a few will probably be bitten by this. -- Christian "naddy" Weisgerber [EMAIL PROTECTED]
Re: Proposal for uname / cvs
On Sat, 09 Dec 2006 19:08:34 +0100, Igor Sobrado wrote: > The BSD operating > systems do not have the overfeaturism we can find in other OSes these > days Seems that it's about only me here who wants this simplification ... . I fully agree with your arguments on -possible change of tags -optionbloat. So I'll have an extra compatibility layer that translates the current version to the current way of tagging. Uwe
Re: VPN Howto
> So whereas Linux has both a Security Policy Database and a Security > Association Database in the kernel, I believe (and someone please correct me > if I'm wrong) that OpenBSD kernel has only an SAD. You put your policy into > ipsecctl, which passes it onto isakmpd, and isakmpd negotiates keys and > sticks them in the SAD. You're wrong. Look at src/sys/netinet/ip_spd.c. You can manipulate the spd by using static flow esp rules and using the type keyword. flow esp from 192.168.0.0/24 to 192.168.1.0/24 peer 192.168.0.2 type require -- Mathieu Sauve-Frankel
www.openbsd.org/want.html
various developers have added new entries to the "want list" at www.openbsd.org/want.html it would be nice if people would review the page again, to see if they spot something that they can help with. many recent drivers (wireless, raid, etc), ports (openoffice for instance) happened because of specific donations made by you people out there. thanks a lot.
Re: Multiple Internet Connection Confusion
On 2006/12/09 17:24, [EMAIL PROTECTED] wrote: > reply-to option (I had missed that earlier), and I now can SSH in via > the cable modem interface (no word yet on whether I can NAT out of it, > I'll figure that out when I'm at a machine that would use that NAT). NATting is fairly straightforward, it's handled the same as any outgoing traffic. Outbound traffic normally follows the routing table, the source IP address is not used in this decision. Any exceptions to this need route-to on the interface used to send the packets out. Note that translation happens before filtering rules, so you can choose which network to use for particular traffic types by changing the NAT IP address. > pass out on $ext_if2 route-to ($ext_if2 $ext_gw2) from $ext_if2 to any In general, on the interface holding the default route (fxp0 in your example), you need to 'pass out..route-to' all traffic from the source address of the other nic (dc0). This gets most traffic routed correctly, but you also need a similar line with the networks reversed to ensure that you can reach the subnets of the other interfaces correctly: using your example addresses, this is necessary so that packets from 66.92.172.3 can reach hosts in 70.174.128/23. That's why there are two rules at the end of faq/pf/pools.html, one for each interface. You should re-read those 2 rules carefully and compare with what you've written (which won't do quite what you expect as it stands).
Re: openbsd 4.0 ralink problem low operation range
I have a Linksys card that uses ral and I can confirm this Sam Fourman Jr. On 12/9/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Hi List, i've tried today openbsd 4.0 with several cards: rt2561t -> PC-620C rt2560f -> WMIR-103G rt2560f -> GN-WIKG with all cards i got a connection (mediaopt ibss -> adhoc) with a distance of some meters. but if i tried a distance of 150 meters with 2 yagi (12dbi) i got no connection :-(. i one test i've used a prism2 card on only the one site and a got a connection but the performance was very bad. with 2 prism cards it work fine. 2 prism -> ok 1 prism and 1 ral -> bad performance 2 ral -> no connection has anyone an idea whats the problem of this low operation range ? Thanks. Thomas
openbsd 4.0 ralink problem low operation range
Hi List, i've tried today openbsd 4.0 with several cards: rt2561t -> PC-620C rt2560f -> WMIR-103G rt2560f -> GN-WIKG with all cards i got a connection (mediaopt ibss -> adhoc) with a distance of some meters. but if i tried a distance of 150 meters with 2 yagi (12dbi) i got no connection :-(. i one test i've used a prism2 card on only the one site and a got a connection but the performance was very bad. with 2 prism cards it work fine. 2 prism -> ok 1 prism and 1 ral -> bad performance 2 ral -> no connection has anyone an idea whats the problem of this low operation range ? Thanks. Thomas
Re: Multiple Internet Connection Confusion
I'm in the process of evaluating whether to transition from a DSL line over to a cable modem, and until February I'll have both hooked up to my OpenBSD 3.8 box, which acts as a mail/web/NAT server. I've got the new cable modem hooked up, it has an IP, and I can ping its gateway...but using that connection to talk to the rest of the world is not yet functional. Basically, if I ping the cable modem's IP, attempt to SSH to it, etc. from the outside world, the packets come into that interface...and then attempt to go out the interface hooked to my DSL modem. Since I'm not sure if this is a route table issue or a PF issue, I'll give my full config here: The return traffic is following your default route which points out your DSL line ($ext_if). The ruleset is evaluated but your "pass out on $ext_if" rule specifies flags S/SA so the packet doesn't match. Read pf.conf(5) and look for the reply-to option. Also the pf faq would probably help you too (http://www.openbsd.org/faq/pf/pools.html). I had already read both of those, without much success. However, your comment prompted me to go poke around a bit more, especially with the reply-to option (I had missed that earlier), and I now can SSH in via the cable modem interface (no word yet on whether I can NAT out of it, I'll figure that out when I'm at a machine that would use that NAT). FYI for anyone reading this now or in an archived version, the only line I really needed was: pass in log on $ext_if2 reply-to ($ext_if2 $ext_gw2) inet proto tcp from any to ($ext_if2) \ port $tcp_ok flags S/SA keep state I'll reply with info on NAT once I get that operational, again for the benefit of anyone else who might be in my situation now or in the future. :-) Alex Kirk
Re: pf
On Sat, 9 Dec 2006, David B. wrote: > oh, and does anyone have any comments on Labrea? as a honeypot? it looks > pretty good, and it comes for openbsd, or is openbsd simply best left alone? > In use here for MANY years! Don't need an OBSD flavor. Lee
Re: Multiple Internet Connection Confusion
--- Quoting [EMAIL PROTECTED] on 2006/12/09 at 16:36 -0500: > I'm in the process of evaluating whether to transition from a DSL line > over to a cable modem, and until February I'll have both hooked up to > my OpenBSD 3.8 box, which acts as a mail/web/NAT server. > > I've got the new cable modem hooked up, it has an IP, and I can ping > its gateway...but using that connection to talk to the rest of the > world is not yet functional. Basically, if I ping the cable modem's IP, > attempt to SSH to it, etc. from the outside world, the packets come > into that interface...and then attempt to go out the interface hooked > to my DSL modem. Since I'm not sure if this is a route table issue or a > PF issue, I'll give my full config here: The return traffic is following your default route which points out your DSL line ($ext_if). The ruleset is evaluated but your "pass out on $ext_if" rule specifies flags S/SA so the packet doesn't match. Read pf.conf(5) and look for the reply-to option. Also the pf faq would probably help you too (http://www.openbsd.org/faq/pf/pools.html). .joel
Re: nat or routing problem?
On Sat, 09 Dec 2006 14:34:04 +0100, Mitja wrote: >Mikael Fridh wrote: >>> # pfctl -s all >>> TRANSLATION RULES: >>> nat on bge0 inet from 192.168.1.0/24 to any -> (bge0:0) >>> rdr pass on em1 inet proto tcp from any to any port = 5900 -> >>> 192.168.1.111 port 5900 >> >> If bge0 is your external interface that nat line now looks correct. >> If your internal hosts on the 192.168.1.0/24 net have default gateway >> 192.168.1.1 it should be nating properly. > >Yes and it is nating, but I am trying to set my source IP to >193.189.180.193 (em1). > Translating a bit from what I use should get you there: lan_ip="192.168.1.0/24" ext_if="bge0" fw_global-ip="193.189.180.193" nat on $ext_if inet from $lan_ip to any -> $fw_global_ip I discovered this by (1) needing it, and (2) reading man 5 pf.conf and checking the BNF grammar near the end, and (3) trying it. It saved me from half-bridging (messy) or renting a /32 (waste of $$). Without the quality of OpenBSD docs it may never have happened. >From the land "down under": Australia. Do we look from up over?
Multiple Internet Connection Confusion
I'm in the process of evaluating whether to transition from a DSL line
over to a cable modem, and until February I'll have both hooked up to
my OpenBSD 3.8 box, which acts as a mail/web/NAT server.
I've got the new cable modem hooked up, it has an IP, and I can ping
its gateway...but using that connection to talk to the rest of the
world is not yet functional. Basically, if I ping the cable modem's IP,
attempt to SSH to it, etc. from the outside world, the packets come
into that interface...and then attempt to go out the interface hooked
to my DSL modem. Since I'm not sure if this is a route table issue or a
PF issue, I'll give my full config here:
* dc0 -- Cable modem at 70.174.128.234, gateway = 70.174.128.1
* fxp0 -- DSL line at 66.92.172.3, gateway = 66.92.172.1
* xl0 -- Internal LAN (192.168.2.0/24)
schnarff.com:~$ route -n show
Routing tables
Internet:
DestinationGatewayFlagsRefs UseMtu Interface
default66.92.172.1UGS 0 344118 - fxp0
66.92.172/24 link#3 UC 00 - fxp0
66.92.172.100:90:1a:40:90:1c UHLc00 - fxp0
66.92.172.300:07:e9:82:98:4c UHLc0 9787 - lo0
66.92.172.50 127.0.0.1 UGHS00 33224 lo0
66.92.172.117 127.0.0.1 UGHS00 33224 lo0
66.92.172.156 127.0.0.1 UGHS02 33224 lo0
70.174.128/23 link#1 UC 00 - dc0
70.174.128.1 00:50:57:01:e6:69 UHLc0 24 - dc0
70.174.128.234 127.0.0.1 UGHS0 121 33224 lo0
127/8 127.0.0.1 UGRS01 33224 lo0
127.0.0.1 127.0.0.1 UH 0 4892 33224 lo0
192.168.2/24 link#2 UC 00 - xl0
192.168.2.500:10:dc:5c:8d:9e UHLc025989 - L xl0
192.168.2.255 link#2 UHLc0 98 - xl0
224/4 127.0.0.1 URS 00 33224 lo0
schnarff.com:~$ sudo cat /etc/pf.conf
# $OpenBSD: pf.conf,v 1.3 2001/11/16 22:53:24 dhartmei Exp $
#
# See pf.conf(5) for syntax and examples
# pass all packets in and out (these are the implicit first two rules)
ext_if=fxp0
ext_if2=dc0
ext_gw2="70.174.128.1"
int_if=xl0
tcp_ok = "{ 22, 25, 80, 143, 443, 993, 3306 }"
icmp_ok = "{ 8, 11 }"
table { 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12,
10.0.0.0/8, 0.0.0.0/8, \
224.0.0.0/4, 255.0.0.0/8 }
set block-policy drop
scrub out all no-df
scrub in all
altq on $ext_if priq bandwidth 1000Kb queue {std_out, tcp_ack_out}
queue std_out priq(default)
queue tcp_ack_out priority 6
nat on $ext_if from $int_if:network to any -> 66.92.172.3
# Default Block
block all
# Allow IPv6 traffic
pass in log quick on gif0 inet6 all
pass out log quick on gif0 inet6 all
pass in quick on fxp0 proto 41 all
pass out quick on fxp0 proto 41 all
# Allow Loopback Adapter
pass quick on lo0 all
# Disallow all illegal (i.e. spoofed) packets
block drop in log quick on $ext_if from to any
block drop out log quick on $ext_if from any to
# Allow inbound TCP/IP connections to specified ports
pass in log on $ext_if inet proto tcp from any to ($ext_if) \
port $tcp_ok flags S/SA keep state
pass in log on $ext_if2 inet proto tcp from any to ($ext_if2) \
port $tcp_ok flags S/SA keep state
# Allow inbound ICMP connections to specified ports
pass in log inet proto icmp all icmp-type $icmp_ok keep state
# Allow traffic within the local network
pass in on $int_if from $int_if:network to any keep state
# Allow firewall to connect to machines on local network
pass out on $int_if from any to $int_if:network keep state
# Allow outbound traffic
pass out log on $ext_if proto tcp all modulate state flags S/SA queue
tcp_ack_out
pass out log on $ext_if2 proto tcp all modulate state flags S/SA queue
tcp_ack_out
pass out log on $ext_if proto { udp, icmp, icmp6 } all keep state
pass out log on $ext_if2 proto { udp, icmp, icmp6 } all keep state
pass out on $ext_if2 route-to ($ext_if2 $ext_gw2) from $ext_if2 to any
It seems to me like the issue is probably the fact that my default
gateway is set to the interface hooked to the DSL line (fxp0), and that
I need appropriate PF or routing table magic to make requests that come
in on the cable modem use its gateway to get back out. Any ideas on how
I can do this?
Thanks,
Alex Kirk
Re: Bug in ksh // Improvement for tar ?
I am not a member of this mailing list, so I will copy and paste the comment of Philip Guenther here: "The 'cpio' format for pax (selected using "-x cpio") handles long file names in a portable way, as opposed to GNU tar's non-portable extension for handling file names longer than 100 bytes." Agreed, GNU tar has some serious problems managing long filenames (and not so long filenames, a short filename on a complex directory hierarchy is all required to break it.) I worked on a fix to gtar in 1998 (we called it "adjusting gtar to the POSIX 1003.1 (ustar) standard). There were very annoying problems sharing data between PCs with Linux, our HP-UX servers and Solaris workstations at that time. At that time, it was only required extracting the contents of some Solaris patches on a Linux machine to see what this problem means. Sadly, this patch is only applied to gtar releases when the maintainer of this application is Frangois Pinard. In this case, gtar is compatible with pax(1) on most operating systems. I am certainly against a patch that breaks the excellent compatibility between pax(1), cpio(1) and tar(1) on OpenBSD and these tools on other platforms. If gtar is incompatible... well... it is the decision of the maintainers of gtar, the patch is available. On the other hand, this problem happens when the filenames (including both the dirname and basename) are larger than one hundred characters. You mention a different issue, filenames larger than 255 characters. I am sure there is something that can be done to avoid so large filenames, like educating Windows users to choose better filenames. Cheers, Igor.
Re: pf
On Sat, Dec 09, 2006 at 02:43:38AM -0700, David B. wrote: > I've looked an man pf, and it's way too confusing; read pf.conf(5) instead. pf(4) isn't going to be very useful to you if you're not writing code who wants to interact with pf. > like go into a file, and have a command in the form of: 'drop all from > 216.87.0.0/17'? that file is usually /etc/pf.conf -- jared
Re: Proposal for uname / cvs
Hi Uwe. I see the advantages of your proposal but, as suggested in this thread and as you did, sed(1) can be very helpful in this matter. Just my opinion, but one of the best features in the BSD family of operating systems is that these operating systems are simple. The BSD operating systems do not have the overfeaturism we can find in other OSes these days (sadly, Linux and Windows are not the only examples right now). In my humble opinion, it is better translating the output of uname(1) to the format required by cvs by means of sed(1). What if developers choose to tag the branches in a different way? A small sed(1) expression to translate lowercase letters to uppercase letters and adding the required underlines is probably easier to read for someone with certain Unix knowledge than a non-standard option added to uname(1). And yes... I am against the "-z" and "-Z" options in tar(1), and the "-t" option in spell(1). The latter is even worse. These options can not only be replaced with a pipe to, we say, the compression tools (in the case of gzip(1) we have even more options available in this way) but the filter to remove TeX commands from the source in spell(1) is not in the base system (and should not be... except if TeX is part of the base system, and detex/delatex are not a part of any LaTeX distribution I am aware of, it must be downloaded from a CTAN). One of the goals of Unix (not only BSDs) was splitting complex tasks in smaller tasks that can be efficiently done by the operating system. Small tasks can be accomplished easily by these commands, larger ones (like the one you describe) can be accomplished by a subset of the commands, usually in one of the powerful scripting languages provided with the operating system. Overfeaturism addes superfluous complexity to the operating system. Just my opinion, Igor.
Re: Proposal for uname / cvs
On Sat, Dec 09, 2006 at 07:04:22PM +0800, Uwe Dippel wrote: > > Thanks Darren, but I'd written this myself faster than it took me to write > the message. I am still sure, that most users, including writers (and > updaters) of the FAQ would profit from this addition. The FAQ is full of > this `arch`, `uname` `machine` and whatnot stuff. > When you read through the cvs chapters, there is always the explicit > OpenBSD_V_n. > > There is a German proverb that expresses something like 'Why make it > simple, when can be done in a complicated way as well ?' rather than adding bloat to uname(1) (that other OSs aren't going to have), just write a simple function in the script that checks for existance of 'CVS/Tag' - assumes 'HEAD' if missing, otherwise reads it in and knocks the first character off. that's easy to write in a manner such that users of several OSs and various shells could just copy/paste and have it work for them too. -- jared
MSI US54SE supported by zyd(4)
Hi,
a friend of mine bought himself a MSI US54SE 11g USB Wlan stick.
I plugged it in and it gets recognized as zyd0.
Just wanted to tell you, so you could add it to list shown in the man
page.
I attached a dmesg. If you want more information, feel free to mail me.
(If you want to email me, please CC me as I'm not subscribed to misc@).
--
simon
OpenBSD 4.0-current (GENERIC) #1244: Wed Nov 29 09:22:42 MST 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium II ("GenuineIntel" 686-class, 512KB L2 cache) 299 MHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
real mem = 133591040 (130460K)
avail mem = 114376704 (111696K)
using 1661 buffers containing 6803456 bytes (6644K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(3a) BIOS, date 05/12/99, BIOS32 rev. 0 @ 0xfd820
apm at bios0 function 0x15 not configured
pcibios0 at bios0: rev 2.1 @ 0xfd880/0x800
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf9e30/96 (4 entries)
pcibios0: PCI Exclusive IRQs: 11
pcibios0: PCI Interrupt Router at 000:07:0 ("Intel 82371AB PIIX4 ISA" rev 0x00)
pcibios0: PCI bus #4 is the last bus
bios0: ROM list: 0xc/0xa000
acpi at mainbus0 not configured
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82443BX" rev 0x02
cbb0 at pci0 dev 2 function 0 "TI PCI1250 CardBus" rev 0x02: irq 11
cbb1 at pci0 dev 2 function 1 "TI PCI1250 CardBus" rev 0x02: irq 11
vga1 at pci0 dev 3 function 0 "Neomagic Magicgraph NM2160" rev 0x01
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x01
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:
wd0: 16-sector PIO, LBA, 11509MB, 23572080 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: SCSI0 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
uhci0 at pci0 dev 7 function 2 "Intel 82371AB USB" rev 0x01: irq 11
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x01: SMI
iic0 at piixpm0
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 1 device 0 cacheline 0x8, lattimer 0xb0
pcmcia0 at cardslot0
cardslot1 at cbb1 slot 1 flags 0
cardbus1 at cardslot1: bus 4 device 0 cacheline 0x8, lattimer 0xb0
pcmcia1 at cardslot1
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, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
sb0 at isa0 port 0x220/24 irq 5 drq 1: dsp v3.02
midi0 at sb0:
audio0 at sb0
opl0 at sb0: model OPL3
midi1 at opl0:
pcppi0 at isa0 port 0x61
midi2 at pcppi0:
spkr0 at pcppi0
lpt2 at isa0 port 0x3bc/4: polled
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
biomask efcd netmask efcd ttymask ffcf
pctr: 686-class user-level performance counters enabled
mtrr: Pentium Pro MTRR support
zyd0 at uhub0 port 1 configuration 1 interface 0
zyd0: ZyDAS USB2.0 WLAN, rev 2.00/48.10, addr 2
dkcsum: wd0 matches BIOS drive 0x80
root on wd0a
rootdev=0x0 rrootdev=0x300 rawdev=0x302
WARNING: / was not properly unmounted
WARNING: clock time much less than file system time
WARNING: using file system time
WARNING: CHECK AND RESET THE DATE!
firmware size=5120
loading firmware block: len=4096, addr=0xee00
loading firmware block: len=1024, addr=0xf600
regulatory domain 30
firmware base address=0xf7c9
zyd0: HMAC ZD1211B, FW 47.25, RF AL2230, PA 0, address 00:02:72:5b:7a:8a
setting MAC address to 00:02:72:5b:7a:8a
setting encryption type
zyd0: RX status indicated error (90)
retry intr: rate=0x19 addr=00:13:f7:1d:ab:d1 count=1 (0x1)
retry intr: rate=0x19 addr=00:13:f7:1d:ab:d1 count=1 (0x1)
retry intr: rate=0x19 addr=00:13:f7:1d:ab:d1 count=1 (0x1)
zyd0: xfer too short (length=8)
retry intr: rate=0x19 addr=00:13:f7:1d:ab:d1 count=1 (0x1)
zyd0: xfer too short (length=8)
zyd0: xfer too short (length=8)
retry intr: rate=0x1a addr=00:13:f7:1d:ab:d1 count=1 (0x1)
retry intr: rate=0x1a addr=00:13:f7:1d:ab:d1 count=1 (0x1)
zyd0: xfer too short (length=8)
zyd0: RX status indicated error (90)
retry intr: rate=0x3 addr=00:13:f7:1d:ab:d1 count=1 (0x1)
pgpjky1KcPoX7.pgp
Description: PGP signature
Re: OpenBSD - Vlans - CISCO
Jacob Yocom-Piatt a icrit : Original message Date: Sat, 09 Dec 2006 08:47:42 -0500 From: michel bidard <[EMAIL PROTECTED]> Subject: Re: OpenBSD - Vlans - CISCO To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], misc@openbsd.org michel bidard a icrit : Henning Brauer a icrit : it was amusing to see henning's initial reply, which contained the solution, go totally ignored by the OP: "so, let's see. vlan0 is in 10/8. vlan1 is in 10/8. vlan2 is in 10/8. vlan 2 are able to ping each other and to surf. However, the remaining vlans aren't working. I have tried to ping the ip's of the vlans but that doesn't work. no surprise with overlapping address space." please pay closer attention, michel. vlan0: flags=8843 mtu 1500 lladdr 00:48:54:80:d0:ec vlan: 2 priority: 0 parent interface: rl0 groups: vlan inet6 fe80::248:54ff:fe80:d0ec%vlan0 prefixlen 64 scopeid 0x8 inet 10.0.0.1 netmask 0xff00 broadcast 255.255.255.0 vlan1: flags=8843 mtu 1500 lladdr 00:48:54:80:d0:ec vlan: 3 priority: 0 parent interface: rl0 groups: vlan inet6 fe80::248:54ff:fe80:d0ec%vlan1 prefixlen 64 scopeid 0x9 inet 10.0.1.1 netmask 0xff00 broadcast 255.255.255.0 vlan2: flags=8843 mtu 1500 lladdr 00:48:54:80:d0:ec vlan: 4 priority: 0 parent interface: rl0 groups: vlan inet6 fe80::248:54ff:fe80:d0ec%vlan2 prefixlen 64 scopeid 0xa inet 10.0.2.1 netmask 0xff00 broadcast 10.255.255.255 vlan3: flags=8843 mtu 1500 lladdr 00:48:54:80:d0:ec vlan: 5 priority: 0 parent interface: rl0 groups: vlan inet6 fe80::248:54ff:fe80:d0ec%vlan3 prefixlen 64 scopeid 0xb inet 10.0.3.1 netmask 0xff00 broadcast 10.255.255.255 vlan4: flags=8843 mtu 1500 lladdr 00:48:54:80:d0:ec vlan: 6 priority: 0 parent interface: rl0 groups: vlan inet6 fe80::248:54ff:fe80:d0ec%vlan4 prefixlen 64 scopeid 0xc inet 10.0.4.1 netmask 0xff00 broadcast 10.255.255.255 vlan5: flags=8843 mtu 1500 lladdr 00:48:54:80:d0:ec vlan: 7 priority: 0 parent interface: rl0 groups: vlan inet6 fe80::248:54ff:fe80:d0ec%vlan5 prefixlen 64 scopeid 0xd inet 10.0.5.1 netmask 0xff00 broadcast 10.255.255.255 All right, thanks people ... it's working right now. You are right Jacob. Honestly, instead of looking at the output of ifconfig, I was looking at the file /etc/hostname. Sorry for that. Thanks again, Mik
Soekris box crashing... drops to ddb>
I'm assuming that this is a bad Soekris box, but I just would like
someone else to review the debug output, and maybe shed some light on
what happened to cause this kernel panic. This is a base install of
OpenBSD with root mounted with noatime, and an mfs mount for the /var
partition as this is running off of a CF card.
If anyone has an idea, please let me know, thanks!
--- dmesg and debug output ---
ddb> dmesg
OpenBSD 3.9 (GENERIC) #617: Thu Mar 2 02:26:48 MST 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by National Semi ("Geode by NSC"
586-class
) 267 MHz
cpu0: FPU,TSC,MSR,CX8,CMOV,MMX
cpu0: TSC disabled
real mem = 133799936 (130664K)
avail mem = 115367936 (112664K)
using 1658 buffers containing 6791168 bytes (6632K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 20/50/29, BIOS32 rev. 0 @ 0xf7840
pcibios0 at bios0: rev 2.0 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc8000/0x9000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Cyrix GXm PCI" rev 0x00
sis0 at pci0 dev 6 function 0 "NS DP83815 10/100" rev 0x00, DP83816A:
irq 10, a
ddress 00:00:24:c1:ce:7c
nsphyter0 at sis0 phy 0: DP83815 10/100 PHY, rev. 1
sis1 at pci0 dev 7 function 0 "NS DP83815 10/100" rev 0x00, DP83816A:
irq 10, a
ddress 00:00:24:c1:ce:7d
nsphyter1 at sis1 phy 0: DP83815 10/100 PHY, rev. 1
sis2 at pci0 dev 8 function 0 "NS DP83815 10/100" rev 0x00, DP83816A:
irq 10, a
ddress 00:00:24:c1:ce:7e
nsphyter2 at sis2 phy 0: DP83815 10/100 PHY, rev. 1
gscpcib0 at pci0 dev 18 function 0 "NS SC1100 ISA" rev 0x00
gpio0 at gscpcib0: 64 pins
"NS SC1100 SMI" rev 0x00 at pci0 dev 18 function 1 not configured
pciide0 at pci0 dev 18 function 2 "NS SCx200 IDE" rev 0x01: DMA, channel
0 wire
d to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 1:
wd0: 1-sector PIO, LBA, 976MB, 2000880 sectors
wd0(pciide0:0:1): using PIO mode 4
geodesc0 at pci0 dev 18 function 5 "NS SC1100 X-Bus" rev 0x00: iid 6
revision 3
wdstatus 0
ohci0 at pci0 dev 19 function 0 "Compaq USB OpenHost" rev 0x08: irq 11,
version
1.0, legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: Compaq OHCI root hub, rev 1.00/1.00, addr 1
uhub0: 3 ports with 3 removable, self powered
isa0 at gscpcib0
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
midi0 at pcppi0:
spkr0 at pcppi0
nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 9: GPIO VLM TMS
gpio1 at nsclpcsio0: 29 pins
gscsio0 at isa0 port 0x15c/2: SC1100 SIO rev 1:
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 fbe5 netmask ffe5 ttymask ffe7
pctr: no performance counters in CPU
dkcsum: wd0 matches BIOS drive 0x80
root on wd0a
rootdev=0x0 rrootdev=0x300 rawdev=0x302
cleaned vnode: type VBAD, usecount 0, writecount 0, holdcount 0,
tag VT_UFS, ino 44465, on dev 0, 0 flags 0x0, effnlink -1, nlink -1
mode 017, owner -1, group -1, size -1 not locked
panic: cleaned vnode isn't
Stopped at Debugger+0x4: leave
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb>
ddb> machine print examine x search set
write w delete d break dwatch
watch steps continuec until
nextmatch trace callps callout
showboothelphangman dmesg
ddb> all breaks extents malloc map object
pagepanic poolprocregisters uvmexp
watches
ddb> show panic
cleaned vnode isn't
ddb> No breakpoints set
ddb> ddb> Debugger(1646d722,d3c48f40,dab54c60,d3c01a5c,d3c00888) at
Debugger+0x
4
panic(d051d2e7,d3c01a5c,0,0,dab54c7c) at panic+0x63
getnewvnode(1,d0a57a00,d0a48e00,dab54c90) at getnewvnode+0x1e4
ffs_vget(d0a57a00,adb2,dab54d20,d3b9b5f8) at ffs_vget+0x50
ufs_lookup(dab54d58,30042,d3ac1b48,0,d05a6ea0) at ufs_lookup+0x756
VOP_LOOKUP(d3b9caf8,dab54e48,dab54e5c,20) at VOP_LOOKUP+0x2e
lookup(dab54e38,d3bfe800,400,dab54e50) at lookup+0x1d0
namei(dab54e38,dab54e88,d3ac1b48,0) at namei+0x180
sys_lstat(d3ac1b48,dab54f68,dab54f58,804b2000,8de) at sys_lstat+0x4a
syscall() at syscall+0x2ea
--- syscall (number 293) ---
0x86d6491:
ddb>PID PPID PGRPUID S FLAGS WAIT COMMAND
32522 17911 29125 0 3 0x4084 piperd sort
13724 17911 29125 0 3 0x4084 piperd xargs
*24091 17911 29125 0 7 0x4004 find
17911
Re: intel pro NICs and OBSD
Russell Fulton wrote: My question is are the em NIC drivers vulnerable to the recently announced intel NIC driver stack overflow bugs? I see that there are new FREEBSD em drivers available on the Intel site but no mention of Open BSD. What makes you think the FreeBSD drivers are vulnerable? The eEye advisory (http://research.eeye.com/html/advisories/published/AD20061207.html) doesn't mention FreeBSD. Also, the advisory says it's a strcpy problem, and there aren't any strcpys in the OpenBSD driver.
Re: OpenBSD - Vlans - CISCO
Original message >Date: Sat, 09 Dec 2006 08:47:42 -0500 >From: michel bidard <[EMAIL PROTECTED]> >Subject: Re: OpenBSD - Vlans - CISCO >To: [EMAIL PROTECTED] >Cc: [EMAIL PROTECTED], misc@openbsd.org > >michel bidard a icrit : >> Henning Brauer a icrit : it was amusing to see henning's initial reply, which contained the solution, go totally ignored by the OP: "so, let's see. vlan0 is in 10/8. vlan1 is in 10/8. vlan2 is in 10/8. > vlan 2 are able to ping each other and to surf. However, the remaining > vlans aren't working. I have tried to ping the ip's of the vlans but > that doesn't work. no surprise with overlapping address space." please pay closer attention, michel. >vlan0: flags=8843 mtu 1500 >lladdr 00:48:54:80:d0:ec >vlan: 2 priority: 0 parent interface: rl0 >groups: vlan >inet6 fe80::248:54ff:fe80:d0ec%vlan0 prefixlen 64 scopeid 0x8 >inet 10.0.0.1 netmask 0xff00 broadcast 255.255.255.0 >vlan1: flags=8843 mtu 1500 >lladdr 00:48:54:80:d0:ec >vlan: 3 priority: 0 parent interface: rl0 >groups: vlan >inet6 fe80::248:54ff:fe80:d0ec%vlan1 prefixlen 64 scopeid 0x9 >inet 10.0.1.1 netmask 0xff00 broadcast 255.255.255.0 >vlan2: flags=8843 mtu 1500 >lladdr 00:48:54:80:d0:ec >vlan: 4 priority: 0 parent interface: rl0 >groups: vlan >inet6 fe80::248:54ff:fe80:d0ec%vlan2 prefixlen 64 scopeid 0xa >inet 10.0.2.1 netmask 0xff00 broadcast 10.255.255.255 >vlan3: flags=8843 mtu 1500 >lladdr 00:48:54:80:d0:ec >vlan: 5 priority: 0 parent interface: rl0 >groups: vlan >inet6 fe80::248:54ff:fe80:d0ec%vlan3 prefixlen 64 scopeid 0xb >inet 10.0.3.1 netmask 0xff00 broadcast 10.255.255.255 >vlan4: flags=8843 mtu 1500 >lladdr 00:48:54:80:d0:ec >vlan: 6 priority: 0 parent interface: rl0 >groups: vlan >inet6 fe80::248:54ff:fe80:d0ec%vlan4 prefixlen 64 scopeid 0xc >inet 10.0.4.1 netmask 0xff00 broadcast 10.255.255.255 >vlan5: flags=8843 mtu 1500 >lladdr 00:48:54:80:d0:ec >vlan: 7 priority: 0 parent interface: rl0 >groups: vlan >inet6 fe80::248:54ff:fe80:d0ec%vlan5 prefixlen 64 scopeid 0xd >inet 10.0.5.1 netmask 0xff00 broadcast 10.255.255.255
Re: OpenBSD - Vlans - CISCO
Darren beat me to it... The hex value of "0xff00" = 255.0.0.0 in decimal. The hosts have a Class A subnet mask. I'm guessing that since you have a Class C broadcast address, you do not want to do this. Fix your mask on the vlan interfaces, then try again. On 12/9/06, Darren Spruell <[EMAIL PROTECTED]> wrote: On 12/9/06, michel bidard <[EMAIL PROTECTED]> wrote: > Ok ... here is the "ifconfig -A" ... > > # ifconfig -A [snip] > vlan0: flags=8843 mtu 1500 > lladdr 00:48:54:80:d0:ec > vlan: 2 priority: 0 parent interface: rl0 > groups: vlan > inet6 fe80::248:54ff:fe80:d0ec%vlan0 prefixlen 64 scopeid 0x8 > inet 10.0.0.1 netmask 0xff00 broadcast 255.255.255.0 > vlan1: flags=8843 mtu 1500 > lladdr 00:48:54:80:d0:ec > vlan: 3 priority: 0 parent interface: rl0 > groups: vlan > inet6 fe80::248:54ff:fe80:d0ec%vlan1 prefixlen 64 scopeid 0x9 > inet 10.0.1.1 netmask 0xff00 broadcast 255.255.255.0 [...] Fix your subnet mask. 0xff00 puts all of your vlan interfaces on the same subnet. And it looks like your broadcast was set to what you wanted your netmask to be. DS
Re: OpenBSD - Vlans - CISCO
On 2006/12/09 08:47, michel bidard wrote: > >3- This is what I have in my /etc/hostname.vlan0 > > 10.0.0.1 255.255.255.0 vlan 2 vlandev rl0 two things: 1. you missed "inet" at the start of the line with the addresses 2. you should either list "vlan 2 vlandev rl0" on a separate line, or include the broadcast address explicitly. > Ok ... here is the "ifconfig -A" ... thanks, that makes things a lot easier.
Re: OpenBSD - Vlans - CISCO
On 12/9/06, michel bidard <[EMAIL PROTECTED]> wrote: Ok ... here is the "ifconfig -A" ... # ifconfig -A [snip] vlan0: flags=8843 mtu 1500 lladdr 00:48:54:80:d0:ec vlan: 2 priority: 0 parent interface: rl0 groups: vlan inet6 fe80::248:54ff:fe80:d0ec%vlan0 prefixlen 64 scopeid 0x8 inet 10.0.0.1 netmask 0xff00 broadcast 255.255.255.0 vlan1: flags=8843 mtu 1500 lladdr 00:48:54:80:d0:ec vlan: 3 priority: 0 parent interface: rl0 groups: vlan inet6 fe80::248:54ff:fe80:d0ec%vlan1 prefixlen 64 scopeid 0x9 inet 10.0.1.1 netmask 0xff00 broadcast 255.255.255.0 [...] Fix your subnet mask. 0xff00 puts all of your vlan interfaces on the same subnet. And it looks like your broadcast was set to what you wanted your netmask to be. DS
Re: nat or routing problem?
Let's try this. It works, but the source IP is from bge0 my external interface (193.77.12.154). Then use address from em1 in nat rule for bge0. nat on bge0 inet from 192.168.1.0/24 to any -> (em1:0) No one said that translated source address must be the same as the address of nat external (outside) interface. Pozdrav, Aleksandar
Re: OpenBSD - Vlans - CISCO
michel bidard a icrit : Henning Brauer a icrit : * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2006-12-08 20:15]: you need on openbsd ifconfig vlan0 create ifconfig vlan0 vlan 2 vlandev rl0 up no. create is implicit. This is what I already did and tried for each port configured on the switch: 1- interface FastEthernet0/23 switchport trunk encapsulation dot1q switchport trunk allowed vlan 2-8 switchport mode trunk spanning-tree portfast no cdp enable 2- And then the ports for the vlans ... interface FastEthernet0/2 switchport access vlan 2 spanning-tree portfast no cdp enable I did the same for all the ports on the switch and then .. write memory. 3- This is what I have in my /etc/hostname.vlan0 10.0.0.1 255.255.255.0 vlan 2 vlandev rl0 And the same for all the vlans ... 4- Finally the config in /etc/pf.conf for natting ... nat on tun0 from 10.0.0.0/24 to any -> tun0 And again the same for all the vlans ... So I'm using a Class C mask ... maybe I should change that ? Is there something I should add in /etc/pf.conf ? Thank you very much for your answers, Mik Ok ... here is the "ifconfig -A" ... # ifconfig -A lo0: flags=8049 mtu 33224 groups: lo inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7 ste0: flags=8802 mtu 1500 lladdr 00:05:5d:07:9d:77 media: Ethernet autoselect (none) status: no carrier de0: flags=8863 mtu 1500 lladdr 00:00:e8:0c:38:ea media: Ethernet autoselect (10baseT) status: active inet6 fe80::200:e8ff:fe0c:38ea%de0 prefixlen 64 scopeid 0x2 rl0: flags=8943 mtu 1500 lladdr 00:48:54:80:d0:ec media: Ethernet autoselect (100baseTX full-duplex) status: active inet 192.168.1.253 netmask 0xff00 broadcast 192.168.1.255 inet6 fe80::248:54ff:fe80:d0ec%rl0 prefixlen 64 scopeid 0x3 pflog0: flags=141 mtu 33224 pfsync0: flags=0<> mtu 1460 enc0: flags=0<> mtu 1536 vlan0: flags=8843 mtu 1500 lladdr 00:48:54:80:d0:ec vlan: 2 priority: 0 parent interface: rl0 groups: vlan inet6 fe80::248:54ff:fe80:d0ec%vlan0 prefixlen 64 scopeid 0x8 inet 10.0.0.1 netmask 0xff00 broadcast 255.255.255.0 vlan1: flags=8843 mtu 1500 lladdr 00:48:54:80:d0:ec vlan: 3 priority: 0 parent interface: rl0 groups: vlan inet6 fe80::248:54ff:fe80:d0ec%vlan1 prefixlen 64 scopeid 0x9 inet 10.0.1.1 netmask 0xff00 broadcast 255.255.255.0 vlan2: flags=8843 mtu 1500 lladdr 00:48:54:80:d0:ec vlan: 4 priority: 0 parent interface: rl0 groups: vlan inet6 fe80::248:54ff:fe80:d0ec%vlan2 prefixlen 64 scopeid 0xa inet 10.0.2.1 netmask 0xff00 broadcast 10.255.255.255 vlan3: flags=8843 mtu 1500 lladdr 00:48:54:80:d0:ec vlan: 5 priority: 0 parent interface: rl0 groups: vlan inet6 fe80::248:54ff:fe80:d0ec%vlan3 prefixlen 64 scopeid 0xb inet 10.0.3.1 netmask 0xff00 broadcast 10.255.255.255 vlan4: flags=8843 mtu 1500 lladdr 00:48:54:80:d0:ec vlan: 6 priority: 0 parent interface: rl0 groups: vlan inet6 fe80::248:54ff:fe80:d0ec%vlan4 prefixlen 64 scopeid 0xc inet 10.0.4.1 netmask 0xff00 broadcast 10.255.255.255 vlan5: flags=8843 mtu 1500 lladdr 00:48:54:80:d0:ec vlan: 7 priority: 0 parent interface: rl0 groups: vlan inet6 fe80::248:54ff:fe80:d0ec%vlan5 prefixlen 64 scopeid 0xd inet 10.0.5.1 netmask 0xff00 broadcast 10.255.255.255 tun0: flags=8011 mtu 1492 groups: tun egress inet 65.94.2.93 --> 64.230.197.66 netmask 0x This is what I'm getting when I try to ping my own vlan from the firewall. As I said, the first vlan works but not the others: # pfctl -d pf disabled # ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: icmp_seq=0 ttl=255 time=1.016 ms 64 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=0.293 ms --- 10.0.0.1 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.293/0.654/1.016/0.362 ms # ping 10.0.1.1 PING 10.0.1.1 (10.0.1.1): 56 data bytes --- 10.0.1.1 ping statistics --- 6 packets transmitted, 0 packets received, 100.0% packet loss # pfctl -e pf enabled # ping 10.0.1.1 PING 10.0.1.1 (10.0.1.1): 56 data bytes ping: sendto: Host is down ping: wrote 10.0.1.1 64 chars, ret=-1 ping: sendto: Host is down ping: wrote 10.0.1.1 64 chars, ret=-1 --- 10.0.1.1 ping statistics --- 8 packets transmitted, 0 packets received, 100.0% packet loss Using a computer in vlan1, I tried to ping the gateway 10.0.1.1 ... but it doesn't work. Mik
Re: nat or routing problem?
Joel Goguen wrote: > On Fri, 08 Dec 2006 17:01:10 +0100, Mitja <[EMAIL PROTECTED]> wrote: >> Joel Goguen wrote: >>> On Fri, 08 Dec 2006 15:16:50 +0100, Mitja <[EMAIL PROTECTED]> wrote: >>> [snip] # pfctl -s all TRANSLATION RULES: nat on em1 inet from 192.168.1.0/24 to any -> (em1:0) >>> If em1 is only serving the one IP address, try changing em1:0 to em1 and >> see if that works. >> >> Checked that option. It is the same...not working. > Upon closer review, I realize that I'm an idiot for even suggesting it :) > > You have a route that goes from your internal LAN (192.168.1.0/24) to em1 > (193.189.180.193). > You have another route that goes from 192.168.1.0/24 to your closest ISP > interface (193.77.12.154). Correct. > When you set up NAT from LAN to em1 and then ping an address that the routing > table says is > accessible from bge0, you skip NAT since you're not going out on em1. You're > going out on bge0, > which means that no translation is done. I'm not sure if it's possible to > ping from LAN and have Correct again. This is the point of the problem. It is actually possible to set NAT or remove a route from LAN to bge0? > your source IP be that of em1, but I think you can just add a second NAT rule > to allow NAT on bge0. > Someone beat me with a cluestick if I'm wrong :) So you'd end up with your > NAT section being: > nat on em1 inet from 192.168.1.0/24 to any -> (em1:0) > nat on bge0 inet from 192.168.1.0/24 to any -> (bge0:0) Actually natting from bge0 works so I think it will also work your idea, but the source IP will not be that from em1. > Again, I don't know if that would actually work, but that's the only other > idea I have now. Let's try this. It works, but the source IP is from bge0 my external interface (193.77.12.154). Regards, Mitja
Re: nat or routing problem?
Mikael Fridh wrote: >> # pfctl -s all >> TRANSLATION RULES: >> nat on bge0 inet from 192.168.1.0/24 to any -> (bge0:0) >> rdr pass on em1 inet proto tcp from any to any port = 5900 -> >> 192.168.1.111 port 5900 > > If bge0 is your external interface that nat line now looks correct. > If your internal hosts on the 192.168.1.0/24 net have default gateway > 192.168.1.1 it should be nating properly. Yes and it is nating, but I am trying to set my source IP to 193.189.180.193 (em1). > Sounds like you want traffic to traverse: > 192.168.1.0/24 -> 192.168.1.1 -> 193.189.180.193 -> 193.77.12.154 -> 0/0 > I don't yet fully get what you're trying to accomplish. You got it right. That's what I am trying to accomplish: em0 em1 bge0 192.168.1.0/24 -> 192.168.1.1 -> 193.189.180.193 -> 193.77.12.154 -> 0/0 >> # tcpdump -i bge0 icmp >> tcpdump: listening on bge0, link-type EN10MB >> 14:49:16.377482 192.168.1.95 > 209.85.129.147: icmp: echo request >> 14:49:17.387437 192.168.1.95 > 209.85.129.147: icmp: echo request >> 14:49:18.397398 192.168.1.95 > 209.85.129.147: icmp: echo request >> >> icmp packets are going out, but it looks like NAT is not working (it >> should change my source IP address). > > That's because now you are dumping traffic on the "internal" interface > where the packets hasn't traversed the NAT yet. > The nat rule you made above has the internal interface where it should > have the external: >> nat on em1:0 from int_net to -> em1:0. bge0 is my external interface (it routes to 0/0). em1 is a network with a range of pubblic IPs. I am trying to use one of those IPs, to NAT traffic from. > # This is a proper simple nat example (that works): > ext_if="rl0" # (or whatever is your external interface) > nat on $ext_if inet from ! ($ext_if) -> ($ext_if:0) This means NAT from all interfaces but not from the external one. It is correct to use this statement? # pfctl -s all TRANSLATION RULES: nat on em1 inet from ! (em1) to any -> (em1:0) rdr pass on em1 inet proto tcp from any to any port = 5900 -> 192.168.1.111 port 5900 I tested with suggested configuration. tcpdump on my external (bge0) interface shows gateway private IP (192.168.1.1). So the packets did not traverse NAT yet. # ping -I 192.168.1.1 72.14.221.104 # tcpdump -i bge0 icmp tcpdump: listening on bge0, link-type EN10MB 14:29:50.077139 192.168.1.1 > 72.14.221.147: icmp: echo request 14:29:51.086365 192.168.1.1 > 72.14.221.147: icmp: echo request 14:29:52.096350 192.168.1.1 > 72.14.221.147: icmp: echo request Other ideas? Regards, Mitja
Re: Bug in ksh // Improvement for tar ?
On 12/9/06, Uwe Dippel <[EMAIL PROTECTED]> wrote: On Wed, 06 Dec 2006 03:15:44 -0700, Philip Guenther wrote: > If so, well, I hope you enjoy that universe you live in. Since someone informed me that ksh on Solaris processes the discussed expressions properly, I might feel tempted to evaluate David's opinion on the behaviour he'd prefer. Maybe your universe would shrink ? There appears to be a bug in your mail client that results in your replies taking other peoples' statements out of context. If you fixed that bug then you wouldn't have to spend so much energy fighting strawmen. Philip Guenther
Re: Bug in ksh // Improvement for tar ?
On Wed, 06 Dec 2006 03:15:44 -0700, Philip Guenther wrote: > If so, well, I hope you enjoy that universe you live in. Since someone informed me that ksh on Solaris processes the discussed expressions properly, I might feel tempted to evaluate David's opinion on the behaviour he'd prefer. Maybe your universe would shrink ? Uwe
Re: Proposal for uname / cvs
On Sat, 09 Dec 2006 02:46:34 -0700, Darrin Chandler wrote: > uname -sr | tr '[:lower:] .' '[:upper:]_' > > Somehow I think changing scripts is a better solution in this case. Or > copy the above into a new script named uname-cvs. ;) Thanks Darren, but I'd written this myself faster than it took me to write the message. I am still sure, that most users, including writers (and updaters) of the FAQ would profit from this addition. The FAQ is full of this `arch`, `uname` `machine` and whatnot stuff. When you read through the cvs chapters, there is always the explicit OpenBSD_V_n. There is a German proverb that expresses something like 'Why make it simple, when can be done in a complicated way as well ?' If what you propose finds entry into the system, fine. Because me and everyone else will have it readily available for the next system to install, and Copy&Paste a command from http://www.openbsd.org/anoncvs.html or the FAQ; to be used freely, immediately, and in scripts and without the need to additionally obtain or create this simplification. Uwe
Re: problem to chroot ftp users
On Fri, 08 Dec 2006 12:24:48 +0100, Sebastian Reitenbach wrote: > I have the same problem on two servers, OpenBSD 4.0 and 3.9. And I do it on both ... ... but differently: ftpd_flags="-DllUS" Their HOME is where I want to chroot them Their shell is /usr/bin/passwd (to change the passwd and prevent ssh) Their username is in /etc/ftpchroot The last is a binary switch for chroot / non-chroot (if I wanted). Test is straightforward: ftp and pwd which gives either $HOME or '/'. The latter is of cause chroot. > I prevent the ftp users from logging in via ssh via the ssh config, the > ftp users are all > in group _ftp, and this group is disallowed in /etc/ssh/sshd_config for > login, but I doubt > that this will interfere with the ftpd. Agreed, only it - at least reads - difficult. Does this help ? Uwe
Re: pf
On Saturday 09 December 2006 04:43, David B. wrote:
> I've looked an man pf, and it's way too confusing; I'm using smoothwall as
> a standalone firewall, and it pretty much works the way I want it to;
> however, I've found a reason to block a an IP range, particularly
> 216.87.0.0/17; is there an equivalent to an iptables command I can use to
> simply
> drop all traffic coming from that range?
>
> like go into a file, and have a command in the form of: 'drop all from
> 216.87.0.0/17'?
>
> oh, and does anyone have any comments on Labrea? as a honeypot? it looks
> pretty good, and it comes for openbsd, or is openbsd simply best left
> alone?
OBSD is for anyone who wants to use it. However, making changes to a computer
which is connected directly to the Internet can be a liability as you may
open yourself up to being hacked.
Having enough experience to at least be able to follow the instructions on how
to set up a firewall is so basic that without it you are "a sitting duck".
This is of course applicable to any O/S.
A good OBSD book to read is Absolute Openbsd by Lucas, No Starch Press.
BSD's begs to be worked on and used. Getting an understanding of pf is really
not that hard as things go. Following the steps in:
http://openbsd.org/faq/faq6.html
are really very simple.
OBSD is different than Linux. It's similar but different. All unix based O/S
have a certain number of things in common. But each have their own direction
and specific ways. Reading a book like the above is a good start for those
new to it and will get you the conceptual understanding needed.
A line in pf.conf along this line may stop traffic from an IP. I say may
because again not knowing what you are doing you can undo it elsewhere.
block in quick on $ext_if from 216.87.0.0/17 to any
Pf.conf is really very very flexible and able to handle any situation. But
again, you must have a clue of what you are doing. The best rule is probably
to know that when looking at a firewall, realize it does not know which side
is on the inside or outside. It simply looks at packets either coming into or
exiting.
You normally only filter on one interface, the external one.
Best practice is usually to start by blocking everything, and then opening
ports/addresses as needed. On that interface you can not only block all
inbound, but also all outbound. This will give you control on what your
computer and or network can do.
The above FAQ example uses a block all inbound and allow all outbound policy,
if I recall correctly. This is a good start. But sometimes it might be needed
to also control which external services can be accessed, at least by port.
(Since there are many workarounds by using commonly used ports like www, port
80.)
One of the really nice things about pf is that you can use variables. So you
can say friends="{ ip ip ip ip ip }" and then later say:
allow in on $ext_if from $friends to any
Or, if you have a LAN and want to let friends reach a computer (192.168.0.10
on a specific number of ports like 2000,2002,2012):
my_comp="192.168.0.10"
my_ports="{ 2000 2002 2012 }"
allow in on $ext_if from $friends to $my_comp port $my_ports
The variable names are of course whatever you choose them to be. Descriptive
names are usually best.
OpenBSD have pretty decent documentation. Just remember not to go past words
or definitions you don't understand. When an unknown term is used chase it
down on google, for example, before going on. Make sure it makes sense before
going on. This is key in learning anything. Otherwise you'll get stuck.
I had a friend that used to program in assembler (machine code) and just enter
the hex values into the computer. He could never really debug what he wrote,
but he could write a new program just like that. He said the key was that he
had complete understanding of all the commands and the environment. There
were nothing misunderstood.
--
Steve Szmidt
"To enjoy the right of political self-government, men must be
capable of personal self-government - the virtue of self-control.
A people without decency cannot be secure in its liberty.
From the Declaration Principles
Re: pf
* David B. wrote: > I've looked an man pf, and it's way too confusing; I'm using smoothwall as a > standalone firewall, and it pretty much works the way I want it to; however, > I've found a reason to block a an IP range, particularly 216.87.0.0/17; > is there an equivalent to an iptables command I can use to simply > drop all traffic coming from that range? so you think you will get help here after admitting to be to lazy to read the man page... ;) do read it, understand it, and apply the wisdom it contains. > > like go into a file, and have a command in the form of: 'drop all from > 216.87.0.0/17'? > > oh, and does anyone have any comments on Labrea? as a honeypot? it looks > pretty good, and it comes for openbsd, or is openbsd simply best left alone? > > thanks > > _ > Get the latest Windows Live Messenger 8.1 Beta version. Join now. > http://ideas.live.com
Re: pf
On Sat, Dec 09, 2006 at 02:43:38AM -0700, David B. wrote: > I've looked an man pf, and it's way too confusing; I'm using smoothwall as a > standalone firewall, and it pretty much works the way I want it to; however, > I've found a reason to block a an IP range, particularly 216.87.0.0/17; > is there an equivalent to an iptables command I can use to simply > drop all traffic coming from that range? > > like go into a file, and have a command in the form of: 'drop all from > 216.87.0.0/17'? The man pages you *probably* want are pf.conf(5) and pfctl(8). Also see http://www.openbsd.org/faq/pf/ The answer is yes, you can do that. Quick answer: echo 'block drop in from 216.87.0.0/17' | pfctl -mf - -n The above won't work until you read the man page for pfctl and remove one of the options. ;) There are better ways in the long run. Read about tables. -- Darrin Chandler| Phoenix BSD Users Group [EMAIL PROTECTED] | http://bsd.phoenix.az.us/ http://www.stilyagin.com/ |
Re: Proposal for uname / cvs
On Sat, Dec 09, 2006 at 05:23:19PM +0800, Uwe Dippel wrote: > I happen to have more and more systems that identify as > $ uname > OpenBSD > which is good. One way or another. > > One item that tends to go wrong here is cvs, where I have some scripts > doing cvs regularly, and I lose track of the version while > upgrading by re-using the scripts. > In cvs it is OPENBSD_4_0 as of now, while > $ uname -sr > OpenBSD 4.0 > , so that I can't use the otherwise very helpful utility (uname) out of > the box. > > I think the objective is clear: Instead of re-learning my cvs-commands or > modifying all those scripts, on a long run, it would be great to migrate > cvs to understand something like: > cvs -a -b [EMAIL PROTECTED]:/cvs -r `uname -sr`-d > or add an option to uname: > cvs -a -b [EMAIL PROTECTED]:/cvs -r `uname -c[vs]`-d > where > $ uname -c > returns > OpenBSD_4_0 > (or anything likewise). > > I am convinced that it will help a lot of people if we had a > placeholder for details of the underlying system when using cvs in a > straightforward manner [or cvs readily accepting the existing ones]. > > My excuses, if it exists. > > Uwe uname -sr | tr '[:lower:] .' '[:upper:]_' Somehow I think changing scripts is a better solution in this case. Or copy the above into a new script named uname-cvs. ;) -- Darrin Chandler| Phoenix BSD Users Group [EMAIL PROTECTED] | http://bsd.phoenix.az.us/ http://www.stilyagin.com/ |
pf
I've looked an man pf, and it's way too confusing; I'm using smoothwall as a standalone firewall, and it pretty much works the way I want it to; however, I've found a reason to block a an IP range, particularly 216.87.0.0/17; is there an equivalent to an iptables command I can use to simply drop all traffic coming from that range? like go into a file, and have a command in the form of: 'drop all from 216.87.0.0/17'? oh, and does anyone have any comments on Labrea? as a honeypot? it looks pretty good, and it comes for openbsd, or is openbsd simply best left alone? thanks _ Get the latest Windows Live Messenger 8.1 Beta version. Join now. http://ideas.live.com
Re: Proposal for uname / cvs
Are you afraid of unleasing the powers of sed(1)?
Proposal for uname / cvs
I happen to have more and more systems that identify as $ uname OpenBSD which is good. One way or another. One item that tends to go wrong here is cvs, where I have some scripts doing cvs regularly, and I lose track of the version while upgrading by re-using the scripts. In cvs it is OPENBSD_4_0 as of now, while $ uname -sr OpenBSD 4.0 , so that I can't use the otherwise very helpful utility (uname) out of the box. I think the objective is clear: Instead of re-learning my cvs-commands or modifying all those scripts, on a long run, it would be great to migrate cvs to understand something like: cvs -a -b [EMAIL PROTECTED]:/cvs -r `uname -sr`-d or add an option to uname: cvs -a -b [EMAIL PROTECTED]:/cvs -r `uname -c[vs]`-d where $ uname -c returns OpenBSD_4_0 (or anything likewise). I am convinced that it will help a lot of people if we had a placeholder for details of the underlying system when using cvs in a straightforward manner [or cvs readily accepting the existing ones]. My excuses, if it exists. Uwe
intel pro NICs and OBSD
Hi Folks, I have just joined the list again after an absence of some months. I have checked two different archives and found no reference to this issue, which surprises me. If it has been discussed please accept my apologies and give me a url to an archive with the relevant posts. My question is are the em NIC drivers vulnerable to the recently announced intel NIC driver stack overflow bugs? I see that there are new FREEBSD em drivers available on the Intel site but no mention of Open BSD. Cheers, Russell
Re: firefox + flash
Hi, just for completeness, I was saying in the openbsd newbies forum that I found the problem somewhere. I post it here just for your information... This has been happening for about everything that requires curl since it was upgraded to shared lib version 4. I believe it's because the package on FTP is version 7.15.4, but the one in ports is 7.15.5. Setting PKG_PATH to one of the ftp mirrors and FETCH_PACKAGES=Yes in your environment may take care of it. If not, try unsetting FETCH_PACKAGES. In any case I am going to wait until the release of the gnash binary... which I really really think should be included in o'bsd 4.1 :) Cheers, Pau 2006/12/8, Nick Guenther <[EMAIL PROTECTED]>: On 12/8/06, Vim Visual <[EMAIL PROTECTED]> wrote: > yes, I was aware of gnash... it sounds indeed very promising > > http://blogs.zdnet.com/Stewart/index.php?p=177 > > in principle they should have something working with youtube and > similar format videos by next summer, even if their main goal is much > more ambitious... > > thanks for the port hint... I'm installing it right now > > ps... something went wrong... > > Error: bad shared lib version /usr/local/lib/libcurl.so.3.4 (curl.>=4) > Fatal error > *** Error code 1 > > Stop in /usr/ports/www/gnash (line 1523 of > /usr/ports/infrastructure/mk/bsd.port.mk). > *** Error code 1 > > Stop in /usr/ports/www/gnash (line 1787 of > /usr/ports/infrastructure/mk/bsd.port.mk). > *** Error code 1 > > Stop in /usr/ports/www/gnash (line 1326 of > /usr/ports/infrastructure/mk/bsd.port.mk). > > > mmmh... now what? > > I start to understand why the yencourage you to only use the package > binaries and not the ports tree... > Are you running -CURRENT? I'm very interested in this port too, but I'm just going to wait 4 months for 4.1 to come out and for gnash to be in packages. -Nick
