Scott Long wrote:
I'm looking a t a similar system right now and it definitely looks
like an interrupt routing problem, not a driver problem. The
interesting thing is that (with 5.2-current as of two days ago)
disabling neither
ACPI nor APIC helps. I guess that we might want to get John Baldw
Hello, and Sorry for a delayed answer.
> On Tue, 4 May 2004 20:16:20 +0200
> [EMAIL PROTECTED](Lukasz Stelmach) said:
> stf interface has one feature, very inconvinient for me. As far as i could
> read the source it returns ENETDOWN if the inet4 address of the machine's
> net interface (
Hello all!
A couple days ago i've got next problem with my ISP (before everything
were ok). When connection to the VPN server is established then I can't
ping anything through the tunel even VPN server (192.168.10.1):
64 bytes from 192.168.10.1: icmp_seq=503 ttl=64 time=0.634 ms
64 bytes from 192
Byla godzina 16:00:42 w Thursday 06 May, gdy do autobusu wsiadl kanar
i wrzasnal:"SUZUKI Shinsuke!!! Bilecik do kontroli!!!" A on(a) na to:
>> On Tue, 4 May 2004 20:16:20 +0200
>> [EMAIL PROTECTED](Lukasz Stelmach) said:
>
> > stf interface has one feature, very inconvinient for me. As
Thursday, May 6, 2004, 4:28:29 PM, you wrote:
I tryed increase NMBCLUSTER, it didn't help.
How can i check if my connection work properly?
VEL> CMIIW, I once had the same problem, but in my other console the system said
VEL> about increasing my NMBCLUSTER value. So I did two things, perhaps you
Hello,
I'd like to try on some changes that I've made in our VoIP
testbed for mobility support at the application layer.
If the user requires support for seamless voice communication during
active call sessions on the mobile UA, it is imperative that the
wireless LAN setup should support roaming
Hi Juan,
On Thu, 6 May 2004 Juan Rodriguez Hervella <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I'd like to try on some changes that I've made in our VoIP
> testbed for mobility support at the application layer.
>
> If the user requires support for seamless voice communication during
> active call
Thank you very much for your replysee below
On Thursday 06 May 2004 15:01, Marco Molteni wrote:
> Hi Juan,
>
> On Thu, 6 May 2004 Juan Rodriguez Hervella <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > I'd like to try on some changes that I've made in our VoIP
> > testbed for mobility support at
Hi, I spent times to figure out the packet flow with ng_ether, like this:
upper layer
|
^
[ether_demux]
^
|
+---<---[ng_ether_rcvdata]--<-- 'upper' --<--,
Am 05.05.2004 um 13:31 schrieb Søren Schmidt:
Pawel Jakub Dawidek wrote:
On Wed, May 05, 2004 at 12:42:48PM +0200, Pawel Jakub Dawidek wrote:
+> Hi.
+> +> I've problems with em(4) and IPSEC/FAST_IPSEC and TCP_STREAM
netperf test.
+> While running netperf tests between two FreeBSD machines directly
I cannot boot the system with em0 after FreeBSD 5.2.1-RELEASE-p3..
it did work with 5.2-RELEASE-p1, though.
See: http://www.freebsd.org/cgi/query-pr.cgi?pr=65282
One month is over since I submitted the pr, but nobody has
looked at it yet.
Stefan Bethke wrote:
Am 05.05.2004 um 13:31 schrieb Søren Sc
On Wed, 2004-05-05 at 13:16, Ahmed Hamada wrote:
[lines wrapped for readability]
> I am student in facaulty of engineering. My undergraduate project
> is "Mobile Ad Hoc Network". I read alot about it and now I want
> to make some simulations to verify some points. I want to use
> the OPNET in m
I´m highly confident that this is a case of integrated "CSA" ethernet
with broken BIOS. I suspect you get an message about that when booting.
Pete
Søren Schmidt wrote:
John Polstra wrote:
On 05-May-2004 Søren Schmidt wrote:
For what its worth I have problems with one em based interface as
well,
Our spam detector has just been triggered by a message you sent:-
Subject: Re: excuse me
Date: Thu May 6 20:01:04 2004
Version Français ci-dessous / Nederlandse text zie beneden
Madam, Sir
Due to the multitude of unsolicited emails, we are forced to use an 'anti-spam' system.
This system m
I have just committed the attached change to ip_input() to control the
behaviour of IP Options processing. The default is the unchanged
current behaviour.
However I want to propose to change the default from processing options
to ignoring options (or even stronger to reject them).
The rationale
On Thu, May 06, 2004 at 09:16:03PM +0200, Andre Oppermann wrote:
> I have just committed the attached change to ip_input() to control the
> behaviour of IP Options processing. The default is the unchanged
> current behaviour.
>
> However I want to propose to change the default from processing opt
On Thu, 6 May 2004, Andre Oppermann wrote:
> I have just committed the attached change to ip_input() to control the
> behaviour of IP Options processing. The default is the unchanged
> current behaviour.
[...]
> routing. The remaining IP Options are RR (record route) and TS (time
> stamp) whic
>Date: Thu, 06 May 2004 21:16:03 +0200
>From: Andre Oppermann <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED], [EMAIL PROTECTED]
>Subject: Default behaviour of IP Options processing
>Sender: [EMAIL PROTECTED]
>However I want to propose to change the default from processing options
>to ignoring options
Petri Helenius wrote:
I´m highly confident that this is a case of integrated "CSA" ethernet
with broken BIOS. I suspect you get an message about that when booting.
Nope. no messages to that effect, oh and it works in windows(tm)...
The last thing I see if I try to use em0 is:
em0: Link is up 100 M
David Wolfskill wrote:
> >However I want to propose to change the default from processing options
> >to ignoring options (or even stronger to reject them).
>
> >
>
> >Opinions? Discussion? Yes/Nay?
>
> >From "ipfw show" on my home gateway/NAT/packet fileter box:
>
> ...
> 02000 0
Søren Schmidt wrote:
>
> Petri Helenius wrote:
> > I´m highly confident that this is a case of integrated "CSA" ethernet
> > with broken BIOS. I suspect you get an message about that when booting.
>
> Nope. no messages to that effect, oh and it works in windows(tm)...
>
> The last thing I see if
Julian Elischer wrote:
>
> On Thu, 6 May 2004, Andre Oppermann wrote:
>
> > I have just committed the attached change to ip_input() to control the
> > behaviour of IP Options processing. The default is the unchanged
> > current behaviour.
> [...]
> > routing. The remaining IP Options are RR (re
Andre Oppermann wrote:
Søren Schmidt wrote:
Petri Helenius wrote:
I´m highly confident that this is a case of integrated "CSA" ethernet
with broken BIOS. I suspect you get an message about that when booting.
Nope. no messages to that effect, oh and it works in windows(tm)...
The last thing I see if
Søren Schmidt wrote:
>
> Andre Oppermann wrote:
> > Søren Schmidt wrote:
> >
> >>Petri Helenius wrote:
> >>
> >>>I´m highly confident that this is a case of integrated "CSA" ethernet
> >>>with broken BIOS. I suspect you get an message about that when booting.
> >>
> >>Nope. no messages to that eff
Søren Schmidt wrote:
Petri Helenius wrote:
I´m highly confident that this is a case of integrated "CSA" ethernet
with broken BIOS. I suspect you get an message about that when booting.
Nope. no messages to that effect, oh and it works in windows(tm)...
The last thing I see if I try to use em0 is:
Søren Schmidt wrote:
Nope. no messages to that effect, oh and it works in windows(tm)...
The last thing I see if I try to use em0 is:
em0: Link is up 100 Mbps Full Duplex
and then the system locks up hard.
Would you mind posting full dmesg output?
Pete
_
Andre Oppermann wrote:
>
> Søren Schmidt wrote:
> >
> > Andre Oppermann wrote:
> > > Søren Schmidt wrote:
> > >
> > >>Petri Helenius wrote:
> > >>
> > >>>I´m highly confident that this is a case of integrated "CSA" ethernet
> > >>>with broken BIOS. I suspect you get an message about that when boot
On 06-May-2004 Andre Oppermann wrote:
> Søren Schmidt wrote:
>>
>> Andre Oppermann wrote:
>> > What MIIPHY does the card have?
>>
>> No idea, builtin of sorts, there is no mention of it in the probe, and
>> no HW to see on the boards. I have two different boards with these on
>> them both show th
Søren Schmidt wrote:
Petri Helenius wrote:
I´m highly confident that this is a case of integrated "CSA" ethernet
with broken BIOS. I suspect you get an message about that when booting.
Nope. no messages to that effect, oh and it works in windows(tm)...
The last thing I see if I try to use em0 is:
On Thu, 6 May 2004, 21:16+0200, Andre Oppermann wrote:
> I have just committed the attached change to ip_input() to control the
> behaviour of IP Options processing. The default is the unchanged
> current behaviour.
>
> However I want to propose to change the default from processing options
> to
> We are using RR option all the time to track down routing asymmetry
> and traceroute is not an option, ping -R is very useful in that cases.
> We all know that ipfw (and I am sure all other *pf*) is able to
> process ip opts quite well and personally see no point in this
> sysctls. I fail to see
On Thu, 6 May 2004, David W. Chapman Jr. wrote:
> > We are using RR option all the time to track down routing asymmetry
> > and traceroute is not an option, ping -R is very useful in that cases.
> > We all know that ipfw (and I am sure all other *pf*) is able to
> > process ip opts quite well an
On Thu, 6 May 2004, 17:35-0500, David W. Chapman Jr. wrote:
> > We are using RR option all the time to track down routing asymmetry
> > and traceroute is not an option, ping -R is very useful in that cases.
> > We all know that ipfw (and I am sure all other *pf*) is able to
> > process ip opts qui
On Thu, May 06, 2004 at 03:42:43PM -0700, Julian Elischer wrote:
>
> what security problem are you expecting?
>
I personally am not expecting any problems because I'm not in a
knowledgeable enough to state my opinion on such matters, but it seems Mr. Vidrine
and Mr. Oppermann were in the opini
> You mean ip options not tcp, right? I do not understant why we
> invent a new mechanism if we already have one. Put an example in
> /etc/rc.firewall.
Yes, I stand corrected, ip option it is :)
> You mean "more obscure", right? Where net.inet.ip.process_options
> documented? How does it oper
On Thu, 6 May 2004, David W. Chapman Jr. wrote:
> > You mean ip options not tcp, right? I do not understant why we
> > invent a new mechanism if we already have one. Put an example in
> > /etc/rc.firewall.
>
> Yes, I stand corrected, ip option it is :)
>
> > You mean "more obscure", right?
My comments in [] below..
On Wed, 5 May 2004, Julian Stecklina wrote:
> Hello,
>
> I have a problem with pppoed: It does not accept connections:
>
> My system is FreeBSD-current as of some days ago running on x86. ath0
> is a DLINK WLAN card, if that matters. If I watch ethernet traffic via
> t
On Thursday 06 May 2004 04:06 pm, Julian Elischer wrote:
> On Thu, 6 May 2004, David W. Chapman Jr. wrote:
> > > You mean ip options not tcp, right? I do not understant why we
> > > invent a new mechanism if we already have one. Put an example in
> > > /etc/rc.firewall.
> >
> > Yes, I stand corre
On Thu, 6 May 2004, Sam Leffler wrote:
>
> For fine-grained selection packet filtering is the better solution. This is a
> simple, much lighterweight, mechanism that doesn't require touching every
> packet.
I would only do the tests if the packet HAD an ip option..
either way I'm not going
Let me take this email from Julian to summarize and answer all the
previous questions of this thread that has spawned...
> I know these are "options" but what does the standards say about not
> supporting them.. ? (I have seen non optional options before :-)
RFC791 (IP specification) requires the
On Thu, May 06, 2004, Andre Oppermann wrote:
> I have just committed the attached change to ip_input() to control the
> behaviour of IP Options processing. The default is the unchanged
> current behaviour.
>
> However I want to propose to change the default from processing options
> to ignoring o
Julian Elischer wrote:
>
> On Thu, 6 May 2004, Sam Leffler wrote:
>
> >
> > For fine-grained selection packet filtering is the better solution. This is a
> > simple, much lighterweight, mechanism that doesn't require touching every
> > packet.
>
> I would only do the tests if the packet HAD an
Julian Elischer wrote:
On Thu, 6 May 2004, David W. Chapman Jr. wrote:
We are using RR option all the time to track down routing
asymmetry and traceroute is not an option, ping -R is very useful
in that cases. We all know that ipfw (and I am sure all other
*pf*) is able to process ip opts quite wel
[...]
> May I propose an default setting for IP options which allows for RR but
> restricts the packet size that will be acted upon and is rate limited like
> many of our ICMP replies to certain other events like closed ports etc?
> This would satisfy the RR tracers and make Jaques and me more happ
44 matches
Mail list logo
