re 871009576 is not a valid port number...
You're on a 64bit machine ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can ad
zation and other protocol
>overhead [...]
Can we keep the option (sysctl ?) of doing the full packet thing, it is
a very convenient debugging tool...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-
In message <4953834e.3020...@dlr.de>, Hartmut Brandt writes:
>> Do we have any of the necessary software parts to do simulated ATM
>> hardware similar to what if_tap does for Ethernet?
I believe I have a couple of ATM cards in my lab somewhere, who wants them ?
--
to be changed lightly, so consider this more of an
observation than bug report.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explain
he FAST_ prefix along with the old IPSEC when we
get to that point ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequatel
's licensing department, there were a $1k licensefee
for anything IEEE1588 related and their message was that even if
the FreeBSD foundation got such a license, the users would still
have to have one as well if they compiled the source code or some
such nonsense.
If this has all been taken c
ything to do with it, but I
>double check internally.
They seem to think they have a patent on doing things that way,
no matter what hardware or software you use.
If Intel chips have hw-support for timestamping, somebody at intel
must have thought about the patent thing.
But as I said, if that can
In message <[EMAIL PROTECTED]>, "M. Warner Losh" writes
:
>In the past I've uesd line disciplines to implement a keyboard driver
>for the Apple Newton Keyboard (serial protocol) [...]
But shouldn't you have used uart(4) for that ?
--
Poul-Henning Kamp | U
lines from different providers.
Run a moderately fresh -current or be prepared to backport
the patches (this shouldn't be hard since it is only libalias
and natd which is changed).
Apply by private email.
Poul-Henning
--
Poul-Henning Kamp | UNIX
l.
Please test and report success/failures/ideas/patches.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by in
In message <[EMAIL PROTECTED]>, "Simon L. Nielsen" writes:
>
>--MGu/vTNewDGZ7tmp
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>On 2004.06.20 21:47:10 +0200, Poul-Henning Kamp wrote:
&g
mething like T/TCP is certainly useful and I know of one special
>purpose application using it (Web Proxy Server/Client for high-delay Satellite
>connections).
Wouldn't that be inferior to what accept-filters gives us ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
--- Forwarded Message
To: [EMAIL PROTECTED]
Subject: Request to back out Luigis polled-net patch in -stable.
From: Poul-Henning Kamp <[EMAIL PROTECTED]>
Date: Fri, 07 Dec 2001 17:13:24 +0100
Message-ID: <[EMAIL PROTECTED]>
Sender: [EMAIL PROTECTED]
I have not read the ent
ome experience with it, we
can decide on a rational basis if it should be MFC'ed, (or committed
cold into -stable if the MFC doesn't make sense).
And of course Luigi is more than welcome to distribute his change
as a patch against -stable, just like Jun-Itoh does with his ALTQ.
(I don't
I still think we should stop having this network-centric view of
polling and implement _real_ *device* polling, so that other
device types can use it as well.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD
In message <[EMAIL PROTECTED]>, Robert Watson writes:
>On Fri, 30 Sep 2005, Poul-Henning Kamp wrote:
>
>> I still think we should stop having this network-centric view of polling
>> and implement _real_ *device* polling, so that other device types can
>> use it as
is a nontrivial task which requires
access to a lot of NDA information and an extensive positive/negative
list of chips and chipsets.
Even in the most recent chips, there are still issues with TSC that
makes it unusable as a default timecounter.
--
Poul-Henning Kamp | UNIX since Zilog Z
In message <[EMAIL PROTECTED]>, Bruce Evans writes:
>On Fri, 14 Oct 2005, Poul-Henning Kamp wrote:
>
>> In message <[EMAIL PROTECTED]>, Andrew Gallatin
>> writes:
>>
>>> Linux already takes care of syncing the TSC between SMP cpus, so we
>>> kn
In message <[EMAIL PROTECTED]>, Andrew Gallatin
writes:
>
>Poul-Henning Kamp writes:
> > The best compromise solution therefore is to change the scheduler
> > to make decisions based on the TSC ticks (or equivalent on other
> > archs) and at regular intervals figu
it just keeping the TSC in sync? They seem to maintain
>a high resolution timer based on tsc, and keep it in sync every
>second, and fixup drift on different cpus, and the TSC
>being reset after suspend/resume.
>http://cvs.opensolaris.org/source/xref/usr/src/uts/i86pc/os/timestamp.c
Sol
In message <[EMAIL PROTECTED]>, Andrew Gallatin
writes:
>
>Poul-Henning Kamp writes:
> > The solution is not faster but less reliable timekeeping, the
> > solution is to move the scheduler(s) away from using time as an
> > approximation of cpu cycles.
>
>So you
In message <[EMAIL PROTECTED]>, Bruce Evans writes:
>On Fri, 14 Oct 2005, Poul-Henning Kamp wrote:
>> Even to this day new CPU chips come out where TSC has flaws that
>> prevent it from being used as timecounter, and we do not have (NDA)
>> access to the data that wou
one who has been there, a couple of times: SECONDED!
It is particular unpleasant when you have no way to test the changes.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute t
tallies and scores to match informed
reality and _then_ we could discuss if the criteria were sound
on the list(s).
Poul-Henning (singing an almost 20 year old refrain again)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD c
rs buys us much more code-isolation, so that would be my vote.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
_
>Archie Cobbs * Packet Design * http://www.packetdesign.com
>
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-hackers" in the body of the message
>
--
Poul-Henning Kamp | UNIX sinc
--- Forwarded Message
To: [EMAIL PROTECTED]
Subject: Request to back out Luigis polled-net patch in -stable.
From: Poul-Henning Kamp <[EMAIL PROTECTED]>
Date: Fri, 07 Dec 2001 17:13:24 +0100
Message-ID: <[EMAIL PROTECTED]>
Sender: [EMAIL PROTECTED]
I have not read the ent
his ALTQ.
(I don't know if Peter has -stable in P4, but that could be one way
to make it easier for Luigi to maintain the patch if he had a branch
there)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD sin
is an I belive it is actually the case on both
-current and -releng4 that disabling newreno improves TCP performance.
I belive running an X11 application or scp(1) over a wavelan is a very
good test-bed for this issue.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]
In message <[EMAIL PROTECTED]>, Michael Sierchio writes:
>Poul-Henning Kamp wrote:
>
>> Yes, I can attest to this an I belive it is actually the case on both
>> -current and -releng4 that disabling newreno improves TCP performance.
>>
>> I belive running
S file: /home/ncvs/src/sys/netinet/tcp_subr.c,v
retrieving revision 1.143
diff -u -r1.143 tcp_subr.c
--- tcp_subr.c 10 Oct 2002 21:41:30 - 1.143
+++ tcp_subr.c 15 Oct 2002 22:06:27 -0000
@@ -62,7 +62,6 @@
#include
#include
-#define _IP_VHL
#include
#include
#include
@@ -284,7 +283,8 @@
{
orical behavior of compilers which allocated space for
>bitfields in BYTE_ORDER order.)
Do you intend to complete the task you originally started ?
What is your plan for 3rd party software ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC
tiple of 8.
Good point.
I'll ammend my proposal to include a __packed__ and a CTASSERT on
the size of struct ip == 20.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute t
& flags */
u_int16_t ipq_div_cookie; /* ipfw divert cookie */
-#endif
struct label ipq_label; /* MAC label */
};
#endif /* _KERNEL */
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
fell for both of those criteria: neither users
nor committers.
netns fails both criteria too.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately b
even compile.
Could we possibly move Terry to the attic too ? Please ?
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
ove if_name/if_unit, it is a thing to do. Moreover it
>sounds a good idea to have the if_dev field into the ifnet structure.
Somebody please explain how this would work for non-hardware
interfaces like if_loop, if_tun, if_tap etc ?
device_t is what we use to hitch drivers to hardware.
ifnet
terms
of what is behind them, hardware, software or bongo drums.
If all you want is an extra field in "struct ifnet" to hang driver
information on, then by all means add that field. As long as you
give it type "void *" and make it private to the driver I have no
problem with t
eir own ifnet so they could assume they had
>filled it in.
So you'd still have to keep the if_name + if_unit around for the
drivers which do not have a device_t ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
download drivers for card
unzip/unrar or whatever it takes.
run strings(1) on the files and look for vendor
indentification strings ("Atheros", "Broadcom" etc etc).
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] |
seless, yet cause some extra PCI transactions.
I don't know if it is correct, but at the very least I have thought
the same thoughts when I looked at the driver last, but I didn't
get time to try out the idea...
Somebody with some spare time should look at this...
Poul-Henning
--
rn
as always).
This patch makes it possible for programs like natd to run multiple
packet-aliasing engines, this was not previously possible because
of the widespread use of global variables in libalias.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP s
outetable or polling the
interface configuration does not count as "simple".
It seems to me that if there is no simple way to do this, it's
about time we added it...
As I see it, we need recvfromto() and sendtofrom().
Any takers ?
Poul-Henning
--
Poul-Henning Kamp
In message <[EMAIL PROTECTED]>, Maxim Konovalov writes:
>On Mon, 19 Jan 2004, 12:07+0100, Poul-Henning Kamp wrote:
>
>> Simple question:
>>
>> Very simple UDP server daemon.
>>
>> Many clients (connect(2)'ing a socket for each is not an option)
&g
In message <[EMAIL PROTECTED]>, "Randall R. Stewart (home)
" writes:
>>>On Mon, 19 Jan 2004, 12:07+0100, Poul-Henning Kamp wrote:
>>>>Simple question:
>>>>
>>>>Very simple UDP server daemon.
>>>>
>>>>Many cl
y do the right thing. That's what the IP_RECVDESTADDR
>option (and its dual whose name I forget right now) is all about.
Yeah, I found that out. Now, where on the earth is that documented ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since R
turn the destination IP address for a UDP data-
> gram. The msg_control field in the msghdr structure points to a buffer
> that contains a cmsghdr structure followed by the IP address. The
> cmsghdr fields have the following values:
>--- cite ---
That really belongs on
47 matches
Mail list logo
