Re: Ephemeral port range (patch)
On Sat, 1 Mar 2008, Fernando Gont wrote: I will also start working on the double-hash ephemeral port selection algorithm described in the draft (this is, IMHO, the right approach to ephemeral port randomization) Kind regards, -- Fernando Gont Earlier in the week, I had commented (via private e-mail?) that I thought that Amit Klein's algorithm which I recently implemented in ip_id.c might be adapted to serve as an ephemeral port allocator. Now that I've thought more about it, I'm not as certain that it would fit well. I'll try to sketch out my ideas and see if I can figure out how it could fit. The double-hash concept sounds pretty good, but there's a major problem with it. If an application does a bind() to get a local port before doing a connect(), you don't know the remote IP or the remote port. There's a related "feature" in the BSD TCP stack that all local ports are considered equal; even for applications that do a connect() call and specify a remote IP/port, we do not let them use the same local port to two different remote IPs at the same time. This puts a limit on the total number of outgoing connections that one machine can have. -Mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ephemeral ports patch (fixed)
On Mon, 3 Mar 2008, Fernando Gont wrote: Folks, Here's the same patch, but with the first ephemeral port changed from 1024 to 1. Now that I've actually gone to try to apply the patch (so I can view the two codepaths side by side, rather than in diff form), I'm finding that I can't apply it. I think all the whitespace got stomped, either by your mail program or my mail program. Can you please resent this as an attachment? -Mike ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FBSD 1GBit router?
> > Hopefully there will be direct memory bus connected nic's in future. > > (HyperTransport connected nic's) > > Well that is going to be an AMD only solution, and I'm not even shure > that AMD would like to have other things than CPU's on that bus. There are FPGAs that plug into a CPU socket (for mainboards with multiple CPU sockets). There will be GPUs on the HyperTransport bus. Putting a network controller there seems a tad extreme. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ephemeral port range (patch)
At 09:49 p.m. 02/03/2008, you wrote: +1 on increasing the threshold, 1024 is way too low. With the current patch, I agree. I'm planning to implement the scheme described in the port randomization internt-draft I referenced, and implement the array-of-bits thing. That way you can exclude whichever ports you want, without "wasting" the 1024- port range. Also consider the folk who depend on the existing behaviour: a predictable ephemeral port range is useful, if for some reason you need to apply a NAT policy to that traffic, with no other knowledge about how the applications you must NAT actually behave. You can still set porthi or portlow to select whichever port range you want. The patch just changes the default case. As noted in one of the sections of the draft I referenced, turns put that each TCP/IP stack chooses its own range for the ephemeral ports. So unless you're tweaking the configuration of each of the systems you have behind the NAT, I'm afraid you won't be able to implement such a policy. FWIW, Windows used the range 1024-4999 or something... at least W95 and XP. Vista probably still does the same thing. Kind regards, -- Fernando Gont e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED] PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Ephemeral ports patch (fixed)
Folks,
Here's the same patch, but with the first ephemeral port changed from
1024 to 1.
Index: in.h
===
RCS file: /home/ncvs/src/sys/netinet/in.h,v
retrieving revision 1.100
diff -u -r1.100 in.h
--- in.h12 Jun 2007 16:24:53 - 1.100
+++ in.h1 Mar 2008 09:00:10 -
@@ -293,8 +293,7 @@
*
* The value IP_PORTRANGE_HIGH changes the range of candidate port numbers
* into the "high" range. These are reserved for client outbound connections
- * which do not want to be filtered by any firewalls. Note that by default
- * this is the same as IP_PORTRANGE_DEFAULT.
+ * which do not want to be filtered by any firewalls.
*
* The value IP_PORTRANGE_LOW changes the range to the "low" are
* that is (by convention) restricted to privileged processes. This
@@ -331,8 +330,13 @@
#defineIPPORT_RESERVED 1024
/*
- * Default local port range, used by both IP_PORTRANGE_DEFAULT
- * and IP_PORTRANGE_HIGH.
+ * Default local port range, used by IP_PORTRANGE_DEFAULT
+ */
+#define IPPORT_EPHEMERALFIRST 1
+#define IPPORT_EPHEMERALLAST 655535
+
+/*
+ * Dynamic port range, used by IP_PORTRANGE_HIGH.
*/
#defineIPPORT_HIFIRSTAUTO 49152
#defineIPPORT_HILASTAUTO 65535
Index: in_pcb.c
===
RCS file: /home/ncvs/src/sys/netinet/in_pcb.c,v
retrieving revision 1.198
diff -u -r1.198 in_pcb.c
--- in_pcb.c22 Dec 2007 10:06:11 - 1.198
+++ in_pcb.c1 Mar 2008 09:00:11 -
@@ -89,8 +89,8 @@
*/
intipport_lowfirstauto = IPPORT_RESERVED - 1; /* 1023 */
intipport_lowlastauto = IPPORT_RESERVEDSTART; /* 600 */
-intipport_firstauto = IPPORT_HIFIRSTAUTO; /* 49152 */
-intipport_lastauto = IPPORT_HILASTAUTO; /* 65535 */
+intipport_firstauto = IPPORT_EPHEMERALFIRST; /* 1 */
+intipport_lastauto = IPPORT_EPHEMERALLAST;/* 65535 */
intipport_hifirstauto = IPPORT_HIFIRSTAUTO;/* 49152 */
intipport_hilastauto = IPPORT_HILASTAUTO; /* 65535 */
@@ -393,7 +393,7 @@
if (*lportp != 0)
lport = *lportp;
if (lport == 0) {
- u_short first, last;
+ u_short first, last, aux;
int count;
if (laddr.s_addr != INADDR_ANY)
@@ -440,47 +440,28 @@
/*
* Simple check to ensure all ports are not used up causing
* a deadlock here.
-*
-* We split the two cases (up and down) so that the direction
-* is not being tested on each round of the loop.
*/
if (first > last) {
- /*
-* counting down
-*/
- if (dorandom)
- *lastport = first -
- (arc4random() % (first - last));
- count = first - last;
+ aux = first;
+ first = last;
+ last = aux;
+ }
- do {
- if (count-- < 0)/* completely used? */
- return (EADDRNOTAVAIL);
- --*lastport;
- if (*lastport > first || *lastport < last)
- *lastport = first;
- lport = htons(*lastport);
- } while (in_pcblookup_local(pcbinfo, laddr, lport,
- wild));
- } else {
- /*
-* counting up
-*/
- if (dorandom)
- *lastport = first +
- (arc4random() % (last - first));
- count = last - first;
+ if (dorandom)
+ *lastport = first +
+ (arc4random() % (last - first));
- do {
- if (count-- < 0)/* completely used? */
- return (EADDRNOTAVAIL);
- ++*lastport;
- if (*lastport < first || *lastport > last)
- *lastport = first;
- lport = htons(*lastport);
- } while (in_pcblookup_local(pcbinfo, laddr, lport,
- wild));
- }
+ count = last - first;
+
+ do {
+ if (count-- < 0)/* completely used? */
+ return (EADDRNOTAVAIL);
+ ++*lastport;
+
msk driver issues [was: Re: vlan issues with 7.0-RC3]
On Fri, Feb 29, 2008 at 03:03:53PM +0900, Pyun YongHyeon wrote: > On Wed, Feb 27, 2008 at 06:38:40PM -0800, Christopher Cowart wrote: >>On Tue, Feb 26, 2008 at 04:43:55PM +0900, Pyun YongHyeon wrote: >>>On Mon, Feb 25, 2008 at 01:17:12AM -0800, Christopher Cowart wrote: I have a mac mini running 7.0-RC3, which I'm trying to turn it into a router. I have a Linksys SRW2008 "fully managed" (via an IE only web interface, ick) switch. Switch: Port 1 - Trunk vlans 10,60,98 - FreeBSD Box Port 7 - Access vlan 98 - Existing LAN (192.168.1.0/24) OpenWRT (192.168.1.1): WRT54G box on the Existing LAN FreeBSD Box: ifconfig msk0 up ifconfig vlan98 create vlan 98 vlandev msk0 inet 192.168.1.67/24 With this configuration, I can ping hosts on the other lan segment (Port 7). Arp and icmp seem to be quite happy. Unfortunately, I'm not having any luck with tcp and udp. Any attempt to ssh to OpenWRT or dig @OpenWRT hangs indefinitely. If I do a tcpdump, I see the SYN or A? leaving and absolutely no response returning. If I run a tcpdump on OpenWRT, I see no incoming traffic. When I try to connect *to* the FreeBSD box from the other lan segment, I continue to have problems. tcpdump shows the SYNs arriving via vlan98 and the FreeBSD box responding with SYN-ACK. OpenWRT receives the SYNACK. I disabled ipfw just to be sure (sysctl -w net.inet.ip.fw.enable=0), but it had no effect on the problem. If I connect the FreeBSD box to a vlan 98 access port and assign the address to msk0, my connectivity problems go away. This leads me to believe that the firewall on OpenWRT is not the problem and the problem is related to vlans. Thinking it was a problem with the not-so-cheap Linksys POS (bitterness about the IE web interface again), I plugged my MacBook (running Leopard, not FreeBSD) into the trunk port. Running the ifconfig commands above (s/msk0/en0/), I got up and running without any problems. This causes me to suspect the FreeBSD box. Does anyone have any idea what's going on here? Any suggestions for further troubleshooting? >>> >>> Try disabling hardware features one by one in msk(4) and see how >>> it goes. >>> o Disable TSO. >>> o Disable Tx checksum offload. >>> o Disable VLAN hardware tagging. >> >>Works great after `sudo ifconfig msk0 -txcsum'. >> >>Is this a known bug, or should I file a PR? Let me know if there are any >>other details I can provide to help somebody squash it. > > Would you capture broken TCP/UDP frames with tcpdump on receiving side > and show it to me? Thanks for your help. I will e-mail you the corresponding tracefile off-list. I wanted to discuss my initial findings here. When the FreeBSD box sends tcp or udp traffic to elsewhere on the network, it is not seen at the receiving side, not even with bad checksums. I tried setting up the Linksys device with a port mirror, but apparently that's only supported on native vlan access ports. Great. So, I decided to cross-connect the FreeBSD box with my MacBook. I set up a vlan interface and was able to reproduce the behavior. I did a traffic dump on the parent interface (not the vlan interface) on the MacBook, and noticed that the ethernet frames originating from the FreeBSD box lacked 802.1q tags. Is it possible that the interface is not performing the hardware tagging when txcsum is enabled? While I have your attention, I am also suffering from a problem that was reported to -questions here[1]. About 3 times a day, I'll see the watchdog timeout (missed Tx interrupts) message get logged, after which point the NIC is useless until I reboot. Any ideas? [1] http://lists.freebsd.org/pipermail/freebsd-questions/2008-February/169633.html -- Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley pgps2Hq0bjAlV.pgp Description: PGP signature
Re: kern/121274: [panic] Panic in ether_input() with different NIC's.
The following reply was made to PR kern/121274; it has been noted by GNATS. From: Sean Farley <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: kern/121274: [panic] Panic in ether_input() with different NIC's. Date: Sun, 2 Mar 2008 17:51:35 -0600 (CST) I am currently running a build with INVARIANTS and WITNESS. No panics so far, but I did get a LOR: Mar 2 15:35:22 gw kernel: 1st 0xc39ee8a0 ipf filter load/unload mutex (ipf filter load/unload mutex) @ /usr/FreeBSD/RELENG_7/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/fil.c:2431 Mar 2 15:35:22 gw kernel: 2nd 0xc3a4a404 gif softc (gif softc) @ /usr/FreeBSD/RELENG_7/src/sys/net/if_gif.c:411 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ephemeral port range (patch)
+1 on increasing the threshold, 1024 is way too low. Also consider the folk who depend on the existing behaviour: a predictable ephemeral port range is useful, if for some reason you need to apply a NAT policy to that traffic, with no other knowledge about how the applications you must NAT actually behave. later BMS ___ 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 a guide to extend|adapting the socket framework for NFCIP-1
Hi, I had to use a search engine to figure out what the acronym NFC was, and I assume you mean this: http://en.wikipedia.org/wiki/Near_Field_Communication It helps if you give more background information when asking a more general audience for feedback. zDen wrote: 1) As the NFC device is attached to the USB or UART port, how and where in the source code can I change the output of the byte-stream packet to the proper physical port? i.e where is the part of the source code that is physical device dependent when doing the I/O calls? You really need to roll your own driver framework for this. Whilst the Bluetooth support sounds like it's the right place to start to look for ideas, you're going to have to write your own layering. I know off the top of my head that the Bluetooth support is able to add its own TTY disciplines to serial devices but I couldn't tell you specifics, as it's not something I meddle with unless I need to. 2) As the protocol family (PF_xx) and address family (AF_xx) of NFC is not define in the socket library, how can I define them and let the default socket() call return a socket with the customized structure? I can see that I may need to use SOCK_RAW as the basic socket framework or any others recommendation? To learn about adding a new socket family to the system, you really need to pick up a copy of TCP/IP Illustrated Volume 2 and read Chapter 15 onwards. It sounds like you have a fairly involved and challenging software project on your hands. I hope you're being funded by someone to do it, it doesn't sound like something a hobbyist would pick up just for the hell of it if it's going to be done properly, i.e. beyond a quick hack for demonstration purposes. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ephemeral port range (patch)
Mike Silbersack wrote: On Sat, 1 Mar 2008, Fernando Gont wrote: Folks, This patch changes the default ephemeral port range from 49152-65535 to 1024-65535. This makes it harder for an attacker to guess the ephemeral ports (as the port number space is larger). Also, it makes the chances of port number collisions smaller. (http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-randomization-01.txt) There are a number of commonly used ports above 1000, such as nfs and x11. I think OpenBSD uses 1-65535, maybe that's a safer choice to go with. Agreed about 1-65535. -- Andre ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/121274: [panic] Panic in ether_input() with different NIC's.
The following reply was made to PR kern/121274; it has been noted by GNATS. From: Sean Farley <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: kern/121274: [panic] Panic in ether_input() with different NIC's. Date: Sun, 2 Mar 2008 15:37:24 -0600 (CST) It passed memtest86+ v2.01 scrutiny. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/121274: [panic] Panic in ether_input() with different NIC's.
On Sun, 2 Mar 2008, [EMAIL PROTECTED] wrote: Could you run memtest86 or some other memory testing tool on the box? While this could well be a software bug, it would be nice to give it a whirl and make sure you're not running into, say, a 1-bit memory error that might easily explain the panic across various drivers. Thanks! It passed memtest86+ v2.01 scrutiny. Sean -- [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: FBSD 1GBit router?
On Sunday 02 March 2008 11:23:16 Ingo Flaschberger wrote: > The 4 port card use 4x lanes. There are also 6 port adapters which use 4x lanes. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FBSD 1GBit router?
Dear Barney, PCIe cards are 1x because the chips are all wired for 1x. Intel has a marketing plan. Its not to use low-end chips for high-end operations. Intel is just going to cannibalized their own business by putting out higher performance low-end chips. really? the 1 port server chip use only 1 lane the 2 port server chip use only sorry, forgotten to finish this part: The 1 and 2 port intel server gbit chipset have a 4x lanes pci-e conection. The 1 port card only use 1x lane. The 2 port card use 4x lanes. The 4 port card use 4x lanes. pci-e bus speeds: http://www.s-t-e.de/index.html?http%3A//www.s-t-e.de/content/Articles/Articles_08b.html (sorry, only in german) http://www.s-t-e.de/content/Articles/images/Articles_08/PCIe_EffVSPay_f24_sml.gif there you see the efficency with different payloads. minimal ethernet packet size of 64 byte has a efficency of 0.4 with small packets you will be able to achieve 800mbits, whats not bad. perhaps with the 2 port-cards it would be better, but I think, the system io of the processor will start limiting. Kind regards, Ingo Flaschberger ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FBSD 1GBit router?
Dear Barney, PCIe cards are 1x because the chips are all wired for 1x. Intel has a marketing plan. Its not to use low-end chips for high-end operations. Intel is just going to cannibalized their own business by putting out higher performance low-end chips. really? the 1 port server chip use only 1 lane the 2 port server chip use only Intel® PRO/1000 PF Dual Port Server Adapter: Today there really is very little reason to use PCI-X instead of PCI-E when one is putting together a brand new system. the "reason" is that its faster, but its clear that you have no interest in understanding that, so I'll give up on trying to educated you. The math is clearly over your head. I have no problems to saturate 1 gbit desktop pci-e intel card in a 50$ asrock mainboard. Lets show me that at your pci-x board? and please read: http://download.intel.com/design/network/applnots/ap453.pdf Kind regards, Ingo Flaschberger ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FBSD 1GBit router?
On Sun, Mar 2, 2008 at 5:11 PM, Ingo Flaschberger <[EMAIL PROTECTED]> wrote: > Dear Bareney, > > >> And back to 1x is not fast enough: > >> There are no 1gbit single port network cards that > >> support more than 1 > >> lane, even if you plug it into a 16 lane slot. > >> (and I'm not talking about 10gbit cards; if you have > >> 10gbit upstream you > >> have enough $$ to buy good gear) > > > > Ok, well I've never seen a router with 1 port. I > > thought we were talking about building a router? > > Have you ever read the link? > Have you noticed that the axiomtek appliance has 7 gigabit ports? > Each one connected with 1 lane pci-e? > > > The lack of PCIe cards is a good reason to consider a > > PCIX machine. On the systems that we have, the 1x PCIe > > ports are a lot slower than a PCI-X card in the slot. > > Perhaps, but: pci-x: 4gbit for the whole bus system. > pci-e: 2gbit/lane > > > You need 4Gb/s of throughput to handle a gigablt > > router. (1 GB/s full duplex times 2). 1x is 4Gb/s > > maximum. In my view, you always need twice the > > bandwidth on the bus to avoid contention issues. > > sample1: > 3 pci-cards: > card 1: 1x = 2gbit (dedicated) > card 2: 1x = 2gbit (dedicated) > card 3: 1x = 2gbit (dedicated) > > sum: 6gbit > (but the use only 3) > > sample2: > 2 pci-x cards > card 1: 4gbit (shared) > card 2: 4gbit (shared) > card 3: 4gbit (shared) > - > sum:4gbit > > homework: > calculate with 7 ports. > > Kind regards, >Ingo Flaschberger > > André Oppermann's excellent paper has even more info to why PCIe is better than PCI-X for networking : http://people.freebsd.org/~andre/Optimizing%20the%20FreeBSD%20IP%20and%20TCP%20Stack.pdf --Niki ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FBSD 1GBit router?
On Sun, Mar 02, 2008 at 04:11:28PM +0100, Ingo Flaschberger wrote: > Dear Bareney, > >>> And back to 1x is not fast enough: >>> There are no 1gbit single port network cards that >>> support more than 1 >>> lane, even if you plug it into a 16 lane slot. >>> (and I'm not talking about 10gbit cards; if you have >>> 10gbit upstream you >>> have enough $$ to buy good gear) >> >> Ok, well I've never seen a router with 1 port. I >> thought we were talking about building a router? > > Have you ever read the link? > Have you noticed that the axiomtek appliance has 7 gigabit ports? > Each one connected with 1 lane pci-e? > >> The lack of PCIe cards is a good reason to consider a >> PCIX machine. On the systems that we have, the 1x PCIe >> ports are a lot slower than a PCI-X card in the slot. > > Perhaps, but: pci-x: 4gbit for the whole bus system. PCI-X actually has up to twice that: 133 MHz * 64 bits = 8.512 Gbit/s ( = 1.066 GB/s ) That's assuming only a single PCI-X device on the bus. If you have two devices connected to the same PCI-X bus then most motherboards will lower the clock frequency to 100MHz for reliability reasons. If there are 3 or more devices connected to the same PCI-X bus then the clock frequency is usually lowered to 66 MHz. (Yes, the more devices you connect to a PCI-X bus, the less bandwidth you get to share among them.) > pci-e: 2gbit/lane In each direction. The total bandwidth available is 4Gbit/s per lane. (This is similar to Gigabit ethernet which can only send 1Gbit/s in each direction, but can send and receive at the same time, thus using a total bandwidth of up to 2Gbit/s.) > >> You need 4Gb/s of throughput to handle a gigablt >> router. (1 GB/s full duplex times 2). 1x is 4Gb/s >> maximum. In my view, you always need twice the >> bandwidth on the bus to avoid contention issues. > > sample1: > 3 pci-cards: > card 1: 1x = 2gbit (dedicated) > card 2: 1x = 2gbit (dedicated) > card 3: 1x = 2gbit (dedicated) > > sum: 6gbit > (but the use only 3) > > sample2: > 2 pci-x cards > card 1: 4gbit (shared) > card 2: 4gbit (shared) > card 3: 4gbit (shared) > - > sum:4gbit > > homework: > calculate with 7 ports. > > Kind regards, > Ingo Flaschberger > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Erik Trulsson [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: ipfw initialization: SI_ORDER_ANY -> SI_ORDER_MIDDLE?
On Sun, Mar 02, 2008 at 03:49:39PM +0100, Paolo Pisati wrote: > Hi, > > i just found out that depending on a KLD doesn't imply any > initialization order, thus depending on a lock initialized in the ipfw > init path is _really_ a bad idea from another KLD init path (see > ip_fw_nat.c::ipfw_nat_init()). > > A fix would be to move ipfw init priority from SI_ORDER_ANY to > SI_ORDER_MIDDLE, but i guess there are side effects that i'm > unaware in this modification... The SI_ORDER_* definitions in /sys/sys/kernel.h are enumerated on a large range, so if the existing code does not have races, you can safely move the non-leaf modules (such as ipfw,ko in your case) to (SI_ORDER_ANY - some_small_integer) without breaking anything. If this change breaks something, it means that there was already a race condition and you are just pointing it out - so it is a worthwhile change... cheers luigi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ipfw initialization: SI_ORDER_ANY -> SI_ORDER_MIDDLE?
Hi, i just found out that depending on a KLD doesn't imply any initialization order, thus depending on a lock initialized in the ipfw init path is _really_ a bad idea from another KLD init path (see ip_fw_nat.c::ipfw_nat_init()). A fix would be to move ipfw init priority from SI_ORDER_ANY to SI_ORDER_MIDDLE, but i guess there are side effects that i'm unaware in this modification... On the other hand, if we keep ipfw at SI_ORDER_ANY, i don't know how to build stuff that relies on it without opening race conditions: see ip_fw_nat.c::flush_nat_ptrs() called in rule deletion and rule configuration paths. bye, P. ps yes, next time i'll better read the MODULE_DEPEND man page... ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FBSD 1GBit router?
Dear Bareney, And back to 1x is not fast enough: There are no 1gbit single port network cards that support more than 1 lane, even if you plug it into a 16 lane slot. (and I'm not talking about 10gbit cards; if you have 10gbit upstream you have enough $$ to buy good gear) Ok, well I've never seen a router with 1 port. I thought we were talking about building a router? Have you ever read the link? Have you noticed that the axiomtek appliance has 7 gigabit ports? Each one connected with 1 lane pci-e? The lack of PCIe cards is a good reason to consider a PCIX machine. On the systems that we have, the 1x PCIe ports are a lot slower than a PCI-X card in the slot. Perhaps, but: pci-x: 4gbit for the whole bus system. pci-e: 2gbit/lane You need 4Gb/s of throughput to handle a gigablt router. (1 GB/s full duplex times 2). 1x is 4Gb/s maximum. In my view, you always need twice the bandwidth on the bus to avoid contention issues. sample1: 3 pci-cards: card 1: 1x = 2gbit (dedicated) card 2: 1x = 2gbit (dedicated) card 3: 1x = 2gbit (dedicated) sum: 6gbit (but the use only 3) sample2: 2 pci-x cards card 1: 4gbit (shared) card 2: 4gbit (shared) card 3: 4gbit (shared) - sum:4gbit homework: calculate with 7 ports. Kind regards, Ingo Flaschberger ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw initialization: SI_ORDER_ANY -> SI_ORDER_MIDDLE?
On Sun, Mar 02, 2008 at 03:49:39PM +0100, Paolo Pisati wrote:
> Hi,
>
> i just found out that depending on a KLD doesn't imply any
> initialization order, thus depending on a lock initialized in the ipfw
> init path is _really_ a bad idea from another KLD init path (see
> ip_fw_nat.c::ipfw_nat_init()).
>
> A fix would be to move ipfw init priority from SI_ORDER_ANY to
> SI_ORDER_MIDDLE, but i guess there are side effects that i'm
> unaware in this modification...
>
> On the other hand, if we keep ipfw at SI_ORDER_ANY, i don't know how
> to build stuff that relies on it without opening race conditions:
> see ip_fw_nat.c::flush_nat_ptrs() called in rule deletion and
> rule configuration paths.
as the problem arises only during ip_fw_nat initialization, another
viable solution would be to fix ipfw_nat_init() this way:
static void
ipfw_nat_init(void)
{
-IPFW_WLOCK(&layer3_chain);
/* init ipfw hooks */
-ipfw_nat_ptr = ipfw_nat;
ipfw_nat_cfg_ptr = ipfw_nat_cfg;
ipfw_nat_del_ptr = ipfw_nat_del;
ipfw_nat_get_cfg_ptr = ipfw_nat_get_cfg;
ipfw_nat_get_log_ptr = ipfw_nat_get_log;
-IPFW_WUNLOCK(&layer3_chain);
+ipfw_nat_ptr = ipfw_nat;
ifaddr_event_tag = EVENTHANDLER_REGISTER(ifaddr_event, ifaddr_change,
NULL, EVENTHANDLER_PRI_ANY);
}
avoid grabbing the lock at all during init, and exploit orders of
hooks initialization: as the presence of ipfw_nat in ipfw is checked
via ipfw_nat_ptr, i can narrow/close the race window initializing
ipfw_nat_ptr at the end of the function, but can i trust the order of
variables assignment? i guess no without some sort of memory barriers,
and are memory barriers available in all archs? and are memory
barriers enough?
bye,
P.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/121274: [panic] Panic in ether_input() with different NIC's.
Synopsis: [panic] Panic in ether_input() with different NIC's. State-Changed-From-To: open->feedback State-Changed-By: rwatson State-Changed-When: Sun Mar 2 15:03:57 UTC 2008 State-Changed-Why: Could you run memtest86 or some other memory testing tool on the box? While this could well be a software bug, it would be nice to give it a whirl and make sure you're not running into, say, a 1-bit memory error that might easily explain the panic across various drivers. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=121274 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FBSD 1GBit router?
Erik Trulsson wrote: Ok, well I've never seen a router with 1 port. I thought we were talking about building a router? He did not say anything about a single port router. He talked about single port network cards. You can use more than one of them when building a router. Well lets nitpick. A router does not have to have 2 ports. 2 examples: - routing between VLANs on the same interface - when doing routing in an overlay network. EG. in a connecting VPN networks I'm looking for a stream exploder.:) 1 2Mbit stream in, and as many as possible out. And 7*1Gb = 14Gbit, so I'd like to be pushing 7000 streams. (One advantage is that they will be UDP streams, so there is a little less bookkeeping in the protocol stack ) The lack of PCIe cards is a good reason to consider a PCIX machine. What lack of PCI-E cards? These days there are quite a few to choose between. I'm under the impression that PCI-E is the way to go. Especially if I look at what is implemented on the more serious server boards. On the systems that we have, the 1x PCIe ports are a lot slower than a PCI-X card in the slot. You need 4Gb/s of throughput to handle a gigablt router. (1 GB/s full duplex times 2). 1x is 4Gb/s maximum. In my view, you always need twice the bandwidth on the bus to avoid contention issues. What contention issues? With PCI-E each device is essentially on its own bus and does not need to contend with other devices for bandwidth on that bus. Right, in PCI-E the lanes are just a star network into a hub. Now there is always going to be a bottleneck in a network. So here the big chance is that this is between the CPU and the hub. To see that just complete the above math: 7000 stream @ 2mbit/sec =~> 1.25E6 p/s =~> 1,75 Gb/sec Where all datatransport has to go over the processor. Well I have not seen systems with this as Frontside bus, so this is going to require a carefully crafted design. :) --WjW ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ephemeral port range (patch)
On Sat, 1 Mar 2008, Mike Silbersack wrote: On Sat, 1 Mar 2008, Fernando Gont wrote: This patch changes the default ephemeral port range from 49152-65535 to 1024-65535. This makes it harder for an attacker to guess the ephemeral ports (as the port number space is larger). Also, it makes the chances of port number collisions smaller. (http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-randomization-01.txt) There are a number of commonly used ports above 1000, such as nfs and x11. I think OpenBSD uses 1-65535, maybe that's a safer choice to go with. In order to get acceptable open connection counts with 10gbps ethernet, I've needed to run with a significantly lower starting portrange. In practice, the following seems to do the trick for me: sysctl net.inet.ip.portrange.first=1 Of course, I only run into this if I also increase maxsockets: sysctl kern.ipc.maxsockets=3 Lowering the lower end of the ephemeral range to 10,000 would do the trick for me, anyway. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FBSD 1GBit router?
--- Erik Trulsson <[EMAIL PROTECTED]> wrote: > On Sat, Mar 01, 2008 at 04:39:57PM -0800, Barney > Cordoba wrote: > > > > --- Erik Trulsson <[EMAIL PROTECTED]> wrote: > > > > > On Sat, Mar 01, 2008 at 01:27:46PM -0800, Barney > > > Cordoba wrote: > > > > > > > > --- Ingo Flaschberger <[EMAIL PROTECTED]> wrote: > > > > > > > > > Dear Barney, > > > > > > > > > > > It seems absolutely ridiculous to buy such > > > > > hardware > > > > > > and not install a PCIx or 4x PCIe card for > > > another > > > > > > $100. or less. Saying a 1x is "fast > enough" is > > > > > like > > > > > > saying a Celeron is "fast enough". > > > > > > > > > > The box is a small 1HE appliance and can > boot > > > from a > > > > > CF-Card. > > > > > I trust them more than a "al cheapo" pc. > > > > > 1x axiomtek NA-820 > > > > > 1x P4 3Ghz cpu > > > > > 1x 1gb ddr2 > > > > > --- > > > > > 850eur without taxes. > > > > > > > > > > A good chipset, good cpu, good ram, good > > > harddisk, > > > > > god powersupply has > > > > > same price. > > > > > And don't forget that in exchanges you pay > for > > > each > > > > > HE. > > > > > > > > > > And back to 1x is not fast enough: > > > > > There are no 1gbit single port network cards > > > that > > > > > support more than 1 > > > > > lane, even if you plug it into a 16 lane > slot. > > > > > (and I'm not talking about 10gbit cards; if > you > > > have > > > > > 10gbit upstream you > > > > > have enough $$ to buy good gear) > > > > > > > > Ok, well I've never seen a router with 1 port. > I > > > > thought we were talking about building a > router? > > > > > > He did not say anything about a single port > router. > > > He talked about single port network cards. You > can > > > use more than one of them when building a > router. > > > > His argument is that there are only 1x PCIe cards > that > > have 1 port. Since he needs 2 ports, and there are > 2 > > port > > PCIe cards, then his argument makes no sense. But > the > > point is that PCIe NICs are implemented with 1 > port > > per lane in the chip. So a 2 port card will use 2 > > lanes > > No, the argument was that all 1-port PCI-E cards are > only > x1, ergo a x1 card must be fast enough for 1 port, > else there > would be 1-port cards manufactured that used more > than > one lane. > PCIe cards are 1x because the chips are all wired for 1x. Intel has a marketing plan. Its not to use low-end chips for high-end operations. Intel is just going to cannibalized their own business by putting out higher performance low-end chips. > > > > > > > > > > > > > > > The lack of PCIe cards is a good reason to > > > consider a > > > > PCIX machine. > > > > > > What lack of PCI-E cards? These days there are > > > quite a > > > few to choose between. > > > > Yes, but they are all 1x, while there are many 1 > and 2 > > port PCIx cards which are twice as fast. > > There are dual- and quad-port PCI-E cards available > too, and they are > generally x4 lane models. > > Today there really is very little reason to use > PCI-X instead > of PCI-E when one is putting together a brand new > system. the "reason" is that its faster, but its clear that you have no interest in understanding that, so I'll give up on trying to educated you. The math is clearly over your head. Barney Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Looking for a guide to extend|adapting the socket framework for NFCIP-1
Hi, I'm exploring the way to extend or adapt the socket programming framework for NFC devices using C programming. (for future-porting compatible) Using the bluetooth framework as basic reference, I've some questions and need helps regarding the adaption. 1) As the NFC device is attached to the USB or UART port, how and where in the source code can I change the output of the byte-stream packet to the proper physical port? i.e where is the part of the source code that is physical device dependent when doing the I/O calls? 2) As the protocol family (PF_xx) and address family (AF_xx) of NFC is not define in the socket library, how can I define them and let the default socket() call return a socket with the customized structure? I can see that I may need to use SOCK_RAW as the basic socket framework or any others recommendation? Any comments and recommendations for the above issue is gladly appreciated. Thanks for help. -- View this message in context: http://www.nabble.com/Looking-for-a-guide-to-extend%7Cadapting-the-socket-framework-for-NFCIP-1-tp15784710p15784710.html Sent from the freebsd-net mailing list archive at Nabble.com. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
