k address space (RFC-1918).
For some European countries I can tell, I've never seen routable
addresses being used on 3G networks. That might be the most likely cause
of your trouble.
All the best,
Volker
___
freebsd-net@freebsd.org mailing list
the attached patch works around the error for me. As this is contributed
code, it should be fixed upstream (no need to file a PR).
Volker
--- contrib/bind9/bin/dig/dighost.c.orig2009-09-13 14:24:13.0
+
+++ contrib/bind9/bin/dig/dighost.c 2009-09-13 14:31:52.0 +
The following reply was made to PR kern/144494; it has been noted by GNATS.
From: vol...@vwsoft.com
To: bug-follo...@freebsd.org, john.giacom...@lineratesystems.com
Cc:
Subject: Re: kern/144494: [ixgbe] ixgbe driver not built as module
Date: Mon, 08 Mar 2010 21:26:54 +0100
This is a multi-part
y want to change ${subject} and post to stable@ to drive more
attention to your problem.
Volker
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
fault fails, then you could get this error.
>
John,
thank you for pointing that out. I've forgotten the mmap'ing of files
over nfs as a possible source of that problem.
With 8-stable I'm seeing mbufs leaking with nfs operation. It may or may
not be related to Giulio's problem.
Volker
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
, 10.5.3.189 etc.. ). Then the problem is
solved.
I wonder how the default router can be changed with packets that came
from network?
How can i prevent this without writing firewall rules?
Or which packets should I drop?
Any ideas?
Özkan,
just one: Do you see RIP (521/tcp, 521/udp) traffic?
Volker
Ls (consult ``svn diff --help``).
It also works for directories and trees but you need to be play with
that a bit.
Volker
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
avecore).
BTW by instructing the kernel to save it's coredump onto a (dedicated)
USB thumb drive, I'm fetching core dumps from embedded units which is
otherwise impossible. You can than later analyze and debug your kernel
crash on a workstation machine.
HTH
Volker
_
> 2.00/0.01, addr 2
>
> from usbdevs -v
>
> port 5 addr 2: high speed, power 300 mA, config 1, 802.11 bg
> WLAN(0x1723), Ralink(0x0b05), rev 0.01
if_ural.c does not know about a usb ID 1723 (only Asus IDs 1706 and
1705 are known). You need to patch it.
HTH
Volker
axe(4) (at least not in STABLE, quite unsure for CURRENT). OpenBSD has
support for the AX88772 chipset.
Volker
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ipset which is currently not supported by aue(4) and is
giving some errors. I haven't been able to figure out what's wrong
with them.
When grabbing aue based USB NICs from an online source, the chances
are 3 out of 4 you're getting a supported one. But you should test
your USB
ting PHY information? I need to
know that to work with the submitter and get their interfaces running
(or retrieve information for you to work on).
Thanks!
Volker
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebs
On 05/12/08 13:19, Marius Strobl wrote:
> On Mon, May 12, 2008 at 12:35:59PM +0200, Volker wrote:
>> Hi!
>>
>> >From the bugbusting front, I'm often seeing network related issues with
>> unknown (new) PHYs.
>>
>> Can please somebody explain me
he newbus interface
> definition for miibus which would be a place to start.
Bruce,
am I correct assuming there's currently no easy way to get that information?
Thanks
Volker
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/m
g output did not show anything which would lead me to an
issue with racoon.
Where do I have to look for? How do I debug this problem? Did anybody
experience similar problems?
Thanks,
Volker
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.or
ess as all works fine while pf is disabled this is an pf issue, right?
Thanks,
Volker
On 2005-10-20 22:12, Volker wrote:
> Hi!
>
> A few days ago I've managed to setup two IPSec tunnels (3 machines
> involved) between FreeBSD 5.4R hosts.
>
> While I do not fully underst
none],
> length: 128) A.B.C.D > E.F.G.H: ESP(spi=0x029a41b4,seq=0x31)
> 1129985379.087562 00:13:c4:fa:6c:20 > 00:c0:9f:46:ec:c7, ethertype IPv4
> (0x0800), length 1366: IP (tos 0x8, ttl 61, id 48065, offset 0, flags
> [none], length: 1352) E.F.G.H > A.B.C.D:
the way tcpdump has seen these packets. That should be related to
priorisation of ACK packets using ALTQ.
Is anybody else here with deep TCP + IPSec knowledge able to get a look
into this? Any known issues? Is there anything I might also check out?
Is there a 64k limit with IPSec? :(
Thanks,
I'm seeing the
fragmented packets coming in properly.
If that's a reliable check for MTU than the problem should not be MTU
related. Is there any other way to check MTU problems by using `ping'?
Thanks,
Volker
On 2005-10-22 20:16, Michael VInce wrote:
> Try sending different
Max,
I set sack.enable=0 on both FreeBSD machines but the same happens.
Volker
On 2005-10-23 00:40, Max Laier wrote:
> To try something else: Could you guys try to disable SACK on the machines
> involved? I haven't looked at the dumps as of yet, but that's one simple
> t
rator)?
May I use FAST_IPSEC even without any hw-crypto devices? While reading
`man fast_ipsec' I would think it depends on a hw-crypto device...
Please tell me if we should check IPSEC / FAST_IPSEC and I'll start a
recompile.
Volker
On 2005-10-23 00:40, Max Laier wrote:
> To try someth
2
(ng0). That should already give enough room (>200byte) for IPSec headers
(as long as the whole path between both hosts does support an MTU of 1500).
I'm currently in the process of switching to FAST_IPSEC on both machines
and will repeat the test. It takes a bit longer as both machines are
rem
inside of the gif tunnel by using IPSec.
Volker
On 2005-10-24 17:08, VANHULLEBUS Yvan wrote:
> On Mon, Oct 24, 2005 at 11:05:21AM -0500, Matthew Grooms wrote:
>
>>Yvan,
>>
>>VANHULLEBUS Yvan wrote:
>>
>>
>>>We have *lots* of Gates running FreeBSD 4.
scp and a plain ascii transfer by using (g)netcat.
Matthew and me have dealt out to test an IPSec + gif setup over the
public internet one more time. I bet this will show the stalling, too.
bye,
Volker
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5/require;
^^
Regards,
Volker
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> to ISP my server will reboot with kernel panic.
>
Ok, I don't care if your ISP has resources or not to serve it's
customers but I would be interested in the actual kernel panic.
Better, please give us the full backtrace and everything else to
investigate this.
Thank you for your
nt_enable="YES"
--
I would be tempted to identify this behaviour as a (serious) bug.
Workaround
If the nis_client_flags option is uncommented like
#nis_client_flags="-S tdom,tdomserv.tdom.de,tdomserv -m"
--
Volker Jahns, [EMAIL PROTECTED]
> Running rpcbind on a FreeBSD 6.1
.
As a first guess I would recommend:
- check /etc/hosts.allow (ssh access control used by FreeBSD)
- shadow support
- rpcinfo -p works OK?
- run ypserv daemon in foregound, check its output
--
Volker Jahns, [EMAIL PROTECTED]
___
freebsd-net@freebsd.org
p localhost works as expected.
I want to run NIS on the system, so rpcbind must run in reliable manner.
Any help is much appreciated.
--
Volker Jahns, [EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebs
29 matches
Mail list logo
