Re: Is it worth the effort to make proxy and server communicate via Unix socket?
Hi, On man, okt 01, 2012 at 12:24:19pm -0400, Mikhail T. wrote: > In a fairly common setup today, a proxy (say, Varnish) runs on the same > system as the actual "backend" server (such as Apache). > > Would it be worthwhile to alter them both to allow them to talk via a > socket instead of via TCP (on the lo0 interface)? > > Or is the win just too negligible? Thanks! I don't see the point. Varnish usually runs on separate servers. On a small scale setup, the likely improvements would be negligible. The Varnish developers also do not want Varnish to become a web server, it's just not it's job. Your time is better spent improving your cache hit ratio (% of requests cached) as well as integrating purging with your content management systems when caching dynamic pages. If you are serving flat files only you may want to consider just using lighttpd or nginx, which are known to be fast. Regards, -- Anders. ___ 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: TCP options order changed in FreeBSD 7, incompatible with some routers
Hi, I had the same problem, and temporarily worked around it by disabling SACK: sysctl net.inet.tcp.sack.enable=0 Which solved my problems. It would be interesting to see if this helps you also? If so, it seems this issue is related to SACK and TCP order maybe? Hmm. On Fri, Apr 04, 2008 at 01:14:19PM -0700, s3raphi wrote: > I upgraded many web servers to FreeBSD 7.0-Release several weeks ago. These > servers serve hundreds of thousands of users. Since then, we have had many > users complain that they cannot connect to these servers any more. This was > a very tricky problem to diagnose, but using packet captures on both the > servers and the clients who have the problem I ended up with the same > results as the original poster. The user can ping the server with ICMP. The > user cannot complete a TCP connection. > Client sends SYN to server > Server responds SYN/ACK > Client packet capture does not show the SYN/ACK arrive. > Connection fails. > > The windows client was running wireshark. > > This problem is specific to windows, but also the network it is on or > devices it goes through. The same user experiencing the problem tried to > connect using a mac, and the problem does not manifest itself. Both the mac > and the windows pc were on the same network, behind the same SOHO router, > same ISP, and talking to the same FreeBSD7.0-RELEASE server. > > Baffled by what the problem could have been, I stood up one of the old > FreeBSD 6.1 servers which had not yet been replaced with FreeBSD7. The user > has no trouble at all accessing the FreeBSD 6.1 server. > > More interesting info: > -This makes it look like windows: > Fails: WindowsXPpro PC -> SOHO -> ISP -> Internet -> MyDataCenter -> > FreeBSD7 > Works: MacBook -> SOHO -> ISP -> Internet -> MyDataCenter -> FreeBSD7 > > -This makes it look like the network(router/firewall/etc..): > If the WindowsPC connects to our office VPN, the connection to the FreeBSD7 > server will work without issue. > > The problem is specific to some combination of Windows and networks or > network devices. I have seen users on many different ISPs, and with many > different flavors of routers/firewalls. > > -The problem only effects a small percentage of our users. Most of our > Windows users have no issue. > > This is a very serious problem for anyone using FreeBSD7 in production as an > internet facing server as a huge percentage of clients will be windows, and > a percentage of those users will no longer be able to use your web services. > > Can the patch be made available to freebsd-update? > > -Seraphi > > > Matt Reimer wrote: > > > > On Thu, Mar 20, 2008 at 7:09 PM, d.s. al coda <[EMAIL PROTECTED]> > > wrote: > >> On 3/12/08, Andre Oppermann <[EMAIL PROTECTED]> wrote: > >> > >> > > >> > >> > I'd be very interesting to know the exactly models and their firmware > >> > version > >> > of the affected routers. If available locally I'd like to obtain a > >> > similar > >> > model myself for future regression tests. > >> > >> > >> Here are the models we managed to hear about via email: > >> D-Link WBR-1310 > >> Linksys WCG200 (with firewall enabled) > >> Encore Broadband Router > >> Linksys WAG354G > >> Ambit U10C019 > >> Netgear CG814GCMR > > > > I've seen this on a Netgear CG814WG. > > > > Matt > > ___ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > > > > > -- > View this message in context: > http://www.nabble.com/TCP-options-order-changed-in-FreeBSD-7%2C-incompatible-with-some-routers-tp15996110p16497816.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]" -- Anders. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP options order changed in FreeBSD 7, incompatible with some routers
Hi, On Wed, Apr 09, 2008 at 08:23:13AM +, Bjoern A. Zeeb wrote: >> I had the same problem, and temporarily worked around it by disabling >> SACK: > ok, here we go... > > as I had explained on freebsd-net@ lately there had been 2 changes to > possibly fix this issue. > > I am currently in the process to find out which of the two is actually > needed and which of the two prior versions caused the problems. > > I have a testbed setup and will have it running for another day or so. > > So could you try to reproduce your problems with the following three > servers (if you could ask your affected customers to test and > report back to you that would be highly appreciated as well). I just got access to a remote PC which has the problem, finally. It runs Windows 2000, service pack 4. > Simply open the following URLs in a browser is enough. If you can > see the pages, fine. If you cannot, tell me which worked, which > didn't. > > http://tcptest1.sbone.de/ This URL does not work, I get "siden kan ikke vises" (page can not be displayed in Norwegian). > http://tcptest2.sbone.de/ This URL works fine, I get the FreeBSD 7.0 TCP options test page. > http://tcptest3.sbone.de/ This URL does not work, I get "siden kan ikke vises" (page can not be displayed in Norwegian). > I have a tcpdump running on my side so all connections will be fully > logged. Good. Your patch on http://sources.zabbadoz.net/freebsd/patchset/20080309-01-tcp-options-padding.diff fixes the problem for me, with SACK still being on as it is by default. I would be much happy if this fix could find it's way to RELENG_7_0 and errata. Thanks a lot! Cheers, -- Anders. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Jails, Portmap, Dracd
Hi, I got tired of dracd's RPC business too. I use ports/mail/pop-before-smtp now, works fine for me. On Tue, Jun 29, 2004 at 10:41:09AM -0400, Tony Holmes wrote: > Hi, > > I'm attempting to set up jails in a 4.9S environment using the newer > rpc versions of dracd. I'm encountering no ends of trouble. > > What I'd like is individual instances of rpc.dracd running to control > each jail individually (each is it's own domain). > > Using the -h flags to portmap, i still get: > > portmap[68286]: cannot bind udp: Address already in use > > Portmap is failing to bind against 127.0.0.1. > > I can sorta "get it to work" if i run portmap in the base system, but then > the drac rpc won't work right. If there is a previous instance of rpc.dracd > running in another jail, it kills it and starts it in the current jail! > > It was S much nicer when dracd was not an rpc service. > > Does anyone have a solution/patches or can recommend a similar service for > postfix in a jailed environment? > > -- > Tony Holmes > > Founder and Senior Systems Architect > Crosswinds Internet Communications Inc. > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Anders. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Filtering jail IP traffic
Hi, IP traffic from one jail to another jail, arrives on destination jail on lo0 having the destination jails IP as source IP. Why not the source jail's IP address? How can I filter traffic from one jail to another, using ipfw of ipf? Cheers, -- Anders. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ipfw uid rules and matching specific services for bandwidth limiting
Hello, Are people actually using uid type rules heavily? I'm having trouble matching the packets generated by programs like Apache and ProFTPD. I believe that may be because of root binding the ports these programs use before they setuid() or something, I'm not sure. Particularly I have trouble matching the packets of active FTP, since I have random ports on both ends to deal with and can't match them by port either. Does anyone have a solution to this? Yep, this is for use with Dummynet, which works OK as long as I get to match the packets I need. :-) ProFTPD's mod_xfer module doesn't seem to be able to globally set a max. transfer rate for all transfers in total either, it seems. I suppose I can proxy the traffic and then match the packets somehow perhaps.. Cheers, -- Anders. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ipfw uid rules and matching specific services for bandwidth limiting
On Mon, Jan 01, 2001 at 05:24:09PM -0600, Bill Fumerola wrote: >> Are people actually using uid type rules heavily? I'm having trouble matching >> the packets generated by programs like Apache and ProFTPD. I believe that may >> be because of root binding the ports these programs use before they setuid() or >> something, I'm not sure. Particularly I have trouble matching the packets of >> active FTP, since I have random ports on both ends to deal with and can't match >> them by port either. Does anyone have a solution to this? > sockstat is your friend, look at the 'user' that is defined per program, > thats who is going to be charged for packets on that socket. Nope, doesn't seem to work. Sockstat says: USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS ftp proftpd 751820 tcp4 10.0.0.8:21 192.168.0.34:4955 ftp proftpd 751821 tcp4 10.0.0.8:21 192.168.0.34:4955 ftp proftpd 75182 12 tcp4 10.0.0.8:478 192.168.0.34:4959 ftp proftpd 75182 13 tcp4 10.0.0.8:478 192.168.0.34:4959 nobody proftpd 688200 tcp4 *:21 *:* Then I add a rule to see if I can count the packets while the above mentioned session is kept alive: # ipfw add 00010 count all from any to any uid ftp And ipfw show shows that the rule doesn't intercept any packets: 000100 0 count ip from any to any uid ftp FYI I am running 4.1.1-STABLE as of Tue Oct 24 01:25:55 CEST 2000, and top(1) shows all proftpd processes as being owned by root. Regards, -- Anders. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: ipfw uid rules and matching specific services for bandwidth limiting
On Tue, Jan 02, 2001 at 01:14:18AM +0100, Anders Nordby wrote: > FYI I am running 4.1.1-STABLE as of Tue Oct 24 01:25:55 CEST 2000, and top(1) > shows all proftpd processes as being owned by root. If I filter on uid root, the rules will match the packets (I tried with specific IPs + uid root): 00010 15392307193 count log ip from any to 192.168.0.34 uid root 00011 881 35259 count log ip from 192.168.0.34 to any uid root But then again filtering on uid root is not what I want -- it will match ssh sessions and other things as well. And then I'm back to start.. Regards, -- Anders. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
64-bit SNMP counters for FreeBSD && graphing bandwidth usage
Hi, Is there any way to have 64-bit SNMP counters in FreeBSD? Especially for ifInOctets/ifOutOctets. It seems the built-in bsnmpd only has Counter32, and net-snmpd the same (--enable-mfd-rewrites, which is supposed to help, seems to only work in Linux). My systems are pushing more than 100 mbps these days, and graphing bandwidth usage with 32-bit counters gives funny-looking graphs. Cheers, -- Anders. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage
Hi, On Tue, Feb 07, 2006 at 05:11:31PM +0300, Gleb Smirnoff wrote: >> Is there any way to have 64-bit SNMP counters in FreeBSD? Especially for >> ifInOctets/ifOutOctets. It seems the built-in bsnmpd only has >> Counter32, and net-snmpd the same (--enable-mfd-rewrites, which is >> supposed to help, seems to only work in Linux). > Extended counters live in a separate subtree and bsnmpd supports them: > >> snmpwalk -v 2c host community ifMIB.ifMIBObjects.ifXTable.ifXEntry Running FreeBSD 6.0-RELEASE and using net-snmp 5.2.2 to walk the tree, I get: # snmpwalk -v 2c -c XXXYYY localhost ifMIB.ifMIBObjects.ifXTable.ifXEntry IF-MIB::ifName.1 = STRING: bge0 IF-MIB::ifName.2 = STRING: bge1 IF-MIB::ifName.3 = STRING: lo0 IF-MIB::ifInMulticastPkts.1 = Counter32: 3430126 IF-MIB::ifInMulticastPkts.2 = Counter32: 0 IF-MIB::ifInMulticastPkts.3 = Counter32: 0 IF-MIB::ifInBroadcastPkts.1 = Counter32: 0 IF-MIB::ifInBroadcastPkts.2 = Counter32: 0 IF-MIB::ifInBroadcastPkts.3 = Counter32: 0 IF-MIB::ifOutMulticastPkts.1 = Counter32: 0 IF-MIB::ifOutMulticastPkts.2 = Counter32: 0 IF-MIB::ifOutMulticastPkts.3 = Counter32: 0 IF-MIB::ifOutBroadcastPkts.1 = Counter32: 0 IF-MIB::ifOutBroadcastPkts.2 = Counter32: 0 IF-MIB::ifOutBroadcastPkts.3 = Counter32: 0 IF-MIB::ifLinkUpDownTrapEnable.1 = INTEGER: enabled(1) IF-MIB::ifLinkUpDownTrapEnable.2 = INTEGER: enabled(1) IF-MIB::ifLinkUpDownTrapEnable.3 = INTEGER: disabled(2) IF-MIB::ifHighSpeed.1 = Gauge32: 10 IF-MIB::ifHighSpeed.2 = Gauge32: 10 IF-MIB::ifHighSpeed.3 = Gauge32: 0 IF-MIB::ifPromiscuousMode.1 = INTEGER: false(2) IF-MIB::ifPromiscuousMode.2 = INTEGER: false(2) IF-MIB::ifPromiscuousMode.3 = INTEGER: false(2) IF-MIB::ifConnectorPresent.1 = INTEGER: true(1) IF-MIB::ifConnectorPresent.2 = INTEGER: true(1) IF-MIB::ifConnectorPresent.3 = INTEGER: false(2) IF-MIB::ifAlias.1 = STRING: IF-MIB::ifAlias.2 = STRING: IF-MIB::ifAlias.3 = STRING: IF-MIB::ifCounterDiscontinuityTime.1 = Timeticks: (0) 0:00:00.00 IF-MIB::ifCounterDiscontinuityTime.2 = Timeticks: (0) 0:00:00.00 IF-MIB::ifCounterDiscontinuityTime.3 = Timeticks: (0) 0:00:00.00 It seems ifHCInOctets and ifHCOutOctets are missing. How come? Do I need to use SNMP v3? Another query tool? Bye, -- Anders. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage
On Tue, Feb 14, 2006 at 09:07:42AM +0100, Harti Brandt wrote: >>It seems ifHCInOctets and ifHCOutOctets are missing. How come? Do I need >>to use SNMP v3? Another query tool? > 10 bits/seconds seems utterly wrong for bge interfaces :-) The HC counters > appear only for speeds >= 20Mbit/sec according to the RFC. I have two servers running bsnmpd in FreeBSD 6.0-RELEASE here now. Both have bge gigabit interfaces. 1) A HP Proliant DL 380 G4 (FreeBSD/i386), with (forced) 100baseTX full-duplex link: # ifconfig bge0 bge0: flags=8843 mtu 1500 options=1a inet X.X.X.X netmask 0xfff0 broadcast 80.91.38.111 ether 00:14:c2:61:5c:95 media: Ethernet 100baseTX status: active # snmpwalk -v 2c -c XX localhost:163 ifMIB.ifMIBObjects.ifXTable.ifXEntry IF-MIB::ifName.1 = STRING: bge0 IF-MIB::ifName.2 = STRING: bge1 IF-MIB::ifName.3 = STRING: lo0 IF-MIB::ifInMulticastPkts.1 = Counter32: 3430507 IF-MIB::ifInMulticastPkts.2 = Counter32: 0 IF-MIB::ifInMulticastPkts.3 = Counter32: 0 IF-MIB::ifInBroadcastPkts.1 = Counter32: 0 IF-MIB::ifInBroadcastPkts.2 = Counter32: 0 IF-MIB::ifInBroadcastPkts.3 = Counter32: 0 IF-MIB::ifOutMulticastPkts.1 = Counter32: 0 IF-MIB::ifOutMulticastPkts.2 = Counter32: 0 IF-MIB::ifOutMulticastPkts.3 = Counter32: 0 IF-MIB::ifOutBroadcastPkts.1 = Counter32: 0 IF-MIB::ifOutBroadcastPkts.2 = Counter32: 0 IF-MIB::ifOutBroadcastPkts.3 = Counter32: 0 IF-MIB::ifLinkUpDownTrapEnable.1 = INTEGER: enabled(1) IF-MIB::ifLinkUpDownTrapEnable.2 = INTEGER: enabled(1) IF-MIB::ifLinkUpDownTrapEnable.3 = INTEGER: disabled(2) IF-MIB::ifHighSpeed.1 = Gauge32: 10 IF-MIB::ifHighSpeed.2 = Gauge32: 10 IF-MIB::ifHighSpeed.3 = Gauge32: 0 IF-MIB::ifPromiscuousMode.1 = INTEGER: false(2) IF-MIB::ifPromiscuousMode.2 = INTEGER: false(2) IF-MIB::ifPromiscuousMode.3 = INTEGER: false(2) IF-MIB::ifConnectorPresent.1 = INTEGER: true(1) IF-MIB::ifConnectorPresent.2 = INTEGER: true(1) IF-MIB::ifConnectorPresent.3 = INTEGER: false(2) IF-MIB::ifAlias.1 = STRING: IF-MIB::ifAlias.2 = STRING: IF-MIB::ifAlias.3 = STRING: IF-MIB::ifCounterDiscontinuityTime.1 = Timeticks: (0) 0:00:00.00 IF-MIB::ifCounterDiscontinuityTime.2 = Timeticks: (0) 0:00:00.00 IF-MIB::ifCounterDiscontinuityTime.3 = Timeticks: (0) 0:00:00.00 2) A HP Proliant DL 385 G1 (FreeBSD/amd64), with gigabit link: # ifconfig bge0 bge0: flags=8843 mtu 1500 options=1a inet X.X.X.X netmask 0xffe0 broadcast 80.91.39.159 ether 00:13:21:b3:01:f6 media: Ethernet autoselect (1000baseTX ) status: active # snmpwalk -v 2c -c XX localhost:163 ifMIB.ifMIBObjects.ifXTable.ifXEntry IF-MIB::ifName.1 = STRING: bge0 IF-MIB::ifName.2 = STRING: bge1 IF-MIB::ifName.3 = STRING: lo0 IF-MIB::ifInMulticastPkts.1 = Counter32: 13303 IF-MIB::ifInMulticastPkts.2 = Counter32: 0 IF-MIB::ifInMulticastPkts.3 = Counter32: 0 IF-MIB::ifInBroadcastPkts.1 = Counter32: 0 IF-MIB::ifInBroadcastPkts.2 = Counter32: 0 IF-MIB::ifInBroadcastPkts.3 = Counter32: 0 IF-MIB::ifOutMulticastPkts.1 = Counter32: 0 IF-MIB::ifOutMulticastPkts.2 = Counter32: 0 IF-MIB::ifOutMulticastPkts.3 = Counter32: 0 IF-MIB::ifOutBroadcastPkts.1 = Counter32: 0 IF-MIB::ifOutBroadcastPkts.2 = Counter32: 0 IF-MIB::ifOutBroadcastPkts.3 = Counter32: 0 IF-MIB::ifLinkUpDownTrapEnable.1 = INTEGER: enabled(1) IF-MIB::ifLinkUpDownTrapEnable.2 = INTEGER: enabled(1) IF-MIB::ifLinkUpDownTrapEnable.3 = INTEGER: disabled(2) IF-MIB::ifHighSpeed.1 = Gauge32: 10 IF-MIB::ifHighSpeed.2 = Gauge32: 10 IF-MIB::ifHighSpeed.3 = Gauge32: 0 IF-MIB::ifPromiscuousMode.1 = INTEGER: false(2) IF-MIB::ifPromiscuousMode.2 = INTEGER: false(2) IF-MIB::ifPromiscuousMode.3 = INTEGER: false(2) IF-MIB::ifConnectorPresent.1 = INTEGER: true(1) IF-MIB::ifConnectorPresent.2 = INTEGER: true(1) IF-MIB::ifConnectorPresent.3 = INTEGER: false(2) IF-MIB::ifAlias.1 = STRING: IF-MIB::ifAlias.2 = STRING: IF-MIB::ifAlias.3 = STRING: IF-MIB::ifCounterDiscontinuityTime.1 = Timeticks: (0) 0:00:00.00 IF-MIB::ifCounterDiscontinuityTime.2 = Timeticks: (0) 0:00:00.00 IF-MIB::ifCounterDiscontinuityTime.3 = Timeticks: (0) 0:00:00.00 I changed port to 163 cause I am actually using net-snmp snmpd on port 161 still. Anyway, it seems bsnmpd insists these are 10 mbps interfaces? Why so? Cheers, -- Anders. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage
Hi, On Tue, Feb 14, 2006 at 11:44:59AM +0300, Gleb Smirnoff wrote: > H> The driver reports a speed of 10Mbits/sec. ifHighSpeed is ifi_baudrate > H> divided by 10^6 (and rounded). This is the default set by ether_ifattach() > H> if the driver did not set another value. It seems that bge never sets that > H> value so you end up with the default. This looks like a bug. > > Harti, we are thinking in parallel :) > > Andres, pls try the attached patch. > > Index: if_bge.c > === > RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v > retrieving revision 1.118 > diff -u -r1.118 if_bge.c > --- if_bge.c 30 Jan 2006 13:45:55 - 1.118 > +++ if_bge.c 14 Feb 2006 08:43:24 - > @@ -2192,6 +2192,7 @@ > ifp->if_snd.ifq_drv_maxlen = BGE_TX_RING_CNT - 1; > IFQ_SET_MAXLEN(&ifp->if_snd, ifp->if_snd.ifq_drv_maxlen); > IFQ_SET_READY(&ifp->if_snd); > + ifp->if_baudrate = IF_Gbps(1); > ifp->if_hwassist = BGE_CSUM_FEATURES; > ifp->if_capabilities = IFCAP_HWCSUM | IFCAP_VLAN_HWTAGGING | > IFCAP_VLAN_MTU | IFCAP_VLAN_HWCSUM; The patches gives me ifHighSpeed = 1000 on bge interfaces, also where the interface is forced to 100baseTX. In any case I get ifHCOutOctets and ifHCInOctets, which was what I was originally looking for. Making bsnmpd report actual speed seems sensible, yes. I should make a list of "what bsnmpd needs" to be more usable, in case Harti is interested. ;-P Mvh, -- Anders. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bsnmpd (was: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage)
Hi, On Tue, Feb 14, 2006 at 01:39:01PM +0300, Gleb Smirnoff wrote: > A> I should make a list of "what bsnmpd needs" to be more usable, in case > A> Harti is interested. ;-P > Where is such list? Some things popping off my mind: - Ability to run as a different user. I suppose we should add a snmp user to the base system. Running as root is not OK, when it is not necessary (net-snmp snmpd can run as a different user, it has a related -r option to not exit if it has privilege problems). - Ability to chroot itself (yes please, for security). - Ability to execute programs and return values on given OIDs, and also cache their results so that the programs doesn't have to be run for every time. It's necessary to cache values to avoid running resource intensive scripts/programs more than necessary. I am using net-snmp snmpd mostly currently, but consider switching as I now can get my 64-bit counters from bsnmpd. It seems net-snmp snmpd can not give ifHCInOctets/ifHCOutOctets (Counter64) in FreeBSD yet. At least the exec issue above must be resolved for me to switch to bsnmpd. Oh, and a couple of questions. If I only want read access enabled, is commenting "write :=" and "trap :=" out all that is necessary? If not, how do I do it? Normally, I only want to read from my SNMP agents. I would prefer to have trap/write disabled completely. Another thing. The trap support in bsnmpd, it's only for forwarding traps? Does bsnmpd have, or will it ever get an ability to generate traps upon failures in FreeBSD? Cheers, -- Anders. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage
Hi,
Done. On system with bge and 100 mbps link speed, I get:
IF-MIB::ifName.1 = STRING: bge0
IF-MIB::ifName.2 = STRING: bge1
IF-MIB::ifName.3 = STRING: lo0
IF-MIB::ifHighSpeed.1 = Gauge32: 100
IF-MIB::ifHighSpeed.2 = Gauge32: 0
IF-MIB::ifHighSpeed.3 = Gauge32: 0
On system with bge and gigabit link speed, I get:
IF-MIB::ifName.1 = STRING: bge0
IF-MIB::ifName.2 = STRING: bge1
IF-MIB::ifName.3 = STRING: lo0
IF-MIB::ifHighSpeed.1 = Gauge32: 1000
IF-MIB::ifHighSpeed.2 = Gauge32: 0
IF-MIB::ifHighSpeed.3 = Gauge32: 0
The second NIC, bge1, is not configured. Seems fine to me. I still get
ifHCInOctets/ifHCOutOctets for both systems mentioned.
On Tue, Feb 14, 2006 at 02:02:17PM +0300, Gleb Smirnoff wrote:
> Oleg, Anders,
>
> can you please remove all your changes to if_bge.c and test the
> attached patch. Awaiting for feedback and thanks.
>
> --
> Totus tuus, Glebius.
> GLEBIUS-RIPN GLEB-RIPE
> Index: net/if_media.c
> ===
> RCS file: /home/ncvs/src/sys/net/if_media.c,v
> retrieving revision 1.22
> diff -u -r1.22 if_media.c
> --- net/if_media.c25 Dec 2005 23:28:23 - 1.22
> +++ net/if_media.c14 Feb 2006 09:51:09 -
> @@ -385,6 +385,28 @@
> return match;
> }
>
> +/*
> + * Compute the interface `baudrate' from the media, for the interface
> + * metrics (used by routing daemons).
> + */
> +static const struct ifmedia_baudrate ifmedia_baudrate_descriptions[] =
> +IFM_BAUDRATE_DESCRIPTIONS;
> +
> +uint64_t
> +ifmedia_baudrate(int mword)
> +{
> + int i;
> +
> + for (i = 0; ifmedia_baudrate_descriptions[i].ifmb_word != 0; i++) {
> + if ((mword & (IFM_NMASK|IFM_TMASK)) ==
> + ifmedia_baudrate_descriptions[i].ifmb_word)
> + return (ifmedia_baudrate_descriptions[i].ifmb_baudrate);
> + }
> +
> + /* Not known. */
> + return (0);
> +}
> +
> #ifdef IFMEDIA_DEBUG
> struct ifmedia_description ifm_type_descriptions[] =
> IFM_TYPE_DESCRIPTIONS;
> Index: net/if_media.h
> ===
> RCS file: /home/ncvs/src/sys/net/if_media.h,v
> retrieving revision 1.30
> diff -u -r1.30 if_media.h
> --- net/if_media.h22 Feb 2005 13:04:03 - 1.30
> +++ net/if_media.h14 Feb 2006 10:29:59 -
> @@ -104,6 +104,9 @@
> int ifmedia_ioctl(struct ifnet *ifp, struct ifreq *ifr,
> struct ifmedia *ifm, u_long cmd);
>
> +/* Compute baudrate for a given media. */
> +uint64_t ifmedia_baudrate(int);
> +
> #endif /*_KERNEL */
>
> /*
> @@ -138,8 +141,8 @@
> #define IFM_1000_CX 15 /* 1000baseCX - 150ohm STP */
> #define IFM_1000_T 16 /* 1000baseT - 4 pair cat 5 */
> #define IFM_HPNA_1 17 /* HomePNA 1.0 (1Mb/s) */
> -#define IFM_10GBASE_SR 18 /* 10GBASE-SR 850nm Multi-mode
> Fiber */
> -#define IFM_10GBASE_LR 19 /* 10GBASE-LR 1310nm
> Single-mode Fiber */
> +#define IFM_10G_LR 18 /* 10GBase-LR 1310nm
> Single-mode */
> +#define IFM_10G_SR 19 /* 10GBase-SR 850nm Multi-mode
> */
>
> /* note 31 is the max! */
>
> @@ -543,4 +546,59 @@
> { 0, NULL },\
> }
>
> +/*
> + * Baudrate descriptions for the various media types.
> + */
> +struct ifmedia_baudrate {
> + int ifmb_word; /* media word */
> + uint64_tifmb_baudrate; /* corresponding baudrate */
> +};
> +
> +#define IFM_BAUDRATE_DESCRIPTIONS { \
> + { IFM_ETHER | IFM_10_T, IF_Mbps(10) }, \
> + { IFM_ETHER | IFM_10_2, IF_Mbps(10) }, \
> + { IFM_ETHER | IFM_10_5, IF_Mbps(10) }, \
> + { IFM_ETHER | IFM_100_TX, IF_Mbps(100) }, \
> + { IFM_ETHER | IFM_100_FX, IF_Mbps(100) }, \
> + { IFM_ETHER | IFM_100_T4, IF_Mbps(100) }, \
> + { IFM_ETHER | IFM_100_VG, IF_Mbps(100) }, \
> + { IFM_ETHER | IFM_100_T2, IF_Mbps(100) }, \
> + { IFM_ETHER | IFM_1000_SX, IF_Mbps(1000) },\
> + { IFM_ETHER | IFM_10_STP, IF_Mbps(10) }, \
> + { IFM_ETHER | IFM_10_FL,IF_Mbps(10) }, \
> + { IFM_ETHER | IFM_1000_LX, IF_Mbps(1000) },\
> + { IFM_ETHER | IFM_1000_CX, IF_Mbps(1000) },\
> + { IFM_ETHER | IFM_1000_T, IF_Mbps(1000) },\
> + { IFM_ETHER | IFM_HPNA_1, IF_Mbps(1) }, \
> + { IFM_ETHER | IFM_10G_LR, IF_Gbps(10ULL) }, \
> + \
> + { IFM_TOKEN | IFM_TOK_STP4, IF_Mbps(4) },
iwi stability when doing large file transfers/backups
Hi, I'm having great difficulties taking backup of my laptop computer. It's a Fujitsu Siemens Lifebook E8020 system with a Intel PRO/Wireless 2915ABG NIC. I'm connected to a FreeBSD hostap, using WPA2 (CCMP/AES). Updating to 6-STABLE (6.1-PRERELEASE) seems to have improved the stability of the iwi driver quite a bit, but when doing large file transfers (in this case rsyncing all the data from the laptop through SSH), I always and oftenly get: Disconnecting: Corrupted MAC on input. The messages comes from SSH, so it seems to be getting corrupted data. Is anyone looking into that? Is there any fixes or settings that should be tried? How are people's experience with iwi? Am I the only one to have problems with it? Cheers, -- Anders. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPF and OOW problems
Hi, The current version of IP Filter in FreeBSD has bugs in the handling of TCP out-of-window checks. Check/follow http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/98978 for a solution. On Mon, Jun 12, 2006 at 02:02:17PM +0200, Sébastien A. VALSEMEY wrote: > Hello, > > I currently have a FreeBSD 6.1-STABLE box configured as a router/firewall > with ipfilter v4.1.8. > > > WAN_IP/32 > | > tun0 > | > |-| > | FreeBSD | > |-| > / \ > xl0 xl1 > / \ > > 192.168.0.0/24 DMZ_BLOCK/29 > > I often experience in my ipf logs such packet drops (the following example is > for an active upload on a FTP server located on the > first IP of the DMZ network). My IPs have been voluntary hidden for privacy > purposes. > > ipmon[329]: 13:12:41.185263 tun0 @0:110 b REMOTE_WAN_IP,8600 -> DMZ_IP_1,20 > PR tcp len 20 1300 -A IN OOW > ipmon[329]: 13:12:41.186493 tun0 @0:110 b REMOTE_WAN_IP,8600 -> DMZ_IP_1,20 > PR tcp len 20 356 -AP IN OOW > > Packet drop occurs a few seconds after the beginning of the transfer, even > allowing a few kilobytes to be uploaded, which means that > the connection establishes well. > > And on another hand, when I try to reach DMZ machines from the LAN (for > example via RDP), I am systematically dropped with the same > kind of OOW packet, I mean the connection is not even established. > > As ICMP is allowed on the whole network, I can traceroute and reach each host > in the network, from inside and outside (except for > the natted LAN...). The IP masquerading for hosts located on LAN works > perfectly as they can go on the Internet without any problem. > > When I add the two following lines in my ipf ruleset, everything runs > smoothly (but insecured!): > pass in quick all > pass out quick all > > I heard that such problems occur with the same version of ipf on Solaris > (http://msgs.securepoint.com/cgi-bin/get/ipfilter-0605/28.html), but I am not > sure it happens because of that. > > What I did wrong? > > Thank you by advance for your help. > > Here are extracts from my main configuration files: > > [/etc/rc.conf] > <... *snip*! ...> > firewall_enable="NO" > firewall_script="/etc/rc.firewall" > firewall_type="/etc/rc.firewall.rules" > firewall_logging="YES" > gateway_enable="YES" > icmp_drop_redirects="YES" > ifconfig_lo0="inet 127.0.0.1" > ifconfig_xl0="inet 192.168.0.254 netmask 255.255.255.0" > ifconfig_xl1="inet DMZ_IP_6 netmask 255.255.255.248" > ipfilter_enable="YES" > ipfilter_rules="/etc/ipf.rules" > ipnat_enable="YES" > ipnat_program="/sbin/ipnat" > ipnat_rules="/etc/ipnat.rules" > ipnat_flags="" > ipmon_enable="YES" > ipmon_program="/sbin/ipmon" > ipmon_flags="-Ds" > kern_securelevel="0" > kern_securelevel_enable="NO" > network_interfaces="lo0 xl0 xl1" > ppp_enable="YES" > ppp_mode="ddial" > ppp_nat="NO" > ppp_profile="My_ISP_PROFILE" > <... *snip*! ...> > > > > [/etc/ipf.rules] > # Allow localhost traffic > pass in quick on lo0 all > pass out quick on lo0 all > > # Allow all outgoing traffic from this gateway > pass out quick on tun0 from any to any keep state > pass out quick on tun0 proto tcp from any to any keep state > pass out quick on xl0 from any to 192.168.0.0/24 keep state > pass out quick on xl0 proto tcp from any to 192.168.0.0/24 keep state > pass out quick on xl1 from any to DMZ_BLOCK/29 keep state > pass out quick on xl1 proto tcp from any to DMZ_BLOCK/29 keep state > > # Allow ICMP traffic (for testing purposes) > pass in quick on xl0 proto icmp from 192.168.0.0/24 to any keep state > pass in quick on xl1 proto icmp from DMZ_BLOCK/29 to any keep state > pass in quick on tun0 proto icmp from any to 192.168.0.0/24 keep state > pass in quick on tun0 proto icmp from any to DMZ_BLOCK/29 keep state > pass out quick proto icmp from any to any keep state > > # Allow FTP server > pass in quick on tun0 proto tcp from any to DMZ_IP_1/32 port = ftp-data keep > state > pass in quick on xl0 proto tcp from 192.168.0.0/24 to DMZ_IP_1/32 port = > ftp-data keep state > pass in quick on tun0 proto tcp from any to DMZ_IP_1/32 port = ftp keep state > pass in quick on xl0 proto tcp from 192.168.0.0/24 to DMZ_IP_1/32 port = ftp > keep state > # This is for the passive ports range... > pass in quick on tun0 proto tcp from any to DMZ_IP_1/32 port 4000 >< 4049 > keep state > pass in quick on xl0 proto tcp from 192.168.0.0/24 to DMZ_IP_1/32 port 4000 > >< 4049 keep state > > # Allow Terminal services > pass in quick on tun0 proto tcp from any to DMZ_IP_1/32 port = rdp keep state > pass in quick on xl0 proto tcp from 192.168.0.0/24 to DMZ_IP_1/32 port = rdp > keep state > > # Default > block in log all > block return-rst in log proto tcp from any to any > block return-icmp-as-dest(port-unr) in log proto udp from any to any > > > [/etc/ipnat.rules] > map tun0 192.168.0.0/24 -> WAN_IP/32 > map tun0
Re: Networking FreeBSD Wiki
Hi, George, maybe there should be a separate category in GNATS also, for network issues? On Thu, Feb 08, 2007 at 05:07:31PM -0800, [EMAIL PROTECTED] wrote: > I've started a Wiki page in the FreeBSD Wiki in an attempt to > coordinate some of the clean up work and networking projects that > aren't already covered. Please see: > > http://wiki.freebsd.org/Networking > > and update (if you're a committer) or email me corrections etc. > > Best, > George > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Anders. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
