Re: Text for IPv6 Scope
Dear all,
aren't site-local IPv6 addresses depreceated (RFC 3879)? So shouldn't
the site-local stuff be removed?
Best regards
Michael
On Jan 4, 2008, at 10:56 PM, Crist J. Clark wrote:
Anyone up for adding text to the scopeid field in the ifconfig(8)
output for IPv6 addresses? Other OSes do. To avoid too much
disruption to the current format, the text is appended after the
currently printed hexadecimal field.
Example:
fxp0: flags=8843 mtu 1500
options=8
inet6 fe80::290:27ff:fe13:2540%fxp0 prefixlen 64 scopeid
0x5(site-local)
While we're at it, update the in6.h file to include all scopes
in RFC4291.
Look OK? Anyone up for applying these?
Patches (diffs off of a not-too-current CURRENT):
Index: sbin/ifconfig/af_inet6.c
===
RCS file: /ncvs/freebsd/src/sbin/ifconfig/af_inet6.c,v
retrieving revision 1.5
diff -u -r1.5 af_inet6.c
--- sbin/ifconfig/af_inet6.c3 Feb 2007 03:40:33 - 1.5
+++ sbin/ifconfig/af_inet6.c4 Jan 2008 21:53:26 -
@@ -290,8 +290,31 @@
if ((flags6 & IN6_IFF_TEMPORARY) != 0)
printf("temporary ");
-if (scopeid)
- printf("scopeid 0x%x ", scopeid);
+if (scopeid) {
+ printf("scopeid 0x%x", scopeid);
+ switch (scopeid) {
+ case __IPV6_ADDR_SCOPE_INTFACELOCAL:
+ printf("(interface-local) ");
+ break;
+ case __IPV6_ADDR_SCOPE_LINKLOCAL:
+ printf("(link-local) ");
+ break;
+ case __IPV6_ADDR_SCOPE_ADMINLOCAL:
+ printf("(admin-local) ");
+ break;
+ case __IPV6_ADDR_SCOPE_SITELOCAL:
+ printf("(site-local) ");
+ break;
+ case __IPV6_ADDR_SCOPE_ORGLOCAL:
+ printf("(org-local) ");
+ break;
+ case __IPV6_ADDR_SCOPE_GLOBAL:
+ printf("(global) ");
+ break;
+ default:
+ putchar(' ');
+ }
+ }
if (ip6lifetime && (lifetime.ia6t_preferred ||
lifetime.ia6t_expire)) {
printf("pltime ");
Index: sys/netinet6/in6.h
===
RCS file: /ncvs/freebsd/src/sys/netinet6/in6.h,v
retrieving revision 1.44
diff -u -r1.44 in6.h
--- sys/netinet6/in6.h 28 Mar 2006 12:51:22 - 1.44
+++ sys/netinet6/in6.h 4 Jan 2008 21:44:36 -
@@ -271,6 +271,7 @@
#define IPV6_ADDR_SCOPE_NODELOCAL 0x01
#define IPV6_ADDR_SCOPE_INTFACELOCAL0x01
#define IPV6_ADDR_SCOPE_LINKLOCAL 0x02
+#define IPV6_ADDR_SCOPE_ADMINLOCAL 0x04
#define IPV6_ADDR_SCOPE_SITELOCAL 0x05
#define IPV6_ADDR_SCOPE_ORGLOCAL0x08/* just used in this file */
#define IPV6_ADDR_SCOPE_GLOBAL 0x0e
@@ -278,6 +279,7 @@
#define __IPV6_ADDR_SCOPE_NODELOCAL 0x01
#define __IPV6_ADDR_SCOPE_INTFACELOCAL 0x01
#define __IPV6_ADDR_SCOPE_LINKLOCAL 0x02
+#define __IPV6_ADDR_SCOPE_ADMINLOCAL 0x04
#define __IPV6_ADDR_SCOPE_SITELOCAL 0x05
#define __IPV6_ADDR_SCOPE_ORGLOCAL 0x08/* just used in this file */
#define __IPV6_ADDR_SCOPE_GLOBAL0x0e
--
Crist J. Clark | [EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[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: Text for IPv6 Scope
Crist J. Clark wrote: Anyone up for adding text to the scopeid field in the ifconfig(8) output for IPv6 addresses? Other OSes do. To avoid too much disruption to the current format, the text is appended after the currently printed hexadecimal field. Example: fxp0: flags=8843 mtu 1500 options=8 inet6 fe80::290:27ff:fe13:2540%fxp0 prefixlen 64 scopeid 0x5(site-local) While we're at it, update the in6.h file to include all scopes in RFC4291. Look OK? Anyone up for applying these? This kind of output might be cooler? fxp0: flags=8843 mtu 1500 options=8 inet6 fe80::290:27ff:fe13:2540%fxp0 prefixlen 64 scope site just my 2c BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: if_ral regression
"Sepherosa Ziehau" <[EMAIL PROTECTED]> writes: > This actually brings up two things: > 1) I think we should ignore seq in multicast frames; this is permitted in > 802.11 standard. In dfly I did that, since one of our users > encountered a broken commercial AP which is not 802.11e but uses > different seq for data and beacon. > 2) TX sequence. I think standards only mention QSTA/nQSTA, but not > AP. Currently our AP uses per node TX seq, which means beacon's seq > is difficult to choose, at least for 2560 based ral(4), whose beacons' > seq need to be set by software. I saw Linksys AP uses one seq for all > of the frames it sends. Sam, what's you opinion on this? > > I think if STA counts ral(4)'s beacon seq, as what we do currently, > beacon missing will quickly happen since beacons will be discarded > after first several data frames. OK, I *think* I understood most of that. Does this suggest a solution to you? I will try to get the wlandebug output tonight. DES -- Dag-Erling Smørgrav - [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: Text for IPv6 Scope
Hello All:
I think we're crossing the streams here. The Site Local (FEC0::/10)
has been deprecated. The fe80:: is Link Local and is very much alive.
Regards,
Mike
On Jan 5, 2008, at 3:52 AM, Michael Tuexen wrote:
Dear all,
aren't site-local IPv6 addresses depreceated (RFC 3879)? So shouldn't
the site-local stuff be removed?
Best regards
Michael
On Jan 4, 2008, at 10:56 PM, Crist J. Clark wrote:
Anyone up for adding text to the scopeid field in the ifconfig(8)
output for IPv6 addresses? Other OSes do. To avoid too much
disruption to the current format, the text is appended after the
currently printed hexadecimal field.
Example:
fxp0: flags=8843 mtu 1500
options=8
inet6 fe80::290:27ff:fe13:2540%fxp0 prefixlen 64 scopeid
0x5(site-local)
While we're at it, update the in6.h file to include all scopes
in RFC4291.
Look OK? Anyone up for applying these?
Patches (diffs off of a not-too-current CURRENT):
Index: sbin/ifconfig/af_inet6.c
===
RCS file: /ncvs/freebsd/src/sbin/ifconfig/af_inet6.c,v
retrieving revision 1.5
diff -u -r1.5 af_inet6.c
--- sbin/ifconfig/af_inet6.c3 Feb 2007 03:40:33 - 1.5
+++ sbin/ifconfig/af_inet6.c4 Jan 2008 21:53:26 -
@@ -290,8 +290,31 @@
if ((flags6 & IN6_IFF_TEMPORARY) != 0)
printf("temporary ");
-if (scopeid)
- printf("scopeid 0x%x ", scopeid);
+if (scopeid) {
+ printf("scopeid 0x%x", scopeid);
+ switch (scopeid) {
+ case __IPV6_ADDR_SCOPE_INTFACELOCAL:
+ printf("(interface-local) ");
+ break;
+ case __IPV6_ADDR_SCOPE_LINKLOCAL:
+ printf("(link-local) ");
+ break;
+ case __IPV6_ADDR_SCOPE_ADMINLOCAL:
+ printf("(admin-local) ");
+ break;
+ case __IPV6_ADDR_SCOPE_SITELOCAL:
+ printf("(site-local) ");
+ break;
+ case __IPV6_ADDR_SCOPE_ORGLOCAL:
+ printf("(org-local) ");
+ break;
+ case __IPV6_ADDR_SCOPE_GLOBAL:
+ printf("(global) ");
+ break;
+ default:
+ putchar(' ');
+ }
+ }
if (ip6lifetime && (lifetime.ia6t_preferred ||
lifetime.ia6t_expire)) {
printf("pltime ");
Index: sys/netinet6/in6.h
===
RCS file: /ncvs/freebsd/src/sys/netinet6/in6.h,v
retrieving revision 1.44
diff -u -r1.44 in6.h
--- sys/netinet6/in6.h 28 Mar 2006 12:51:22 - 1.44
+++ sys/netinet6/in6.h 4 Jan 2008 21:44:36 -
@@ -271,6 +271,7 @@
#define IPV6_ADDR_SCOPE_NODELOCAL 0x01
#define IPV6_ADDR_SCOPE_INTFACELOCAL0x01
#define IPV6_ADDR_SCOPE_LINKLOCAL 0x02
+#define IPV6_ADDR_SCOPE_ADMINLOCAL 0x04
#define IPV6_ADDR_SCOPE_SITELOCAL 0x05
#define IPV6_ADDR_SCOPE_ORGLOCAL0x08/* just used in this file */
#define IPV6_ADDR_SCOPE_GLOBAL 0x0e
@@ -278,6 +279,7 @@
#define __IPV6_ADDR_SCOPE_NODELOCAL 0x01
#define __IPV6_ADDR_SCOPE_INTFACELOCAL 0x01
#define __IPV6_ADDR_SCOPE_LINKLOCAL 0x02
+#define __IPV6_ADDR_SCOPE_ADMINLOCAL 0x04
#define __IPV6_ADDR_SCOPE_SITELOCAL 0x05
#define __IPV6_ADDR_SCOPE_ORGLOCAL 0x08/* just used in this file */
#define __IPV6_ADDR_SCOPE_GLOBAL0x0e
--
Crist J. Clark | [EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-
[EMAIL PROTECTED]"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
looking for dual-phy (copper & fiber) NIC
Sorry for the slightly OT, but I've run out of ideas... I could of sworn about a month ago or so, I found a half-height gigabit NIC (PCI Express I think) which offered two copper AND two SFP connectors for fiber. The card had only two ethernet controllers (Marvell I think), hence you could only use up to two connectors at any time. Very similar to many switches which give you the choice of copper or fiber but not both (sometimes called "combo ports"). Of course, I didn't bookmark the page, I can't find it in my browser history and Google is failing me horribly. Note: I'm NOT looking for the old SysKonnect or Allied Tellysn cards which are 10/100Mbps. This was a gigabit card! Any hints or pointers to the page, vendor or reseller would be greatly appreciated. Thanks, Aaron -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: resend: multiple routing table roadmap (format fix)
04.01.08 @ 00:52 Julian Elischer wrote:
By the way, I might add that in the 6.x compat. version I may end up
limiting the feature to 8 tables. This is because I need to store some
stuff in an efficient way in the mbuf, and in a compatible manner this
is easiest done by stealing the top 4 bits in the mbuf dlags word
and defining them as:
#define M_HAVEFIB0x1000
#define M_FIBMASK0x07
#define M_FIBNUM0xe000
#define M_FIBSHIFT29
#define m_getfib(_m, _default) ((m->m_flags & M_HAVE_FIBNUM) ?
((m->m_flags >> M_FIBSHIFT) & M_FIBMASK) : _default)
#M_SETFIB(_m, _fib) do { \
_m->m_flags &= ~M_FIBNUM; \
_m->m_flags |= (M_HAVEFIB|((_fib & M_FIBMASK) << M_FIBSHIFT));\
} while (0)
This then becomes very easy to change to use a tag or
whatever is needed in later versions , and the number can
be expanded past 8 predefined FIBs at that time..
If you want it to be a tag, why spent bits in m_flags and not just do
it as a tag at once? Or it is supposed to completely throw away 6.x
(possibly 7.x too) implementation in favor of right thing in 8.0 ?
basically yes..
I'm looking at just doing tags to start with, but haven't done it yet..
I'm looking for a good bit of tag code to copy :-)
Look at ipfw's O_ALTQ/O_TAG/O_TAGGED (ands some other parts), ng_tag.c,
ng_ipfw.c, ng_ksocket.c and some other stuff :-) Tags are simple, if 16
bits are enough to you then even do not have to allocate data, just use
tag_id member. Also they are easy to manipulate within netgraph with
ng_tag, etc. But as drawback - you have to allocate memory for them, an as
it is M_NOWAIT, malloc() can return NULL in interrupt threads... So a new
field in mbuf (or flags) would be better in terms of performance, but it
will break ABI :(
I don't have m_tag_alloc() measurements, though. Doing 'ipfw add 1 tag 1
ip from any to any' on a 15 kpps 6.2 router didn't cause any noticeable
slowdown while looking for half a minute at 'systat -vm 1'...
setfib 3 /bin/sh
now by default everythign you do uses table 3.
or even
setfib 3 jail {blah}
and all the procs in the jail use table 3. You also need to do
setfib 3 jexec xxx
for extra processes you add to the jail afterwards.
May be introduce a field in a struct prison to make it possible without
additional commands?
2/ packets received on an interface for forwarding.
By default these packets would use table 0,
(or possibly a number settable in a sysctl(not yet)).
but prior to routing the firewall can inspect them (see below).
3/ packets inspected by a packet classifier, which can arbitrarily
associate a fib with it on a packet by packet basis.
A fib assigned to a packet by a packet classifier
(such as ipfw) would over-ride a fib associated by
a more default source. (such as cases 1 or 2).
Sounds good. I like idea to do routing decisions in firewall, to not
double kernel code and userspace utilities, like in Linux' iproute2
(which, however, still have a few parameters and relies on firewall
marks for others). However, there are some cases, I think, where it
could be done outisde firewall. For example, make an ifconfig option to
use a specific FIB as a default for all packets outgoing from this
interface's address. But here arises another related question - Linux
allows to select a specific src IP based on a routing table entry -
destination address (thoughts about pf reply-to/route-ro, huh).
that is default here too if I understand what you are talking about.
teh src address is selected from the routing table's exit interface.
In the code I'm showing in perforce, that address would depend on which
table your process was associated with. (or just the socket if you have
used the socket option on it before doing the bind/connect)
What I'm talking about is adding possibility for future MPLS/VRF/etc. For
example, if we make an interface option to use a specific FIB on that
interface, for every incoming packet (put a tag on early input?), then ARP
replies, ICMP redirects (yes, make stack to process them to particular FIB
if specified, not to main) and so on will affect only this table. Then, it
will be possible, say, to have 192.168.0.0/24 on em0 and also have
192.168.0.0/24 on em1, but that networks are completely independent of
each other on both L2 and L3 (different customers) - after that, a change
allowing to have the same IP address on different interfaces will lead to
complete virtual independence. Without any vimages - why do we need
separate TCP stacks etc. copies on a router without any jails, under a
single administrator's control?
Yes, this may be difficult with planned L2/L3 separation (currently ARP
table is in fact part of FIB), but it is solvable - say, by binding an ARP
table to one or several FIBs. Moreover, I think that complete stack
virtulization in each jail/vimage is waste of resources - instead one or
several FIBs/interfaces/
ipsec_tools will not compile after IPSEC_NAT_T patch
I applied the IPSEC_NAT_T patch from http://vanhu.free.fr/FreeBSD/patch-natt-freebsd6-2007-05-31.diff to FreeBSD 6.2-release-p9 yesterday to include IPSEC_NAT_T support. i did a make buildworld buildkernel && make installworld installkernel && shutdown -r now Now when i recompile /usr/ports/security/ipsec-tools it passes the test for checking if the nat_t patch is installed but the port fails in make. I did some research and noticed the same function it errors at is in the patch. Did i mess something up or what? I'm not sure where to go from here. Should i just delete /usr/src/* and extract a new src and start over? cc -DHAVE_CONFIG_H -I. -I../.. -I./../libipsec -I./../../src/racoon/missing -D_GNU_SOURCE -DSYSCONFDIR=\"/usr/local/etc/racoon\" -DADMINPORTDIR=\"/var/db/racoon\" -pipe -g -Wall -Werror -Wno-unused -MT isakmp.o -MD -MP -MF .deps/isakmp.Tpo -c -o isakmp.o isakmp.c isakmp.c: In function `isakmp_open': isakmp.c:1750: error: `UDP_ENCAP_ESPINUDP' undeclared (first use in this function) isakmp.c:1750: error: (Each undeclared identifier is reported only once isakmp.c:1750: error: for each function it appears in.) isakmp.c:1753: error: `UDP_ENCAP_ESPINUDP_NON_IKE' undeclared (first use in this function) isakmp.c:1757: error: `UDP_ENCAP' undeclared (first use in this function) *** Error code 1 Stop in /usr/ports/security/ipsec-tools/work/ipsec-tools-0.7/src/racoon. *** Error code 1 Stop in /usr/ports/security/ipsec-tools/work/ipsec-tools-0.7/src. *** Error code 1 Stop in /usr/ports/security/ipsec-tools/work/ipsec-tools-0.7. *** Error code 1 Stop in /usr/ports/security/ipsec-tools/work/ipsec-tools-0.7. *** Error code 1 Stop in /usr/ports/security/ipsec-tools. *** Error code 1 -- Lyle Scott, III http://www.lylescott.ws ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: resend: multiple routing table roadmap (format fix)
Vadim Goncharov wrote:
04.01.08 @ 00:52 Julian Elischer wrote:
By the way, I might add that in the 6.x compat. version I may end up
limiting the feature to 8 tables. This is because I need to store some
stuff in an efficient way in the mbuf, and in a compatible manner
this is easiest done by stealing the top 4 bits in the mbuf dlags word
and defining them as:
#define M_HAVEFIB0x1000
#define M_FIBMASK0x07
#define M_FIBNUM0xe000
#define M_FIBSHIFT29
#define m_getfib(_m, _default) ((m->m_flags & M_HAVE_FIBNUM) ?
((m->m_flags >> M_FIBSHIFT) & M_FIBMASK) : _default)
#M_SETFIB(_m, _fib) do { \
_m->m_flags &= ~M_FIBNUM; \
_m->m_flags |= (M_HAVEFIB|((_fib & M_FIBMASK) << M_FIBSHIFT));\
} while (0)
This then becomes very easy to change to use a tag or
whatever is needed in later versions , and the number can
be expanded past 8 predefined FIBs at that time..
If you want it to be a tag, why spent bits in m_flags and not just
do it as a tag at once? Or it is supposed to completely throw away
6.x (possibly 7.x too) implementation in favor of right thing in 8.0 ?
basically yes..
I'm looking at just doing tags to start with, but haven't done it
yet.. I'm looking for a good bit of tag code to copy :-)
Look at ipfw's O_ALTQ/O_TAG/O_TAGGED (ands some other parts), ng_tag.c,
ng_ipfw.c, ng_ksocket.c and some other stuff :-) Tags are simple, if 16
bits are enough to you then even do not have to allocate data, just use
tag_id member. Also they are easy to manipulate within netgraph with
ng_tag, etc. But as drawback - you have to allocate memory for them, an
as it is M_NOWAIT, malloc() can return NULL in interrupt threads... So a
new field in mbuf (or flags) would be better in terms of performance,
but it will break ABI :(
so that may happen later.. this code is specifically to not break
ABIs.
The tag method worries me as overhead for potentially every packet
might bee too much. In mbuf field is the delux solution.
I don't have m_tag_alloc() measurements, though. Doing 'ipfw add 1 tag 1
ip from any to any' on a 15 kpps 6.2 router didn't cause any noticeable
slowdown while looking for half a minute at 'systat -vm 1'...
that already has ipfw overhead.
it may be noticable if you are coparing adding and reading tags in a
data path with no ipfw overhead.
setfib 3 /bin/sh
now by default everythign you do uses table 3.
or even
setfib 3 jail {blah}
and all the procs in the jail use table 3. You also need to do
setfib 3 jexec xxx
for extra processes you add to the jail afterwards.
May be introduce a field in a struct prison to make it possible without
additional commands?
yes it's in my original description email that that may be an option.
2/ packets received on an interface for forwarding.
By default these packets would use table 0,
(or possibly a number settable in a sysctl(not yet)).
but prior to routing the firewall can inspect them (see below).
3/ packets inspected by a packet classifier, which can arbitrarily
associate a fib with it on a packet by packet basis.
A fib assigned to a packet by a packet classifier
(such as ipfw) would over-ride a fib associated by
a more default source. (such as cases 1 or 2).
Sounds good. I like idea to do routing decisions in firewall, to not
double kernel code and userspace utilities, like in Linux' iproute2
(which, however, still have a few parameters and relies on firewall
marks for others). However, there are some cases, I think, where it
could be done outisde firewall. For example, make an ifconfig option
to use a specific FIB as a default for all packets outgoing from this
interface's address. But here arises another related question - Linux
allows to select a specific src IP based on a routing table entry -
destination address (thoughts about pf reply-to/route-ro, huh).
that is default here too if I understand what you are talking about.
teh src address is selected from the routing table's exit interface.
In the code I'm showing in perforce, that address would depend on
which table your process was associated with. (or just the socket if
you have used the socket option on it before doing the bind/connect)
What I'm talking about is adding possibility for future MPLS/VRF/etc.
For example, if we make an interface option to use a specific FIB on
that interface, for every incoming packet (put a tag on early input?),
then ARP replies, ICMP redirects (yes, make stack to process them to
particular FIB if specified, not to main) and so on will affect only
this table. Then, it will be possible, say, to have 192.168.0.0/24 on
em0 and also have 192.168.0.0/24 on em1, but that networks are
completely independent of each other on both L2 and L3 (different
customers) - after that, a change allowing to have the same IP address
on different interfaces will lead to complete virtual independence.
Without any vimages - why do we need separate TCP stacks etc.
Re: looking for dual-phy (copper & fiber) NIC
Dear Aaron, i give up on searching for a Dual-phy copper fiber gigabit nic. the search terminates at this 2004 article http://www.thefreelibrary.com/Ixia+Introduces+Dual-PHY+Copper%2FFiber-Optic+Gigabit+Ethernet+Testing...-a0112895579 assumption would be that Allied Telesis have made a successfull hybridus at 100bps and when things went closer to 1000bps vendors have decided to invest into media converters. these are available stand-alone or slide-in (Transition Networks for example). sincerely, nash p.s. please send a note if you ever find one - Original Message From: Aaron Turner <[EMAIL PROTECTED]> To: freebsd-net@freebsd.org Sent: Saturday, January 5, 2008 10:30:43 PM Subject: looking for dual-phy (copper & fiber) NIC Sorry for the slightly OT, but I've run out of ideas... I could of sworn about a month ago or so, I found a half-height gigabit NIC (PCI Express I think) which offered two copper AND two SFP connectors for fiber. The card had only two ethernet controllers (Marvell I think), hence you could only use up to two connectors at any time. Very similar to many switches which give you the choice of copper or fiber but not both (sometimes called "combo ports"). Of course, I didn't bookmark the page, I can't find it in my browser history and Google is failing me horribly. Note: I'm NOT looking for the old SysKonnect or Allied Tellysn cards which are 10/100Mbps. This was a gigabit card! Any hints or pointers to the page, vendor or reseller would be greatly appreciated. Thanks, Aaron -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: looking for dual-phy (copper & fiber) NIC
On Jan 5, 2008, at 2:30 PM, Aaron Turner wrote: Sorry for the slightly OT, but I've run out of ideas... I could of sworn about a month ago or so, I found a half-height gigabit NIC (PCI Express I think) which offered two copper AND two SFP connectors for fiber. The card had only two ethernet controllers (Marvell I think), hence you could only use up to two connectors at any time. Very similar to many switches which give you the choice of copper or fiber but not both (sometimes called "combo ports"). Of course, I didn't bookmark the page, I can't find it in my browser history and Google is failing me horribly. Note: I'm NOT looking for the old SysKonnect or Allied Tellysn cards which are 10/100Mbps. This was a gigabit card! Any hints or pointers to the page, vendor or reseller would be greatly appreciated. I know this isn't what you're looking for, but what about buying a 2 port SFP gigabit card, and putting a copper SFP and a fiber SFP in? http://www.dssnetworks.com/v3/gigabit_pci_6267.asp That should work with the "em" driver I believe, and you can stuff whichever kind of SFP you want in it. Copper SFPs are pretty cheap... http://www.finisar.com/product-160-1000BASE-T_Copper_SFP_(FCMJ-8521-3_8520-3) While I'm not saying I don't believe what you're describing exists, I'm having trouble picturing how you could fit 2 RJ48 and 2 SFP slots on a half height card. -- Kevin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Text for IPv6 Scope
On Sat, Jan 05, 2008 at 11:39:21AM -0800, Michael Smith wrote:
> Hello All:
>
> I think we're crossing the streams here. The Site Local (FEC0::/10)
> has been deprecated. The fe80:: is Link Local and is very much alive.
Those are all of the scope values still assigned in RFC4291 which is
the latest draft standard. See section 2.5.7.
As for whether all of the site-local support should be removed, RFC3879,
says,
"...the formal deprecation
allows existing usage of site-local addresses to continue until the
replacement is standardized and implemented."
The replacement does not yet exist.
> On Jan 5, 2008, at 3:52 AM, Michael Tuexen wrote:
>
> >Dear all,
> >
> >aren't site-local IPv6 addresses depreceated (RFC 3879)? So shouldn't
> >the site-local stuff be removed?
> >
> >Best regards
> >Michael
> >
> >On Jan 4, 2008, at 10:56 PM, Crist J. Clark wrote:
> >
> >>Anyone up for adding text to the scopeid field in the ifconfig(8)
> >>output for IPv6 addresses? Other OSes do. To avoid too much
> >>disruption to the current format, the text is appended after the
> >>currently printed hexadecimal field.
> >>
> >>Example:
> >>
> >>fxp0: flags=8843 mtu 1500
> >> options=8
> >> inet6 fe80::290:27ff:fe13:2540%fxp0 prefixlen 64 scopeid
> >>0x5(site-local)
> >>
> >>While we're at it, update the in6.h file to include all scopes
> >>in RFC4291.
> >>
> >>Look OK? Anyone up for applying these?
> >>
> >>Patches (diffs off of a not-too-current CURRENT):
> >>
> >>Index: sbin/ifconfig/af_inet6.c
> >>===
> >>RCS file: /ncvs/freebsd/src/sbin/ifconfig/af_inet6.c,v
> >>retrieving revision 1.5
> >>diff -u -r1.5 af_inet6.c
> >>--- sbin/ifconfig/af_inet6.c3 Feb 2007 03:40:33 - 1.5
> >>+++ sbin/ifconfig/af_inet6.c4 Jan 2008 21:53:26 -
> >>@@ -290,8 +290,31 @@
> >>if ((flags6 & IN6_IFF_TEMPORARY) != 0)
> >>printf("temporary ");
> >>
> >>-if (scopeid)
> >>- printf("scopeid 0x%x ", scopeid);
> >>+if (scopeid) {
> >>+ printf("scopeid 0x%x", scopeid);
> >>+ switch (scopeid) {
> >>+ case __IPV6_ADDR_SCOPE_INTFACELOCAL:
> >>+ printf("(interface-local) ");
> >>+ break;
> >>+ case __IPV6_ADDR_SCOPE_LINKLOCAL:
> >>+ printf("(link-local) ");
> >>+ break;
> >>+ case __IPV6_ADDR_SCOPE_ADMINLOCAL:
> >>+ printf("(admin-local) ");
> >>+ break;
> >>+ case __IPV6_ADDR_SCOPE_SITELOCAL:
> >>+ printf("(site-local) ");
> >>+ break;
> >>+ case __IPV6_ADDR_SCOPE_ORGLOCAL:
> >>+ printf("(org-local) ");
> >>+ break;
> >>+ case __IPV6_ADDR_SCOPE_GLOBAL:
> >>+ printf("(global) ");
> >>+ break;
> >>+ default:
> >>+ putchar(' ');
> >>+ }
> >>+ }
> >>
> >>if (ip6lifetime && (lifetime.ia6t_preferred ||
> >>lifetime.ia6t_expire)) {
> >>printf("pltime ");
> >>Index: sys/netinet6/in6.h
> >>===
> >>RCS file: /ncvs/freebsd/src/sys/netinet6/in6.h,v
> >>retrieving revision 1.44
> >>diff -u -r1.44 in6.h
> >>--- sys/netinet6/in6.h 28 Mar 2006 12:51:22 - 1.44
> >>+++ sys/netinet6/in6.h 4 Jan 2008 21:44:36 -
> >>@@ -271,6 +271,7 @@
> >>#define IPV6_ADDR_SCOPE_NODELOCAL 0x01
> >>#define IPV6_ADDR_SCOPE_INTFACELOCAL0x01
> >>#define IPV6_ADDR_SCOPE_LINKLOCAL 0x02
> >>+#define IPV6_ADDR_SCOPE_ADMINLOCAL 0x04
> >>#define IPV6_ADDR_SCOPE_SITELOCAL 0x05
> >>#define IPV6_ADDR_SCOPE_ORGLOCAL0x08/* just used in this file */
> >>#define IPV6_ADDR_SCOPE_GLOBAL 0x0e
> >>@@ -278,6 +279,7 @@
> >>#define __IPV6_ADDR_SCOPE_NODELOCAL 0x01
> >>#define __IPV6_ADDR_SCOPE_INTFACELOCAL 0x01
> >>#define __IPV6_ADDR_SCOPE_LINKLOCAL 0x02
> >>+#define __IPV6_ADDR_SCOPE_ADMINLOCAL 0x04
> >>#define __IPV6_ADDR_SCOPE_SITELOCAL 0x05
> >>#define __IPV6_ADDR_SCOPE_ORGLOCAL 0x08/* just used in this file */
> >>#define __IPV6_ADDR_SCOPE_GLOBAL0x0e
> >>--
> >>Crist J. Clark | [EMAIL PROTECTED]
> >>___
> >>freebsd-net@freebsd.org mailing list
> >>http://lists.freebsd.org/mailman/listinfo/freebsd-net
> >>To unsubscribe, send any mail to "freebsd-net-
> >>[EMAIL PROTECTED]"
> >>
> >
> >___
> >freebsd-net@freebsd.org mailing list
> >http://lists.freebsd.org/mailman/listinfo/freebsd-net
> >To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
Crist J. Clark | [EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send
