>> what are you planning to do after checking IPv6 support in the kernel?
>> applications should be written so that it would work on both
>> IPv4-only, IPv6-only and IPv4/v6 dual stack kernels, by using
>> getaddrinfo(3) and getnameinfo(3). you do not need to check if you
>>
On Mon, 26 Mar 2001, Jun-ichiro itojun Hagino wrote:
> what are you planning to do after checking IPv6 support in the kernel?
> applications should be written so that it would work on both
> IPv4-only, IPv6-only and IPv4/v6 dual stack kernels, by using
> getaddrinfo(3) and
Hi,
I have three possible ways to get to the internet from my FreeBSD gateway.
1) ADSL session via netgraph PPTP implementation. The interface used is ng0
2) ISDN dial-up via netgraph PPP. The interface used is ng1
3) direct connection (limited bandwidth), interface is sf3
Curr
> I'm getting a page fault, trap 12, whenever a packet from a bridged
> interface matches a pipe fule in IPFW. Any suggestions?
known problem in 4.2R, you have to upgrade to a recent -stable or 4.3
cheers
luigi
> dmesg:
> Copyright (c) 1992-2000 The FreeBSD Project.
> Copyright
I'm getting a page fault, trap 12, whenever a packet from a bridged
interface matches a pipe fule in IPFW. Any suggestions?
dmesg:
Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of Califor
>
> Alas, that patch is exactly what I have already done. I was hoping you'd
> found somewhere that I missed an update, but I already had those three spots
> covered.
Fine. I'm including another patch with a slight change. I don't know if
this will make a difference or not since I've never kn
>I'm wondering how one is supposed to test for INET6 support in the
>kernel. Currently a few places do it in a somewhat bogus fashion
>like this:
what are you planning to do after checking IPv6 support in the kernel?
applications should be written so that it would work on both
>Guh. Support for this card was added to -current, but the changes never
>made it back to -stable. The problem (I think) is that while you updated
>the device list, you overlooked a piece of code in rl_attach() that selects
>the driver behavior depending on the PCI device ID. Get back your origin
Ruslan Ermilov wrote:
>
> On Thu, Mar 22, 2001 at 09:45:12PM +0100, Peter Blok wrote:
> > Hi,
> >
> > I'm having a strange problem. I have a block public ip addresses at
> > X.Y.Z.128/28. My FreeBSD 4.3-BETA system has assigned IP address X.Y.Z.140
> > netmask 255.255.255.240, broadcast X.Y.Z.143
Guh. Support for this card was added to -current, but the changes never
made it back to -stable. The problem (I think) is that while you updated
the device list, you overlooked a piece of code in rl_attach() that selects
the driver behavior depending on the PCI device ID. Get back your original
ve
Yes FreeBSD does support Frame relay... and seems to do
so quite well so far ...
(I'm an 'expert' with 5 days of real connect time! still in the system
final configuration stages wrt DNS etc ;-)
I am using a WANic 405 PCI card with an X21 interface to the telco terminal
unit
FreeBSD has been re
> >Are you sure the card is using the 8139 chipset? The 8139 can provide
PHY
> >information via the status register. Since we're obviously not getting
any
> >such data, I'm wondering if this card is based on something else.
>
> I'm pretty sure it is. The Linux driver source file is called
"rtl8
>Are you sure the card is using the 8139 chipset? The 8139 can provide PHY
>information via the status register. Since we're obviously not getting any
>such data, I'm wondering if this card is based on something else.
I'm pretty sure it is. The Linux driver source file is called "rtl8139.c",
* Alfred Perlstein <[EMAIL PROTECTED]> [010325 12:57] wrote:
> I'm wondering how one is supposed to test for INET6 support in the
> kernel. Currently a few places do it in a somewhat bogus fashion
> like this:
>
> s = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP);
> if (s == -1)
> ha
> >[snip] Sorry 'bout that. I was working on the assumption that the driver
> >was working properly, and was just dying during userland init (ifconfig).
> >The "rlphy0: no media present" line tells us that the driver isn't 100%
> >healthy, at least with this card.
>
> Not a problem. Good learnin
I'm wondering how one is supposed to test for INET6 support in the
kernel. Currently a few places do it in a somewhat bogus fashion
like this:
s = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP);
if (s == -1)
have_v6 = 0;
else
close(s);
But this is wrong because unless er
>[snip] Sorry 'bout that. I was working on the assumption that the driver
>was working properly, and was just dying during userland init (ifconfig).
>The "rlphy0: no media present" line tells us that the driver isn't 100%
>healthy, at least with this card.
Not a problem. Good learning exercise
> Okay, I've managed to get the debug kernel built and save the core file.
> I'll include the output of some basic debugging below. If there's
anything
> else that would be helpful, let me know. The D-Link driver disk includes
C
> source for a Linux driver, so when the problem gets narrowed down
> Its not a "proprietary tree". I dont have time to clean it up and submit
> patches.
diff -u original.c mysource.c | mail -s "fxp fix in progress" \
[EMAIL PROTECTED]
I'm sure someone would forgive the digress from style(9) and clean it up for
you, and I'm sure ALL of us would appreciate the f
19 matches
Mail list logo
