Re: Marvell/SysKonnect YukonII source code available
On Thu, 26 Jan 2006, Vulpes Velox wrote: On Tue, 24 Jan 2006 11:19:05 +0100 Andre Oppermann <[EMAIL PROTECTED]> wrote: Marvell/SysKonnect made the source code to the YukonII chips available today under a BSD license: ... I haven't tested the driver yet and I don't know if it available directly from the their website already. Who would one send bug reports too? well, that's a good question. I have a 88E8053 in a laptop with a releng_6 install that is up to date as of saturday. The status of the connection does not change off of "no carrier". Yeah lucky you. I have manually updated it so it compiles on HEAD but loading it on amd64 makes the machine panic. Not that I'd have expected it to fully work asap;) I guess it would be best to wait until the driver is officially supported by the FreeBSD project (read once it is comitted). -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Failover and load balancing using advanced NAT daemon
Hello, Jon Simola <[EMAIL PROTECTED]> wrote: > You may want to check out PF, the packet filter imported from OpenBSD. > I have it running on some large routers doing NAT out multiple > interfaces, load balancing and policy routing. Careful use of anchors > and some scripting (or ifstated which might be in ports) can move > traffic off failed links or respond to changing loads. > I've done a lot with both ipfw and PF now, and I'm finding PF to be > more flexible for my uses. Thanks. I've looked through PF documentation and find it quite interesting to use in this tasks. In combination with ifstated much can be done. I'm sorry for my incompetence in this case. I have always used ipfw for packet processing and now find a mistake not looking through PF. As I can now say ipfw is faster and easier to configure, but PF contains more flexible mechanisms supporting aliasing address pools for NAT and stateful routing. The only visible problem I see is a lack of policy routing in FreeBSD routing system which is used to create session listener when packets origin is a router itself (like tunnels) and packets cant be passed through NAT to be routed to another interface different from that in routing table. -- Best regards, Oleg Tarasov mailto:[EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Named could not listen on UDP socket: permission denied
Hello, I run FreeBSD 6.0 and I have begun to recieve quite periodic error messages like these: Jan 25 19:45:50 central named[728]: could not listen on UDP socket: permission denied Jan 25 19:45:50 central named[728]: creating IPv4 interface ng0 failed; interface ignored ng0 is my main internet interface and is created on early boot (rcordered like ppp-user) by mpd. Certainly, I need DNS listening on this interface. The reason is that if mpd is restarted for some reason, interface ng0 is destroyed and created again while listener on this interface is destroyed too. Named is chrooted at this time and cannot re-bind listener on this interface. Only manual restart of named helps it bind to this interface. This is not deadly situation as if I manually restart mpd I will be able to restart named too... Running named under root user or out of chroot environment is not quite acceptable way... Please tell me if this problem has a solution other then above -- Best regards, Oleg Tarasov mailto:[EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Duplicate SAD entries lead to ESP tunnel malfunction
Hello, I run FreeBSD 6.0 and installed latest ported version of ipsec-tools. A had to create two IPSEC tunnels to two different hosts. On one host runs FreeBSD too, on another host is located hardware router DI-804HV (D-Link). That router is supposed to support IPSEC tunnelling and seems to work fine. When IPSEC tunnel is established two SAD entries are created - one per direction. This is normal functioning. In my case sometimes there are two more created. Some connection problem occurs causing both sides to reestablish tunnel. Both sides report that tunnel is established successfully but no packets can pass through tunnel. Dumping SAD entries using setkey -D shows that there are two SAD entries for both address pairs. How can this happen anyway? Flushing SAD entries helps tunnel to return its functionality - after this tunnel is established successfully and works properly. === central# setkey -D 172.21.0.222 172.21.0.224 esp mode=tunnel spi=230854012(0x0dc28d7c) reqid=0(0x) E: 3des-cbc dabdc3b8 ea8f9519 c755b2da 57d348f5 a319f839 555e5759 A: hmac-md5 8139183d b8c06aea 65ac6a72 4c93f714 seq=0x3c46 replay=4 flags=0x state=mature created: Jan 26 17:58:29 2006 current: Jan 26 18:58:41 2006 diff: 3612(s) hard: 28800(s) soft: 23040(s) last: Jan 26 18:58:35 2006 hard: 0(s) soft: 0(s) current: 2689960(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 15430hard: 0 soft: 0 sadb_seq=5 pid=5501 refcnt=2 172.21.0.224 172.21.0.222 esp mode=tunnel spi=192143459(0x0b73e063) reqid=0(0x) E: 3des-cbc 5b75d9dc b2cba7c5 be08b863 e11e3c79 b993f636 d76b4437 A: hmac-md5 69759773 cfeb1fe1 e0dac25f 5360851e seq=0x30fd replay=4 flags=0x state=mature created: Jan 26 17:58:29 2006 current: Jan 26 18:58:41 2006 diff: 3612(s) hard: 28800(s) soft: 23040(s) last: Jan 26 18:58:35 2006 hard: 0(s) soft: 0(s) current: 1781854(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 12541hard: 0 soft: 0 sadb_seq=4 pid=5501 refcnt=1 172.21.0.222 172.21.0.225 esp mode=tunnel spi=1241514000(0x4a10) reqid=0(0x) E: 3des-cbc 71061694 cf98e926 fed56e44 ca6437fd d681a362 36342bd0 A: hmac-md5 8c62152f 272b19d5 dcda82db 4772d15c seq=0x replay=4 flags=0x state=mature created: Jan 26 18:49:30 2006 current: Jan 26 18:58:41 2006 diff: 551(s)hard: 28800(s) soft: 23040(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0hard: 0 soft: 0 sadb_seq=3 pid=5501 refcnt=1 172.21.0.222 172.21.0.225 esp mode=tunnel spi=1207959568(0x4810) reqid=0(0x) E: 3des-cbc 17aab273 2df4dca8 7871aa0c b3342a68 35221d02 bbbabbf6 A: hmac-md5 4f708fc1 1762371d 95e55918 1a167a31 seq=0x00a7 replay=4 flags=0x state=mature created: Jan 26 17:58:03 2006 current: Jan 26 18:58:41 2006 diff: 3638(s) hard: 28800(s) soft: 23040(s) last: Jan 26 18:58:30 2006 hard: 0(s) soft: 0(s) current: 18656(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 167 hard: 0 soft: 0 sadb_seq=2 pid=5501 refcnt=2 172.21.0.225 172.21.0.222 esp mode=tunnel spi=220625554(0x0d267a92) reqid=0(0x) E: 3des-cbc a446d441 856a0ed3 0f8d8ad8 065a6b27 da756609 98fa670e A: hmac-md5 7f14777f e5131500 8c345030 d90900d2 seq=0x0003 replay=4 flags=0x state=mature created: Jan 26 18:49:30 2006 current: Jan 26 18:58:41 2006 diff: 551(s)hard: 28800(s) soft: 23040(s) last: Jan 26 18:49:56 2006 hard: 0(s) soft: 0(s) current: 144(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 3hard: 0 soft: 0 sadb_seq=1 pid=5501 refcnt=1 172.21.0.225 172.21.0.222 esp mode=tunnel spi=90138890(0x055f690a) reqid=0(0x) E: 3des-cbc 4f77a3d4 7d2e446c a0e54ee5 ed482e15 e6e4b75b d723803c A: hmac-md5 ebc9281a 780016ce 295ad45a 9d969b46 seq=0x009e replay=4 flags=0x state=mature created: Jan 26 17:58:03 2006 current: Jan 26 18:58:41 2006 diff: 3638(s) hard: 28800(s) soft: 23040(s) last: Jan 26 18:00:44 2006 hard: 0(s) soft: 0(s) current: 9480(bytes)hard: 0(bytes) soft: 0(bytes) allocated: 158 hard: 0 soft: 0 sadb_seq=0 pid=5501 refcnt=1 === central# setkey -D -P 192.168.0.0/24[any] 192.168.82.0/24[any] any in ipsec esp/tunnel/172.21.0.224-172.21.0.222/require created: Jan 26 15:20:00 2006 lastused: Jan
Re: Duplicate SAD entries lead to ESP tunnel malfunction
Oleg Tarasov wrote: Hello, I run FreeBSD 6.0 and installed latest ported version of ipsec-tools. A had to create two IPSEC tunnels to two different hosts. On one host runs FreeBSD too, on another host is located hardware router DI-804HV (D-Link). That router is supposed to support IPSEC tunnelling and seems to work fine. When IPSEC tunnel is established two SAD entries are created - one per direction. This is normal functioning. In my case sometimes there are two more created. Some connection problem occurs causing both sides to reestablish tunnel. Both sides report that tunnel is established successfully but no packets can pass through tunnel. Dumping SAD entries using setkey -D shows that there are two SAD entries for both address pairs. How can this happen anyway? Flushing SAD entries helps tunnel to return its functionality - after this tunnel is established successfully and works properly. There is a sysctl that can help this behaviour but I forget which something to do with ipsec and oldSAD or newSAD or something.. == ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VPN when host is not gateway
Tiago Cruz wrote: > On Mon, 2006-01-23 at 20:49 +, Nate Nielsen wrote: > > >>I'd use tcpdump on the various interfaces (tap devices, ethernet) on the >>machines in question to see exactly at which host is not forwarding the >>packets properly and where they're going. > > > Thank you Nielsen! > I'm not expert in art of tcpdump, bu I see that: > > So, my questions is this: How I make this route? I guess either with the 'route' command or by running a routing protocol like RIP or OSPF. Cheers, Nate ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Race condition in ip6_getpmtu (actually gif)?
On Wed, Jan 25, 2006 at 09:20:33AM -0600, [EMAIL PROTECTED] wrote: > I seem to be running into a race condition in ip6_getpmtu. I've been > having sporadic panics recently -- sometimes the machine will last a > week, sometimes it'll panic twice in a day. The backtrace is always the > same: > > -- snip -- After some more analysis I think this is a problem in in6_gif_output. It keeps a cached route in its softc. After ip6_output completes, if IFF_LINK0 is not set, the cached route is freed. This works fine so long as in6_gif_output is not reentered. My current theory is that a higher priority kernel thread is preempting while we're somewhere in ip6_getmtu. Say, an incoming IPv4 ICMP packet might cause the NIC driver to call ether_input from an ithread. Since IPv4 is marked NETISR_MPSAFE it will be dispatched from the ithread, filter all the way down to icmp_input, which decides that an ICMP reply needs to be sent a host across the tunnel. It goes to icmp_send, which passes it to ip_output. The destination is a gif interface, so into gif_output we go, and BAM! We just re-entered in6_gif_output while still in the ithread. When this happens, the route cached in the sc is still valid, so a new one is not allocated. After ip6_output completes, the route is freed and set to NULL. Later, context returns to the original thread, and ip6_getpmtu (called from ip6_output) has just had its route pulled out from under it... It's a longshot, but I think it is possible and that would certainly explain why it sometimes takes millions of packets to trigger. Attached is a quick hack to protect the cached route with a mutex. A better fix with less overhead would be to allocate the route in a local variable on the stack, and only copy it to the softc if route caching is enabled. I'll run for a couple weeks with the patch and file a PR if that fixes it. If I have time I'll also try to set up a test machine and attempt to detect if ip6_gif_output is indeed reentered, and if so how. I think this should only be a problem for gif when IPv4 is the inner protocol and IPv6 is the outer. Since IPv4 is MPSAFE and v6 is not, gif might sometimes inadvertently cause v6 code that hasn't been fully locked to be re-entered or otherwise called without GIANT held. There may be other problems that are less likely to occur... Craig ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Race condition in ip6_getpmtu (actually gif)?
On Thu, Jan 26, 2006 at 08:05:28PM -0600, Craig Boston wrote:
> Attached is a quick hack...
Whoops, patch _actually_ attached this time.
=== net/if_gif.c
==
--- net/if_gif.c(/vendor/sys) (revision 292)
+++ net/if_gif.c(/gif6) (revision 292)
@@ -154,6 +154,8 @@
return (ENOSPC);
}
+ mtx_init(&sc->gif_ro_mtx, "gif_ro_mtx", NULL, MTX_DEF);
+
GIF2IFP(sc)->if_softc = sc;
if_initname(GIF2IFP(sc), ifc->ifc_name, unit);
@@ -227,6 +229,7 @@
mtx_lock(&gif_mtx);
LIST_REMOVE(sc, gif_list);
mtx_unlock(&gif_mtx);
+ mtx_destroy(&sc->gif_ro_mtx);
gif_destroy(sc);
}
=== net/if_gif.h
==
--- net/if_gif.h(/vendor/sys) (revision 292)
+++ net/if_gif.h(/gif6) (revision 292)
@@ -65,6 +65,7 @@
struct route_in6 gifscr_ro6; /* xxx */
#endif
} gifsc_gifscr;
+ struct mtx gif_ro_mtx;
int gif_flags;
const struct encaptab *encap_cookie4;
const struct encaptab *encap_cookie6;
=== netinet6/in6_gif.c
==
--- netinet6/in6_gif.c (/vendor/sys) (revision 292)
+++ netinet6/in6_gif.c (/gif6) (revision 292)
@@ -195,25 +195,30 @@
dst->sin6_family = sin6_dst->sin6_family;
dst->sin6_len = sizeof(struct sockaddr_in6);
dst->sin6_addr = sin6_dst->sin6_addr;
+ mtx_lock(&sc->gif_ro_mtx);
if (sc->gif_ro6.ro_rt) {
RTFREE(sc->gif_ro6.ro_rt);
sc->gif_ro6.ro_rt = NULL;
}
+ mtx_unlock(&sc->gif_ro_mtx);
#if 0
GIF2IFP(sc)->if_mtu = GIF_MTU;
#endif
}
+ mtx_lock(&sc->gif_ro_mtx);
if (sc->gif_ro6.ro_rt == NULL) {
rtalloc((struct route *)&sc->gif_ro6);
if (sc->gif_ro6.ro_rt == NULL) {
m_freem(m);
+ mtx_unlock(&sc->gif_ro_mtx);
return ENETUNREACH;
}
/* if it constitutes infinite encapsulation, punt. */
if (sc->gif_ro.ro_rt->rt_ifp == ifp) {
m_freem(m);
+ mtx_unlock(&sc->gif_ro_mtx);
return ENETUNREACH; /*XXX*/
}
#if 0
@@ -238,6 +243,7 @@
RTFREE(sc->gif_ro6.ro_rt);
sc->gif_ro6.ro_rt = NULL;
}
+ mtx_unlock(&sc->gif_ro_mtx);
return (error);
}
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
