Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).
The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.
S Tracker
- Original Message -
From: "Kevin Oberman"
Use "tcpdump -s0 -w file.pcap host remote-system" to see how it fails. You
may want to capture on both ends. Then use wireshark (in ports) to analyze
the data.
There are other tools to provide other types of analysis, depending on the
type of
I guess one could monitor (!?) the program and ``Force Failover of the
Master''[1] in case of errors. Is this the preferred way of doing it, and if so
what are common ways of monitoring programs and executing actions on
(monitor-)state changes?
/Kim
[1] http://www.openbsd.org/faq/pf/carp.html
Hello list,
is it possible to let a CARP-interface fail(-over) in the situation when a
certain program fails or stops working? I hope it's clear enough what I have in
mind. Could you give me any pointers on how this can be archived?
/Kim
this code behaves correctly when run from a diskless host which booted via PXE,
but fails on a host that was booted from disk.
hint: the non working sends a packet with a non ethernet broadcast address and
an ip address of 255.255.255.255, the working version sets the ethernet address
to 0x
On 18.07.2011 18:05, Kim A. Brandt wrote:
Hello list,
is it possible to let a CARP-interface fail(-over) in the situation when
a certain program fails or stops working? I hope it's clear enough what
I have in mind. Could you give me any pointers on how this can be archived?
You can write sim
Confirmed with blade to blade transfer. Also noticed that if two transfers are
happening at the same time, both will stall, not just one, but ssh consoles
don't seem to be effected only high volume transfers like scp and rsync.
It also seems like the more active connections the more likely a stal
I have no idea... but as a matter of principle I would see if updating to
later code,
both OS and especially the driver, reproduces the issue. Our validation
group
often has Linux as a link partner in testing, which can be good and bad, it
actually
sometimes has problems that FBSD on both sides doe
On 7/18/2011 7:20 AM, Steven Hartland wrote:
>
> The layout for this test was:-
> Source (7.0-RELEASE-p2 on em0) -> Cisco 6509 -> supermicro blade -> Target
> (8.2-RELEASE on igb0)
Perhaps this might fix your issue ?
http://svnweb.freebsd.org/base?view=revision&revision=223675
It was MFC'd to R
Hi Steven,
On 11-07-18 12:11 PM, Steven Hartland wrote:
Confirmed with blade to blade transfer. Also noticed that if two
transfers are
happening at the same time, both will stall, not just one, but ssh
consoles
don't seem to be effected only high volume transfers like scp and rsync.
It also s
On 07/14/11 00:02, a...@freebsd.org wrote:
Synopsis: [ral] ral(4) needs to be resynced with OpenBSD's to gain RT2860/2870
support.
Responsible-Changed-From-To: freebsd-net->freebsd-wireless
Responsible-Changed-By: ae
Responsible-Changed-When: Thu Jul 14 07:00:44 UTC 2011
Responsible-Changed-Why
Daniel, good day.
Mon, Jul 18, 2011 at 05:04:27PM +0300, Daniel Braniss wrote:
> this code behaves correctly when run from a diskless host which
> booted via PXE, but fails on a host that was booted from disk.
> hint: the non working sends a packet with a non ethernet broadcast
> address and an ip
On 16-7-2011 14:40, Willem Jan Withagen wrote:
> On 15-7-2011 18:47, Steven Hartland wrote:
>> Been trying to identify an strange network stalling issue while using
>> scp or rsync between two machines, initially at remote locations.
>>
>> The behaviour has proved quite difficult to track as it see
- Original Message -
From: "Jack Vogel"
I have no idea... but as a matter of principle I would see if updating to
later code,
both OS and especially the driver, reproduces the issue. Our validation
group often has Linux as a link partner in testing, which can be good and bad,
it actua
Old Synopsis: freebsd ipv6 address are advertised but do not respond
New Synopsis: [ip6] freebsd ipv6 address are advertised but do not respond
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Tue Jul 19 05:16:38 UTC 2011
Responsible-
15 matches
Mail list logo