Re: high cpu usage on natd / dhcpd
On Jan 31, 2013, at 16:03, Matthew Luckie wrote: > > 00510 allow ip from me to not me out via em1 > 00550 divert 8668 ip from any to any via em1 > > Rule 510 fixes it. Yep, it does. Can I ask someone to commit this to rc.firewall? (And I wonder if the rules for the ipfw kernel firewall need a similar addition, because the system locks up under heavy network load if I use that instead of natd.) Lars ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
OCE driver patches
Hi, I have submitted this patch http://www.freebsd.org/cgi/query-pr.cgi?pr=171838 some time back. Could you please let me know when this will be pulled in? I have some more patches to submit. Please let me know if submitting it online at this link http://www.freebsd.org/send-pr.html is the only way to get them in or is there an alternative to the patch submission? Thanks, Venkat ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: high cpu usage on natd / dhcpd
On Thu, 7 Feb 2013 08:08:59 +, Eggert, Lars wrote:
> On Jan 31, 2013, at 16:03, Matthew Luckie wrote:
> >
> > 00510 allow ip from me to not me out via em1
> > 00550 divert 8668 ip from any to any via em1
> >
> > Rule 510 fixes it.
>
> Yep, it does. Can I ask someone to commit this to rc.firewall?
The ruleset Matthew posted bears no resemblance to rc.firewall, so I
don't see that (or how) it solves any generic problem.
> (And I wonder if the rules for the ipfw kernel firewall need a
> similar addition, because the system locks up under heavy network
> load if I use that instead of natd.)
>
> Lars
Which rc.firewall ruleset are you referring to? There certainly are
problems with the 'simple' ruleset relating to use of $natd_enable vs
$firewall_nat_enable (not to mention the denial of ALL icmp traffic)
that I posted patches to a couple of years ago in ipfw@ to rc.firewall
and /etc/rc.d/{ipfw,natd) addressing about 4 PRs .. sadly to no avail.
I suggest following up to ipfw@ (cc'd) rather than net@
cheers, Ian
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: high cpu usage on natd / dhcpd
Hi,
On Feb 7, 2013, at 13:40, Ian Smith wrote:
> On Thu, 7 Feb 2013 08:08:59 +, Eggert, Lars wrote:
>> On Jan 31, 2013, at 16:03, Matthew Luckie wrote:
>>>
>>> 00510 allow ip from me to not me out via em1
>>> 00550 divert 8668 ip from any to any via em1
>>>
>>> Rule 510 fixes it.
>>
>> Yep, it does. Can I ask someone to commit this to rc.firewall?
>
> The ruleset Matthew posted bears no resemblance to rc.firewall, so I
> don't see that (or how) it solves any generic problem.
sorry for having been imprecise. What I was asking for was this change:
--- /usr/src/etc/rc.firewall2012-11-17 12:36:10.0 +0100
+++ rc.firewall 2013-02-06 11:35:45.0 +0100
@@ -155,6 +155,7 @@
case ${natd_enable} in
[Yy][Ee][Ss])
if [ -n "${natd_interface}" ]; then
+ ${fwcmd} add 49 allow ip from me to not me out via
${natd_interface}
${fwcmd} add 50 divert natd ip4 from any to any via
${natd_interface}
fi
;;
>> (And I wonder if the rules for the ipfw kernel firewall need a
>> similar addition, because the system locks up under heavy network
>> load if I use that instead of natd.)
>
> Which rc.firewall ruleset are you referring to?
My rc.conf has:
gateway_enable="YES"
firewall_enable="YES"
firewall_type="OPEN"
natd_enable="YES"
natd_interface="bce0"
With the patch above, that seems to work fine.
I tried to replace the natd_* lines with:
firewall_nat_enable="YES"
firewall_nat_interface="bce0"
which caused the machine to lock up under load, similar to when natd started
eating CPU cycles. This made me wonder if a similar patch to the above for the
firewall_nat_* case in rc.firewall might be needed.
> There certainly are
> problems with the 'simple' ruleset relating to use of $natd_enable vs
> $firewall_nat_enable (not to mention the denial of ALL icmp traffic)
> that I posted patches to a couple of years ago in ipfw@ to rc.firewall
> and /etc/rc.d/{ipfw,natd) addressing about 4 PRs .. sadly to no avail.
>
> I suggest following up to ipfw@ (cc'd) rather than net@
Will subscribe, thanks.
Lars
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
L2TP with Certificates
Hi, I've found a handful of good tutorials explaining how to set up MPD and Racoon using pre-shared keys and user/pass authentication, but I can't seem to find anything that uses certificates. Is this not an option? Does anyone know if there's a good demo of this out there? Also, if I do use user/pass auth, I see that I can specify an external password-verification program in MPD. Has anyone had any luck with tying that to an LDAP server for auth? -- Tim Gustafson t...@ucsc.edu 831-459-5354 Baskin Engineering, Room 313A ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [PATCH] Add a new TCP_IGNOREIDLE socket option
On Feb 6, 2013, at 12:28 , Alfred Perlstein wrote: > On 2/6/13 4:46 AM, John Baldwin wrote: >> On Wednesday, February 06, 2013 6:27:04 am Randall Stewart wrote: >>> John: >>> >>> A burst at line rate will *often* cause drops. This is because >>> router queues are at a finite size. Also such a burst (especially >>> on a long delay bandwidth network) cause your RTT to increase even >>> if there is no drop which is going to hurt you as well. >>> >>> A SHOULD in an RFC says you really really really really need to do it >>> unless there is some thing that makes you willing to override it. It is >>> slight wiggle room. >>> >>> In this I agree with Andre, we should not be *not* doing it. Otherwise >>> folks will be turning this on and it is plain wrong. It may be fine >>> for your network but I would not want to see it in FreeBSD. >>> >>> In my testing here at home I have put back into our stack max-burst. This >>> uses Mark Allman's version (not Kacheong Poon's) where you clamp the cwnd at >>> no more than 4 packets larger than your flight. All of my testing >>> high-bw-delay or lan has shown this to improve TCP performance. This >>> is because it helps you avoid bursting out so many packets that you overflow >>> a queue. >>> >>> In your long-delay bw link if you do burst out too many (and you never >>> know how many that is since you can not predict how full all those >>> MPLS queues are or how big they are) you will really hurt yourself even >>> worse. >>> Note that generally in Cisco routers the default queue size is somewhere >>> between >>> 100-300 packets depending on the router. >> Due to the way our application works this never happens, but I am fine with >> just keeping this patch private. If there are other shops that need this >> they >> can always dig the patch up from the archives. >> > This is yet another time when I'm sad about how things happen in FreeBSD. > > A developer come forward with a non-default option that's very useful for > some specific workloads, specifically one that contributes much time and $$$ > to the project and the community rejects the patches even though it's been > successful in other OSes. > > It makes zero sense. > > John, can you repost the patch? Maybe there is a way to refactor this > somehow so it's like accept filters where we can plug in a hook for TCP? > > I am very disappointed, but not surprised. > I take away the complete opposite feeling. This is how we work through these issues. It's clear from the discussion that this need not be a default in the system, and is a special case. We had a reasoned discussion of what would be best to do and at least two experts in TCP weighed in on the effect this change might have. Not everything proposed by a developer need go into the tree, in particular since these discussions are archived we can always revisit this later. This is exactly how collaborative development should look, whether or not the patch is integrated now, next week, next year, or ever. Best, George ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: A question about SYN cookies...
On Feb 4, 2013, at 04:09 , Andre Oppermann wrote: > On 04.02.2013 01:09, George Neville-Neil wrote: >> Howdy, >> >> I've been reviewing the SYN cache and SYN cookie code and I'm wondering why >> we do all the work >> of generating a SYN cache entry before sending a SYN cookie. If the point >> of SYN cookies is to >> defend against a SYN flood then, to my mind, the SYN/ACK for the cookie case >> should be sent off before >> doing all the work to try to create and insert a cache entry. Has anyone, >> as yet, looked at a way >> to move the sending code earlier into syncache_add() and checked to see if >> there is a performance >> improvement when a system is flooded with SYN packets? > > So far all syncookie implementations have an information loss because > they can't store all state in the cookie unless timestamps are enabled. > Apparently Windows 8 still doesn't enable timestamps but does quite a > bit of window scaling leading to problems. See recent bug report here > on net@. > Yes, I heard about that off list and then got time to review the mailbox. > For generating syncookies we have three possible strategies: > > 1/ Use syncache and cookies in parallel and bump the oldest syncache >entry replacing it with the new SYN attempt. Syncookies are done >on all SYN-ACK's going out. > > 2/ Fill the syncache but do not bump the oldest entry, other than normal >expiry. All further SYN-ACK's are syncookies-only (w/o window scaling >etc). Those in the syncache do not need to carry syncookies and are >real full SYN-ACK's. > > 3/ Only send syncookies and do not cache anything. No window scaling >and SACK-PERM can be carried though. > > So far we've been doing option 1. We can switch to option 2 which, depending > on the situation, may be better or worse. Options 3 isn't viable currently > due to loss of window scaling and SACK. > > Based on the recent Windows 8 issue I've devised a different HMAC based > syncookie scheme where all necessary information can be stored in the ISS > forgoing the need for the timestamp bits. I have sent a description of > the scheme to Colin and Nate to have it reviewed. It must be > cryptographically > strong enough to withstand cracking attempts for about 30 seconds. Forward > security isn't necessary as the syncookie secrets are completely random and > renewed every 30 seconds. I'll wait for Colin and Nates' evaluation of your scheme to weigh in, though given the limited key space already in place I do wonder how you got that much information into a 32 bit int. Thanks, George ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Question: Why ain't I getting gigabit speed?
I just aquired a brand new chepie gigabit PCI ethernet card off eBay. The main chip on it appears to be an RTL8110S-32. I stuck this card into a 9.1-RELEASE system that I have been putting together, and it seemed to be recognized ok (as re0) upon boot up, so I diddled my /etc/rc.conf file to get it to ifconfig as 192.168.1.3 on reboot. Then I rebooted. I have the card wired via a CAT6 cable to my Linksys E2000 gigabit router. Nonetheless, upon reboot, followed by "ifconfig -a", the output from ifconfig says the following for this card: re0: flags=8843 metric 0 mtu 1500 options=8209b ether 00:13:3b:02:03:bd inet 192.168.1.3 netmask 0xff00 broadcast 192.168.1.255 inet6 fe80::213:3bff:fe02:3bd%re0 prefixlen 64 scopeid 0x7 nd6 options=29 media: Ethernet autoselect (100baseTX ) status: active I've tried two different CAT6 cables, two different LAN ports on my E2000, and I've even tried the card in two different PCI slost on my motherboard, but the results are always the same. So, um, what gives? Why does the driver appear to be setting this card to 100baseTX rather than the 1000baseTX that I was hoping for? Is there some magic spell that I am unaware of that I must cast on this in order to get it to work right? P.S. dmesg has this to say about the card: re0: port 0xbe00-0xbeff mem 0xdf9ff000-0xdf9ff0ff irq 18 at device 5.0 on pci4 re0: Chip rev. 0x0400 re0: MAC rev. 0x re0: Ethernet address: 00:13:3b:02:03:bd re0: link state changed to UP re0: link state changed to DOWN re0: link state changed to UP ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Question: Why ain't I getting gigabit speed?
Apologies for following up on myself, but I just now found this: https://support.freenas.org/ticket/894 This thread would suggest that I ain't alone in experienceing this problem with the RTL8110S. That other guy apparently solved his problem by just simply switching to a CAT6 cable. I however am already using CAT6 cables, and the problem for me still exists. I tried adding: media 1000baseTX to my ifconfig_re0= line in my /etc/rc.conf file (and then rebooting), however when I did that, a subsequent "ifconfig -a" showed that indeed, the card had now been correctly configured to speak 1000baseT, however it also said: status: no carrier even though the thing most definitely _is_ still plugged in to my E2000 router, and I could not ping anything else, even on my own LAN. So I'm still stuck, and still looking for an answer. How can I get this card working at gigabit speed? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Question: Why ain't I getting gigabit speed?
Maybe you're not using all 4 pairs in the CAT 6 cable. - Original Message - From: "Ronald F. Guilmette" To: Sent: Thursday, February 07, 2013 6:53 PM Subject: Question: Why ain't I getting gigabit speed? Apologies for following up on myself, but I just now found this: https://support.freenas.org/ticket/894 This thread would suggest that I ain't alone in experienceing this problem with the RTL8110S. That other guy apparently solved his problem by just simply switching to a CAT6 cable. I however am already using CAT6 cables, and the problem for me still exists. I tried adding: media 1000baseTX to my ifconfig_re0= line in my /etc/rc.conf file (and then rebooting), however when I did that, a subsequent "ifconfig -a" showed that indeed, the card had now been correctly configured to speak 1000baseT, however it also said: status: no carrier even though the thing most definitely _is_ still plugged in to my E2000 router, and I could not ping anything else, even on my own LAN. So I'm still stuck, and still looking for an answer. How can I get this card working at gigabit speed? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
