Re: Install octeon on Qemu question(s)
> -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On > Behalf Of soko.tica > Sent: 09 September 2016 11:09 > To: misc > Subject: Install octeon on Qemu question(s) > > Hello, > > I am unsucesfully trying to install octeon on Qemu (I have managed to > install it on Ubiquity edge router Lite, but I need a qemu guest for > updating the router as needed). > > After much trouble, i have managed to alter miniroot for booting via > serial, if that was needed at all. > === > # vnconfig vnd0 > miniroot60.fs > # mount /dev/vnd0i /mnt > # ls -lh /mnt > total 16672 > -rw-r--r-- 1 root wheel 8.1M Jul 29 08:32 bsd.rd > # mkdir /mnt/etc > # echo 'set tty > com0'>/mnt/etc/boot.conf > # umount /mnt > # vnconfig -u vnd0 > === > I'm trying to install miniroot.fs according to the instructions from > /usr/local/share/doc/pkg-readmes/qemu, but I am always getting the errors > I > don't understand, e.g.: > === > $ qemu-system-mips64 -m 512 -serial stdio -hda octeon.img -hdb > miniroot60.fs -> > WARNING: Image format was not specified for 'miniroot60.fs' and probing > guessed raw. > Automatically detecting the format is dangerous for raw images, > write operations on block 0 will be restricted. > Specify the 'raw' format explicitly to remove the restrictions. > qemu-system-mips64: Could not load MIPS bios 'mips_bios.bin', and no > -kernel argument was specified > $ qemu-system-mips64 -m 512 -serial stdio -hda octeon.img format=raw - > hdb > miniroot60< > qemu-system-mips64: -hda octeon.img: drive with bus=0, unit=0 (index=0) > exists > === > > Please point to what should I do to accomplish it, I have already wasted > too much time on it. > > Thanks in advance. You can't emulate Octeon with QEMU. You also need more than that to emulate a MIPS64 board, it isn't x86.
Re: Problem with interface in promiscuous mode
On 3/20/2009 12:59 PM, (private) HKS wrote: On Wed, Mar 18, 2009 at 8:49 PM, Mail Lists wrote: On Wed, Mar 18, 2009 at 12:33 PM, (private) HKS wrote: On Wed, Mar 18, 2009 at 12:12 PM, Mail Lists wrote: Hello all, I'm have some issues setting up a bridge. We recently co-located a router in a data canter. The machine is a a soekris 5501 running openbsd4.4. The interfaces use the vr drivers. A machine belonging to someone in our cabinet is sending out about 10 packets/second of udp traffic on port 42. When I try to put my primary interface into bridge mode my machine locks up. I'm assuming this is because it can't handle the amount of packets flowing past the interface. Could anyone indicate whether or not this could indeed be the problem or if I'm completely off base here. The admin at the data center seems to think my box should be able to handle that amount of traffic just fine. The problem is not as pronounced when PF is disabled. The machine still crawls to a virtual standstill but I can at least do a ctrl-c on a tcpdump to stop it. The only way to get back at the command line when PF is enabled is to unplug the ethernet cable. When I DO a tcpdump I get millions of the following: 23:25:10.082217 00:0b:db:93:fb:70 01:00:5e:00:01:18 0800 60: 74.255.56.30.42> 224.0.1.24.42: udp 16 Cancelling the dump it reports for instance 20 packets received by filter 198000 packets dropped by kernel I can provide more details on the box if needed but I would just like some advice on what I can do about this. Is there a way to ignore all packets coming from a certain MAC address on layer 2? Is there anyway possible that this is 'legitimate' traffic? Is there any other way to create a filtering bridge without putting interfaces into promiscuous mode? Thanks for any advice, would really appreciate it. Steve This PR may be related: http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yes&numbers=6072 Try setting up a blackhole route for multicast addresses, see if that settles things down a bit. On another note, I'd be blown away to see a Soekris 5501 handle 100k packets/second without eating shit. Their NICs are Terrible (capital T), and the low-powered CPU is quickly overwhelmed by interrupts. -HKS Thanks, I will try this when I'm next able to drive down there as I've effectively cut myself off doing exactly what I shouldn't have. I'm not sure I get why routing these packets to a blackhole would be any easier on the CPU though. Would something like this work? route add IPOFOFFENDINGMACHINE 127.0.0.1 -blackhole Thanks for the advice! Oh, I missed the question you asked about why it would be easier. The PR explains some of that, but I've observed that when multicast traffic enters an interface in promiscuous mode, if net.inet.ip.forwarding=1, the host will attempt to route those packets. This can create a loop where traffic is repeatedly replicated until the box is paralyzed. I knocked down a couple 5501s in discovering this problem. I don't know that this is what you're seeing, but 100k multicast packets/sec from a single host sounds an awful lot like a traffic replication loop. -HKS OK, I understand. If that were the case I should be able to turn off forwarding and the bulk of the problem would disappear? I tried this and this wasn't the case. I tried the blackhole too - route add IP 127.0.0.1 -blackhole and it didn't make any apparent difference. I guess that leads me to believe that these packets are all original packets coming from this IP? What exactly does the OS do when it receives a multicast packet? Does the packet get passed all the way down the network stack and back out? (when in promiscuous mode I suppose). If so why can't you simply tell the stack not to do this for specific packets? I'm sure there's a real reason why this isn't possible I'm just trying to get a grasp on what's hapenning. Anyways, thanks for all the help, really appreciate it. I think I've pretty much given up on this situation and am going to approach this on a physical level (move to a different cabinet probably). I'm mostly pursuing this for my own edification I suppose. Thanks, Steve
Re: Problem with interface in promiscuous mode
On Thu, Mar 19, 2009 at 4:45 AM, Stuart Henderson wrote: > On 2009/03/18 20:45, Mail Lists wrote: >> >> Is there anyway possible that this is 'legitimate' traffic? >> > >> > damned unlikely. I think I'd be looking at a layer-1 solution if the >> > box can't be made to behave... >> >> Sorry, I don't quite know what you mean by a layer one solution short >> of moving the box to a different network. B I'm a little new to this >> sort of stuff. > > layer 1 = physical -> pulling the cable :-) > >> Thanks for the help - I'll probably end up insisting he move us to a >> different cabinet or a different VLAN if he can't contact the owner of >> the server sending the traffic. The funny thing is that they have >> VLAN's set up for separate cabinets but don't seem to be able to setup >> individual customers with their own vlan. > > They might not want to segregate customers as a matter of course, it's > a fair bit of work to setup in the first place (and extra IP address use > unless you use filtering bridges), and if they're a very large operation, > the maximum of 4096 VLANs might make things excessively complicated if > they do this for everyone. But I don't think you should accept being > DOS'd by someone in the same rack.. > > Did you see what sort of packets they are? Broadcast or multicast or > something? I'm wondering why they would even hit your machine otherwise. > > They are multicast packets that are going to 224.0.1.24 which according to this: http://www.iana.org/assignments/multicast-addresses/ is for microsoft-ds. A snippet of the UDP stream looks like this: 8.J.8.J.8.J.8.J.8 .J.8.J.8.J.8.J.8.J.8. J.8.J.8.J I have not a clue that that means. Is there perhaps something in this that lets me tell the administrator of the offending box what's going on since the network admin seems unwilling or unable to to so? Anyways -this isn't really openbsd related any longer. Apologies if this is turning into noise. Thanks for all the help!
Problem with interface in promiscuous mode
Hello all, I'm have some issues setting up a bridge. We recently co-located a router in a data canter. The machine is a a soekris 5501 running openbsd4.4. The interfaces use the vr drivers. A machine belonging to someone in our cabinet is sending out about 10 packets/second of udp traffic on port 42. When I try to put my primary interface into bridge mode my machine locks up. I'm assuming this is because it can't handle the amount of packets flowing past the interface. Could anyone indicate whether or not this could indeed be the problem or if I'm completely off base here. The admin at the data center seems to think my box should be able to handle that amount of traffic just fine. The problem is not as pronounced when PF is disabled. The machine still crawls to a virtual standstill but I can at least do a ctrl-c on a tcpdump to stop it. The only way to get back at the command line when PF is enabled is to unplug the ethernet cable. When I DO a tcpdump I get millions of the following: 23:25:10.082217 00:0b:db:93:fb:70 01:00:5e:00:01:18 0800 60: 74.255.56.30.42 > 224.0.1.24.42: udp 16 Cancelling the dump it reports for instance 20 packets received by filter 198000 packets dropped by kernel I can provide more details on the box if needed but I would just like some advice on what I can do about this. Is there a way to ignore all packets coming from a certain MAC address on layer 2? Is there anyway possible that this is 'legitimate' traffic? Is there any other way to create a filtering bridge without putting interfaces into promiscuous mode? Thanks for any advice, would really appreciate it. Steve
VPN Failover
Hello List, I'm having some issues with IPSec VPN tunnels. Here is what I'm trying to do: I have a VPN 'server' with 2 internet connections (IP1, IP2) I have several remote locations which connect to the VPN server. When IP1 goes down on the VPN server I want the remote locations to negotiate the tunnel with IP2 What is the best way to accomplish this? I have tried a couple of different things, none successful. My ipsec.conf on the server looks like this: /#Remote Location 1/ / ike passive esp from 10.110.39.0/24 to 10.115.10.0 peer main auth hmac-sha1 enc 3des quick auth hmac-sha1 enc 3des group none psk "psk" #Remote Location 2 ////ike passive esp from 10.110.39.0/24 to 10.115.20.0 peer main auth hmac-sha1 enc 3des quick auth hmac-sha1 enc 3des group none psk "psk" /My ipsec.conf on one of the remote location machines looks like this: /#Main Office/ /ike esp from 10.115.20.0 to 10.110.39.0/24 peer main auth hmac-sha1 enc 3des quick auth hmac-sha1 enc 3des group none psk "psk" #Main Office Backup //ike esp from 10.115.20.0 to 10.110.39.0/24 peer main auth hmac-sha1 enc 3des quick auth hmac-sha1 enc 3des group none psk "psk" /This doesn't work. When I comment out the 'Backup' tunnel on the remote location machine the IP1 tunnel comes up just fine. When I try un-commenting it neither of the tunnels come up. I'm pretty sure that this is not SUPPOSED to work as the subnets are the same for both tunnels. I have played around with the various "ike [mode]" parameters, substituting dynamic,passive, etc in every possible combination. I have configured isakmpd to listen on both interfaces on the main office machine. ie. /[general] Listen-on=IP1,IP2 /I have also tried to just change the default routes on the main office machine and restart isakmpd. Can anyone recommend a way to do VPN failover in this manner? Is it possible to use the DPD of dynamic mode to somehow make isakmpd negotiate a backup tunnel when the main tunnel goes down? Thanks so much, Steve / /
Re: cable moden - bridge - dhcp problem.
Jesus Sanchez wrote: Hi, I'm using 4.2 with no problem for anything but one thing. I have a box with 2 NICs. One have a ip get with dhcp from the cable moden, and everything goes right but at the other side, if I wake up a bridge as described in brconfig manpage and ifconfig manpage (following the FAQ) I can't get a ip with dhcp from the other computer connected at the other side of the bridge. I'm forgetting something but I did not found it on man pages. What can I do? Thanks for all. I don't think you want to bridge (Unless that's really what you want) You want to configure the internal NIC with a reserved address (192.168.2.1 for example). You then have to make sure that dhcpd is serving addresses on that interface. (man dhcpd) Then you have to setup NAT (network address translation) That's covered in the PF Howto: http://openbsd.org/faq/pf/nat.html
Re: PF Rules
David Newman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/7/07 8:59 AM, Stuart Henderson wrote:
On 2007/09/07 08:41, David Newman wrote:
1. I believe "keep state" is still needed when using queuing. The
pf.conf manpage says it must be specified explicitly to apply options to
a rule.
Only for state-related options (max-src-conn-rate and so);
queue is separate (and may also be used where you don't keep state).
Ah, ok -- thanks.
2. The "queue (class1, class2)" syntax assumes class1 TOS == 0 and
class2 TOS != 0.
look for pqid in sys/net/pf.c or just look at QUEUEING in pf.conf(5):
Packets can be assigned to queues based on filter rules by using the
queue keyword. Normally only one queue is specified; when a second one
is specified it will instead be used for packets which have a TOS of
lowdelay and for TCP ACKs with no data payload.
Again, thanks. The OP's pass out rule puts at least some VoIP traffic
into the first queue:
pass out log quick on $ext_if proto {tcp,udp} from $VOIP_SERVERS to any
port $VOIP_PORTS queue (voip_out, tos_lowdelay_out)
We don't know how voip_out differs from tos_lowdelay_out
I'm not sure what you mean but I think they differ in that tos_lowdelay
out has +1 higher priority
, but my
understanding is that voip_out will only go into that queue if its TOS
value is 0. True?
My understanding is that any packets marked TOS lowdelay (by my VoIP
server for instance. ie, rtp packetes) will get pushed into the
tos_lowdelay_out queue.
Doing things the way Stuart said in his first post (queuing the inbound
packets) seems to work.
One question, though, because I'm not sure:
Once you have created a default queue - do all packets go into that
queue REGARDLESS of whether or not they match a rule in which they're
assigned to a specific queue?
PF Rules
Hello everyone,
I have what might amount to a silly question.
I'm attempting to set up pf for a voip system. In order to prioritize
VoIP packets I have this queue:
altq on $ext_if priq bandwidth 1.4Mb queue {std_out, voip_out,
tos_lowdelay_out}
queue std_out priq(default)
queue voip_out priority 11
queue tos_lowdelay_out priority 12
This normally works very well. I'm planning to allow all inbound
traffic to my VOIP Server like this:
pass in quick log on $ext_if proto {tcp,udp} from any to $VOIP_SERVERS
port $VOIP_PORTS
This rule works. I then wish to pass all OUTGOING traffic back out
through the queue, like this:
pass out log quick on $ext_if proto {tcp,udp} from $VOIP_SERVERS to any
port $VOIP_PORTS queue (voip_out, tos_lowdelay_out)
Here's is where my problem arises. I'm assuming that when the packet
comes in through the first rule it creates a state entry. That way the
outgoing rule is never applied and packets never enter the voip_out
queue. They all just go out through the std_out queue. I could of course
append the "no state" option to the first rule but considering the
amount of small packets voip produces it would be better to have state
entries created.
Does anyone know of a simple way to handle this? Is the no state option
the best (or only) way to ensure the outgoing rule is applied? Maybe I'm
just overlooking something absurdly silly.
Thanks!
Steve Glaus
Re: Long WEP key
Darren Spruell wrote: On 3/30/07, mail-lists <[EMAIL PROTECTED]> wrote: > Openvpn Unless I'm mistaken Openvpn is not equal to Ipsec Depends on what you mean by "equal to" - OpenVPN makes use of SSL/TLS rather than the transport protocols IPsec employs, but they are of similar equivalence in terms of security. OpenVPN does make use of strong cryptographic primitives, and typically is considered easier to set up than IPsec (although the newer ipsec.conf support in OpenBSD seems to have turned the tables around on that one.) I meant 'equal to' in the most superficial sense :). Ipsec is easy enough to set up on the OpenBSD end (using ipsec.conf), but I haven't been able to find an ipsec client that doesn't make you want to slit your wrists in the windows world. I've tried greenbow? but there's no way an end user could configure even that. Plus it's not 'free' software. Anyways - I'm just slaking my own curiosity as to what solutions other people have come up with. I haven't really visited this issue in awhile, maybe I'll take another look at openVPN. Thanks! http://www.sans.org/reading_room/whitepapers/vpns/1459.php DS
Re: Long WEP key
Openvpn Unless I'm mistaken Openvpn is not equal to Ipsec
Re: Long WEP key
Why bother adding WPA when you can turn many wlan cards into AP-mode and have an OpenBSD box serve wireless computers with IPsec capabilities. You then have an AP with many more capabilities than any linksys/netgear/whatever AP. This would be great. However, I've yet to find an IPsec client that's 'easy' to set up.. ie. an end user can do it. Perhaps you know of a good way to solve this issue? I'd love to hear it!
Re: maxcluster errors
On 3/26/07, Stuart Henderson <[EMAIL PROTECTED]> wrote:
>
> On 2007/03/26 16:41, mail-lists wrote:
> > I'm noticing that when I do a 'top' my interrupt usage stays at aroudn
> > 30%. Again - I have to think that this is a hardware limitation on the
> > soekris.
>
> soekris is not a fast i/o machine, it is a low-power machine.
>
> > altq on $wii_if priq bandwidth 40Mb queue {wii_std, wii_voip}
>
> it definitely won't push 40Mb/s of data (nor will 802.11 wireless,
> for that matter).
No, I don't imagine it would. Those queues aren't actually being used
though. I'd say maybe 10Mb/s at most right now
> pass in quick on $wii_if from $wireless_lan to $VOIP_SERVERS keep state
> > pass in quick on $int_if from $VOIP_SERVERS to $wireless_lan keep state
> > pass in quick on $ext_if from $VOIP_GATEWAYS to $VOIP_SERVERS
>
> small packets too, that won't help.
Yeah, I was afraid of that.
However, another soekris I have seems to do fine with ~ 30Mb/s peaks, also
handling a fair amount of VOIP traffic.
The difference is that it's not serving as a wireless AP
Re: maxcluster errors
One other thing: I have discovered that when I'm not connected to the wireless network with my laptop (which has a belkin pcmcia card), the soekris seems to stay up indefinitely (mbufs keep accumulating though). This sort of leads me to believe I have some sort of setting incorrect pertaining to my wireless interface. Also, I see a LOT (over 50%) of crc errors on the workstations connected wirelessly. Not transmitting but receiving. my ral0 interface is configured thusly: ral0: flags=8843 mtu 1500 lladdr 00:08:a1:a7:8f:d7 media: IEEE802.11 autoselect mode 11g hostap status: active ieee80211: nwid ACG_COMM chan 2 bssid 00:08:a1:a7:8f:d7 nwkey xxx 100dBm inet 192.168.5.1 netmask 0xff00 broadcast 192.168.5.255 inet6 fe80::208:a1ff:fea7:8fd7%ral0 prefixlen 64 scopeid 0x4
Re: maxcluster errors
Thanks for your reply.
I'm really about at my wits end with this. I think I'm going add a
generic wireless router to my switch and have everyone access through
that. Is it possible that there's something wrong with the ral driver?
I've heard though that this is a very reliable driver under openbsd.
I'm noticing that when I do a 'top' my interrupt usage stays at aroudn
30%. Again - I have to think that this is a hardware limitation on the
soekris.
Here is my pf.conf
ext_if="sis0"
dmz_if="sis1"
int_if="sis2"
wii_if="ral0"
wired_lan= "192.168.4.0/24"
wireless_lan="192.168.5.0/24"
VOIP_PORTS = "{4520, 4569, 5060, 5061, 5062, 1:6}"
VOIP_SERVERS = "{IP OF VOIP SERVER}"
ADMIN_PORTS = "{80,22,2812, 4445}"
ADMIN_HOSTS = "{A BUNCH OF IPS}"
VOIP_GATEWAYS = "{74.52.15.138}"
OUTGOING_PORTS = "{80, 53}"
set block-policy return
#scrub in all
#scrub out all
altq on $ext_if priq bandwidth 500Kb queue {std_out, voip_out}
queue std_out priq(default)
queue voip_out priority 10
altq on $wii_if priq bandwidth 40Mb queue {wii_std, wii_voip}
queue wii_std priq(default)
queue wii_voip priority 10
set skip on {lo0 sis1 ral0 sis2 }
###NAT
nat on $ext_if from $wired_lan to any -> ($ext_if)
nat on $ext_if from $wireless_lan to any -> ($ext_if)
block log all
pass quick on $ext_if proto tcp from $ADMIN_HOSTS to any port 22 keep state
pass quick on $ext_if proto {tcp udp} from $ADMIN_HOSTS to any port
$ADMIN_PORTS keep state
pass quick on $ext_if proto {tcp udp} from $ADMIN_HOSTS to any port
$VOIP_PORTS keep state
pass quick on $ext_if proto {icmp} from $ADMIN_HOSTS to any
pass in quick on $wii_if from $wireless_lan to $VOIP_SERVERS keep state
pass in quick on $int_if from $VOIP_SERVERS to $wireless_lan keep state
pass in quick on $ext_if from $VOIP_GATEWAYS to $VOIP_SERVERS
pass quick on $int_if from any to any
pass out quick on $ext_if from any to any keep state
pass out quick from $VOIP_SERVERS to any keep state
pass out quick on {$ext_if} from $VOIP_SERVERS to any keep state
#
Here is my netstat -m out:
9720 mbufs in use:
9670 mbufs allocated to data
47 mbufs allocated to packet headers
3 mbufs allocated to socket names and addresses
9661/9674/3 mbuf clusters in use (current/peak/max)
21784 Kbytes allocated to network (-92% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
Re: maxcluster errors
Hello again, Unfortunately the 'quick' keyword in my pf.conf file didn't seem to fix the issue. The situation lies as such: I can increase mbufs indefinitely (until I run out of memory I suppose). When I disable pf (pfctl -d) the mbufs are immediately released and the usage count drops to ~ 200. As soon as I enable pf the usage count goes up again until it finally maxes out. This is the hardware I'm using: soekris net4801 3x sis ethernet 1x ral wireless ethernet. Does anyone know of any reason that this might be happening? I was suspecting that the soekris isn't fast enough to handle the packet filtering but that seems a little unlikely. There are about 100 rules all with keep state and all using the quick keyword. I can post a copy of my pf.conf if anyone thinks that might help
Re: maxcluster errors
Well, I think I might have discovered the cause of this. I noticed that when I disabled pf that all the mbufs were released immediately. I then configured my pf rules from the wireless network with the 'quick' keyword and the current buffer count doesn't seem to be rising very much any more - 3 or 4 over the course of a minute while sending 2 simultaneous ping floods to hosts on the wireless network. Before I would see the count go up by about 200 every minute. Is this just an inability of my hardware (soekris net4801) to handle pf? or is it in any way connected to the fact that it's going out over a wireless link? Thanks!
maxcluster errors
I've looked over this mailing list and noticed some questions about maxclusters I'm running a wireless ap and for some reason the wireless link seems to die on me intermittently Looking at /var/log/messages I notice errors referring to maxclusters. I then increased my maxclusters to 65000 and haven't had it going out yet (I'm running very aggressive ping tests from a host connected to a local WIRED network) However, when I do a netstat -m I notice mbuf clusters goes up and up and never comes back down. Is this what's supposed to happen? What happens when it maxes out again - I imagine I lose my wireless link? I'm running openbsd 4.0 Sorry about the lack of detail in this post - unfortunately (much to my emberassment) this is running in production and I need to babysit this thing. Any suggestions would be appreciated Thanks!
acx on soekris with openbsd 4.0 - Re-post
Sorry, I've asked this before and didn't get a response.. am I asking
this incorrectly - or in the wrong place?
Hello all,
I'm trying to get a mini pci card working on OpenBSD 4.0. I ripped this
card out of a dlink router that we weren't using. From what I understand
it's supposed to use the acx driver.
When I try to do an 'ifconfig acx0 up' it gives me 'Device no configured'
I'm assuming that this is because OpenBSD didn't detect the card. I
scoured the dmesg output but didn't find anything that looks like a
wireless card. I'm not overly familiar with the way openbsd handles
hardware so is there a way to 'force' openbsd to find the card?
I've already installed the firmware as specified in the man-page, but I
don't know where to go from here..
I have a feeling I'm SOL with this card
Thanks!
I've appended the dmesg output in case there's something I'm missing:
OpenBSD 4.0 (GENERIC) #1107: Sat Sep 16 19:15:58 MDT 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by Nataonal Semi ("Geode by NSC"
586-class) 267 MHz
cpu0: FPU,TSC,MSR,CX8,CMOV,MMX
cpu0: TSC disabled
real mem = 268005376 (261724K)
avail mem = 236724224 (231176K)
using 3297 buffers containing 13504512 bytes (13188K) 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, address 00:00:24:c8:01:a0
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, address 00:00:24:c8:01:a1
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, address 00:00:24:c8:01:a2
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 \M-[C1100 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 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 1-sector PIO, LBA, 1946MB, 3985632 sectors
wd0(pciide0:0:0): 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
syncing disks... done
OpenBSD 4.0 (GENERIC) #1107: Sat Sep 16 19:15:58 MDT 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 = 268005376 (261724K)
avail mem = 236724224 (231176K)
using 3297 buffers containing 13504512 bytes (13188K) 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, address 00:00:24:c8:01:a0
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, address 00:00:24:c8:01:a1
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, address 00:00:24:c8:01:a2
nsphyter2 at sis2 phy 0: DP83815 10/1p0 PHY, rev. 1
gscpcib0 at pci0 dev 18 function 0 "NS SC1100 ISA" rev 0x00
gpio
acx on soekris with openbsd 4.0
Hello all,
I'm trying to get a mini pci card working on OpenBSD 4.0. I ripped this
card out of a dlink router that we weren't using. From what I understand
it's supposed to use the acx driver.
When I try to do an 'ifconfig acx0 up' it gives me 'Device no configured'
I'm assuming that this is because OpenBSD didn't detect the card. I
scoured the dmesg output but didn't find anything that looks like a
wireless card. I'm not overly familiar with the way openbsd handles
hardware so is there a way to 'force' openbsd to find the card?
I've already installed the firmware as specified in the man-page, but I
don't know where to go from here..
I have a feeling I'm SOL with this card
Thanks!
I've appended the dmesg output in case there's something I'm missing:
OpenBSD 4.0 (GENERIC) #1107: Sat Sep 16 19:15:58 MDT 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by Nataonal Semi ("Geode by NSC"
586-class) 267 MHz
cpu0: FPU,TSC,MSR,CX8,CMOV,MMX
cpu0: TSC disabled
real mem = 268005376 (261724K)
avail mem = 236724224 (231176K)
using 3297 buffers containing 13504512 bytes (13188K) 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, address 00:00:24:c8:01:a0
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, address 00:00:24:c8:01:a1
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, address 00:00:24:c8:01:a2
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 \M-[C1100 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 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 1-sector PIO, LBA, 1946MB, 3985632 sectors
wd0(pciide0:0:0): 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
syncing disks... done
OpenBSD 4.0 (GENERIC) #1107: Sat Sep 16 19:15:58 MDT 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 = 268005376 (261724K)
avail mem = 236724224 (231176K)
using 3297 buffers containing 13504512 bytes (13188K) 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, address 00:00:24:c8:01:a0
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, address 00:00:24:c8:01:a1
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, address 00:00:24:c8:01:a2
nsphyter2 at sis2 phy 0: DP83815 10/1p0 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 confi
Re: OpenBSD wierdness
Jon Radel wrote: Duplex mismatch between OpenBSD router NICs and switch ports plugged into? Can make a horrible mess of packet loss rates and throughput. Also see what OpenBSD has to say about NIC error rates. --Jon Radel Steve Glaus wrote: Looking at my dmesg's I noticed the following lines: dc0: failed to force tx and rx to idle state dc2: failed to force tx and rx to idle state Could this have anything to do with it? I'm not really worried about the outside interfaces though... looking at ifconfig I see: internal LAN interface--- sis0: flags=8943 mtu 1500 media: Ethernet autoselect(100baseTX full-duplex) external ISP1 interface dc2: flags=8902Another (interesting?) thing is that when I manually configure the mediaoptions (ifconfig sis0 media 100baseTX mediaopt full-duplex ) The iperf test shows ~ 200Kbit/s !! I'm starting to have the feeling that this is just a bad adapter.. Thanks!
OpenBSD wierdness
Hi everyone, I'm at my wits end here with this and I don't know who to ask.. For about a week now my OpenBSD router has been acting up in the strangest ways. Route's dissapear, ethernet speeds crawl to a halt and other wierdness.. I'm about to wipe this box clean and start from scratch but I would really like to try and figure out what's going on first.. I don't know if it helps if I describe some of the symptoms.. I'll try and draw a diagram first if I may... ISP1ISP2 | | | | | | dc1--- dc2 | obsd3.9 | | | |-sis0--dc0--| || ||-DMZ | -10.110.38/24 Interface dc0 is bridged with interfaces dc1&dc2 Firstly, and perhaps most alarming When I run the iperf utitlity between the router and a system on the network I get about 3Mb/s throughput. When I run it between a system on the DMZ and the router - the same thing. I tried disabling pf and get the same results. Running iperf between the boxes on the LAN I get proper results - of course. My only ideas are 1) failing NIC 2) NIC Drivers?? 3) routing issues? The second symptom is that periodically my vpn will drop throughout the day - corresponding with this (I think) whenever I run a continual ping to somewhere(anywhere) on the internet it will work fine any number of times but then it'll stop - sit there and hang for 10 seconds perhaps and then start back up IF it is a failing NIC - could one bad NIC make the others act up (interrupts?) I'm not sure I made myself very clear on this - I'm having a very hard time tracking this down. Any ideas or suggestions on investigation this would be appreciated. Any beautifully simple solutions even more so :) I REALLY want to figure out what's going on instead of simply wiping the box clean. Think of all the knowledge value :| Thanks a lot... Steve Glaus
802.11e
Hello, Does anyone know anything of when 802.11e might be supported in any of the wireless drivers? I've searched around and can't really find anything about it other than a review Theo gave in 2003 mentioning that they don't plan to focus on it. Perhaps someone is familiar with a radio that does 802.11e in hardware? We have a client that would like to do VOIP from wireless workstations and we would like to use openbsd as the access point. Thanks for any advice/help
Re: for the OpenBSD Asterisk VoIP admins
Stuart Henderson wrote: On 2006/11/15 08:22, Diana Eichert wrote: Are TDM over Ethernet devices supported under Asterisk running on OpenBSD? No, they are configured as a channel under zaptel which we don't have. (zaptel is ~20k lines of kernel driver including such fun things as echo cancellation; the closest OS it's ported to is NetBSD). They also need a timing source, which some comments suggest needs to be a zaptel PCI card rather than ztdummy (these both need the same core zaptel driver that's needed for TDMoE). [http://en.wikipedia.org/wiki/Asterisk_PBX] Asterisk's timing mechanism (both timestamps and wake-ups) is strongly biased toward systems which contain at least one of Digium's PCI boards. Users with other needs, including pure VoIP setups, are likely to experience timing problems. (this is why things like meetme and iax trunking don't work properly, and could explain any other random problems that may crop up, though strange things have been known to happen with Asterisk on systems that do have a timer too). I read some comment on the Asterisk bug tracker suggesting Digium are not particularly interested in making things work better on systems that don't use their cards so I don't think we're very likely to see timing changing to a more sane method just yet... I have a couple IAX trunks that work pretty well. Mind you the system isn't under any sort of load. Is there any word as to when zaptel might be ported to OpenBSD? Would one be able to compile the NETBSD port into the openbsd kernel? Has anyone had any success with asterisk 1.4?
