I have a problem with xl driver under FreeBSD 4.6-STABLE system.
I have 3com905b ethernet cards, one 3com980 server ethernet card. But, I see
that they serve better under Windows systems. After I dig it deeper. I found
that during transfers there are a lot of bad chksum messages.
Here is a s
On Mon, 7 Oct 2002, Don Lewis wrote:
> On 7 Oct, Nate Lawson wrote:
> > On Mon, 7 Oct 2002, Julian Elischer wrote:
>
> >> it is just working on the principal that there is not going to be
> >> a collision in the 32 bit space. Especially when we create them from
> >> "time since the epoch", a
On Mon, 7 Oct 2002, Nate Lawson wrote:
> On Mon, 7 Oct 2002, Julian Elischer wrote:
> > On Mon, 7 Oct 2002, Terry Lambert wrote:
> > > On Mon, 7 Oct 2002, Julian Elischer wrote:
> > > > Your tags have a single 16 bit tag ID field.
> > > > This is insufficient for my needs.
> > > > I need to be
On 7 Oct, Nate Lawson wrote:
> On Mon, 7 Oct 2002, Julian Elischer wrote:
>> it is just working on the principal that there is not going to be
>> a collision in the 32 bit space. Especially when we create them from
>> "time since the epoch", and when teh various authors can see each
>> other's
On Mon, 7 Oct 2002, Julian Elischer wrote:
> On Mon, 7 Oct 2002, Terry Lambert wrote:
> > On Mon, 7 Oct 2002, Julian Elischer wrote:
> > > Your tags have a single 16 bit tag ID field.
> > > This is insufficient for my needs.
> > > I need to be able to store the API cookie which is a 32 bit
> > > u
Try these links:
http://free.mine.nu/~squirrel/PPPoE/FreeBSD%20PPPoE%20Howto.htm
http://www.freebsddiary.org/pppoe.php
http://renaud.waldura.com/doc/freebsd/pppoe/
JT.
- Original Message -
From: "alexis georges" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, October 07, 2002 12:
Luigi Rizzo wrote:
> i wonder what do we gain by moving to 32 bit m_tag_id -- because there is
> is still no strict guarantee that we have no conflicts
> if people randomly choose "cookies", and also, using the same reasoning
> for allocations one could argue that having the cookie chosen as the n
On Mon, 7 Oct 2002, Julian Elischer wrote:
> definitly.
> Each API authout gets to polute his own namespace as much as he
author
> wants.. :-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Julian Elischer wrote:
> > This is insufficient for Alpha and other 64 bit architectures. I
> > think what you are asking for is really a 'void *'.
>
> IT IS NOT A POINTER!
>
> it is a 32 bit unsigned number.
OK, I give up. Why is 2^32 possibilities better than 2^16th
possibilities? You have
On Mon, 7 Oct 2002, Julian Elischer wrote:
>
>
> On Mon, 7 Oct 2002, Luigi Rizzo wrote:
>
> > the 16 vs. 32 bit
> > On Mon, Oct 07, 2002 at 03:52:49PM -0700, Sam Leffler wrote:
> > ...
> > > Sounds to me like the real issue for you is insuring unique m_tag_id values.
> > > We're certainly le
On Mon, 7 Oct 2002, Sam Leffler wrote:
> > On Mon, 7 Oct 2002, Sam Leffler wrote:
> > >
> > > If you allocate tag id's using your 32-bit time scheme then the fixed
> values
> > > above would never be hit since they are all for impossible times and so
> > > there'd be no conflict.
> >
> > Just m
> On Mon, 7 Oct 2002, Sam Leffler wrote:
> >
> > If you allocate tag id's using your 32-bit time scheme then the fixed
values
> > above would never be hit since they are all for impossible times and so
> > there'd be no conflict.
>
> Just make them all IDs in a single "Legacy" API
>
Good idea; I
On Mon, 7 Oct 2002, Luigi Rizzo wrote:
> the 16 vs. 32 bit
> On Mon, Oct 07, 2002 at 03:52:49PM -0700, Sam Leffler wrote:
> ...
> > Sounds to me like the real issue for you is insuring unique m_tag_id values.
> > We're certainly less likely to have collisions with a 32-bit value than a
> > 16-b
On Mon, 7 Oct 2002, Sam Leffler wrote:
>
> So all this is to say that you want m_tag_id to be u_int32_t. Having
> another 16-bit field is immaterial to anything I've thought of but given
> that switching to a 32-bit tag_id will require allocating an additional
> 32-bit item you can have that
the 16 vs. 32 bit
On Mon, Oct 07, 2002 at 03:52:49PM -0700, Sam Leffler wrote:
...
> Sounds to me like the real issue for you is insuring unique m_tag_id values.
> We're certainly less likely to have collisions with a 32-bit value than a
> 16-bit value and expanding this way gives you your "field
On Mon, 7 Oct 2002, Terry Lambert wrote:
>
>
> > Your tags have a single 16 bit tag ID field.
> > This is insufficient for my needs.
> > I need to be able to store the API cookie which is a 32 bit
> > unsigned number, and on top of that, I also need a 16 bit type field
> > that specifies what
> If we make this a 'standard' method of adding metadata to a packet, then
> I'd like to move netgraph to use it to. it's always better
> to use a standard method if it will do than to roll your own.
>
> however, there are some thiongs that would proclude me from doing so at
> tth moment. Thes are
Julian Elischer wrote:
> Firstlty, each netgraph module type is ignorant of
> all other types (except in some special cases). Each 'type'
> labels its structures, control messages, and in fact special metadata
> that it keeps on a packet, using a special maginc number. Each 'type'
> of netgraph no
If we make this a 'standard' method of adding metadata to a packet, then
I'd like to move netgraph to use it to. it's always better
to use a standard method if it will do than to roll your own.
however, there are some thiongs that would proclude me from doing so at
tth moment. Thes are not major
Hello,
Why is it not allowed to get more that 65536 ip6fw rules from the kernel
in the ip6fw.c:list() function?
Here is some lines from ip6fw.c:
maxbytes = 65536 * sizeof *rules;
while (bytes >= nalloc) {
nalloc = nalloc * 2 + 200;
bytes = nalloc;
My thought is that the net.inet.ip.intr_queue_maxlen should be set to the
maximum receive queue length of your NIC. Depending upon traffic (bursty
short packets being the worst), other kernel operations being slow, and
NIC interrupt coalesce or polling times, your NIC's rx buffer can fill
signif
Hi:
While attempting to make inetd work with SCTP (the one
distrbituted with the KAME stack now).. I ran in to
a little issue..
It appears when inetd opens its socket it does:
"
if ((sep->se_fd = socket(sep->se_family, sep->se_socktype, 0)) < 0) {
if (debug)
Hello,
This is my first message posted to the list..hehehe
anyways, i used to have a simple cable connection, which would be
automatically comfigured by FreeBSD upon installation..I just moved and now
we have an ADSL connection (from Sympatico).. The connection is not
configured automatically..
> On Sun, 6 Oct 2002, Sam Leffler wrote:
>
> > > 1. Is ordering important or is an SLIST sufficient for all cases?
> >
> > Order is not important.
>
> I do similar in Netgraph but could move to whatever scheme becomes
> standard in the rest of the system. However I have some serious
> comments.
>
> Actually, the integration into IPv4 strikes me as little more than
> an afterthought: the KAME code handles it in IPv6 without the extra
> overhead for the non-IPSEC sockets, and the IPv4 support is more of
> a bolt-on than something designed in. I'd almost want to see the
> IPSEC stuff treated
> What is the relationship between these changes and the KAME
> code? In particular, are they goign to take these
> changes back into Kame? Can you outline the compatibility
> issues, both with KAME, and with NetBSD and OpenBSD, as I know you have
> been looking at OpenBSD?
>
I've looked at many
I've tried the customer-is-always-right routine, and it ends up back at
the same place, lets bounce your system...
I'll try the route add when I get home and let you know if it works.
Thanks
Jim
-- In Response to your message -
> Date: Mon, 7 Oct 2002 09:55:41 -0400
>
Hello -net,
misc/42121 has a detailed problem description, fix is obvious. Here is
a patch:
Index: ip_input.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v
retrieving revision 1.210
diff -u -r1.210 ip_input.c
--- ip_input.c
Sorry, it's a cable modem service. I did try to explain to them that I
wasn't looking for system support support, only that the provide me
with a standard network configuration. The response was "I don't know
how to change it and the three resources I talked to don't either."
-- In R
Hi,
My isp, RCN, issues dynamic addresses via DHCP and for some strange, unknown
reason issues a gateway address on a different "network" than the machine
address. Windows works fine with the arrangement, but, as I would expect,
FreeBSD doesn't. In the past, I've called and be able to get this
On Mon, 7 Oct 2002, Harti Brandt wrote:
> On Sun, 6 Oct 2002, Craig Rodrigues wrote:
>
> CR>There are 2 total nodes:
> CR> Name: ngctl3796 Type: socket ID: 001d Num hooks: 0
> CR> Name: fatm0 Type: atm ID: 000a Num hooks: 0
> CR>
> CR>The fatm
Do something like this:
static int my_variable = 0;
SYSCTL_INT(_net_inet_ip, OID_AUTO, my_sysctl_name, CTLFLAG_RW,
&my_variable, 0, "Description of my variable");
Now you can access my_variable in kernel code, and configure it using:
sysctl -w net.inet.ip.my_sysctl_name = new_value
look
Hi list
How can i create a variable in kernel source codes ( for network layer - ip)
that i can access it by sysctl command like other variables.
Thanx
S.h.y
_
MSN Photos is the easiest way to share and print your photos:
http://
> -Original Message-
> From: Rogier R. Mulhuijzen [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, October 06, 2002 8:15 PM
> To: Ido Barnea; [EMAIL PROTECTED]
> Subject: RE: Help with net.inet.ip.intr_queue_maxlen
>
>
> Is there a write-up anywhere about what variables are
> tuneable, where
On Sun, 6 Oct 2002, Craig Rodrigues wrote:
CR>There are 2 total nodes:
CR> Name: ngctl3796 Type: socket ID: 001d Num hooks: 0
CR> Name: fatm0 Type: atm ID: 000a Num hooks: 0
CR>
CR>The fatm0 is from Harti Brandt's Netgraph ATM system which I am t
On Fri, Oct 04, 2002 at 10:09:47AM -0400, [EMAIL PROTECTED] wrote:
> I haven't been able to turn up anything under Google...
>
> Has anyone ever successfully gotten an IP-IP or GRE tunnel working
> between a FreeBSD machine (4-STABLE) and a Linux machine (2.4.x)? I
> can get a tunnel up between
On Sun, 6 Oct 2002, Sam Leffler wrote:
> > 1. Is ordering important or is an SLIST sufficient for all cases?
>
> Order is not important.
I do similar in Netgraph but could move to whatever scheme becomes
standard in the rest of the system. However I have some serious
comments.
In netgraph I
37 matches
Mail list logo
