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
, 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
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"
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"
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
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 +
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
_
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"
> 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
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
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
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
.
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
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
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]"
> 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
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
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
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]"
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]"
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.
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
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
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
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
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,
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:
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
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
29 matches
Mail list logo
