stable-digest V5 #780
owner-freebsd...@freebsd.org
stable-digest Friday, January 31 2003 Volume 05 : Number 780
In this issue:
Re: when make installkernel doesn't
Please test, big if_sis MFC for STABLE
Subscribe
subscribe
BTX halted message on Tyan Thunder motherboard ...
Re: BTX halted message on Tyan Thunder motherboard ...
IPF & IPFW
How to make ATA-100 work under stable ?
SCSI issues after upgrade from 4.5-RELEASE to 4.7-STABLE
Re: How to make ATA-100 work under stable ?
Re: How to make ATA-100 work under stable ?
Re: IPF & IPFW
Re: How to make ATA-100 work under stable ?
IPSEC problems after upgrade
Hospedagem profissional de domínios e sites
Re: SCSI issues after upgrade from 4.5-RELEASE to 4.7-STABLE
Re: SCSI issues after upgrade from 4.5-RELEASE to 4.7-STABLE
Re: HEADS UP: fast ipsec committed
Re: HEADS UP: fast ipsec committed
Re: HEADS UP: fast ipsec committed
----------------------------------------------------------------------
Date: Thu, 30 Jan 2003 15:59:23 -0600 (CST)
From: "J.F. Noonan" <j...@msc.com>
Subject: Re: when make installkernel doesn't
On Wed, 29 Jan 2003 at 3:34pm Chris BeHanna wrote:
> On Wednesday 29 January 2003 11:44, J.F. Noonan wrote:
>
> make installworld doesn't touch the kernel bits
I mistyped, I'd meant installkernel.
In any event, the solution was to mount the correct partitions!
The machine has both an IDE and a SCSI drive. For some reason
that I never bothered to figure out, the system never would boot
from the SCSI drive so I left / on the IDE and put everything else
on the SCSI (once the system is up and running most of the
activity is on the SCSI, so performance is not hurt by this.)
Well at some point during the upgrade, presumably during
mergemaster, I must have said 'yes' to an offer to 'update' my
fstab. So after I rebooted I was running updated 4.7-stable on my
root drive and the VERY OLD 4.4 or 4.5 userland from the old IDE
partitions. (A long time ago the system had only the IDE).
Moral: not only should one do level 0 dumps before starting this
sort of thing (i was about 5 minutes from restoring mine), but do
try and remember how you actually build your systems before to
start messing about with them.
Thanks,
- --
Joseph F. Noonan
Rigaku/MSC Inc.
j...@msc.com
------------------------------
Date: Fri, 31 Jan 2003 00:08:51 +0100 (CET)
From: Martin Blapp <m...@imp.ch>
Subject: Please test, big if_sis MFC for STABLE
Hi all,
I plan to MFC this patch soon if there aren't any problem.
I'm very happy to get feed back if it doesn't work for your card,
please let me know. I just own one if_sis card, and the feedback
for the CURRENT version has been positive.
http://people.freebsd.org/~mbr/patches/if_sis_stable.diff
Martin
Martin Blapp, <m...@imp.ch> <m...@FreeBSD.org>
- ------------------------------------------------------------------
ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
PGP: <finger -l m...@freebsd.org>
PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
- ------------------------------------------------------------------
------------------------------
Date: Thu, 30 Jan 2003 15:08:39 -0800 (PST)
From: pat...@pspnet.ath.cx
Subject: Subscribe
Subscribe
------------------------------
Date: Fri, 31 Jan 2003 00:57:38 +0200
From: Patrick <pat...@pspnet.ath.cx>
Subject: subscribe
subscribe
------------------------------
Date: Thu, 30 Jan 2003 19:38:56 -0400 (AST)
From: "Marc G. Fournier" <scr...@hub.org>
Subject: BTX halted message on Tyan Thunder motherboard ...
Yesterday, trying to resolve a problem, we upgraded the BIOs to 1.07,
after which we started to get the BTX halted message above ... searching
the web, I've not found much in the way of solution, but the one I did see
talked about disabling teh BIOS DMA, in relation to a Compaq server, or
downgrading teh BIOs ... since we can't find a BIOS DMA setting in the
Tyan BIOS, we went with downgrading back to 1.06 ...
... but we're still getting it ...
I'm running 4.7-STABLE on this server, with one of teh Adaptec ZCR
controllers ... is there something else we should try?
------------------------------
Date: Thu, 30 Jan 2003 16:08:13 -0800
From: clark shishido <cl...@ruminary.org>
Subject: Re: BTX halted message on Tyan Thunder motherboard ...
On Thu, Jan 30, 2003 at 07:38:56PM -0400, Marc G. Fournier wrote:
>
> Yesterday, trying to resolve a problem, we upgraded the BIOs to 1.07,
> after which we started to get the BTX halted message above ... searching
> the web, I've not found much in the way of solution, but the one I did see
> talked about disabling teh BIOS DMA, in relation to a Compaq server, or
> downgrading teh BIOs ... since we can't find a BIOS DMA setting in the
> Tyan BIOS, we went with downgrading back to 1.06 ...
>
> ... but we're still getting it ...
>
> I'm running 4.7-STABLE on this server, with one of teh Adaptec ZCR
> controllers ... is there something else we should try?
>
There's a similar problem with Intel L440GX+ boards.
I've found that disabling the BIOS over COM1 feature
allows me to boot without errors. My guess is that the
board is hanging onto the serial port (console) when
the boot loader tries to write to it.
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/30125
but I don't remember Tyans having console redirection.
HTH.
- --clark
------------------------------
Date: 31 Jan 2003 19:06:03 +1300
From: Andrew Thompson <an...@fud.org.nz>
Subject: IPF & IPFW
Hi,
I am writing an app to do pre-pay internet and are using a combination
of ipf and ipfw. I stupidly assumed that ipfw ran before ipf, of course
its the other way around. This has put a hurdle in my design, is there
an easy way to change the order of the two? or do I need to redesign :(
Running 4.7p3
thanks,
Andy
------------------------------
Date: Fri, 31 Jan 2003 10:34:56 +0000
From: Pete French <pfr...@firstcallgroup.co.uk>
Subject: How to make ATA-100 work under stable ?
So, for the first time in my life I find myself going out and buying
an ATA drive (no space for a SCSI controller). Since I've more or
less ignored these drives until now I'm not finding it and easy (or
pleasent) experience. But have finally got to the point when its installed,
running 4.7-STABLE without complaining about implausible disc geometries
and generally seems O.K.
What I *cant* seem to do is to make it run at UDMA100 speed - it always
seems to do UDMA66. Whats the magic incantation under -STABLE to make it
work ? I did try 'atacontrol mode ata0 udma100' but that just
tells me that its not supported by the hardware.
The hardware in question is a Seagate BarracudaATA IV - I've run the Seagate
utility to set the drive to report itself as UDMA100 capable, I have installed
the 80 way ribbon connector and I have (as a last resort) flashed the
BIOS on the motherboard. The board itself is a Microstar dual PIII board,
and the drive controller appears to be called a "Promise" something
or other.
I have noticed that the BIOS on the controller says it is searching
for ATA-100 drives, but does not find any. On the other hand I assume that
BSD is not using the BIOS, so I am not sure if thats relevent.
Any ideas ? Is there soome kernel option for UDMA 100 that I am missing ?
- -pcf. [this is the first and last time I venture out of SCSI-land!]
------------------------------
Date: Fri, 31 Jan 2003 21:59:01 +1100
From: Steve Horan <sjh...@horan.net.au>
Subject: SCSI issues after upgrade from 4.5-RELEASE to 4.7-STABLE
Hi,
I cvsup'd a 4.5-RELEASE machine yesterday to latest -STABLE sources
and made world & new kernel.
The new (GENERIC) kernel no longer detects the SCSI disk. It detects
the sym0 SCSI controller fine, but no disk.
Booting with the old 4.5-RELEASE kernel finds it fine.
Has anyone else seen this behavior/know a fix?
I don't have physical access to the machine, but here's the info I can
pull from dmesg (using 4.5-RELEASE kernel) etc:
sym0: <875> port 0x5000-0x50ff mem
0xe0080000-0xe0080fff,0xe0100000-0xe01000ff irq 11 at device 12.0 on
pci1
sym0: No NVRAM, ID 7, Fast-20, SE, parity checking
da0 at sym0 bus 0 target 0 lun 0
da0: <COMPAQ WDE4360W 1.52> Fixed Direct Access SCSI-2 device
da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged
Queueing Enabled
da0: 4094MB (8386000 512 byte sectors: 255H 63S/T 522C)
From pciconf:
sym0@pci1:12:0: class=0x010000 card=0x00000000 chip=0x000f1000
rev=0x04 hdr=0x00
vendor = 'LSI Logic (Was: Symbios Logic, NCR)'
device = 'LSI53C875/E,LSI53C876/E PCI to Ultra SCSI I/O
Processor'
class = mass storage
subclass = SCSI
Any info would be great.
Regards,
sjh
------------------------------
Date: Fri, 31 Jan 2003 12:00:33 +0100 (CET)
From: Mats Larsson <myr...@marvin.sko.mh.se>
Subject: Re: How to make ATA-100 work under stable ?
Hello!
Once owned a MSI 694D PRO, on that only 2 ide ports was able to support
udma 100 and the two other only 33/66, my card worked nicely in udma 100
if a switched port.
// Mats
On Fri, 31 Jan 2003, Pete French wrote:
> So, for the first time in my life I find myself going out and buying
> an ATA drive (no space for a SCSI controller). Since I've more or
> less ignored these drives until now I'm not finding it and easy (or
> pleasent) experience. But have finally got to the point when its installed,
> running 4.7-STABLE without complaining about implausible disc geometries
> and generally seems O.K.
>
> What I *cant* seem to do is to make it run at UDMA100 speed - it always
> seems to do UDMA66. Whats the magic incantation under -STABLE to make it
> work ? I did try 'atacontrol mode ata0 udma100' but that just
> tells me that its not supported by the hardware.
>
> The hardware in question is a Seagate BarracudaATA IV - I've run the Seagate
> utility to set the drive to report itself as UDMA100 capable, I have installed
> the 80 way ribbon connector and I have (as a last resort) flashed the
> BIOS on the motherboard. The board itself is a Microstar dual PIII board,
> and the drive controller appears to be called a "Promise" something
> or other.
>
> I have noticed that the BIOS on the controller says it is searching
> for ATA-100 drives, but does not find any. On the other hand I assume that
> BSD is not using the BIOS, so I am not sure if thats relevent.
>
> Any ideas ? Is there soome kernel option for UDMA 100 that I am missing ?
>
> -pcf. [this is the first and last time I venture out of SCSI-land!]
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message
>
------------------------------
Date: Fri, 31 Jan 2003 05:01:52 -0600
From: Greg Panula <greg....@dolaninformation.com>
Subject: Re: How to make ATA-100 work under stable ?
Pete French wrote:
>
> So, for the first time in my life I find myself going out and buying
> an ATA drive (no space for a SCSI controller). Since I've more or
> less ignored these drives until now I'm not finding it and easy (or
> pleasent) experience. But have finally got to the point when its installed,
> running 4.7-STABLE without complaining about implausible disc geometries
> and generally seems O.K.
>
> What I *cant* seem to do is to make it run at UDMA100 speed - it always
> seems to do UDMA66. Whats the magic incantation under -STABLE to make it
> work ? I did try 'atacontrol mode ata0 udma100' but that just
> tells me that its not supported by the hardware.
>
> The hardware in question is a Seagate BarracudaATA IV - I've run the Seagate
> utility to set the drive to report itself as UDMA100 capable, I have installed
> the 80 way ribbon connector and I have (as a last resort) flashed the
> BIOS on the motherboard. The board itself is a Microstar dual PIII board,
> and the drive controller appears to be called a "Promise" something
> or other.
>
> I have noticed that the BIOS on the controller says it is searching
> for ATA-100 drives, but does not find any. On the other hand I assume that
> BSD is not using the BIOS, so I am not sure if thats relevent.
Ummm, if the controller isn't finding any UDMA100 drives, then your OS
isn't going have much better luck. The OS is dependant on what the BIOS
is reporting.
I'll guess the BIOS on the controller finds the drive but thinks it is a
UDMA66 drive. yes?
Since the controller isn't seeing any UDMA100 drives, the problem is
most likely with either the drive or controller. Try a different IDE
cable, setting the drive jumper to Master, setting the drive jumper to
'Cable Select', try the drive in another machine, try the drive under
another OS, etc, etc. The joys of trouble-shooting hardware. :)
Good Luck,
greg
------------------------------
Date: Fri, 31 Jan 2003 12:10:50 +0100 (CET)
From: =?iso-8859-1?q?Claus=20Guttesen?= <cgut...@yahoo.dk>
Subject: Re: IPF & IPFW
Hi.
> I am writing an app to do pre-pay internet and are
> using a combination
> of ipf and ipfw. I stupidly assumed that ipfw ran
> before ipf, of course
> its the other way around. This has put a hurdle in
You may wish to read
http://home.earthlink.net/~jaymzh666/ipf/IPFfreebsd.html#14.
This explains in what order ipf and ipfw is loaded.
If you want to let ipfw to process the ip-packet
first, you can remove ipfilter from the kernel and
load it as a module instead. This should solve your
problem.
regards
Claus
Har du problemer med din hjemmecomputer? Få hjælp med Yahoo!s PC-support på http://dk.shopping.yahoo.com/pcsupport/index.html
------------------------------
Date: Fri, 31 Jan 2003 12:41:49 +0100
From: Erik Trulsson <ertr...@student.uu.se>
Subject: Re: How to make ATA-100 work under stable ?
On Fri, Jan 31, 2003 at 10:34:56AM +0000, Pete French wrote:
> So, for the first time in my life I find myself going out and buying
> an ATA drive (no space for a SCSI controller). Since I've more or
> less ignored these drives until now I'm not finding it and easy (or
> pleasent) experience. But have finally got to the point when its installed,
> running 4.7-STABLE without complaining about implausible disc geometries
> and generally seems O.K.
>
> What I *cant* seem to do is to make it run at UDMA100 speed - it always
> seems to do UDMA66. Whats the magic incantation under -STABLE to make it
> work ? I did try 'atacontrol mode ata0 udma100' but that just
> tells me that its not supported by the hardware.
>
> The hardware in question is a Seagate BarracudaATA IV - I've run the Seagate
> utility to set the drive to report itself as UDMA100 capable, I have installed
> the 80 way ribbon connector and I have (as a last resort) flashed the
> BIOS on the motherboard. The board itself is a Microstar dual PIII board,
> and the drive controller appears to be called a "Promise" something
> or other.
>
> I have noticed that the BIOS on the controller says it is searching
> for ATA-100 drives, but does not find any. On the other hand I assume that
> BSD is not using the BIOS, so I am not sure if thats relevent.
>
> Any ideas ? Is there soome kernel option for UDMA 100 that I am missing ?
>
> -pcf. [this is the first and last time I venture out of SCSI-land!]
There is no magic incantation of kernel option for this. The only
thing that might work is using 'atacontrol mode' but since you have
already tried that it seems not not to be the solution.
(And making sure you have an 80-way cable, but you already have that.)
My first guess would be that your disk controller simply does not
support UDMA100 but only UDMA66 and slower. There are many slightly
older diskcontrollers that can't handle UDMA100 (mostly because the
controller was made before UDMA100 had been introduced.)
Similarily I have a drive that won't work in UDMA100 but only in
UDMA66, but that is beacuse the drive simply does not support UDMA100.
The bad news is that you probably won't be able to get the drive to
work in UDMA100 mode without getting a new controller.
The good news is that there really isn't that much of a difference
between UDMA66 and UDMA100. Either mode can transfer data faster than
the drive can deliver it.
- --
<Insert your favourite quote here.>
Erik Trulsson
ertr...@student.uu.se
------------------------------
Date: Fri, 31 Jan 2003 05:39:25 -0800
From: Peter Haight <pet...@sapros.com>
Subject: IPSEC problems after upgrade
I've now upgraded two machines that I use as IPSEC tunnel endpoints to
create a VPN. I used to use a script to setup the VPN that I will post
below, but that script no longer works and I haven't been able to figure out
why. Before I upgraded, the VPN was working fine. (Though maybe I had some
security hole that is now caught by FreeBSD and is preventing my VPN from
working.)
If I turn IPSEC off, the tunnel works fine, so it isn't a routing or
interface issue, it must be something wrong with the way I'm setting up
IPSEC. The only wierd thing I noticed was that on one of the machines, if I
do a 'netstat -sn -p ipsec', the 'inbound packets violated process security
policty' counter increases by one with every packet that host receives. That
does not seem to happen on the other other host.
Here's some setkey output:
192.168.1.1/24[any] 10.10.1.1/24[any] any
in ipsec
esp/tunnel/XX.XX.XX.XX-YY.YY.YY.YY/require
spid=24 seq=1 pid=24319
refcnt=1
10.10.1.1/24[any] 192.168.1.1/24[any] any
out ipsec
esp/tunnel/YY.YY.YY.YY-XX.XX.XX.XX/require
spid=23 seq=0 pid=24319
refcnt=1
setkey -DP (4.7-RELEASE):
10.10.1.1/24[any] 192.168.1.1/24[any] any
in ipsec
esp/tunnel/YY.YY.YY.YY-XX.XX.XX.XX/require
spid=4 seq=1 pid=8760
refcnt=1
192.168.1.1/24[any] 10.10.1.1/24[any] any
out ipsec
esp/tunnel/XX.XX.XX.XX-YY.YY.YY.YY/require
spid=3 seq=0 pid=8760
refcnt=1
Here's my script. I use the same script on both machines, but I switch the
local and remote variables. Note that the add SAD entry IPs do not use the
variables, so they are the same on both machines.
local_ip="XX.XX.XX.XX"
local_net_ip="10.10.1.1"
local_net_prefixlen="24"
remote_ip="YY.YY.YY.YY"
remote_net_ip="192.168.1.1"
remote_net_prefixlen="12"
remote_net_netmask="255.255.0.0"
ifconfig gif0 create
ifconfig gif0 tunnel ${local_ip} ${remote_ip}
ifconfig gif0 inet ${local_net_ip} ${remote_net_ip} netmask ${remote_net_netmask
}
setkey -c << EOF
flush;
spdflush;
add XX.XX.XX.XX YY.YY.YY.YY esp 9991 -E blowfish-cbc "foobar1";
add YY.YY.YY.YY XX.XX.XX.XX esp 9992 -E blowfish-cbc "foobar2";
spdadd ${local_net_ip}/${local_net_prefixlen} ${remote_net_ip}/${remote_net_pref
ixlen} any -P out ipsec esp/tunnel/${local_ip}-${remote_ip}/require;
spdadd ${remote_net_ip}/${remote_ne t_prefixlen} ${local_net_ip}/${local_net_prefixlen} any -P in ipsec esp/tunnel/${remote_ip}-${local_ip}/require;
EOF
------------------------------
Date: Fri, 31 Jan 2003 05:40:47 -0800 (PST)
From: "VirtualServ" <virt...@brfree.com.br>
Subject: Hospedagem profissional de domínios e sites
Esta mensagem está sendo enviada em resposta ao cadastro do seu e-mail em sites associados.
_________________________________________
HOSPEDAGEM PROFISSIONAL DE DOMÍNIOS E SITES
Servidores com plataformas: Windows - Unix
A VirtualServ oferece o mais completo plano de hospedagem profissional do mercado. Todas as possibilidades disponíveis hoje na WEB num só plano. O melhor servidor, a melhor conexão, o melhor suporte e recursos ilimitados.
Nosso serviço é top de linha entre os melhores servidores e temos como objetivo a sua satisfação e confiança. Visite-nos: http://virtualserv.com
_________________________________________
PAINEL DE CONTROLE - CPANEL
O painel de controle oferecido pela VirtualServ simplifica todos os comandos Unix em uma interface gráfica intuitiva e fácil de usar, agilizando a manutenção de sua conta.
Disponibilizamos essa ferramenta para todos os clientes.
_________________________________________
LOJA VIRTUAL GRÁTIS
Adquirindo o plano de hospedagem profissional da VirtualServ, você ganha uma Loja virtual Grátis totalmente automatizada e com e-commerce*. Você pode oferecer qualquer produto ou serviço que quiser com divulgação permanente na internet. Você também pode modificá-la de acordo com suas necessidades.
Na loja, você pode receber pelos seus produtos ou serviços através de depósito bancário, boleto ou cartão de crédito.
_________________________________________
Plano profissional de hospedagem com recursos ilimitados VirtualServ
Valor Mensal - R$ 21,00
Taxa única de Setup - R$: 15,00
Espaço em Disco 100 MB (ampliável)
Transferência Mensal 2 GB
Contas de E-mail POP3 personalizadas com anti-vírus - ilimitadas
Subdomínios - ilimitados
Redirecionamento de domínios - ilimitados
Contas de FTP individuais - ilimitadas
Bancos de Dados MY SQL 3.45 - ilimitados
Painel de Controle CPANEL - Sim
Diretório CGI-BIN - Sim
Estatísticas Completas - Sim
Loja Virtual GRÁTIS - Sim
ASP e tarefas CRON - Sim
Suporte Técnico - Sim
Software para e-commerce - Sim
Divulgação permanente na internet - Sim
_______________________________________________
Não perca tempo, entre hoje mesmo para a VirtualServ e obtenha o serviço mais completo do mercado ! Visite nosso site: http://www.virtualserv.com
Suporte online: sup...@virtualserv.com - Fones: (11)6567-3684 ou (11)9443-4276 - h/c - ICQ-141826334
______________________________________________
Esta mensagem será enviada apenas esta vez.
------------------------------
Date: Fri, 31 Jan 2003 11:06:28 -0800 (PST)
From: Nate Lawson <na...@root.org>
Subject: Re: SCSI issues after upgrade from 4.5-RELEASE to 4.7-STABLE
On Fri, 31 Jan 2003, Steve Horan wrote:
> I cvsup'd a 4.5-RELEASE machine yesterday to latest -STABLE sources
> and made world & new kernel.
>
> The new (GENERIC) kernel no longer detects the SCSI disk. It detects
> the sym0 SCSI controller fine, but no disk.
>
> Booting with the old 4.5-RELEASE kernel finds it fine.
I am not sure about this but try disabling some of the other devices in
GENERIC. It may be a new conflict.
- -Nate
------------------------------
Date: Fri, 31 Jan 2003 13:02:58 -0800 (PST)
From: Chuck McCrobie <mccrob...@yahoo.com>
Subject: Re: SCSI issues after upgrade from 4.5-RELEASE to 4.7-STABLE
- --- Steve Horan <sjh...@horan.net.au> wrote:
> Hi,
>
> I cvsup'd a 4.5-RELEASE machine yesterday to latest
> -STABLE sources
> and made world & new kernel.
>
> The new (GENERIC) kernel no longer detects the SCSI
> disk. It detects
> the sym0 SCSI controller fine, but no disk.
>
> Booting with the old 4.5-RELEASE kernel finds it
> fine.
>
> Has anyone else seen this behavior/know a fix?
>
> I don't have physical access to the machine, but
> here's the info I can
> pull from dmesg (using 4.5-RELEASE kernel) etc:
>
> sym0: <875> port 0x5000-0x50ff mem
> 0xe0080000-0xe0080fff,0xe0100000-0xe01000ff irq 11
> at device 12.0 on
> pci1
> sym0: No NVRAM, ID 7, Fast-20, SE, parity checking
>
> da0 at sym0 bus 0 target 0 lun 0
> da0: <COMPAQ WDE4360W 1.52> Fixed Direct Access
> SCSI-2 device
> da0: 40.000MB/s transfers (20.000MHz, offset 15,
> 16bit), Tagged
> Queueing Enabled
> da0: 4094MB (8386000 512 byte sectors: 255H 63S/T
> 522C)
>
I have a Western Digital ULTRA-WIDE disk that has
problems on -STABLE. Turns out the disk does not
issue a "ignore wide residual" message after
transferring inquiry data during FreeBSD's CAM
probing. As a result, CAM thinks there's an error and
refuses to attach to the disk.
I wonder if your Compaq disk is the same way. I
noticed that it also is a wide drive (16-bit).
If you are able to get to the BIOS of the SCSI
controller and there's an available option, try
setting the drive to 8-bit on the SCSI controller.
Then see if -STABLE will talk to it.
I'm _STILL_ running my Western Digital in NARROW mode.
I don't know if anyone will fix the ODD length
inquiry data request that CAM is issuing. But,
evidently, there are other possible fixes.
Please search freebsd-scsi for my messages about the
Western Digital.
Good luck,
Chuck McCrobie
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
------------------------------
Date: Fri, 31 Jan 2003 22:53:53 +0100 (CET)
From: Helge Oldach <stable...@oldach.net>
Subject: Re: HEADS UP: fast ipsec committed
Sam Leffler:
> I just commited my "Fast IPsec" support. This is an implementation of the
> IPsec protocols that makes use of the kernel crypto framework.
>
[...]
>
> There should be minimal user-visible differences from the KAME IPsec code.
> In particular you should be able to use racoon, setkey, isakmpd, or whatever
> as with KAME.
I had problems with racoon. My previous buildworld and kernel was of
January 19th while today's build (January 31st) effectively disabled
racoon. After tracing around a bit it seemed that racoon had problems
to parse its configuration file and some tokens were tracked down to
the wrong constants. I am using hmac_md5 authentication and racoon was
complaining "algorithm 1 not supported". Yes - "1" instead of a string
with the algorithm name.
It turned out that this (abridged) change was the culprit:
diff -r /usr/include/net/pfkeyv2.h /mnt/usr/include/net/pfkeyv2.h
1c1
< /* $FreeBSD: src/sys/net/pfkeyv2.h,v 1.4.2.4 2003/01/24 05:11:33 sam Exp $ */
- ---
> /* $FreeBSD: src/sys/net/pfkeyv2.h,v 1.4.2.3 2001/10/24 19:49:13 ume Exp $ */
303,305c303,305
< #define SADB_AALG_MD5HMAC 2
< #define SADB_AALG_SHA1HMAC 3
< #define SADB_AALG_MAX 251
- ---
> #define SADB_AALG_MD5HMAC 1 /*2*/
> #define SADB_AALG_SHA1HMAC 2 /*3*/
> #define SADB_AALG_MAX 8
Reinstalling racoon instantly fixed the issue. Probably other ISAKMP
daemons (e.g. isakmpd) are affected as well.
Note that quite a number of other constants were redefined by this
change, not just the ones mentioned in the diff excerpt above.
Regards,
Helge
------------------------------
Date: Fri, 31 Jan 2003 13:56:33 -0800
From: "Sam Leffler" <s...@errno.com>
Subject: Re: HEADS UP: fast ipsec committed
> Sam Leffler:
> > I just commited my "Fast IPsec" support. This is an implementation of
the
> > IPsec protocols that makes use of the kernel crypto framework.
> >
> [...]
> >
> > There should be minimal user-visible differences from the KAME IPsec
code.
> > In particular you should be able to use racoon, setkey, isakmpd, or
whatever
> > as with KAME.
>
> I had problems with racoon. My previous buildworld and kernel was of
> January 19th while today's build (January 31st) effectively disabled
> racoon. After tracing around a bit it seemed that racoon had problems
> to parse its configuration file and some tokens were tracked down to
> the wrong constants. I am using hmac_md5 authentication and racoon was
> complaining "algorithm 1 not supported". Yes - "1" instead of a string
> with the algorithm name.
>
> It turned out that this (abridged) change was the culprit:
>
> diff -r /usr/include/net/pfkeyv2.h /mnt/usr/include/net/pfkeyv2.h
> 1c1
> < /* $FreeBSD: src/sys/net/pfkeyv2.h,v 1.4.2.4 2003/01/24 05:11:33 sam Exp
$ */
> ---
> > /* $FreeBSD: src/sys/net/pfkeyv2.h,v 1.4.2.3 2001/10/24 19:49:13 ume Exp
$ */
> 303,305c303,305
> < #define SADB_AALG_MD5HMAC 2
> < #define SADB_AALG_SHA1HMAC 3
> < #define SADB_AALG_MAX 251
> ---
> > #define SADB_AALG_MD5HMAC 1 /*2*/
> > #define SADB_AALG_SHA1HMAC 2 /*3*/
> > #define SADB_AALG_MAX 8
>
> Reinstalling racoon instantly fixed the issue. Probably other ISAKMP
> daemons (e.g. isakmpd) are affected as well.
>
> Note that quite a number of other constants were redefined by this
> change, not just the ones mentioned in the diff excerpt above.
Yes, I missed this in my commit. I should revert pfkeyv2.h's constants to
maintain binary compatibility. Unfortunately this will require another
rebuild of racoon. Sorry.
Sam
------------------------------
Date: Fri, 31 Jan 2003 23:07:18 +0100 (CET)
From: Helge Oldach <stable...@oldach.net>
Subject: Re: HEADS UP: fast ipsec committed
Sam Leffler:
> > diff -r /usr/include/net/pfkeyv2.h /mnt/usr/include/net/pfkeyv2.h
> > 1c1
> > < /* $FreeBSD: src/sys/net/pfkeyv2.h,v 1.4.2.4 2003/01/24 05:11:33 sam Exp
> $ */
> > ---
> > > /* $FreeBSD: src/sys/net/pfkeyv2.h,v 1.4.2.3 2001/10/24 19:49:13 ume Exp
> $ */
> > 303,305c303,305
> > < #define SADB_AALG_MD5HMAC 2
> > < #define SADB_AALG_SHA1HMAC 3
> > < #define SADB_AALG_MAX 251
> > ---
> > > #define SADB_AALG_MD5HMAC 1 /*2*/
> > > #define SADB_AALG_SHA1HMAC 2 /*3*/
> > > #define SADB_AALG_MAX 8
> >
> Yes, I missed this in my commit. I should revert pfkeyv2.h's constants to
> maintain binary compatibility. Unfortunately this will require another
> rebuild of racoon. Sorry.
Never mind. My intention was just to warn the list about this side
effect.
It will affect -STABLE trackers who install ports on their own only.
Future -RELEASE users installing packages will see a working racoon.
The new constants appear more sensible to me as they are in line
with RFC 2407. Please keep it like it is; it's fairly easy to make a
workaround.
I would suggest to just document the necessity to re-build userland
ISAKMP daemons in UPDATING instead.
Regards,
Helge
------------------------------
End of stable-digest V5 #780
****************************
To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-stable-digest in the body of the message