Free Linux Driver Development!
On the subject of http://www.kroah.com/log/linux/free_drivers.html Now these companies have a great excuse to keep specs locked up tight under NDA, while pretending to be "open." The OpenBSD project has been made clear more than once how this will hurt Free Software in the long run. Signing NDA's ensures that Linux gets a working driver, sure, but the internals are indistinguishable from magic. It is a source code version of a blob. It now became clear you also don't give a damn about freedom. Well done, Greg. -- Stephan A. Rickauer --- Institute of Neuroinformatics Tel +41 44 635 30 50 University / ETH Zurich Sec +41 44 635 30 52 Winterthurerstrasse 190 Fax +41 44 635 30 53 CH-8057 ZurichWeb www.ini.unizh.ch RSA public key: https://www.ini.uzh.ch/~stephan/pubkey.asc ---
Re: OT? Is this bad news?
On 2/13/07, Han Boetes <[EMAIL PROTECTED]> wrote: Darren Spruell wrote: > Instead we end up with a GPL driver that has to be reverse > engineered and we end up with the same problems we already have. Since when is the GPL a close source license? Who said it was? If you mean what I said about the same problems we already have, I mean that we don't have specifications and documentation from which a reliable driver can be written. Problems with magic numbers and unclear implementation details have been pointed out in the past. Reverse engineering can only take you so far, no? DS
Re: OT? Is this bad news?
On 2/13/07, Han Boetes <[EMAIL PROTECTED]> wrote: Darren Spruell wrote: > Instead we end up with a GPL driver that has to be reverse > engineered and we end up with the same problems we already have. Since when is the GPL a close source license? You still don't get it. The problem is lack of available documentation. CK -- GDB has a 'break' feature; why doesn't it have 'fix' too?
Re: OT? Is this bad news?
Darren Spruell wrote: > Instead we end up with a GPL driver that has to be reverse > engineered and we end up with the same problems we already have. Since when is the GPL a close source license? # Han
Re: OT? Is this bad news?
On 2/13/07, chefren <[EMAIL PROTECTED]> wrote: On 2/13/07 7:15 PM, Andreas Bihlmaier wrote: > I were the hulk, everything would have went green. Why? If people want to use blobs or write copyrighted code or GPL code, let them do so. Free world... > Seriously WTF are those guys thinking? Nothing? > There is no use to binary source drivers, they are not free/usable, They believe they can use them, and they obviously some kind of work. It's about quality, philosophy and so on if you think things should be free, others have an other opinion, let them. So many times it's been said and yet people still don't grasp the big picture. If the work being done here didn't impact anyone other than the GPL driver writing Linux crew, it would be one thing. When the message sent to commercial hardware manufacturers is "we don't want your specifications to be open, we just want to work under NDA so we can produce a single driver" by one open source guy, the message is received by said vendor is different. What it tells them is that not releasing open documentation and specifications is the norm, they don't have to disclose anything to the open source community outside of NDA, and that helping produce a GPL driver is good enough. The next step is them thinking that they can just produce said driver themselves. And then that they can just release a blob. In other words, it undermines the (better) efforts of a project like OpenBSD who try to get fully open docs and specs so that OpenBSD can have a functioning driver, FreeBSD can have one, NetBSD can have one, Linux can have one... etc. Instead we end up with a GPL driver that has to be reverse engineered and we end up with the same problems we already have. It's not enough to be "good enough". If the damn community can't get this by now, it's going to continue to be an uphill battle. DS
circumventing spamd-setup's supernet/sort function
in trying to get a spamd server to eat a boatload of RBLs,
i've come across what i believe is a situation in which
it would be desirable for spamd-setup to not perform
the supernet/sort/nonoverlap functions in collapse_blacklist().
this test host is freebsd 6.2-RC2 running amd64 on a dual cpu dual
core dell 2850 with 12GB RAM ( freebsd as i had no success
getting openbsd to run on it with i386+PAE or amd64 and see
more than 4GB in despite of the patch i found on tech@ ).
if i make it beyond testing successfully, in production will
likely be a 9th gen dell box with some more RAM, anyway...
here's the "wc -l" of the RBLs i'm trying to get in there:
1387159 /var/rbldns/sorbs/safe.dnsbl.sorbs.net.sorted
4975141 /var/rbldns/cbl/cbl.sorted
10379650 /var/rbldns/dsbl/dsbl.sorted
3191173 /var/rbldns/spamhaus/rsync/spamhaus.sorted
235 /var/rbldns/internal/customers-block.sorted
1618 /var/rbldns/internal/outside-block.sorted
19934976 total
where each of the 'sorted' suffixes denote that i have
run 'sort -nut. -k{1\,1,2\,2,3\,3,4\,4}' on them, in
addition to pumping them through Net::CIDR::Lite to
have it perform the supernetting.
spamd.conf was then asked to use each of them as a
seperate blacklist, and then spamd-setup was run
on an empty .
the runtime, as reported by the time function builtin
to "@(#)PD KSH v5.2.14.2 99/07/13.2" was 10531 seconds.
i then took the contents of and dumped to a file:
# pfctl -t spamd -Ts | wc -l
16175328
# pfctl -t spamd -Ts > rbls.ouch
and reconfigured spamd.conf to use only that 'ouch' rbl and
no others.
ran spamd-setup again. this time:
# time /usr/local/sbin/spamd-setup
14000.20s real 8515.07s user 5473.58s system
# grep -v '#' /usr/local/etc/spamd.conf
all:ouch:
ouch:black:msg="ouch":file=/var/rbldns/rbls.ouch
# ls -l /var/rbldns/rbls.ouch
-rw-r--r-- 1 root wheel 282116850 Feb 13 14:20 /var/rbldns/rbls.ouch
# wc -l /var/rbldns/rbls.ouch
16175328 /var/rbldns/rbls.ouch
# pfctl -t spamd -Ts | wc -l
5550409
i was initially confused about the discrepancy between
5550409 and 16175328 until i ran the following small test
that showed the difference:
---
# cat file1
1.2.3.0/30
# cat file2
1.2.3.1/32
# grep -ve '#' -e '^$' /usr/local/etc/spamd.conf
all:test:test2:
test:black:msg="test":file=/var/rbldns/file1
test2:black:msg="test":file=/var/rbldns/file2
# /usr/local/sbin/spamd-setup
# pfctl -t spamd -Ts
1.2.3.0/30
1.2.3.1
---
so it seems that spamd-setup's collapse_blacklist()
supernets/sorts *per* blacklist such that if a blacklist
B enumerates an IP block that is within a larger block
in blacklist A, both entries are kicked to pf (and perhaps
spamd(8)?). this could totally be the expected behaviour,
and may well be obvious to anyone reading the source, but
this trait isn't what i'm particularly concerned with.
if i take that resultant 5,550,409 entry table
that is the culmination of all the possible supernetting
and sorting and non-overlapping-ness of the component
RBLs, and save that to a file, and then spamd-setup(8)
*that* file, such that spamd-setup(8) has the least
amount of work (i'm guessing) possible to do in preparation
for pushing that data to pf(4) (note, it is inconsequential
to me that i am losing the granularity of being able to
send a 'msg' to any particular connecting IP %A about which
RBL that IP was found on as we'll have all spamd.conf
'msg's configured to go to an external lookup page that
will show all the matching RBLs an IP was found on), it
still takes a hefty amount of time.
---
# pfctl -t spamd -Ts > rbls.ouch2
# wc -l rbls.ouch2
5550409 rbls.ouch2
# grep -ve '#' -e '^$' /usr/local/etc/spamd.conf
all:ouch2:
ouch2:black:msg="ouch2":file=/var/rbldns/rbls.ouch2
# time /usr/local/sbin/spamd-setup
1670.45s real 1056.12s user 610.64s system
as opposed to:
# time pfctl -t spamd -Tr -f rbls.ouch2
5550409 addresses added.
2 addresses deleted.
23.66s real 10.68s user 12.97s system
# time pfctl -t spamd -Tr -f rbls.ouch2
no changes.
17.27s real 10.66s user 6.60s system
# time pfctl -t spamd -Tr -f rbls.ouch2
no changes.
17.28s real 10.71s user 6.56s system
while i'm only totally guessing, i imagine that
if spamd-setup could be told to not go through the
motions of supernetting/sorting/uniqing the source
data (where it would then be my responsibility to
ensure that the data is "as it should be", or otherwise
just like it would be after spamd-setup would be done
collapsing it anyway), i'd be surprised if the entire
spamd-setup process of shipping the data to spamd(8)
and then pfctl'ing it into took longer than
two minutes - perhaps less.
under two minutes would be entirely usable in a production
environment given that we're talking about 5 million
CIDR blocks, but 27 minutes is a bit suboptimal.
would it be trivial to skip the expensive parts of
collapse_blacklist such that it would essentially assume
that
Re: SIP in OpenBSD
[EMAIL PROTECTED] wrote: Whereas, if you want to interface you machine to an existing old pabx or if you want your openbsd machine to work with pstn at your location then you need to get zaptel+libpri working on your machine. Not at all, you only need zaptel and libpri if you want to interface *directly* with the PSTN/PBX. There are numerous standalone solutions (like the spa-3000 adapters) that will interface with PSTN/PBX and connect to your asterisk/ser box. Depending on your specific site needs those solutions may be better (or worse) than using a digium/tormenta card. --- Lars
Re: What's up with my pf.conf?
On 2/14/07, mal content <[EMAIL PROTECTED]> wrote: To clarify: I can connect from any 192.168.2.* IP to a temporary machine in the 192.168.1.* network (the empty network between the hardware router and the openbsd box), so packets appear to be forwarded correctly. If I try to connect to an external IP, however, the packets don't seem to go anywhere. I have, on a few occasions, seen responses from openbsd.org to packets sent earlier which are then blocked by pf (correctly, as they are no longer associated with any connection). I have connected a machine to the 192.168.1.* network to sniff packets with wireshark and see absolutely nothing go through when a machine at 192.168.2.5 attempts to 'nc' to openbsd.org:80. Watching pf logs with tcpdump shows that pf certainly believes it has forwarded packets to the external IP address. ... In the old days, we'd have opened the switch with bolt cutters and set fire to the building on the way out. MC what does `route show` say and is the default gateway correct? Cheers Ste
Re: What's up with my pf.conf?
On Tuesday 13 February 2007 18:40, mal content wrote: > To clarify: > > I can connect from any 192.168.2.* IP to a temporary machine > in the 192.168.1.* network (the empty network between the hardware > router and the openbsd box), so packets appear to be forwarded > correctly. If I try to connect to an external IP, however, the packets > don't seem to go anywhere. I have, on a few occasions, seen responses > from openbsd.org to packets sent earlier which are then blocked by > pf (correctly, as they are no longer associated with any connection). > > I have connected a machine to the 192.168.1.* network to sniff > packets with wireshark and see absolutely nothing go through when > a machine at 192.168.2.5 attempts to 'nc' to openbsd.org:80. Watching > pf logs with tcpdump shows that pf certainly believes it has forwarded > packets to the external IP address. Just out of curiosity, what is the output from netstat -nrf inet? Is this possibly a routing problem? If pf is turned off, are you able to connect to external IP addresses? > > ... > > In the old days, we'd have opened the switch with bolt cutters and > set fire to the building on the way out. > > MC > > > !DSPAM:1,45d25f0378142517112723! -- Vijay Sankar ForeTell Technologies Limited 59 Flamingo Avenue, Winnipeg, MB, Canada R3J 0X6 Phone: +1 (204) 885-9535, E-Mail: [EMAIL PROTECTED]
Re: What's up with my pf.conf?
Well. Amazing, and sickening as it is, rebooting the machine appears to have cleared up the problem. Any more of this and I'd have broken out in hives or chewed through a mains cable. Thanks for your time, everybody who replied on and off list. MC
Re: SIP on OpenBSD
On Tuesday 13 February 2007 21:04, Stuart Henderson wrote: > Anyone with a phone... there are numerous companies gatewaying > PSTN<>SIP in and out and some doing PSTN<>H323 and a few doing > PSTN<>IAX And a choice of ISDN (basic, pri) -> SIP gateways. Much easier.
Re: What's up with my pf.conf?
On 14/02/07, Ste Jones <[EMAIL PROTECTED]> wrote: what does `route show` say and is the default gateway correct? Cheers Ste DestinationGatewayFlagsRefs UseMtu Interface default192.168.1.1UGS 0 194 - fxp0 127/8 127.0.0.1 UGRS00 33224 lo0 127.0.0.1 127.0.0.1 UH 3 389 33224 lo0 192.168.1/24 link#1 UC 30 - fxp0 192.168.1.100:50:7f:21:67:94 UHLc1 37 - fxp0 192.168.1.400:11:25:46:4b:11 UHLc01 - fxp0 192.168.2/24 link#2 UC 10 - fxp1 192.168.2.500:d0:b7:3f:44:85 UHLc223543 - fxp1 192.168.3/24 link#3 UC 20 - fxp2 The default gateway appears to be correct, 192.168.1.1, the IP address of the hardware router. MC
Re: What's up with my pf.conf?
To clarify: I can connect from any 192.168.2.* IP to a temporary machine in the 192.168.1.* network (the empty network between the hardware router and the openbsd box), so packets appear to be forwarded correctly. If I try to connect to an external IP, however, the packets don't seem to go anywhere. I have, on a few occasions, seen responses from openbsd.org to packets sent earlier which are then blocked by pf (correctly, as they are no longer associated with any connection). I have connected a machine to the 192.168.1.* network to sniff packets with wireshark and see absolutely nothing go through when a machine at 192.168.2.5 attempts to 'nc' to openbsd.org:80. Watching pf logs with tcpdump shows that pf certainly believes it has forwarded packets to the external IP address. ... In the old days, we'd have opened the switch with bolt cutters and set fire to the building on the way out. MC
Re: SIP on OpenBSD
On Tuesday 13 February 2007 09:47, Karel Kulhavy wrote: > Did anyone succeed in installing any SIP client on OpenBSD? Several, and IAX. Always had fatal problems with audio and/or threads.
Re: What's up with my pf.conf?
I have simplified the config file down to: # $Id: pf.conf 202 2007-02-13 23:44:37Z mc $ nic_dmz = fxp2 nic_pri = fxp1 nic_wan = fxp0 # ip addresses for this machine and the wan router ip_dmz = 192.168.3.1 ip_pri = 192.168.2.1 ip_wan = 192.168.1.2 ip_dtek = 192.168.1.1 # network net_pri = "192.168.2.0/24" net_dmz = "192.168.3.0/24" # privileged terminals ip_priv_term1= 192.168.2.5 # blacklist table persist file "/etc/pf.blacklist" #-- # global normalize rules scrub in all fragment reassemble #-- # NAT nat on $nic_wan from $nic_pri:network to any -> ($nic_wan) nat on $nic_wan from $nic_dmz:network to any -> ($nic_wan) #-- # global filter rules block log all block log quick from to any block log quick from any to pass quick on lo0 all #-- # WAN subnet # allow outgoing pass out on $nic_wan proto tcp \ from $ip_wan to any flags S/SA modulate state pass out on $nic_wan proto udp \ from $ip_wan to any modulate state #-- # private subnet block in log quick on $nic_pri from ! $net_pri to any block out log quick on $nic_pri from any to ! $net_pri # allow the private administrative terminal to connect to the SSH port pass in log quick on $nic_pri proto tcp \ from $ip_priv_term1 to $ip_pri port 22 modulate state # allow connections from admin terminal to dtek pass in log quick on $nic_pri proto tcp \ from $ip_priv_term1 to $ip_dtek port 8080 modulate state # allow private lan to connect out pass in log on $nic_pri proto tcp \ from $net_pri to any flags S/SA modulate state pass in log on $nic_pri proto udp \ from $net_pri to any modulate state #-- # dmz block in log quick on $nic_dmz from ! $net_dmz to any block out log quick on $nic_dmz from any to ! $net_dmz # allow into the DMZ pass out log on $nic_dmz proto tcp \ from any to $net_dmz flags S/SA modulate state pass out log on $nic_dmz proto udp \ from any to $net_dmz modulate state ...but it still just isn't working. I'm scratching my head over this one. This is the exact same system I've been using for a good year and a half. Have there been any changes to pf that I've missed (in terms of interface - obviously there have been new features and fixes etc.)? MC
Re: Problems with routing
2007/2/14, Jamie Penman-Smithson <[EMAIL PROTECTED]>: Any hints? afterboot(8) has a section on routing. Best Martin
Problems with routing
Hi all, I'm attempting to setup openbsd 4.0 as a router, the system has two interfaces, rl0 and rl1. It looks something like this (apologies if this looks really odd): router [x.x.58.129] --- router2: rl0 [x.x.58.130] router2: rl1 [x.x.58.140] --- DMZ subnet x.x.58/28 I've tried: route add -net x.x.58.128 -netmask 255.255.255.240 -iface x.x.58.140 route add -host x.x.58.129 -iface x.x.58.130 However, then packets to x.x.58.129 don't seem to be routed through rl0, but I can ping everything on that subnet. If I do: route add -net x.x.58.128 -netmask 255.255.255.240 -iface x.x.58.130 Then I can ping x.x.58.129, but then I obviously can't ping anything else on that subnet since it's connected through rl1. Internet: DestinationGatewayFlagsRefs UseMtu Interface defaultx.x.58.129 UGS 8 141451 - rl0 x.x.58.128/28 link#2 UC 70 - rl0 x.x.58.129 00:50:7f:09:0e:1c UHLc2 6966 - rl0 Under Linux I just had: Destination Gateway Genmask Flags MSS Window irtt Iface x.x.58.129 0.0.0.0 255.255.255.255 UH0 0 0 eth1 x.x.58.128 0.0.0.0 255.255.255.240 U 0 0 0 eth2 10.0.0.00.0.0.0 255.0.0.0 U 0 0 0 eth0 0.0.0.0 x.x.58.129 0.0.0.0 UG0 0 0 eth1 ..and it 'just worked'.. I've read through the manpage for route, to no avail. Any hints? Thanks in advance, -- -Jamie L. Penman-Smithson <[EMAIL PROTECTED]>
Re: dmesg and fdisk do not match about usb external disk
On Tue, Feb 13, 2007 at 04:50:27PM +0100, frantisek holop wrote: > hmm, on Tue, Feb 13, 2007 at 08:18:50AM -0500, Kenneth R Westerback said that > > OpenBSD aligns to boundaries. It just makes up the boundaries, as do > > other OS's. It's unfortunate that all OS's don't make up the same > > boundaries but until you can convince all OS developers to use the > > same fake geometry you'll have to live with the current situation. > > > > OpenBSD makes absolutely no effort to get 'real' geometry > > information from USB attached disks. Too many such devices simply > > freak out and stop working when asked this difficult question. > > Others make up even more bizarre geometries than the one we use. > > > > So OpenBSD uses 64*32, divides the number of sectors (which all > > devices do provide) by this value to give a cylinder count, and > > truncates the fractional cylinder. So up to 64*31 = 1984 sectors > > will be 'wasted'. > > thanks for the src pointer, interesting. this explains the dmesg > clearly, but what about fdisk? fdisk is supposed to get the > geometry from the the bios (not much help for usb disks i guess) > and then the disklabel. is disklabel using the same fake magic? > Yes. > > in the case of the 160G disk[1], there must be something wrong > as the dmesg total number of sectors is the same as the fdisk > total number of sectors, while it's pretty clear that not all > of the disk is usable and there is a 5103 sectors of waste... > > > i believe you when you say a lot of umass stuff is broken > and choking on basic calls. but wouldn't it make sense > to tell sd_get_parms() to go ahead and query an actual > geometry in case of "external hdd" usb devices? are the > usb disks just as broken as any random umass device in this > respect? > > > i don't have a netbsd install to test it, but their approach > seems te be not as discriminative towards umass devices[2]... > > > > btw this disk (wd passport) is strange in more respects. > first of all, partition magic got its geometry wrong also > a couple of times: > > 310,101 Cylinders, 16 Heads, 63 Sectors/Track but then > 19,457 Cylinders, 255 Heads, 63 Sectors/Track[2]. > > > second: > > 14:48:07 a /bsd: sd0(umass0:1:0): Check Condition (error 0x70) on opcode 0x2a > 14:48:07 a /bsd: SENSE KEY: Illegal Request > 14:48:07 a /bsd: ASC/ASCQ: Logical Block Address Out of Range > 14:50:21 a /bsd: sd0(umass0:1:0): Check Condition (error 0x70) on opcode 0x2a > 14:50:21 a /bsd: SENSE KEY: Illegal Request > 14:50:21 a /bsd: ASC/ASCQ: Logical Block Address Out of Range > 14:50:56 a /bsd: sd0(umass0:1:0): Check Condition (error 0x70) on opcode 0x2a > 14:50:56 a /bsd: SENSE KEY: Illegal Request > 14:50:56 a /bsd: ASC/ASCQ: Logical Block Address Out of Range > 14:53:53 a /bsd: sd0(umass0:1:0): Check Condition (error 0x70) on opcode 0x2a > 14:53:53 a /bsd: SENSE KEY: Illegal Request > 14:53:53 a /bsd: ASC/ASCQ: Logical Block Address Out of Range > > so this baby is certainly going back where it came from... > > > -f > > 1. http://marc.theaimsgroup.com/?l=openbsd-misc&m=117133082530013 > 2. http://opengrok.netbsd.org/source/xref/sys/dev/scsipi/sd.c#sd_get_parms > 3. http://marc.theaimsgroup.com/?l=openbsd-misc&m=116475065104125&w=4 > -- > the word of the day is legs. now spread the word!
Re: "sh checkflist" after "make release" of 4.0-stable gives starnge result.
The short version is:
/usr/src/distrib/sets/lists/base/mi
seems to be out of sync for 4.0-stable since Feb. 4.
The long version is:
Didier Wiroth wrote on Tue, Feb 13, 2007 at 01:29:28PM +0100:
> I made a 4.0-stable "make release" on the amd64 architecture.
> Running "sh checkflist" gives this:
> # sh checkflist
> 14877a14878
> > ./usr/share/zoneinfo/Africa/Asmara
[...]
> What does this actually mean?
Your release(8) process built files in
${DESTDIR}/usr/share/zoneinfo/
not being listed in your
/usr/src/distrib/sets/lists/base/mi
file list.
That is, your source tree and your distribution set file lists
are out of sync. When tacking -current, this does happen from
time to time. With -stable, this symptom is rather uncommon.
The typo correction Asmera -> Asmara in particular
was committed on 2007/02/02 by millert@,
/usr/src/share/zoneinfo/datfiles/africa r1.17
during the update to tzdata2007a from elsie.nci.nih.gov.
Stable was also updated, see
/usr/src/share/zoneinfo/datfiles/africa r1.15.4.1
committed two days later, on 2007/02/04 by [EMAIL PROTECTED]
Yet, as far is i can see, unless mirrors are out of date,
OPENBSD_4_0 still has the -release revision 1.394 for
/usr/src/distrib/sets/lists/base/mi
Perhaps someone with commit access should sync base/mi for -stable?
Yours,
Ingo
Re: watch traffic on IPSEC tunnel?
Dag Richards wrote: Tim Pushor wrote: May be a dumb question, but how do I look at traffic going over an IPSEC tunnel, on one of the OpenBSD machines? I've tried tcpdump -i enc0 but get nothing .. That is exactly what you do. Remember you can not use filters on it, no tcpdump -i enc0 host wakkawakka Interesting. Why can't you use filters?
Re: OT? Is this bad news?
On 13/02/07, chefren <[EMAIL PROTECTED]> wrote: > > > > On 2/14/07 12:12 AM, Jeff Rollin wrote: > > Actually, the FAQ specifically states that this is *not* about creating > > binary blobs. As for any BSD involvement, GKH specifically states that > > he is not involved in the development of any BSD. I am sure there are > > many BSD devs who are not involved in Linux. For that matter, for all I > > know there may well be BSD devs who confine themselves to involvement in > > only one BSD. > > > > Jeff. > > As I wrote: let them, who cares, free world. Nobody gets murdered or so. > > +++chefren > > > Let's hope not! Jeff R -- Now, did you hear the news today? They say the danger's gone away But I can hear the marching feet Moving into the street Adapted from Genesis, "Land of Confusion" http://latedeveloper.org.uk
Re: linux emulation without redhat_base
Hi Karel, Karel Kulhavy wrote on Tue, Feb 13, 2007 at 11:21:19AM +0100: > Now I avoided the NTPL problem by removing the redhat base and > copying only the libraries that printed an error that it wants > them. No comment whether this is a good or a bad idea. In case you get lost in the Linux lib* jungle, err, well... > But when I copied libstdc++.so.6 it now print: > [EMAIL PROTECTED]:~$ ./ekiga > ./ekiga: error while loading shared libraries: libstdc++.so.6: > cannot handle TLS data Probably, you took the wrong file. Some libraries exist *twice* on Linux with identical file names: [EMAIL PROTECTED]:~$ uname -a Linux donnerwolke.usta.de 2.6.16 #1 SMP Mon Aug 14 19:46:21 CEST 2006 i686 GNU/Linux [EMAIL PROTECTED]:~$ ls -al /lib/libc-* /lib/tls/libc-* -rwxr-xr-x 1 root root 1244752 Apr 19 2006 /lib/libc-2.3.2.so -rwxr-xr-x 1 root root 1254660 Apr 19 2006 /lib/tls/libc-2.3.2.so [EMAIL PROTECTED]:/raid/ftpd$ cmp /lib/libc-* /lib/tls/libc-* /lib/libc-2.3.2.so /lib/tls/libc-2.3.2.so differ: char 25, line 1 You may call this wierd, but it won't help you. ;-) Yours, Ingo
Re: OT? Is this bad news?
Actually, the FAQ specifically states that this is *not* about creating binary blobs. As for any BSD involvement, GKH specifically states that he is not involved in the development of any BSD. I am sure there are many BSD devs who are not involved in Linux. For that matter, for all I know there may well be BSD devs who confine themselves to involvement in only one BSD. Jeff.
Re: OT? Is this bad news?
On 2/13/07 7:15 PM, Andreas Bihlmaier wrote: I were the hulk, everything would have went green. Why? If people want to use blobs or write copyrighted code or GPL code, let them do so. Free world... Seriously WTF are those guys thinking? Nothing? There is no use to binary source drivers, they are not free/usable, They believe they can use them, and they obviously some kind of work. It's about quality, philosophy and so on if you think things should be free, others have an other opinion, let them. whether they are distributed as binaries by the vendor, or written under NDAs doesn't make a difference at all. We agree but they don't think this is a problem. They probably like signing agreements with big companies. Gives them some feeling of importance. I personally would feel like a dog with any unpaid agreement, but shees, let them! You know what happends when I tell my linux friends? Their argumentation goes along the lines of: "You shouldn't be such a idealist, be more pragmatic". Damn it! Incredible, go hiking, buy flowers... Okay sorry, there is no use the preach to the saints here, but what should one do against it? Nothing, wasted energy. Good moment to once more thank the OpenBSD devs for their 'long term pragmatics' instead of short lived 'well, now it works'. Yes! +++chefren
Re: SIP in OpenBSD
bloody rubbish... > On Tue, Feb 13, 2007 at 12:35:56PM -, [EMAIL PROTECTED] wrote: > >> If one's intention is to run just purely VOIP softphones and hardphones, the >> asterisk software >> alone is enough to do the job. Whereas, if you want to interface you machine >> to an existing old >> pabx or if you want your openbsd machine to work with pstn at your location >> then you need to get >> zaptel+libpri working on your machine. > > This is not true, as several people have told you already. > > I myself run Asterisk on my openbsd box at home, and I have connected my > PSTN line to it using a Sipura SPA-3000 instead of a zaptel card. It works > just > fine: *all* my calls are handled (PSTN/VoIP) by the Asterisk server. > > Now please stop posting nonsense. Thanks. > > -- > Jurjen Oskam > > Savage's Law of Expediency: > You want it bad, you'll get it bad.
Re: SIP in OpenBSD
whatever! > On Tue, Feb 13, 2007 at 12:35:56PM -, [EMAIL PROTECTED] wrote: > >> If one's intention is to run just purely VOIP softphones and hardphones, the >> asterisk software >> alone is enough to do the job. Whereas, if you want to interface you machine >> to an existing old >> pabx or if you want your openbsd machine to work with pstn at your location >> then you need to get >> zaptel+libpri working on your machine. > > This is not true, as several people have told you already. > > I myself run Asterisk on my openbsd box at home, and I have connected my > PSTN line to it using a Sipura SPA-3000 instead of a zaptel card. It works > just > fine: *all* my calls are handled (PSTN/VoIP) by the Asterisk server. > > Now please stop posting nonsense. Thanks. > > -- > Jurjen Oskam > > Savage's Law of Expediency: > You want it bad, you'll get it bad.
Re: SIP on OpenBSD
On 2007/02/13 14:46, Nick ! wrote: > >Someone also mentioned Asterisk can be used as a phone, but I didn't > >find anything in the Asterisk doc, also nothing in the Asterisk > >commandline help. You can probably do something with chan_oss or chan_alsa, but it may well need some hackery on OpenBSD. The voip-info.org wiki might give some clues, it's about the closest thing there is to an Asterisk reference manual. > I haven't tried it, but I believe this would work: > http://www.voip-info.org/tiki-index.php?page=Asterisk+cmd+MeetMe MeetMe (certainly in 1.2, don't know about 1.4) needs zaptel kernel parts as a timing source. There's an alternative in ports/telephony/app_conference. OpenPBX afaik doesn't need this (though I'm not sure whether or not their conferencing app requires POSIX timers or whether it manages without). > Now I'm excited. I want to try this at home. But who could I call? Anyone with a phone... there are numerous companies gatewaying PSTN<>SIP in and out and some doing PSTN<>H323 and a few doing PSTN<>IAX (this is less popular as the dedicated gateway devices which are normally used to interconnect with PSTN (with DSPs to handle codecs, E1/T1 interfaces, etc) generally don't do IAX.
Re: SIP on OpenBSD
On Tue, 2007-02-13 at 14:46 -0500, Nick ! wrote: > On 2/13/07, Karel Kulhavy <[EMAIL PROTECTED]> wrote: > > On Tue, Feb 13, 2007 at 11:53:04AM +0100, Alessio Cappelli wrote: > > > Hi, did you know about OpenPBX? > > > > PBX==Private Branch Exchange. I want a SIP phone, not a SIP exchange. > > Or is it possible to use OpenPBX as a phone, too? > > > > Someone also mentioned Asterisk can be used as a phone, but I didn't > > find anything in the Asterisk doc, also nothing in the Asterisk > > commandline help. > > I haven't tried it, but I believe this would work: > http://www.voip-info.org/tiki-index.php?page=Asterisk+cmd+MeetMe > > Now I'm excited. I want to try this at home. But who could I call? MeetMe will not work on OpenBSD because MeetMe requires the Zaptel kernel drivers to do audio mixing and timing. OpenPBX has similar functionality but it does not require Zaptel. Jeff [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: SIP on OpenBSD
On 2007/02/13 10:39, [EMAIL PROTECTED] wrote: > If zaptel won't work in openbsd, there is no way for asterisk > be installed. pkg_add works nicely for me... 1.2.15 is in -current ports for the upcoming release, 1.4.whatever-it-is-then is planned for sometime after ports unlocks after the release. The port maintainer doesn't have any plans to port the zaptel kernel pieces to OpenBSD. Asterisk has some soundcard channel, which could theoretically be used to make a softphone (you can send a dial command from the CLI), but I never tried it, it is most likely linux-specific (portability does not appear to be a primary concern of Asterisk, though it's a lot better than it used to be) though it may be an easier target than the usual softphones since * mostly works.
Re: What's up with my pf.conf?
On 13/02/07, Bryan Irvine <[EMAIL PROTECTED]> wrote: On 2/13/07, mal content <[EMAIL PROTECTED]> wrote: > Hi. > > I just upgraded from 3.7 to 4.0 (complete wipe and reinstall) and > my previously working pf.conf now doesn't work correctly. Machines > inside the private network can no longer connect to any IP outside > of my network. can you connect to any ip that is located on a different interface of the firewall? ie can 192.168.3.10 ping 192.168.2.15? check the output of 'sysctl net.inet.ip.forwarding' Hi. Yes, I see 'pass in on fxp1' and 'pass out on fxp2'. net.inet.ipforwarding is enabled. MC
Re: What's up with my pf.conf?
On 2/13/07, mal content <[EMAIL PROTECTED]> wrote: Hi. I just upgraded from 3.7 to 4.0 (complete wipe and reinstall) and my previously working pf.conf now doesn't work correctly. Machines inside the private network can no longer connect to any IP outside of my network. can you connect to any ip that is located on a different interface of the firewall? ie can 192.168.3.10 ping 192.168.2.15? check the output of 'sysctl net.inet.ip.forwarding' --Bryan
Re: OT? Is this bad news?
On Tue, Feb 13, 2007 at 12:59:52PM -0700, Steven wrote: > Which brings me back to the question, what can an OpenBSD/open > source/free software user do about it? Well, since Greg Kroah-Hartman seems to be at the focal point of this, he'd be a good person to educate as to why this solution isn't as good as he thinks it is. He invites questions about this program and gives [EMAIL PROTECTED] for that purpose. I'd like to make some points. He probably believes he's really doing a good thing. If you think you're doing good and people start tearing you down it's natural to get defensive. DO RAISE THE ISSUES, but there's no reason to be unduly nasty. -- Darrin Chandler | Phoenix BSD Users Group [EMAIL PROTECTED] | http://bsd.phoenix.az.us/ http://www.stilyagin.com/darrin/ |
What's up with my pf.conf?
Hi. I just upgraded from 3.7 to 4.0 (complete wipe and reinstall) and my previously working pf.conf now doesn't work correctly. Machines inside the private network can no longer connect to any IP outside of my network. # $Id: pf.conf 201 2007-02-13 20:03:11Z mc $ # network interface cards dmz_nic="fxp2" priv_nic="fxp1" wan_nic="fxp0" # ip addresses for this machine and the wan router my_dmz_ip="192.168.3.1" my_priv_ip="192.168.2.1" my_wan_ip="192.168.1.2" dtek_ip="192.168.1.1" # DNS server dns_cache="192.168.3.10" # clock server ntp_server="192.168.3.20" silc_server="192.168.3.33" irc_server="192.168.3.32" http_server="192.168.3.31" www_server="192.168.3.30" # private terminals priv_terminal1="192.168.2.15" priv_terminal2="192.168.2.5" # ip ranges of both networks priv_ips="192.168.2.0/24" dmz_ips="192.168.3.0/24" # freebsd.org hole for portaudit freebsd_org = "216.136.204.117" # blacklist table persist file "/etc/pf.blacklist" #-- # global rules # normalise incoming traffic scrub in all fragment reassemble #-- # NAT nat on $wan_nic from $priv_nic:network to any -> ($wan_nic) nat on $wan_nic from $dmz_nic:network to any -> ($wan_nic) # server services redirects rdr on $wan_nic proto tcp \ from any to any port 80 -> $http_server port 80 rdr on $wan_nic proto tcp \ from any to any port 2200 -> $http_server port 22 rdr on $wan_nic proto tcp \ from any to any port 6667 -> $irc_server port 6667 rdr on $wan_nic proto tcp \ from any to any port 6669 -> $irc_server port 6669 rdr on $wan_nic proto tcp \ from any to any port 706 -> $silc_server port 10706 #-- # blacklist block log quick from to any block log quick from any to # clear localhost traffic pass out quick on lo0 all pass in quick on lo0 all #-- # wan subnet # the wan subnet is a tiny subnet containing only this nic and the # router (dtek) that gives access to the WAN. Legal packets include: # # - udp log packets from the wan router (dtek_ip) # - packets from the WAN, destined for the DMZ (destined for NAT) # - responses to requests for the admin web interface, destined for # the private network # # allow outgoing from $my_wan_ip because all outgoing connections # have this source address after being rewritten by NAT block in log on $wan_nic all block out log on $wan_nic all # allow web server, ssh, irc, silc in post-NAT pass in log quick on $wan_nic proto tcp \ from any to $http_server port 80 modulate state pass in log quick on $wan_nic proto tcp \ from any to $http_server port 2200 modulate state pass in log quick on $wan_nic proto tcp \ from any to $irc_server port 6667 modulate state pass in log quick on $wan_nic proto tcp \ from any to $irc_server port 6669 modulate state pass in log quick on $wan_nic proto tcp \ from any to $silc_server port 10706 modulate state # allow outgoing pass out on $wan_nic inet proto tcp \ from $my_wan_ip to any flags S/SA modulate state pass out on $wan_nic inet proto udp \ from $my_wan_ip to any modulate state #-- # private network # prevent spoofing block in log quick on $priv_nic from ! $priv_ips to any block out log quick on $priv_nic from any to ! $priv_ips # block everything by default block in log on $priv_nic all block out log on $priv_nic all # allow the private administrative terminal to connect to the SSH port pass in log quick on $priv_nic proto tcp \ from $priv_terminal1 to $my_priv_ip port 22 modulate state # allow connections from admin terminal to dtek pass in log quick on $priv_nic proto tcp \ from $priv_terminal1 to $dtek_ip port 8080 modulate state # same as above, different terminal pass in log quick on $priv_nic proto tcp \ from $priv_terminal2 to $my_priv_ip port 22 modulate state pass in log quick on $priv_nic proto tcp \ from $priv_terminal2 to $dtek_ip port 8080 modulate state # block anybody else that tries it block in log quick on $priv_nic \ from any to $dtek_ip block in log quick on $priv_nic \ from any to $my_priv_ip # allow private lan to connect out pass in log on $priv_nic proto tcp \ from $priv_ips to any flags S/SA modulate state pass in log on $priv_nic proto udp \ from $priv_ips to any modulate state #-- # dmz block in log quick on $dmz_nic from ! $dmz_ips to any block out log quick on $dmz_nic from any to ! $dmz_ips block in log on $dmz_nic all block out log on $dmz_nic all # this is the opposite of how it sounds. # pass in on $dmz_nic means any packets coming into the firewall from # the DMZ # pass out means any packets going into the DMZ from the firewall # allow DNS requests out pass in log quick on $dmz_nic proto udp \
Re: SIP on OpenBSD
On 2/13/07, Karel Kulhavy <[EMAIL PROTECTED]> wrote: On Tue, Feb 13, 2007 at 11:53:04AM +0100, Alessio Cappelli wrote: > Hi, did you know about OpenPBX? PBX==Private Branch Exchange. I want a SIP phone, not a SIP exchange. Or is it possible to use OpenPBX as a phone, too? Someone also mentioned Asterisk can be used as a phone, but I didn't find anything in the Asterisk doc, also nothing in the Asterisk commandline help. I haven't tried it, but I believe this would work: http://www.voip-info.org/tiki-index.php?page=Asterisk+cmd+MeetMe Now I'm excited. I want to try this at home. But who could I call? -Nick
Re: OT? Is this bad news?
* Darrin Chandler <[EMAIL PROTECTED]> [070213 12:30]: On Tue, Feb 13, 2007 at 06:04:08PM +, Jeff Rollin wrote: On 13/02/07, Steven <[EMAIL PROTECTED]> wrote: > Free Linux Driver Development FAQ > http://linux.slashdot.org/article.pl?sid=07/02/13/0220233&from=rss > > Is this bad news for the OpenBSD developers efforts to free hardware > documentation? If it is, how can OpenBSD users, and users of other > FOSS, help? > Well as I understand it one of the things they are looking for are specs on which to base their own drivers. Also as I understand it, they cannot work under NDA's, so any specs released to them would be released to the public. The guy announcing this put together a FAQ (linked from the /. article) explaining that he has no problem with signing NDAs, but that the code will not be obfuscated in any way. So it seems that he's not going to push for companies to release specs. ... There *may* be some companies that release specs for this. I doubt any of the Linux people would dream of discouraging that directly. But any companies sitting on the fence on that issue now have a great excuse to keep specs locked up tight under NDA, while pretending to be "open." So my fears are probably well grounded then. So it seems like this does suck, not just for *BSD, but for Linux as well. Which brings me back to the question, what can an OpenBSD/open source/free software user do about it? -- W. Steven Schneider <[EMAIL PROTECTED]>
Re: SIP on OpenBSD
On Tue, Feb 13, 2007 at 11:53:04AM +0100, Alessio Cappelli wrote: > Hi, did you know about OpenPBX? PBX==Private Branch Exchange. I want a SIP phone, not a SIP exchange. Or is it possible to use OpenPBX as a phone, too? Someone also mentioned Asterisk can be used as a phone, but I didn't find anything in the Asterisk doc, also nothing in the Asterisk commandline help. CL< > > Alessio > > Karel Kulhavy ha scritto: > >Did anyone succeed in installing any SIP client on OpenBSD? > > > >CL<
Re: OT? Is this bad news?
On 13/02/07, Jack J. Woehr <[EMAIL PROTECTED]> wrote: > > Jeff Rollin wrote: > > Also as I understand it, they cannot work > > under NDA's, so any specs released to them would be released to the > public. > > > They say quite the opposite at > http://www.kroah.com/log/linux/free_drivers_faq.html: > > Q: How are you going to write a GPL driver by signing an NDA? Is it > going to require > a binary blob or some other way of obfuscating the code? > > A: No, not at all. I have written many drivers after signing NDAs > with companies. > They are usually signed either to keep information about the device > private until it > is announced at a specific date, or to just keep the actual > specification documents > from being released to the public directly. All code created by this > NDA program > is to be released under the GPL for inclusion in the main kernel > tree, nothing > will be obfuscated at all. > > -- I see; thanks for the correction/clarification Jeff
Re: SIP on OpenBSD
On Tue, Feb 13, 2007 at 11:09:06AM -, [EMAIL PROTECTED] wrote: > I don't know for sure how you did it. Just install the asterisk package, which is made available by the ports team. > and never had any single damn problem. I have and reviewed the specs of > digium over and over again > that zaptel is the device driver for the NIC card that talks to the kernel. Yes, and if you don't use that card, you don't need zaptel. If you don't use the card, you can still connect to any POTS system just fine using some other POTS <-> SIP interface. -- Jurjen Oskam Savage's Law of Expediency: You want it bad, you'll get it bad.
Re: OT? Is this bad news?
On Tue, Feb 13, 2007 at 06:04:08PM +, Jeff Rollin wrote: > On 13/02/07, Steven <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > I happened to see this on the slashdot rss feed, and out of > > curiosity took a look. > > > > Free Linux Driver Development FAQ > > http://linux.slashdot.org/article.pl?sid=07/02/13/0220233&from=rss > > > > Is this bad news for the OpenBSD developers efforts to free hardware > > documentation? If it is, how can OpenBSD users, and users of other > > FOSS, help? > > > > -- > > W. Steven Schneider <[EMAIL PROTECTED]> > > > > > Well as I understand it one of the things they are looking for are specs on > which to base their own drivers. Also as I understand it, they cannot work > under NDA's, so any specs released to them would be released to the public. > > This is only bad if the specs are released under a licence that would > prohibit OBSD people from looking at them. If companies go so far as > releasing the specs to Linux people, I can't see that happening, although of > course using the GPL'ed Linux drivers released under such conditions > would/might be problematic. > > Maybe it's time for the OBSD dev community to make similar overtures, > though, just in case > > Jeff R The guy announcing this put together a FAQ (linked from the /. article) explaining that he has no problem with signing NDAs, but that the code will not be obfuscated in any way. So it seems that he's not going to push for companies to release specs. Also in the FAQ is that he's not concerned about the BSDs. To me he's saying he doesn't care about open source or free software, as long as it works in Linux and can have the GPL license on it then it's fine. There *may* be some companies that release specs for this. I doubt any of the Linux people would dream of discouraging that directly. But any companies sitting on the fence on that issue now have a great excuse to keep specs locked up tight under NDA, while pretending to be "open." So it seems like this does suck, not just for *BSD, but for Linux as well. -- Darrin Chandler | Phoenix BSD Users Group [EMAIL PROTECTED] | http://bsd.phoenix.az.us/ http://www.stilyagin.com/darrin/ |
Re: SIP on OpenBSD
Lars Hansson <[EMAIL PROTECTED]> writes: >> Unless zaptel is supported under the OpenbSD platform, then there is no way >> you can get sip >> protocol run on OpenBSD platform. > There are software SIP clients, you know. Like Ekiga, KCall, KPhone > etc. It's just that no one as ported them yet. > SIP has NOTHING to do with zaptel and both Asterisk and SER are in the > ports tree. zaptel is only required if you want to use digium cards to > interface with a PBX or similar. or you need meetme application (wihin asterisk/openpbx) -- r.
Re: Finding Qt headers on OBSD 4.0
On Tue, Feb 13, 2007 at 05:53:34PM +0100, Karel Kulhavy wrote:
> Anyone knows the secret trick what to do to make a Qt app find the Qt headers?
>
> [EMAIL PROTECTED]:~/kphone$ CXXFLAGS="-I/usr/local/include
> -I/usr/local/lib/qt3/include" LDFLAGS="-L/usr/local/lib
> -L/usr/local/lib/qt3/lib" ./configure
> [...]
> checking location of Qt header files...
> not found. Giving up.
>
> CL<
Hope this helps, otherwise look at the ports tree in general, and especially
this
file:
/usr/ports/x11/qt3/qt3.port.mk
# $OpenBSD: qt3.port.mk,v 1.7 2006/11/20 20:41:00 espie Exp $
MODULES+= gcc3
MODGCC3_ARCHES+=sparc64
MODGCC3_LANGS+= c++
# This fragment uses MODQT_* variables to make it easier to substitute
# qt1/qt2/qt3 in a port.
MODQT_LIBDIR= ${LOCALBASE}/lib/qt3
MODQT_INCDIR= ${LOCALBASE}/include/X11/qt3
MODQT_OVERRIDE_UIC?=Yes
MODQT_MT?=Yes
MODQT_CONFIGURE_ARGS= --with-qt-includes=${MODQT_INCDIR} \
--with-qt-libraries=${MODQT_LIBDIR}
_MODQT_SETUP= MOC=${MODQT_MOC} \
MODQT_INCDIR=${MODQT_INCDIR} \
MODQT_LIBDIR=${MODQT_LIBDIR}
.if ${MODQT_OVERRIDE_UIC:L} == "yes"
_MODQT_SETUP+= UIC=${MODQT_UIC}
.endif
MODQT_LIB_DEPENDS=lib/qt3/qt-mt.>=3::x11/qt3
LIB_DEPENDS+= ${MODQT_LIB_DEPENDS}
# may be needed to find plugins
MODQT_MOC= ${LOCALBASE}/bin/moc3-mt
MODQT_UIC= ${LOCALBASE}/bin/uic3-mt
MODQT_QTDIR=${LOCALBASE}/lib/qt3
MODQT_PLUGINS= lib/qt3/plugins-30
.if ${MODQT_MT:L} != "yes"
ERRORS+="Fatal: support QTMT only"
.endif
CONFIGURE_ENV+= ${_MODQT_SETUP}
MAKE_ENV+= ${_MODQT_SETUP}
MAKE_FLAGS+=${_MODQT_SETUP}
qmake-mt -makefile \
-spec ${MODQT_LIBDIR}/mkspecs/openbsd-g++ \
-unix \
"LIBS+=-L/usr/local/lib -lm -lqt-mt" \
"PREFIX=${LOCALBASE}" \
"INCLUDEPATH+=${MODQT_INCDIR}" \
"UIC=${MODQT_UIC}" \
"MOC=${MODQT_MOC}" \
.pro
Regards,
ahb
Re: OT? Is this bad news?
On Tue, Feb 13, 2007 at 09:38:51AM -0700, Steven wrote: > Hi, > > I happened to see this on the slashdot rss feed, and out of > curiosity took a look. > > Free Linux Driver Development FAQ > http://linux.slashdot.org/article.pl?sid=07/02/13/0220233&from=rss > > Is this bad news for the OpenBSD developers efforts to free hardware > documentation? If it is, how can OpenBSD users, and users of other > FOSS, help? > > -- > W. Steven Schneider <[EMAIL PROTECTED]> I read the same thing in the German 'linuxuser' magazin this morning, if I were the hulk, everything would have went green. Seriously WTF are those guys thinking? Nothing? There is no use to binary source drivers, they are not free/usable, whether they are distributed as binaries by the vendor, or written under NDAs doesn't make a difference at all. You know what happends when I tell my linux friends? Their argumentation goes along the lines of: "You shouldn't be such a idealist, be more pragmatic". Damn it! Okay sorry, there is no use the preach to the saints here, but what should one do against it? Good moment to once more thank the OpenBSD devs for their 'long term pragmatics' instead of short lived 'well, now it works'. Regards, ahb
Re: OT? Is this bad news?
Jeff Rollin wrote: Also as I understand it, they cannot work under NDA's, so any specs released to them would be released to the public. They say quite the opposite at http://www.kroah.com/log/linux/free_drivers_faq.html: Q: How are you going to write a GPL driver by signing an NDA? Is it going to require a binary blob or some other way of obfuscating the code? A: No, not at all. I have written many drivers after signing NDAs with companies. They are usually signed either to keep information about the device private until it is announced at a specific date, or to just keep the actual specification documents from being released to the public directly. All code created by this NDA program is to be released under the GPL for inclusion in the main kernel tree, nothing will be obfuscated at all. -- Jack J. Woehr Director of Development Absolute Performance, Inc. [EMAIL PROTECTED] 303-443-7000 ext. 527
Re: OT? Is this bad news?
On 13/02/07, Steven <[EMAIL PROTECTED]> wrote: > > Hi, > > I happened to see this on the slashdot rss feed, and out of > curiosity took a look. > > Free Linux Driver Development FAQ > http://linux.slashdot.org/article.pl?sid=07/02/13/0220233&from=rss > > Is this bad news for the OpenBSD developers efforts to free hardware > documentation? If it is, how can OpenBSD users, and users of other > FOSS, help? > > -- > W. Steven Schneider <[EMAIL PROTECTED]> > > Well as I understand it one of the things they are looking for are specs on which to base their own drivers. Also as I understand it, they cannot work under NDA's, so any specs released to them would be released to the public. This is only bad if the specs are released under a licence that would prohibit OBSD people from looking at them. If companies go so far as releasing the specs to Linux people, I can't see that happening, although of course using the GPL'ed Linux drivers released under such conditions would/might be problematic. Maybe it's time for the OBSD dev community to make similar overtures, though, just in case Jeff R
Finding Qt headers on OBSD 4.0
Anyone knows the secret trick what to do to make a Qt app find the Qt headers? [EMAIL PROTECTED]:~/kphone$ CXXFLAGS="-I/usr/local/include -I/usr/local/lib/qt3/include" LDFLAGS="-L/usr/local/lib -L/usr/local/lib/qt3/lib" ./configure [...] checking location of Qt header files... not found. Giving up. CL<
Re: qt-mt.pc
On Tue, Feb 13, 2007 at 04:41:06PM +0100, Karel Kulhavy wrote: > Trying to compile twinkle-0.1 I am getting this ./configure error: > checking for qt-mt >= 3.3.0 qt-mt < 4.0... Package qt-mt was not found in the > pkg-config search path. Perhaps you should add the directory containing > `qt-mt.pc' to the PKG_CONFIG_PATH environment variable No package 'qt-mt' > found > configure: error: Library requirements (qt-mt >= 3.3.0 qt-mt < 4.0) not met; > consider adjusting the PKG_CONFIG_PATH environment variable if your libraries > are in a nonstandard prefix so pkg-config can find them. > > There is no qt-mt.pc on my system, nor even qt3-mt.pc. I have qt3-mt-3.5p8.tgz > package installed. What should I put into the PKG_CONFIG_PATH then when > qt-mt.pc doesn't exist on the system? > > CL< There is *no* qt-mt.pc file in the standard qt distribution. You need to tell configure to fuck off, we're not debian nor redhat.
OT? Is this bad news?
Hi, I happened to see this on the slashdot rss feed, and out of curiosity took a look. Free Linux Driver Development FAQ http://linux.slashdot.org/article.pl?sid=07/02/13/0220233&from=rss Is this bad news for the OpenBSD developers efforts to free hardware documentation? If it is, how can OpenBSD users, and users of other FOSS, help? -- W. Steven Schneider <[EMAIL PROTECTED]>
OT: apache chroot query
This is slightly off topic, but since chroot has been integral to openbsd's apache longer than pretty much anywhere else, I figure you guys will probably have an answer for me. I've been beating my head against the monitor for a couple of days trying to figure out the best way to get some generated PHP code (rails-style) to run both in and out of the chroot environment, since it comes with a lot of paths that get hard coded into place, and I need to use the same codebase on the webserver and from the console. I finally had a minor epiphany, and created a /var/www/var/www symlink that points up to the chroot: $ pwd /var/www/var $ ls -l total 0 lrwxr-xr-x 1 root daemon 3 Feb 13 01:49 www -> ../ this works perfectly, my only question is whether there's any security concerns with such a setup that I should be aware of. Thanks in advance, Marti -- Systems Programmer, Senior Electrical & Computer Engineering The University of Arizona [EMAIL PROTECTED] (520) 465-6257
Re: SIP on OpenBSD
[EMAIL PROTECTED] wrote: I would rather design a PABX that could interface with existing non VOIP PABX at all. Again, this is about preference not advocacy. that's why your posting your FUD on-list, eh? asterisk + SPA-3000 + openbsd works fine for me. it's on TV, but it's not a commercial, i just want you to buy what i'm selling.
Re: dmesg and fdisk do not match about usb external disk
hmm, on Tue, Feb 13, 2007 at 08:18:50AM -0500, Kenneth R Westerback said that > OpenBSD aligns to boundaries. It just makes up the boundaries, as do > other OS's. It's unfortunate that all OS's don't make up the same > boundaries but until you can convince all OS developers to use the > same fake geometry you'll have to live with the current situation. > > OpenBSD makes absolutely no effort to get 'real' geometry > information from USB attached disks. Too many such devices simply > freak out and stop working when asked this difficult question. > Others make up even more bizarre geometries than the one we use. > > So OpenBSD uses 64*32, divides the number of sectors (which all > devices do provide) by this value to give a cylinder count, and > truncates the fractional cylinder. So up to 64*31 = 1984 sectors > will be 'wasted'. thanks for the src pointer, interesting. this explains the dmesg clearly, but what about fdisk? fdisk is supposed to get the geometry from the the bios (not much help for usb disks i guess) and then the disklabel. is disklabel using the same fake magic? in the case of the 160G disk[1], there must be something wrong as the dmesg total number of sectors is the same as the fdisk total number of sectors, while it's pretty clear that not all of the disk is usable and there is a 5103 sectors of waste... i believe you when you say a lot of umass stuff is broken and choking on basic calls. but wouldn't it make sense to tell sd_get_parms() to go ahead and query an actual geometry in case of "external hdd" usb devices? are the usb disks just as broken as any random umass device in this respect? i don't have a netbsd install to test it, but their approach seems te be not as discriminative towards umass devices[2]... btw this disk (wd passport) is strange in more respects. first of all, partition magic got its geometry wrong also a couple of times: 310,101 Cylinders, 16 Heads, 63 Sectors/Track but then 19,457 Cylinders, 255 Heads, 63 Sectors/Track[2]. second: 14:48:07 a /bsd: sd0(umass0:1:0): Check Condition (error 0x70) on opcode 0x2a 14:48:07 a /bsd: SENSE KEY: Illegal Request 14:48:07 a /bsd: ASC/ASCQ: Logical Block Address Out of Range 14:50:21 a /bsd: sd0(umass0:1:0): Check Condition (error 0x70) on opcode 0x2a 14:50:21 a /bsd: SENSE KEY: Illegal Request 14:50:21 a /bsd: ASC/ASCQ: Logical Block Address Out of Range 14:50:56 a /bsd: sd0(umass0:1:0): Check Condition (error 0x70) on opcode 0x2a 14:50:56 a /bsd: SENSE KEY: Illegal Request 14:50:56 a /bsd: ASC/ASCQ: Logical Block Address Out of Range 14:53:53 a /bsd: sd0(umass0:1:0): Check Condition (error 0x70) on opcode 0x2a 14:53:53 a /bsd: SENSE KEY: Illegal Request 14:53:53 a /bsd: ASC/ASCQ: Logical Block Address Out of Range so this baby is certainly going back where it came from... -f 1. http://marc.theaimsgroup.com/?l=openbsd-misc&m=117133082530013 2. http://opengrok.netbsd.org/source/xref/sys/dev/scsipi/sd.c#sd_get_parms 3. http://marc.theaimsgroup.com/?l=openbsd-misc&m=116475065104125&w=4 -- the word of the day is legs. now spread the word!
qt-mt.pc
Trying to compile twinkle-0.1 I am getting this ./configure error: checking for qt-mt >= 3.3.0 qt-mt < 4.0... Package qt-mt was not found in the pkg-config search path. Perhaps you should add the directory containing `qt-mt.pc' to the PKG_CONFIG_PATH environment variable No package 'qt-mt' found configure: error: Library requirements (qt-mt >= 3.3.0 qt-mt < 4.0) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. There is no qt-mt.pc on my system, nor even qt3-mt.pc. I have qt3-mt-3.5p8.tgz package installed. What should I put into the PKG_CONFIG_PATH then when qt-mt.pc doesn't exist on the system? CL<
Re: SIP on OpenBSD
It works if you intend that machine as VOIP only. But I don't think without zaptel/libpri, you can connect it to existing PABX or PSTN. > It seems that you are not understanding * architecture well. > > As I know zaptel is required for analog FXO/FXS cards from digium and > libpri for T1/E1 cards. But they have nothing to do with VoIP, which is > SIP, IAX ... > > I have never ran asterisk on OBSD, but I believe it works (I mean > asterisk only, no zaptel and libpri) > > Shohrukh > > [EMAIL PROTECTED] wrote: >> I don't know for sure how you did it. But I been working with >> Asterisk+Zaptel+Libpri here in UK >> both for personnal and commercial VOIP applications. My success so far on >> the BSDs is with >> FreeBSD >> and never had any single damn problem. I have and reviewed the specs of >> digium over and over >> again >> that zaptel is the device driver for the NIC card that talks to the kernel. >> If you claimed that >> you made OpenBSD run asterisk, then that is something worthwhile to talk >> about. But as I could >> see, your setup is making your machine connecting to some other machine >> elsewhere. Well, in my >> opinion it would be nice if one could put zaptel+libpri+asterisk under one >> box just as a typical >> pabx. >> >> FYI, I do not used softphones and I prefer hardphones. >> >> >>> On Tue, Feb 13, 2007 at 10:39:59AM -, [EMAIL PROTECTED] wrote: >>> | If zaptel won't work in openbsd, there is no way for asterisk be >>> installed. Hence, no chance >>> for >>> | any SIP protocol to work. But in case you want to get SIP running on the >>> BSDs, I suggest you >>> go >>> | over to FreeBSD. >>> >>> I've been running a PBX with Asterisk and OpenBSD for quite some time >>> now. I'm very happy with the resulting uptime and functionality. I've >>> used an IAX softphone (LoudHush, MacOSX payware) and a few hardware >>> SIP phones. It connects to a SIP provider in the Netherlands to >>> connect to the rest of the world. No zaptel in my (sparc64) machine. >>> >>> I would also like a softphone (preferably IAX based, but SIP would be >>> fine too I suppose) in the OpenBSD ports tree, but not having one does >>> not make Asterisk on OpenBSD useless. >>> >>> Cheers, >>> >>> Paul 'WEiRD' de Weerd >>> >>> -- >>> [<++>-]<+++.>+++[<-->-]<.>+++[<+ >>> +++>-]<.>++[<>-]<+.--.[-] >>> http://www.weirdnet.nl/
Re: dmesg and fdisk do not match about usb external disk
On Tue, Feb 13, 2007 at 07:55:16AM -0600, Matthew R. Dempsky wrote: > On Tue, Feb 13, 2007 at 08:18:50AM -0500, Kenneth R Westerback wrote: > > So OpenBSD uses 64*32, divides the number of sectors (which all > > devices do provide) by this value to give a cylinder count, and > > truncates the fractional cylinder. So up to 64*31 = 1984 sectors > > will be 'wasted'. > > > > Windows uses 255 * 63, so up to 255 * 62 = 15,810 sectors could be > > 'wasted'. > > Shouldn't the potential waste be 64*32-1 = 2047 and 255*63-1 = 16064, > respectively? > OK, arithmetic has never been my strong suit. I knew you had to subract 1 from something. I can only say I had not had my morning tea yet. :-). Ken
Re: dmesg and fdisk do not match about usb external disk
On 13/02/2007, at 10:07 PM, frantisek holop wrote: hmm, on Tue, Feb 13, 2007 at 08:56:24PM +1100, Shane J Pearson said that On 13/02/2007, at 8:18 PM, frantisek holop wrote: how am i (and fdisk) supposed to make partitions on CHS boundaries if instead of 19457/255/63 fdisk sees the disk as 152627/64/32? What is the point in trying to align to such boundaries, when the physical HDD does not have 255 or 64 heads and those numbers are faked due to working around legacy limitations? fdisk(8): CAVEATS Hand crafted disk layouts are highly error prone. MBR partitions should start on a cylinder boundary (head 0, sector 1), except when starting on track 0, (these should begin at head 1, sector 1). MBR partitions should also end at cylinder boundaries. as far as i know most of the other OSs also align to boundaries. Thanks Frantisek, I must have spent too much time away from arches which use MBR. I wondered for a second why my sparc64 firewall was returning "no entry" for man fdisk. :-) Shane J Pearson shanejp netspace net au
Re: SIP on OpenBSD
It seems that you are not understanding * architecture well. As I know zaptel is required for analog FXO/FXS cards from digium and libpri for T1/E1 cards. But they have nothing to do with VoIP, which is SIP, IAX ... I have never ran asterisk on OBSD, but I believe it works (I mean asterisk only, no zaptel and libpri) Shohrukh [EMAIL PROTECTED] wrote: I don't know for sure how you did it. But I been working with Asterisk+Zaptel+Libpri here in UK both for personnal and commercial VOIP applications. My success so far on the BSDs is with FreeBSD and never had any single damn problem. I have and reviewed the specs of digium over and over again that zaptel is the device driver for the NIC card that talks to the kernel. If you claimed that you made OpenBSD run asterisk, then that is something worthwhile to talk about. But as I could see, your setup is making your machine connecting to some other machine elsewhere. Well, in my opinion it would be nice if one could put zaptel+libpri+asterisk under one box just as a typical pabx. FYI, I do not used softphones and I prefer hardphones. On Tue, Feb 13, 2007 at 10:39:59AM -, [EMAIL PROTECTED] wrote: | If zaptel won't work in openbsd, there is no way for asterisk be installed. Hence, no chance for | any SIP protocol to work. But in case you want to get SIP running on the BSDs, I suggest you go | over to FreeBSD. I've been running a PBX with Asterisk and OpenBSD for quite some time now. I'm very happy with the resulting uptime and functionality. I've used an IAX softphone (LoudHush, MacOSX payware) and a few hardware SIP phones. It connects to a SIP provider in the Netherlands to connect to the rest of the world. No zaptel in my (sparc64) machine. I would also like a softphone (preferably IAX based, but SIP would be fine too I suppose) in the OpenBSD ports tree, but not having one does not make Asterisk on OpenBSD useless. Cheers, Paul 'WEiRD' de Weerd -- [<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: dmesg and fdisk do not match about usb external disk
On Tue, Feb 13, 2007 at 08:18:50AM -0500, Kenneth R Westerback wrote: > So OpenBSD uses 64*32, divides the number of sectors (which all > devices do provide) by this value to give a cylinder count, and > truncates the fractional cylinder. So up to 64*31 = 1984 sectors > will be 'wasted'. > > Windows uses 255 * 63, so up to 255 * 62 = 15,810 sectors could be > 'wasted'. Shouldn't the potential waste be 64*32-1 = 2047 and 255*63-1 = 16064, respectively?
Re: linux emulation without redhat_base
On Tue, Feb 13, 2007 at 11:21:19AM +0100, Karel Kulhavy wrote: > [EMAIL PROTECTED]:~$ ./ekiga > ./ekiga: error while loading shared libraries: libstdc++.so.6: cannot handle > TLS data TLS in this context probably refers to Thread Local Storage. I don't think it's C++ specific though.
Re: dmesg and fdisk do not match about usb external disk
On Tue, Feb 13, 2007 at 12:07:57PM +0100, frantisek holop wrote: > hmm, on Tue, Feb 13, 2007 at 08:56:24PM +1100, Shane J Pearson said that > > On 13/02/2007, at 8:18 PM, frantisek holop wrote: > > > > >how am i (and fdisk) supposed to make partitions on CHS boundaries > > >if instead of 19457/255/63 fdisk sees the disk as 152627/64/32? > > > > What is the point in trying to align to such boundaries, when the > > physical HDD does not have 255 or 64 heads and those numbers are > > faked due to working around legacy limitations? > > fdisk(8): > > CAVEATS > Hand crafted disk layouts are highly error prone. MBR partitions should > start on a cylinder boundary (head 0, sector 1), except when starting on > track 0, (these should begin at head 1, sector 1). MBR partitions should > also end at cylinder boundaries. > > > as far as i know most of the other OSs also align to boundaries. > > -f > -- > the borg are coming! quick! try and look useless! > OpenBSD aligns to boundaries. It just makes up the boundaries, as do other OS's. It's unfortunate that all OS's don't make up the same boundaries but until you can convince all OS developers to use the same fake geometry you'll have to live with the current situation. OpenBSD makes absolutely no effort to get 'real' geometry information from USB attached disks. Too many such devices simply freak out and stop working when asked this difficult question. Others make up even more bizarre geometries than the one we use. So OpenBSD uses 64*32, divides the number of sectors (which all devices do provide) by this value to give a cylinder count, and truncates the fractional cylinder. So up to 64*31 = 1984 sectors will be 'wasted'. Windows uses 255 * 63, so up to 255 * 62 = 15,810 sectors could be 'wasted'. Interested parties can examine /usr/src/sys/scsi/sd.c, lines 1344 and 1453. Ken
"sh checkflist" after "make release" of 4.0-stable gives starnge result.
Hello, I made a 4.0-stable "make release" on the amd64 architecture. Running "sh checkflist" gives this: # sh checkflist 14877a14878 > ./usr/share/zoneinfo/Africa/Asmara 14945a14947 > ./usr/share/zoneinfo/America/Atikokan 14950a14953 > ./usr/share/zoneinfo/America/Blanc-Sablon 15035a15039 > ./usr/share/zoneinfo/America/North_Dakota/New_Salem 15180a15185 > ./usr/share/zoneinfo/Atlantic/Faroe 15194a15200 > ./usr/share/zoneinfo/Australia/Eucla 15286a15293 > ./usr/share/zoneinfo/Europe/Guernsey 15287a15295 > ./usr/share/zoneinfo/Europe/Isle_of_Man 15288a15297 > ./usr/share/zoneinfo/Europe/Jersey 15303a15313 > ./usr/share/zoneinfo/Europe/Podgorica 15321a15332 > ./usr/share/zoneinfo/Europe/Volgograd 15443a15455 > ./usr/share/zoneinfo/posix/Africa/Asmara 15511a15524 > ./usr/share/zoneinfo/posix/America/Atikokan 15516a15530 > ./usr/share/zoneinfo/posix/America/Blanc-Sablon 15601a15616 > ./usr/share/zoneinfo/posix/America/North_Dakota/New_Salem 15746a15762 > ./usr/share/zoneinfo/posix/Atlantic/Faroe 15760a15777 > ./usr/share/zoneinfo/posix/Australia/Eucla 15852a15870 > ./usr/share/zoneinfo/posix/Europe/Guernsey 15853a15872 > ./usr/share/zoneinfo/posix/Europe/Isle_of_Man 15854a15874 > ./usr/share/zoneinfo/posix/Europe/Jersey 15869a15890 > ./usr/share/zoneinfo/posix/Europe/Podgorica 15887a15909 > ./usr/share/zoneinfo/posix/Europe/Volgograd 16010a16033 > ./usr/share/zoneinfo/right/Africa/Asmara 16078a16102 > ./usr/share/zoneinfo/right/America/Atikokan 16083a16108 > ./usr/share/zoneinfo/right/America/Blanc-Sablon 16168a16194 > ./usr/share/zoneinfo/right/America/North_Dakota/New_Salem 16313a16340 > ./usr/share/zoneinfo/right/Atlantic/Faroe 16327a16355 > ./usr/share/zoneinfo/right/Australia/Eucla 16419a16448 > ./usr/share/zoneinfo/right/Europe/Guernsey 16420a16450 > ./usr/share/zoneinfo/right/Europe/Isle_of_Man 16421a16452 > ./usr/share/zoneinfo/right/Europe/Jersey 16436a16468 > ./usr/share/zoneinfo/right/Europe/Podgorica 16454a16487 > ./usr/share/zoneinfo/right/Europe/Volgograd What does this actually mean? Thank you very much. Kind re
Re: SIP in OpenBSD
If one's intention is to run just purely VOIP softphones and hardphones, the asterisk software alone is enough to do the job. Whereas, if you want to interface you machine to an existing old pabx or if you want your openbsd machine to work with pstn at your location then you need to get zaptel+libpri working on your machine.
Re: SIP on OpenBSD
I would rather design a PABX that could interface with existing non VOIP PABX at all. Again, this is about preference not advocacy. > [EMAIL PROTECTED] wrote: >> that zaptel is the device driver for the NIC card that talks to the kernel. > > No, it's the device driver/API for telephony (Digium and Tormenta) > cards, not NIC cards. > >> If you claimed that >> you made OpenBSD run asterisk, then that is something worthwhile to talk >> about. > > It's not a claim, it's a fact. It's in the ports tree and it works. > >> But as I could >> see, your setup is making your machine connecting to some other machine >> elsewhere. > > That's what most VOIP systems do. Would be pretty pointless if it didnt > communicate with other VOIP systems. > >> Well, in my >> opinion it would be nice if one could put zaptel+libpri+asterisk under one >> box just as a typical >> pabx. > > And indeed the *only* thing missing on OpenBSD is the ability to > interface directly with an *existing* non-VOIP PBX or non-VOIP phones. > You can design and implement a perfectly functioning VOIP PBX on OpenBSD > as long as you don't need the OpenBSD box to interface directly with a > traditional PBX or telephone. > >> FYI, I do not used softphones and I prefer hardphones. > > It's of no relevance, both works with Asterisk (and SER) on OpenBSD. > > --- > Lars Hansson
Re: SIP on OpenBSD
On Tue, Feb 13, 2007 at 10:39:59AM -, [EMAIL PROTECTED] wrote: > If zaptel won't work in openbsd, there is no way for asterisk be installed. > Hence, no chance for > any SIP protocol to work. But in case you want to get SIP running on the > BSDs, I suggest you go > over to FreeBSD. I'm guessing no one advocating using asterisk or zaptel interfaces has read any of the code, the zaptel driver in particular is really gross in addition to the problems associated with the design of the hardware.
Re: SIP on OpenBSD
[EMAIL PROTECTED] wrote: that zaptel is the device driver for the NIC card that talks to the kernel. No, it's the device driver/API for telephony (Digium and Tormenta) cards, not NIC cards. If you claimed that you made OpenBSD run asterisk, then that is something worthwhile to talk about. It's not a claim, it's a fact. It's in the ports tree and it works. But as I could see, your setup is making your machine connecting to some other machine elsewhere. That's what most VOIP systems do. Would be pretty pointless if it didnt communicate with other VOIP systems. Well, in my opinion it would be nice if one could put zaptel+libpri+asterisk under one box just as a typical pabx. And indeed the *only* thing missing on OpenBSD is the ability to interface directly with an *existing* non-VOIP PBX or non-VOIP phones. You can design and implement a perfectly functioning VOIP PBX on OpenBSD as long as you don't need the OpenBSD box to interface directly with a traditional PBX or telephone. FYI, I do not used softphones and I prefer hardphones. It's of no relevance, both works with Asterisk (and SER) on OpenBSD. --- Lars Hansson
Re: SIP on OpenBSD
Well we have different experience and approaches. I want a VOIP PABX and I find it easier to play with voip telephony system if I have all what is listed as requirements on the asterisk website. > [EMAIL PROTECTED] wrote: >> Unless zaptel is supported under the OpenbSD platform, then there is no way >> you can get sip >> protocol run on OpenBSD platform. > > There are software SIP clients, you know. Like Ekiga, KCall, KPhone etc. > It's just that no one as ported them yet. > SIP has NOTHING to do with zaptel and both Asterisk and SER are in the > ports tree. zaptel is only required if you want to use digium cards to > interface with a PBX or similar. > > --- > Lars Hansson
Re: SIP on OpenBSD
I don't know for sure how you did it. But I been working with Asterisk+Zaptel+Libpri here in UK both for personnal and commercial VOIP applications. My success so far on the BSDs is with FreeBSD and never had any single damn problem. I have and reviewed the specs of digium over and over again that zaptel is the device driver for the NIC card that talks to the kernel. If you claimed that you made OpenBSD run asterisk, then that is something worthwhile to talk about. But as I could see, your setup is making your machine connecting to some other machine elsewhere. Well, in my opinion it would be nice if one could put zaptel+libpri+asterisk under one box just as a typical pabx. FYI, I do not used softphones and I prefer hardphones. > On Tue, Feb 13, 2007 at 10:39:59AM -, [EMAIL PROTECTED] wrote: > | If zaptel won't work in openbsd, there is no way for asterisk be installed. > Hence, no chance for > | any SIP protocol to work. But in case you want to get SIP running on the > BSDs, I suggest you go > | over to FreeBSD. > > I've been running a PBX with Asterisk and OpenBSD for quite some time > now. I'm very happy with the resulting uptime and functionality. I've > used an IAX softphone (LoudHush, MacOSX payware) and a few hardware > SIP phones. It connects to a SIP provider in the Netherlands to > connect to the rest of the world. No zaptel in my (sparc64) machine. > > I would also like a softphone (preferably IAX based, but SIP would be > fine too I suppose) in the OpenBSD ports tree, but not having one does > not make Asterisk on OpenBSD useless. > > Cheers, > > Paul 'WEiRD' de Weerd > > -- >>[<++>-]<+++.>+++[<-->-]<.>+++[<+ > +++>-]<.>++[<>-]<+.--.[-] > http://www.weirdnet.nl/
Re: dmesg and fdisk do not match about usb external disk
hmm, on Tue, Feb 13, 2007 at 08:56:24PM +1100, Shane J Pearson said that > On 13/02/2007, at 8:18 PM, frantisek holop wrote: > > >how am i (and fdisk) supposed to make partitions on CHS boundaries > >if instead of 19457/255/63 fdisk sees the disk as 152627/64/32? > > What is the point in trying to align to such boundaries, when the > physical HDD does not have 255 or 64 heads and those numbers are > faked due to working around legacy limitations? fdisk(8): CAVEATS Hand crafted disk layouts are highly error prone. MBR partitions should start on a cylinder boundary (head 0, sector 1), except when starting on track 0, (these should begin at head 1, sector 1). MBR partitions should also end at cylinder boundaries. as far as i know most of the other OSs also align to boundaries. -f -- the borg are coming! quick! try and look useless!
Re: SIP on OpenBSD
[EMAIL PROTECTED] wrote: Unless zaptel is supported under the OpenbSD platform, then there is no way you can get sip protocol run on OpenBSD platform. There are software SIP clients, you know. Like Ekiga, KCall, KPhone etc. It's just that no one as ported them yet. SIP has NOTHING to do with zaptel and both Asterisk and SER are in the ports tree. zaptel is only required if you want to use digium cards to interface with a PBX or similar. --- Lars Hansson
Re: SIP on OpenBSD
On Tue, Feb 13, 2007 at 10:39:59AM -, [EMAIL PROTECTED] wrote: | If zaptel won't work in openbsd, there is no way for asterisk be installed. Hence, no chance for | any SIP protocol to work. But in case you want to get SIP running on the BSDs, I suggest you go | over to FreeBSD. I've been running a PBX with Asterisk and OpenBSD for quite some time now. I'm very happy with the resulting uptime and functionality. I've used an IAX softphone (LoudHush, MacOSX payware) and a few hardware SIP phones. It connects to a SIP provider in the Netherlands to connect to the rest of the world. No zaptel in my (sparc64) machine. I would also like a softphone (preferably IAX based, but SIP would be fine too I suppose) in the OpenBSD ports tree, but not having one does not make Asterisk on OpenBSD useless. Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/ [demime 1.01d removed an attachment of type application/pgp-signature]
Re: SIP on OpenBSD
On Tue, Feb 13, 2007 at 10:39:59AM -, [EMAIL PROTECTED] wrote: > If zaptel won't work in openbsd, there is no way for asterisk be > installed. Hence, no chance for any SIP protocol to work. But in case > you want to get SIP running on the BSDs, I suggest you go over to > FreeBSD. You still can use asterisk on OpenBSD as SIP registrar with enhanced features. The only thing that does not work is using Asterisk as a VoIP gateway to PoTS. > > > On Tue, Feb 13, 2007 at 09:57:20AM -, [EMAIL PROTECTED] wrote: > >> In my opinion, if you could install asterisk+zaptel+libpri in openbsd, > >> then I could not see any reason why you cannot get SIP running on it. > >> > >> > Did anyone succeed in installing any SIP client on OpenBSD? > >> > > > > > The only problem is that we don't support zaptel. It is an incredible ugly > > interface that only works with the digium cards that are not supported. > > > > -- > > :wq Claudio > -- :wq Claudio
Re: SIP on OpenBSD
Unless zaptel is supported under the OpenbSD platform, then there is no way you can get sip protocol run on OpenBSD platform. I have read in the digium mailing lists that work is on the way in transferring the success of digium-based cards to either the NetBSD/OpenBSD. >>Claudio Jeker wrote: >> On Tue, Feb 13, 2007 at 09:57:20AM -, [EMAIL PROTECTED] wrote: >>> In my opinion, if you could install asterisk+zaptel+libpri in openbsd, >>> then I could not see any reason why you cannot get SIP running on it. >>> Did anyone succeed in installing any SIP client on OpenBSD? >> >> The only problem is that we don't support zaptel. It is an incredible ugly >> interface that only works with the digium cards that are not supported. >> > > Also, the OP asked for a SIP client, not a about running a SIP server. > AFAIk there are no SIP clients in the ports tree. > > --- > Lars Hansson
Re: SIP on OpenBSD
If zaptel won't work in openbsd, there is no way for asterisk be installed. Hence, no chance for any SIP protocol to work. But in case you want to get SIP running on the BSDs, I suggest you go over to FreeBSD. > On Tue, Feb 13, 2007 at 09:57:20AM -, [EMAIL PROTECTED] wrote: >> In my opinion, if you could install asterisk+zaptel+libpri in openbsd, >> then I could not see any reason why you cannot get SIP running on it. >> >> > Did anyone succeed in installing any SIP client on OpenBSD? >> > > > The only problem is that we don't support zaptel. It is an incredible ugly > interface that only works with the digium cards that are not supported. > > -- > :wq Claudio
Re: linux emulation without redhat_base
On Mon, Feb 12, 2007 at 10:12:09PM +0200, [EMAIL PROTECTED] wrote: > On Mon, Feb 12, 2007 at 06:04:36PM +0100, Karel Kulhavy wrote: > > 16287 yes CALL #243 (unimplemented linux_sys_set_thread_area)() > > 16287 yes PSIG SIGSYS SIG_DFL code 0 > > 16287 yes NAMI "yes.core" > > > > What does this mean? That linux_sys_set_thread_area is unimplemented in the > > emulation? > > > > IIRC, it's like that: > > The linux ld-linux.so dynamic linker calls uname(), gets the version > of the kernel (4.0 on OpenBSD), and based on the fact that 4.0 > 2.5.58 > (or something similar) decides that you're running a 2.6.X NPTL-able > kernel, and goes on to set up things for NTPL threads with > set_thread_area(), etc, even if the program is a non-threaded one. > > The solution to that is to run the linux binary with > > LD_ASSUME_KERNEL=2.4.2 > > in the environment. Now I avoided the NTPL problem by removing the redhat base and copying only the libraries that printed an error that it wants them. But when I copied libstdc++.so.6 it now print: [EMAIL PROTECTED]:~$ ./ekiga ./ekiga: error while loading shared libraries: libstdc++.so.6: cannot handle TLS data I tried to google but didn't find any information what it means. Probably not Transport Layer Security. Any idea somehow who understands this C++ stuff? CL<
Re: COMPAT_LINUX IN KERNEL
On Mon, Feb 12, 2007 at 09:07:06AM -0800, [EMAIL PROTECTED] wrote: > Quoting Nick ! <[EMAIL PROTECTED]>: > > > On 2/12/07, Karel Kulhavy <[EMAIL PROTECTED]> wrote: > > > Hello > > > > > > How do I figure out if my kernel was compiled with COMPAT_LINUX option or > > not? > > > I didn't compile it. I put "COMPAT_LINUX openbsd kernel" into google but > > didn't > > > find anything useful in the first several pages. > > > > > > I have 4.0 on i386 installed from a CD it must be running the default > > kernel. > > > > http://www.openbsd.org/faq/faq9.html#Interact > > "OpenBSD/i386 is able to run Linux binaries when the kernel is > > compiled with the COMPAT_LINUX option and the runtime sysctl > > kern.emul.linux is also set. If you are using the GENERIC kernel > > (which you should be), COMPAT_LINUX is already enabled, and you will > > just need to do:" > > > > -Nick > > > > > > Why do static linux binaries at least sometimes run > without executing "sysctl kern.emul.linux=1" and > without removing the "#" in front of the line for > "kern.emul.linux=1" in /etc/sysctl.conf? Is there a way to take a dynamic binary on a Linux system and the dynamic libraries and make a static one from it? Isn't it that the libraries get linked and an image is created and that is then run? Isn't possible to dump the image to disk in an ELF form before it's executed? Then it would remove all the hassle with the dynamic libraries in Linux emulation. CL<
Re: SIP on OpenBSD
Claudio Jeker wrote: On Tue, Feb 13, 2007 at 09:57:20AM -, [EMAIL PROTECTED] wrote: In my opinion, if you could install asterisk+zaptel+libpri in openbsd, then I could not see any reason why you cannot get SIP running on it. Did anyone succeed in installing any SIP client on OpenBSD? The only problem is that we don't support zaptel. It is an incredible ugly interface that only works with the digium cards that are not supported. Also, the OP asked for a SIP client, not a about running a SIP server. AFAIk there are no SIP clients in the ports tree. --- Lars Hansson
Re: SIP on OpenBSD
On Tue, Feb 13, 2007 at 09:57:20AM -, [EMAIL PROTECTED] wrote: > In my opinion, if you could install asterisk+zaptel+libpri in openbsd, > then I could not see any reason why you cannot get SIP running on it. > > > Did anyone succeed in installing any SIP client on OpenBSD? > > The only problem is that we don't support zaptel. It is an incredible ugly interface that only works with the digium cards that are not supported. -- :wq Claudio
Re: dmesg and fdisk do not match about usb external disk
On 13/02/2007, at 8:18 PM, frantisek holop wrote: how am i (and fdisk) supposed to make partitions on CHS boundaries if instead of 19457/255/63 fdisk sees the disk as 152627/64/32? What is the point in trying to align to such boundaries, when the physical HDD does not have 255 or 64 heads and those numbers are faked due to working around legacy limitations? Shane J Pearson shanejp netspace net au
Re: SIP on OpenBSD
In my opinion, if you could install asterisk+zaptel+libpri in openbsd, then I could not see any reason why you cannot get SIP running on it. > Did anyone succeed in installing any SIP client on OpenBSD? > > CL<
SIP on OpenBSD
Did anyone succeed in installing any SIP client on OpenBSD? CL<
Re: dmesg and fdisk do not match about usb external disk
hmm, on Mon, Feb 12, 2007 at 06:23:31PM -0800, Marco S Hyman said that > frantisek holop writes: > > so what's up with these dick measurements? > > I think you got that part just right :-) > > Expecthing cyl * head * sec/cyl to come up with the number of actual > sectors on the disk is your problem. Modern disk don't have a fixed > number of sec/track. They use Zone Bit Recording which uses a different > number of sec/track depending upon the location of the track on the > disk. all i "expect" is consistency and the same kind of numbers accross diff OSes.. how am i (and fdisk) supposed to make partitions on CHS boundaries if instead of 19457/255/63 fdisk sees the disk as 152627/64/32? > The code tries to come up with an approximate CHS for historical > reasons. It would probably be best if it just reported the number > of sectors as that is the only important measure. ok, on the 500G disk the fdisk total no. of sectors did not equal to dmesg total no. of sectors. with this disk, it does. why is that? -f -- doubt is the beginning of wisdom
Re: Kernel Compile errors
I installed cvsup and ran cvsup -g -L 2 cvsup-file-src (my configuration file). Afterwards, I began the compile process using make clean && make depend && make && make install . make install needs to be run as root. Miod
Kernel Compile errors
I installed cvsup and ran cvsup -g -L 2 cvsup-file-src (my configuration
file). Afterwards, I began the compile process using
make clean && make depend && make && make install .
However, when the commands were running, this returned:
rm -f bsd
ld -Ttext 0xD0200120 -e start -N -S -x -o bsd ${SYSTEM_OBJ} vers.o
text data bss dec hex
5298463 217920 867984 6384367 616aef
rm -f/obsd
ln/bsd /obsd
ln: /obsd: Operation not permitted
*** Error code 1
