Re: Can someone take a look at PR 89061 (ipv6 autoconfigure 6to4)
At Fri, 8 Sep 2006 17:14:18 -0700, Matt Reimer wrote: Can someone take a look at PR 89061 (http://www.freebsd.org/cgi/query-pr.cgi?pr=89061). It contains a patch adding an /etc/rc.conf knob to autoconfigure an RFC 3068 6to4 address. The comments in the PR indicate that awk can't be used at that point, so if that's true, while I think it's a good idea, the implementation will have to changed. From an IPv6 standpoint it's fine though. Later, George ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problems with ng_fec
Thank you, this was exactly right. Just had to wait for maintenance day to try it. (copying the list for the archives) On Thu, Sep 07, 2006 at 11:15:20AM +0200, Robert Blacquiere wrote: On Wed, Sep 06, 2006 at 10:56:48PM -0400, Michael W. Lucas wrote: Hi, (asked this first on -questions, but it seems that this exceeds their wisdom...) I'm using a recent -current on amd64, and trying to use ng_fec to hopefully provide a wide-bandwidth connection with cable-level redundancy, and instead I get get errors and sporadic connectivity. I configured fec0 as such: #!/bin/sh ngctl mkpeer fec dummy fec ngctl msg fec0: add_iface 'em3' ngctl msg fec0: add_iface 'em7' ngctl msg fec0: set_mode_inet ifconfig fec0 up ifconfig fec0 inet 10.184.1.19 netmask 255.255.0.0 The Cisco 6509 I was attached to had ports configured with: switchport trunk encapsulation dot1q switchport mode trunk You need a port channel interface and make the switchports member of the port channel. some thing like: ! interface Port-channel1 description 2 combined interfaces to freebsd fec0 switchport ! only needed for vlan tagging... ! switchport trunk encapsulation dot1q ! switchport trunk allowed vlan x,y,z,... ! switchport mode trunk ! mtu 9216 no ip address interface GigabitEthernet5/1 description UPLINK #1 switchport ! needer only for vlan tagging ! switchport trunk encapsulation dot1q ! switchport trunk allowed vlan x,y,z,... ! switchport mode trunk ! mtu 9216 no ip address no cdp enable channel-group 1 mode on interface GigabitEthernet5/2 description UPLINK #2 switchport ! needer only for vlan tagging ! switchport trunk encapsulation dot1q ! switchport trunk allowed vlan x,y,z,... ! switchport mode trunk ! mtu 9216 no ip address no cdp enable channel-group 1 mode on When I tried to ping various hosts, however, I got sporadic and intermittent connectivity to other hosts on the network. This is spanning tree behavour Dmesg follows after log entries. Any suggestions? Thanks, ==ml Hopeful this will give you a head start in configuring the cisco. Robert -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: Hey guys you left some holes out there! -- Michael W. Lucas[EMAIL PROTECTED], [EMAIL PROTECTED] http://www.BlackHelicopters.org/~mwlucas/ Latest book: PGP GPG -- http://www.pgpandgpg.com The cloak of anonymity protects me from the nuisance of caring. -Non Sequitur ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ppp command port does not listens on ipv4 unless no INET6 in kernel
Hi,
On Thu, 14 Sep 2006 15:44:18 +0200 (CEST)
Julian Stacey [EMAIL PROTECTED] said:
jhs I'm not clear if this is a bug or a config error:
jhs It seems though my /usr/sbin/ppp was moving traffic
jhs to from internet, it was only listening for commands
jhs (not data) on ipv6, not ipv4, thus I could not type commands
jhs like dial drop, unless instead of running ppp -auto
jhs instead I invoked ppp manually in foreground on localhost.
As far as I read the source of ppp(8), it only listen on an IPv6, and
expects to listen on an IPv4 through an IPv4-mapped IPv6 address.
However, an IPv4-mapped IPv6 address feature is disabled by default.
ppp(8) should be rewritten to listen on both an IPv4 and an IPv6.
But, it is slightly complex. So, I made a patch to enable an
IPv4-mapped IPv6 address only for the socket that ppp(8) is listening
on.
I have no environment for testing this. Could you try this patch?
Index: usr.sbin/ppp/server.c
diff -u -p usr.sbin/ppp/server.c.orig usr.sbin/ppp/server.c
--- usr.sbin/ppp/server.c.orig Sun Sep 5 10:46:52 2004
+++ usr.sbin/ppp/server.c Sun Sep 17 19:54:43 2006
@@ -346,6 +346,13 @@ server_TcpOpen(struct bundle *bundle, u_
goto failed;
}
+#ifndef NOINET6
+ if (probe.ipv6_available) {
+int off = 0;
+setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, (char *)off, sizeof(off));
+ }
+#endif
+
setsockopt(s, SOL_SOCKET, SO_REUSEADDR, s, sizeof s);
if (bind(s, (struct sockaddr *)ss, sz) 0) {
log_Printf(LogWARN, Tcp: bind: %s\n, strerror(errno));
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FAST_IPSEC NAT-T support
On Fri, Sep 15, 2006 at 12:07:58PM -0400, Scott Ullrich wrote: [] Next problem that I have encountered (with FAST_IPSEC) is: # /sbin/setkey -D Invalid extension type Invalid extension type Invalid extension type Invalid extension type Invalid extension type Invalid extension type Invalid extension type Invalid extension type Invalid extension type Invalid extension type Invalid extension type Invalid extension type Invalid extension type Invalid extension type Let me know if I can do any further testing, still waiting for status reports from a few of the pfSense users, but IPSEC seems to work okay even with this small cosmetic setkey issue. Make sure your ipsec-tools port have been recompiled after your system has been patched / compiled / upgraded, and use /usr/local/sbin/setkey. FreeBSD's setkey does not (yet ?) support NAT-T extensions at all. Yvan. -- NETASQ http://www.netasq.com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS-UP: VLAN tag changes committed
FYI.
---BeginMessage---
andre 2006-09-17 13:33:30 UTC
FreeBSD src repository
Modified files:
sys/dev/bce if_bce.c
sys/dev/bge if_bge.c
sys/dev/em if_em.c
sys/dev/ixgb if_ixgb.c
sys/dev/nfe if_nfe.c
sys/dev/nge if_nge.c
sys/dev/re if_re.c
sys/dev/stge if_stge.c
sys/dev/ti if_ti.c
sys/dev/txp if_txp.c
sys/dev/vge if_vge.c
sys/net if_vlan.c if_vlan_var.h
sys/net80211 ieee80211_input.c ieee80211_output.c
sys/netgraph ng_vlan.c
sys/sys mbuf.h
Log:
Move ethernet VLAN tags from mtags to its own mbuf packet header field
m_pkthdr.ether_vlan. The presence of the M_VLANTAG flag on the mbuf
signifies the presence and validity of its content.
Drivers that support hardware VLAN tag stripping fill in the received
VLAN tag (containing both vlan and priority information) into the
ether_vtag mbuf packet header field:
m-m_pkthdr.ether_vtag = vlan_id; /* ntohs()? */
m-m_flags |= M_VLANTAG;
to mark the packet m with the specified VLAN tag.
On output the driver should check the mbuf for the M_VLANTAG flag to
see if a VLAN tag is present and valid:
if (m-m_flags M_VLANTAG) {
... = m-m_pkthdr.ether_vtag; /* htons()? */
... pass tag to hardware ...
}
VLAN tags are stored in host byte order. Byte swapping may be necessary.
(Note: This driver conversion was mechanic and did not add or remove any
byte swapping in the drivers.)
Remove zone_mtag_vlan UMA zone and MTAG_VLAN definition. No more tag
memory allocation have to be done.
Reviewed by:thompsa, yar
Sponsored by: TCP/IP Optimization Fundraise 2005
Revision ChangesPath
1.8 +4 -7 src/sys/dev/bce/if_bce.c
1.146 +4 -6 src/sys/dev/bge/if_bge.c
1.145 +7 -12 src/sys/dev/em/if_em.c
1.20 +13 -4 src/sys/dev/ixgb/if_ixgb.c
1.5 +5 -16 src/sys/dev/nfe/if_nfe.c
1.89 +5 -8 src/sys/dev/nge/if_nge.c
1.75 +6 -9 src/sys/dev/re/if_re.c
1.3 +6 -6 src/sys/dev/stge/if_stge.c
1.125 +4 -7 src/sys/dev/ti/if_ti.c
1.42 +4 -7 src/sys/dev/txp/if_txp.c
1.26 +5 -8 src/sys/dev/vge/if_vge.c
1.115 +5 -17 src/sys/net/if_vlan.c
1.25 +16 -39src/sys/net/if_vlan_var.h
1.95 +2 -10 src/sys/net80211/ieee80211_input.c
1.43 +2 -3 src/sys/net80211/ieee80211_output.c
1.4 +8 -8 src/sys/netgraph/ng_vlan.c
1.196 +1 -4 src/sys/sys/mbuf.h
---End Message---
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FAST_IPSEC NAT-T support
On 9/17/06, VANHULLEBUS Yvan [EMAIL PROTECTED] wrote: Make sure your ipsec-tools port have been recompiled after your system has been patched / compiled / upgraded, and use /usr/local/sbin/setkey. FreeBSD's setkey does not (yet ?) support NAT-T extensions at all. I tried both /sbin/setkey and /usr/locals/bin/setkey and both result in the same Invalid extension type errors. builder# ls -la /sbin/setkey -r-xr-xr-x 1 root wheel 56456 Jun 16 03:49 /sbin/setkey builder# ls -la /usr/local/sbin/setkey -r-xr-xr-x 1 root wheel 86472 Sep 17 15:54 /usr/local/sbin/setkey # /sbin/setkey -D Invalid extension type Invalid extension type Invalid extension type Invalid extension type Invalid extension type Invalid extension type Invalid extension type Invalid extension type # /usr/local/sbin/setkey -D Invalid extension type Invalid extension type Invalid extension type Invalid extension type Invalid extension type Invalid extension type Invalid extension type Invalid extension type Can you think of anything else to try? I re-compiled ipsec-tools on the same host before sending this. Thanks! ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ppp command port does not listens on ipv4 unless no INET6 in kernel
I have no environment for testing this. Could you try this patch? Yes certainly, thanks a lot, delighted to get a reply will report back soon. -- Julian Stacey. BSD Unix C Net Consultancy, Munich/Muenchen http://berklix.com Mail Ascii, not HTML. Ihr Rauch = mein allergischer Kopfschmerz. Don't buy it ! Get it free ! http://berklix.org/free-software ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
kevent/kqueue http socks proxy
Hi list. I've found bsdproxy using kevent/kqueue(2) system calls. Is there any http/https and/or socks proxy using this mechanism? Thanks ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ppp command port does not listens on ipv4 unless no INET6 in kernel
On Sun, 17 Sep 2006 20:10:47 +0900 Hajimu UMEMOTO [EMAIL PROTECTED] wrote:
Hi,
On Thu, 14 Sep 2006 15:44:18 +0200 (CEST)
Julian Stacey [EMAIL PROTECTED] said:
jhs I'm not clear if this is a bug or a config error:
jhs It seems though my /usr/sbin/ppp was moving traffic
jhs to from internet, it was only listening for commands
jhs (not data) on ipv6, not ipv4, thus I could not type commands
jhs like dial drop, unless instead of running ppp -auto
jhs instead I invoked ppp manually in foreground on localhost.
As far as I read the source of ppp(8), it only listen on an IPv6, and
expects to listen on an IPv4 through an IPv4-mapped IPv6 address.
However, an IPv4-mapped IPv6 address feature is disabled by default.
ppp(8) should be rewritten to listen on both an IPv4 and an IPv6.
But, it is slightly complex. So, I made a patch to enable an
IPv4-mapped IPv6 address only for the socket that ppp(8) is listening
on.
I have no environment for testing this. Could you try this patch?
Index: usr.sbin/ppp/server.c
diff -u -p usr.sbin/ppp/server.c.orig usr.sbin/ppp/server.c
--- usr.sbin/ppp/server.c.origSun Sep 5 10:46:52 2004
+++ usr.sbin/ppp/server.c Sun Sep 17 19:54:43 2006
@@ -346,6 +346,13 @@ server_TcpOpen(struct bundle *bundle, u_
goto failed;
}
+#ifndef NOINET6
+ if (probe.ipv6_available) {
+int off = 0;
+setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, (char *)off, sizeof(off));
+ }
+#endif
+
setsockopt(s, SOL_SOCKET, SO_REUSEADDR, s, sizeof s);
if (bind(s, (struct sockaddr *)ss, sz) 0) {
log_Printf(LogWARN, Tcp: bind: %s\n, strerror(errno));
Sincerely,
AFAIR I had trouble getting that code to work and was advised at
the time that I'd just get the mapped port for free. I haven't
been using IPv6 on production machines for some time, so I haven't
seen the problem :(
It'd be great if you'd commit the patch if Julian says it works
ok for him.
Cheers.
--
Brian Somers [EMAIL PROTECTED]
Don't _EVER_ lose your sense of humour ! [EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iwi discarding oversized packets while mtu=1500 for src/dst
Sam Leffler wrote: Hans Nieser wrote: Sam Leffler wrote: Hans Nieser wrote: [EMAIL PROTECTED]:~# uname -a FreeBSD aphax-laptop.lan 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Thu May 11 07:17:09 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/APHAX-LAPTOP i386 Are you running the iwi driver that came with 6.1-release? If so it has numerous problems that have been fixed in 6-STABLE and HEAD. I'm not sure how best to update your system except by going to 6-STABLE via a src upgrade. Today I have upgraded my laptop to 6-STABLE, but unfortunately the problems remain. I don't even know wether iwi is to blame, because I can't figure out wether perhaps xl on my server really is sending out too large packets. That is, so far I've been assuming that an mtu of 1500 may not mean that there's exactly 1500 bytes going over the wire (overhead of protocols to which the mtu doesn't apply or something, I dunno, I'm no networking expert obviously :), because xl is definitely sending out packets of 1518 bytes. Which iwi on my laptop doesn't like, but the NIC in my desktop machine (which runs Linux) has no problem with. Maybe someone can tell me which of the machines is in error here, at least I'd know what to blame :( The fact that my Linux box doesn't discard these packages coming from my server made me suspicious of iwi initially, but maybe iwi is doing nothing wrong and my Linux box is simply willing to accept these oversized packets. I can't speak to linux but an mtu of 1500 will cause a 1518 byte packet to be discarded. I don't recall what your problem was but if the iwi driver is receiving the frame and passing it up only to be discarded by the 802.3 layer then you've received a frame that's too large and you should look at the sender side for why it's being generated. If you don't want to do that you can probably just up the mtu on iwi and let the frame through. This does sound awfully lot like the driver doesn't strip the 4 byte checksum of a basic 802.[23] ethernet frame. My initial thought was that it was a vlan frame but the frame protocol indicates it's an IP packet. Perhaps it's a frame that slips through the AP's checks on it's way out to the wireless? -- Sten Daniel Sørsdal ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iwi discarding oversized packets while mtu=1500 for src/dst
Sten Daniel Sørsdal wrote: Sam Leffler wrote: Hans Nieser wrote: Sam Leffler wrote: Hans Nieser wrote: [EMAIL PROTECTED]:~# uname -a FreeBSD aphax-laptop.lan 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Thu May 11 07:17:09 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/APHAX-LAPTOP i386 Are you running the iwi driver that came with 6.1-release? If so it has numerous problems that have been fixed in 6-STABLE and HEAD. I'm not sure how best to update your system except by going to 6-STABLE via a src upgrade. Today I have upgraded my laptop to 6-STABLE, but unfortunately the problems remain. I don't even know wether iwi is to blame, because I can't figure out wether perhaps xl on my server really is sending out too large packets. That is, so far I've been assuming that an mtu of 1500 may not mean that there's exactly 1500 bytes going over the wire (overhead of protocols to which the mtu doesn't apply or something, I dunno, I'm no networking expert obviously :), because xl is definitely sending out packets of 1518 bytes. Which iwi on my laptop doesn't like, but the NIC in my desktop machine (which runs Linux) has no problem with. Maybe someone can tell me which of the machines is in error here, at least I'd know what to blame :( The fact that my Linux box doesn't discard these packages coming from my server made me suspicious of iwi initially, but maybe iwi is doing nothing wrong and my Linux box is simply willing to accept these oversized packets. I can't speak to linux but an mtu of 1500 will cause a 1518 byte packet to be discarded. I don't recall what your problem was but if the iwi driver is receiving the frame and passing it up only to be discarded by the 802.3 layer then you've received a frame that's too large and you should look at the sender side for why it's being generated. If you don't want to do that you can probably just up the mtu on iwi and let the frame through. This does sound awfully lot like the driver doesn't strip the 4 byte checksum of a basic 802.[23] ethernet frame. My initial thought was that it was a vlan frame but the frame protocol indicates it's an IP packet. Perhaps it's a frame that slips through the AP's checks on it's way out to the wireless? Hmm, I'm not exactly sure what all this means but I suppose I could spent some time capturing packets on both sides and see if anything happens in between, and maybe read a book or two on networking/tcp-ip =] I should maybe also mention that my desktop Linux box is connected over wifi as well. Perhaps if the AP is at fault, it would explain some weird packetloss problems I've been having when playing online games (and maybe in other situations as well, but I guess this kind of thing is most noticable with online games). ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kevent/kqueue http socks proxy
Anton Butsyk wrote this message on Sun, Sep 17, 2006 at 21:40 +0300: I've found bsdproxy using kevent/kqueue(2) system calls. Is there any http/https and/or socks proxy using this mechanism? I believe squid makes use of kqueue, or our port of squid has patches the uses it... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ppp command port does not listens on ipv4 unless no INET6 in kernel
Brian Somers wrote:
On Sun, 17 Sep 2006 20:10:47 +0900 Hajimu UMEMOTO [EMAIL PROTECTED] wrote:
Hi,
On Thu, 14 Sep 2006 15:44:18 +0200 (CEST)
Julian Stacey [EMAIL PROTECTED] said:
jhs I'm not clear if this is a bug or a config error:
jhs It seems though my /usr/sbin/ppp was moving traffic
jhs to from internet, it was only listening for commands
jhs (not data) on ipv6, not ipv4, thus I could not type commands
jhs like dial drop, unless instead of running ppp -auto
jhs instead I invoked ppp manually in foreground on localhost.
As far as I read the source of ppp(8), it only listen on an IPv6, and
expects to listen on an IPv4 through an IPv4-mapped IPv6 address.
However, an IPv4-mapped IPv6 address feature is disabled by default.
ppp(8) should be rewritten to listen on both an IPv4 and an IPv6.
But, it is slightly complex. So, I made a patch to enable an
IPv4-mapped IPv6 address only for the socket that ppp(8) is listening
on.
I have no environment for testing this. Could you try this patch?
Index: usr.sbin/ppp/server.c
diff -u -p usr.sbin/ppp/server.c.orig usr.sbin/ppp/server.c
--- usr.sbin/ppp/server.c.orig Sun Sep 5 10:46:52 2004
+++ usr.sbin/ppp/server.c Sun Sep 17 19:54:43 2006
@@ -346,6 +346,13 @@ server_TcpOpen(struct bundle *bundle, u_
goto failed;
}
+#ifndef NOINET6
+ if (probe.ipv6_available) {
+int off = 0;
+setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, (char *)off, sizeof(off));
+ }
+#endif
+
setsockopt(s, SOL_SOCKET, SO_REUSEADDR, s, sizeof s);
if (bind(s, (struct sockaddr *)ss, sz) 0) {
log_Printf(LogWARN, Tcp: bind: %s\n, strerror(errno));
Sincerely,
AFAIR I had trouble getting that code to work and was advised at
the time that I'd just get the mapped port for free. I haven't
been using IPv6 on production machines for some time, so I haven't
seen the problem :(
It'd be great if you'd commit the patch if Julian says it works
ok for him.
Tested. It Works. Thanks !
I tested the patch on PPP running under both kernels IPV4+6 V4only
just to be sure, it works on both, allows me to type dial down
(all I tried or wanted.)
Output With patch:
strings /boot/kernel/kernel | grep ___ | grep INET
___options INET
___options INET6
sockstat -l
USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root ppp939 9 tcp46 *:12345 *:*
strings /boot/kernel/kernel | grep ___ | grep INET
___options INET
___# options INET6
sockstat -l
USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root ppp931 9 tcp4 *:12345 *:*
Old V4+6 Kernel pre patch:
USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root ppp1020 9 tcp6 *:12345 *:*
I hope it's commited. (Dont't know if a 2nd tester is needed to verify ?)
Thanks Hajimu :-)
Julian
--
Julian Stacey. BSD Unix C Net Consultancy, Munich/Muenchen http://berklix.com
Mail Ascii, not HTML. Ihr Rauch = mein allergischer Kopfschmerz.
Don't buy it ! Get it free ! http://berklix.org/free-software
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ppp command port does not listens on ipv4 unless no INET6 in kernel
Hi, On Sun, 17 Sep 2006 23:35:57 +0200 Julian H. Stacey [EMAIL PROTECTED] said: AFAIR I had trouble getting that code to work and was advised at the time that I'd just get the mapped port for free. I haven't been using IPv6 on production machines for some time, so I haven't seen the problem :( It'd be great if you'd commit the patch if Julian says it works ok for him. jhs Tested. It Works. Thanks ! jhs I tested the patch on PPP running under both kernels IPV4+6 V4only jhs just to be sure, it works on both, allows me to type dial down jhs (all I tried or wanted.) jhs Output With patch: jhs strings /boot/kernel/kernel | grep ___ | grep INET jhs ___options INET jhs ___options INET6 jhs sockstat -l jhs USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS jhs root ppp939 9 tcp46 *:12345 *:* jhs strings /boot/kernel/kernel | grep ___ | grep INET jhs ___options INET jhs ___# options INET6 jhs sockstat -l jhs USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS jhs root ppp931 9 tcp4 *:12345 *:* jhs Old V4+6 Kernel pre patch: jhs USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS jhs root ppp1020 9 tcp6 *:12345 *:* jhs I hope it's commited. (Dont't know if a 2nd tester is needed to verify ?) Thank you for testing. I've just committed it. jhs Thanks Hajimu :-) You are welcome. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NIC Problems
[EMAIL PROTECTED] wrote: --On September 16, 2006 2:04:38 AM -0400 Tim Allender [EMAIL PROTECTED] wrote: Not sure if I should post this here or straight to the pfSensse list. I suspect this kind of thing is a faulty NIC but since I've not seen it before I'm not sure: vr0: receive error (81): rx buffer error vr0: revieve error (0024) no buffers vr0: receive error (81): rx buffer error vr0: revieve error (0024) no buffers vr0: receive error (81): rx buffer error vr0: revieve error (0024) no buffers vr0: receive error (81): rx buffer error vr0: revieve error (0024) no buffers What NIC is it? Good question. It's the onboard NIC for a Intel® Desktop Board D850GB. (http://www.intel.com/support/motherboards/desktop/d850gb/) You know, one of those one's from about 5 years back when RDRAM looked like it might be promising. The board uses RDRAM. It also uses one of those upgrade processor socket extensions to use socket 478 procs (upgraded from socket 423), so that I could put a spare 1.7 p4 in it that I didn't want to go to waste. I guess I've really squeezed my money's worth out of this old puppy. Actually, though, (concerning the issue) it seems to have stopped happening now that I've undone most of the traffic shaping rules I had setup. I did leave on Prioritize VoIP traffic, but disabled all the other rules I'd thrown in for the heck of it. Seems to be working fine now. (We'll see how the phone holds up). Maybe it's an issue with the extent to which the NIC supports ALTQ? I know, the one I setup at the office doesn't do traffic shaping at all. (old p3 board, onboard NIC not supporting ALTQ, that is). So, I wanted to try it out at home. I really want to get the full use out of the traffic shaping, though. It'll really come in handy at the office. I'm going to order a few NICs, for this purpose and to have some spares on hand. I'm not really sure, though, how to measure the quality of NICs beyond the typical 10/100/1000 rating. Are there certain NICs recommended to get the most out of ALTQ? Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
