Re: Some gruesome moments with performance of FreeBSD at over 20K interfaces
On Wed, 9 Apr 2014, Vladislav Prodan wrote: VP>b) Service bsnmpd started at 12K interfaces, but immediately loaded CPU VP>at 80-100% I could imagine that this is because of the statistics polling. bsnmp implements 64-bit interface statistics but we have only 32-bit statistics in the kernel. So it polls the kernel statistics for each interface on a rate that ensures that 32-bit don't overflow. If the interfaces are GBit or, worse, 10GBit interfaces the polling rate is rather high (in the order of seconds). You should either make sure that the interfaces report sensible bitrates (I doubt that 20k interfaces could all be GBit interfaces) or force a slower polling interval by setting begemotIfForcePoll.0 to some large value. harti ___ 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: BSNMPD: several (cosmetic?) problems
Hi, On Sun, 7 Apr 2013, Lev Serebryakov wrote: LS>(1) I have a lot of "could not encode error response" in LS>/var/log/messages after change of hardware. It looks like, every LS>request from mrtg for "unexistent" interface leads to this message. LS>I'll reconfigure mrtg, of course, but it is annoying. I think this is a problem I have already got a patch for from Steryana, but did not manage yet to test. If it is that problem, then it is not entirely cosmetic, because the daemon fails to send error responses in many cases. harti LS>(2) With wlan plugin daemon complains "unknown regdomain (0x8a)", and LS>I have "regdomain ROW country DE" on my WiFi card. LS> LS> ___ 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: bsnmpd: ifTable and if_nametoindex() inconsistency
On Sat, 22 Jan 2011, Eugene Grosbein wrote: EG>On 23.01.2011 00:24, Eugene Grosbein wrote: EG>> I really need quick method to obtain SNMP index within mpd55 code EG>> (for my local mpd hacks) and if_nametoindex() used to seem nice way... EG>> I need to export indexes via mpd's web interface so that they may be EG>> checked remotely using SNMP. EG> EG>Still wondering how to get SNMP index without way too slow walking ifTable over... We could implement a private table which maps sysindex -> ifIndex. That would then require one GET before accessing ifTable. harti ___ 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: Querying bsnmpd through /var/run/snmpd.sock
On Sun, 23 Jan 2011, Eugene Grosbein wrote: EG>bsnmpd running with mibII module opens local socket /var/run/snmpd.sock EG>mentioned in snmp_mibII(3) manual page: EG> EG> The mibII module opens a socket that is used to execute all network EG> related ioctl(2) functions. This socket is globally available under the EG> name mib_netsock. EG> EG>How do I use the socket? I hope to be able to call mib_find_if_sys() function EG>from another process using the socket. Is there a documentation for this? The socket works just like a UDP socket with the additional plus that the daemon knows whether you're root or not. As I said in my previous mail, easiest would be to implement an additional table with the sysindex as index and ifIndex as a row. harti ___ 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: bsnmpd: ifTable and if_nametoindex() inconsistency
On Sat, 22 Jan 2011, Eugene Grosbein wrote: EG>I run 8.2-PRERELEASE with bsnmpd and mpd55 serving PPPoE users. EG>I've noticed that sometimes snmpwalk shows interface indexes EG>that partially differ from what if_nametoindex(3) returns EG>with off-by-one or off-by-two. For example, just now this server has EG>813 connected PPPoE sessions (interfaces named ng) EG>and SNMP returns wrong indexes for 567 out of them, starting from ng334. EG> EG>I've restarted bsnmpd but this made it worse: now all dynamic ng EG>interfaces have obtained new indexes in SNMP ifTable and no one EG>equals to if_nametoindex(name). EG> EG>Aren't these indexes supposed to be equal? EG>I really need quick method to obtain SNMP index within mpd55 code EG>(for my local mpd hacks) and if_nametoindex() used to seem nice way... EG>I need to export indexes via mpd's web interface so that they may be EG>checked remotely using SNMP. The problem is that the RFC which defines the ifTable puts some interesting restrictions on the ifIndex. For example, the same interface must get the same index if it is removed and inserted again (without the RFC actually describing what means 'same'). Somewhere in the bsnmp code or the man page there is a discussion on this. What it does is: it remembers the ifIndex <-> MAC address mapping and remaps the interface indexes so that this mapping remains constant. This also means, that an interface index is never reused for another interface. So, unless you reboot the system, the same index means always the same interface (identified by MAC address), which is probably a good thing. For 'virtual' interfaces of all kinds there is never the same interface - each interface is a new one and the index is just incremented for each new interface. Since I implemented this I'm torn apart whether this is a good idea or not :-( harti ___ 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: Future of netnatm: looking for testers
On Fri, 17 Dec 2010, Robert Watson wrote: RW> RW>On Wed, 15 Dec 2010, Bjoern A. Zeeb wrote: RW> RW>> I would request two things: RW>> RW>> 1) the extra couple of months; this will not prevent the evitable removal RW>> yet only defer it. RW> RW>Sounds good to me -- my goal is not to remove NETNATM, rather, the remove RW>code that doesn't compile or work. I'm happy to sit on this for a while and RW>see if things improve; fixing the former is great, fixing the latter would be RW>even better :-). RW> RW>(I wonder if Harti is in a situation to test any of this still?) I have the equipment, but catastrophically no time. If there were a developer somewhere around the corner here, I could give him a couple of ATM cards and even a switch. sorry, harti RW>> RW>> 2) If anyone of you is using (or want to be able to (continue to) use) NATM RW>> or can test things, I re-enabled it with most of the code in HEAD and RW>> the patch is available for 8,x as well but need to work with somoene RW>> to make sure it'll really work. I am willing to spend more time on it RW>> if you send me an email. RW>> RW>> Best Regards, RW>> Bjoern RW>> RW>> RW>> > Author: bz RW>> > Date: Wed Dec 15 22:58:45 2010 RW>> > New Revision: 216466 RW>> > URL: http://svn.freebsd.org/changeset/base/216466 RW>> > RW>> > Log: RW>> > Bring back (most of) NATM to avoid further bitrot after r186119. RW>> > Keep three lines disabled which I am unsure if they had been used at RW>> > all. RW>> > This will allow us to seek testers and possibly bring it all back. RW>> RW>> If you have the ability to test (on 8.x or HEAD) or are using NATM, RW>> please get in contact with me. RW>> RW>> RW>> RW>> > Discussed with: rwatson RW>> > MFC after: 7 weeks RW>> > RW>> > Modified: RW>> > head/sys/conf/NOTES RW>> > head/sys/netinet/if_atm.c RW>> RW>> RW>> -- RW>> Bjoern A. Zeeb Welcome a new stage of life. RW>> Going to jail sucks -- All my daemons like it! RW>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html RW>> RW>___ RW>freebsd-a...@freebsd.org mailing list RW>http://lists.freebsd.org/mailman/listinfo/freebsd-arch RW>To unsubscribe, send any mail to "freebsd-arch-unsubscr...@freebsd.org" RW> RW> ___ 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: Poor situation with snmp support in FreeBSD
Hi, On Fri, 26 Mar 2010, Alexander Bubnov wrote: AB>One more question please in scope of snmp topic. does bsnmp support master AB>agentx mode? No. I read through the documents and decided that I would not have time to implement this. I often use external agents in projects, but usually use custom protocols or shared memory with them. harti ___ 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: Poor situation with snmp support in FreeBSD
Hi, On Thu, 25 Mar 2010, Shteryana Shopova wrote: SS>On Thu, Mar 25, 2010 at 1:33 PM, Harti Brandt wrote: SS>> On Thu, 25 Mar 2010, Vasyl Samoilov wrote: SS>> SS>> SS>> - bsnmp is lacking developers (I'm the only one). I had a surgery in SS>+ 1 (count me in that is) SS>> november and took the 4 weeks after this to rewrite all the networking SS>> stuff. It is in principle mostly up to date and supports also IPv6. The SS>> problem is that I run out of time again and just cannot do the last steps SS>> to release it (including testing). If there were people interested in it, SS>> I would happily work with them. SS>> SS>> harti SS>> SS>sorry to hear about the surgery - I've recently resumed somewhat SS>active work on bsnmp and modules, so if you can upload your work to an SS>accessible repository, say svn.freebsd.org/user/harti I can take on SS>testing and preparing the code for import. btw, I was contacted some SS>time ago by Carlos Santos suggesting a set of patches adding IPV6 SS>transport, unfortunatelly he hasn't replied to any of my last e-mails, SS>is this the same patchset we're talking about or a different one? No this is different code. I guess, I should really put it on svn.freebsd.org. I do this in the next days... SS>P.S. Back to the thread topic - so the only problem the author is SS>facing with bsnmp is that it lacks support for LLDP, do I understand SS>correctly? This is what I understood too. harti ___ 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: Poor situation with snmp support in FreeBSD
On Thu, 25 Mar 2010, Vasyl Samoilov wrote: VS>So far I found two options for snmp daemon - bsnmp and net-snmp. net-snmo VS>giving back invalid data, bsnmp lacks some data at all. Just two general remarks: - net-snmp is probably developed on Linux so it doesn't know how to access many of the informations that is available in FreeBSD. - bsnmp is lacking developers (I'm the only one). I had a surgery in november and took the 4 weeks after this to rewrite all the networking stuff. It is in principle mostly up to date and supports also IPv6. The problem is that I run out of time again and just cannot do the last steps to release it (including testing). If there were people interested in it, I would happily work with them. harti ___ 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"
generating routing message on LL address change
Hi all, I would like to commit the following patch. It generates an RTM_IFINFO message when the link-layer address of an interface is changed. This should be no problem for routing daemons, because the same messages are also generated when other interface state changes. Are there any reasons not to do this? harti Index: /sys/net/if.c === RCS file: /freebsd/cvsup/src/sys/net/if.c,v retrieving revision 1.370 diff -u -r1.370 if.c --- /sys/net/if.c 30 Nov 2009 21:25:57 - 1.370 +++ /sys/net/if.c 2 Dec 2009 17:33:56 - @@ -3136,6 +3136,10 @@ } #endif } + + /* inform daemons */ + rt_ifmsg(ifp); + return (0); } ___ 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"
ARP regression in releng-8
Hi all, I try to figure out something simple like the ARP retransmission timeout to populate the ipv4InterfaceRetransmitTime in the RFC4293 MIB. In line 357 of netinet/if_ether.c it says: /* * Return EWOULDBLOCK if we have tried less than arp_maxtries. It * will be masked by ether_output(). Return EHOSTDOWN/EHOSTUNREACH * if we have already sent arp_maxtries ARP requests. Retransmit the * ARP request, but not faster than one request per second. */ Unfortunately the comment about the 1s minimum retransmit interval is there, but the code not. A simple ping -f shows the code transmitting ARP requests every 30 milliseconds, which is not good in my opinion. releng-7 (with the old L2 code) works correctly. BTW, what means the comment on line 282 in the same file? /* X */ harti ___ 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 bug?
Hi, On Fri, 19 Jun 2009, Chuck Swiger wrote: CS>On Jun 19, 2009, at 10:44 AM, Harti Brandt wrote: CS>> When the TCP is in SYN-SENT state (the user has called connect()) and the CS>> peer answers with an almost-lamp test packet which has SYN, FIN, ACK and CS>> data larger than the window, TCP ACKs a window full of data, drops the CS>> rest, but processes the FIN - it goes into CLOSE_WAIT. This looks wrong to CS>> me. When dropping the data that is outside the window, it should also drop CS>> the FIN. CS> CS>Clearly, you shouldn't process a FIN which happens outside of the current CS>window: "For sequence number purposes, the SYN is considered to occur before CS>the first actual data octet of the segment in which it occurs, while the FIN CS>is considered to occur after the last actual data octet in a segment in which CS>it occurs." CS> CS>If the socket was in a synchronized state, RFC-793 pg 37 says: CS> CS>"3. If the connection is in a synchronized state (ESTABLISHED, CS> FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), CS> any unacceptable segment (out of window sequence number or CS> unacceptible acknowledgment number) must elicit only an empty CS> acknowledgment segment containing the current send-sequence number CS> and an acknowledgment indicating the next sequence number expected CS> to be received, and the connection remains in the same state." CS> CS>...if it's before the connection is fully setup, ie, in SYN-SENT state as you CS>say, then the fact that the packet contains data which does not fit in the CS>window suggests it should be handled by the rules for half-open connections: CS> CS> "As a general rule, reset (RST) must be sent whenever a segment arrives CS> which apparently is not intended for the current connection. A reset CS> must not be sent if it is not clear that this is the case." CS> CS>See figure 12-- I think you should be sending a RST back I think this is too drastic. A segment is unacceptable only if it is completly out of the window. Here part is in the window. Also conceptually TCP enters the ESTABLISHED state as soon as it finds that the ACK in the SYN,ACK is correct before it starts to process the data and the FIN (p.68 of RFC793 - first you enter ESTABLISHED and ACK, then you goto step 6). So taking into account the explanation at top of page 70 (which logically belongs to step 6) you just drop everything outside the window - part of the data and the FIN in our case - and proceed. Note, that the data in the SYN,ACK is always partly in the window because this segment contains the IRS, except if the window is 0 and the segment contains data or FIN. harti ___ 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"
TCP bug?
Hi all, one of my TCP test cases breaks in what one could call an edge case: When the TCP is in SYN-SENT state (the user has called connect()) and the peer answers with an almost-lamp test packet which has SYN, FIN, ACK and data larger than the window, TCP ACKs a window full of data, drops the rest, but processes the FIN - it goes into CLOSE_WAIT. This looks wrong to me. When dropping the data that is outside the window, it should also drop the FIN. The problem seems to be very old - I found it alread in rev. 1.1 of tcp_input.c. In -CURRENT it is on line 2590: when the sequence number of the incoming segment is the next expected one, the reassembly queue is empty and we are in an established state, the segment data is added to the socket buffer and all TCP header flags are cleared except for TH_FIN. Unfortunately here the original header flags are taken instead of the cached version in thflags. Earlier in the processing the out-of-window data and the FIN in thflags were chopped off and now TH_FIN reappears. The fix should be easy: instead of using the original flag byte to get the FIN use the cached copy. Index: tcp_input.c === --- tcp_input.c (revision 194499) +++ tcp_input.c (working copy) @@ -2587,7 +2587,7 @@ else tp->t_flags |= TF_ACKNOW; tp->rcv_nxt += tlen; - thflags = th->th_flags & TH_FIN; + thflags &= TH_FIN; TCPSTAT_INC(tcps_rcvpack); TCPSTAT_ADD(tcps_rcvbyte, tlen); ND6_HINT(tp); I wonder, though, why the code is as it is, i.e. why it takes the original FIN flag. Any idea? harti ___ 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"
TCP bug?
Hi all, one of my TCP test cases breaks in what one could call an edge case: When the TCP is in SYN-SENT state (the user has called connect()) and the peer answers with an almost-lamp test packet which has SYN, FIN, ACK and data larger than the window, TCP ACKs a window full of data, drops the rest, but processes the FIN - it goes into CLOSE_WAIT. This looks wrong to me. When dropping the data that is outside the window, it should also drop the FIN. The problem seems to be very old - I found it alread in rev. 1.1 of tcp_input.c. In -CURRENT it is on line 2590: when the sequence number of the incoming segment is the next expected one, the reassembly queue is empty and we are in an established state, the segment data is added to the socket buffer and all TCP header flags are cleared except for TH_FIN. Unfortunately here the original header flags are taken instead of the cached version in thflags. Earlier in the processing the out-of-window data and the FIN in thflags were chopped off and now TH_FIN reappears. The fix should be easy: instead of using the original flag byte to get the FIN use the cached copy. Index: tcp_input.c === --- tcp_input.c (revision 194499) +++ tcp_input.c (working copy) @@ -2587,7 +2587,7 @@ else tp->t_flags |= TF_ACKNOW; tp->rcv_nxt += tlen; - thflags = th->th_flags & TH_FIN; + thflags &= TH_FIN; TCPSTAT_INC(tcps_rcvpack); TCPSTAT_ADD(tcps_rcvbyte, tlen); ND6_HINT(tp); I wonder, though, why the code is as it is, i.e. why it takes the original FIN flag. Any idea? harti ___ 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 Free-BSD setup behaviour.
On Tue, 16 Jun 2009, Erik Trulsson wrote: ET>On Tue, Jun 16, 2009 at 04:37:32PM +0530, saravana perumal wrote: ET>> Hi Louie. ET>> ET>> As per Testing ET>> ET>> 1.Sending SYN and reaching the SYN_SENT state INTIALLY [Active open] ET>> 2. Then Expects to RECEIVE SYN packet and ET>> 3. To Send SYN & ACK to reach SYN-RCVD state. ET> ET>That does not sound quite correct. The normal sequence for the TCP ET>three-way handshake is: ET> ET>-> SYN ET><- SYN+ACK ET>-> ACK ET> ET>while you for some reason seem to be expecting ET> ET>-> SYN ET><- SYN ET>-> SYN+ACK ET> ET>which is not what I would expect. Wouldn't that be a correct simultaneous setup? harti ET> ET> ET>> ET>> In Free BSD active SYN-RCVD state is not happening . ET>> ET>> In TCP state tranistion my expectation is represented for SYN_RCVD state. ET>> ET>> ET>> Thanks. ET>> Saravanan ET>> ET>> ET>> --- On Tue, 6/16/09, saravana perumal wrote: ET>> ET>> ET>> From: saravana perumal ET>> Subject: Re: TCP Free-BSD setup behaviour. ET>> To: "Louis Mamakos" ET>> Cc: "FreeBSD Mailer List" ET>> Date: Tuesday, June 16, 2009, 3:15 PM ET>> ET>> ET>> ET>> ET>> ET>> ET>> ET>> Hi Louie ET>> ET>> We are trying to make Active Sync Received state. ET>> ET>> As per our testing we are trying to received Syn packet from APPLICATION end and to send syn & ACK from Device END and hence reaching the ACTIVE SYN-RECEIVED state. ET>> ET>> So initially make the application to send SYN sending the Initial SYN and once Received the SYN packet , expecting the Device to Send SYN & ACK ET>> ET>> I hope the expectation should be rite in case of ACTIVE-SYN received State. ET>> ET>> Thanks. ET>> Saravanan ET>> ET>> ET>> ET>> --- On Tue, 6/16/09, Louis Mamakos wrote: ET>> ET>> ET>> From: Louis Mamakos ET>> Subject: Re: TCP Free-BSD setup behaviour. ET>> To: "saravana perumal" ET>> Cc: freebsd-net@freebsd.org, sarba...@gmail.com ET>> Date: Tuesday, June 16, 2009, 3:05 AM ET>> ET>> ET>> ET>> On Jun 15, 2009, at 3:44 AM, saravana perumal wrote: ET>> ET>> > Hi Louie , ET>> > ET>> > ET>> > Thanks for the Response on my Queries. ET>> > ET>> > For QUERY 3, ET>> > ACTIVE open frm Free BSD end: ET>> > ET>> > FREE BSD APPLICATION ET>> > Send -> syn ET>> > Receive < SYN ET>> > ET>> > Expect SYN & ACK-> Getting only ACK in this Scenario, ET>> > ET>> > Now Expects FREE BSD to respond back with the SYN & ACK , but BSD is sending only ACK message as the response. ET>> ET>> There's no reason why the FreeBSD host would send another SYN; presumably the "APPLICATION" host received the SYN and responds back with SYN of it's own and ACK of the FreeBSD host's SYN. Once the SYN has been ACK'd, there's no reason to resend it. I suppose I wonder why you expect the FreeBSD system to retransmit it's SYN? ET>> ET>> > 4 .When checking the State - TIME-WAIT Sending FIN and expecting the ACK ;Getting the ACK properly. Sending Data Segment and Expecting the RST signal not getting the RST ; Instead DUT is sending the Last TCP packet. Issue seen only in Free BSD ET>> > ET>> > ET>> > For this Issue mentioned above, Last TCP packet is jst a Testing packet with the ET>> > following Field set in TIME-WAIT state , ET>> > ET>> > ET>> > TCP: TCP Packet ET>> > TCP: ET>> > TCP: Source Port = 16815 (16815) ET>> > TCP: Destination Port = 16816 (16816) ET>> > TCP: Sequence Number = 3865716731 (0xE66A27FB) ET>> > TCP: Acknowledgment Number = 0 (0x) ET>> > TCP: Data Offset = 5 (20 bytes) ET>> > TCP: Reserved = 0 ET>> > TCP: Control Bits = 0x10 ET>> > TCP: |543210 ET>> > TCP: |0. = Urgent Pointer Isn't Significant ET>> > TCP: |.1 = Acknowledgment Is Significant ET>> > TCP: |..0... = No Push Function ET>> > TCP: |...0.. = No Reset Connection ET>> > TCP: |0. = No Synchronize Sequence Numbers ET>> > TCP: |.0 = More Data From Sender ET>> > TCP: Window = 32752 bytes ET>> > TCP: Checksum = 0x41A0 (Correct) ET>> > TCP: Urgent Pointer = 0 (Not Significant) ET>> > TCP: ET>> > TCP: --- Trailing Data [12 bytes] --- ET>> > TCP: 53 61 6D 70 6C 65 20 44 61 74 61 00 Sample Data. ET>> > TCP: --- Trailing Data End --- ET>> > From machine Sending to the FREE BSD machine, ET>> > ET>> > This is to verify that Free BSD is in TIME-WAIT state. ET>> ET>> Not sure what good this packet trace is; the only reason the TCP would respond with a RST segment is if the segment it receives is somehow bogus. Perhaps that the send sequence is outside the window. If the data is within the window, it might be considered an "old" segment that happens to arrive, perhaps out-of-order; why would the local TCP reset the connection for no g
Re: bsnmpd + netsnmp & 64bits counters problem, bce interface problems maybe ?
On Fri, 29 May 2009, smallpox wrote: s>me: is it supposed to be sequential ? s>me: from low to high ? s>netsnmpguy: no, it's the difference between on poll period to the next The value of ifOutOctets is not the difference between poll periods but it is just the polled value of the octets that are sent. If you make sure that your poll period is short enough (bsnmpd tries to make this sure for the 64-bit counters by adjusting its own poll interval to the speed of the fastest network). Of course it will wrap, but that's the only time it can go down (except for discontinuities which happen if you restart the daemon or the OS). So if you have, for example, a gigabit interface, the output octet counter wraps at minimum every 35 seconds. If you poll every second you should see the counter going down not more than every 35 polls. So what are the values you are printing below? The differences between two polls or the poll values? harti s> s>he did admit that he doesn't monitor high speed networks so he can't be too s>sure. s> s>ifconfig bce0 -tso s> s>bce0: flags=8843 metric 0 mtu 1500 s> options=bb s> s> s> s>[10:13:21 5/29] IF-MIB::ifInOctets.1 /1 sec: 157715996 s>[10:13:21 5/29] IF-MIB::ifOutOctets.1 /1 sec: 161365331 s>[10:13:36 5/29] IF-MIB::ifInOctets.1 /1 sec: 181177076 s>[10:13:36 5/29] IF-MIB::ifOutOctets.1 /1 sec: 172743760 s>[10:13:51 5/29] IF-MIB::ifInOctets.1 /1 sec: 173974646 s>[10:13:51 5/29] IF-MIB::ifOutOctets.1 /1 sec: 179701472 s> s>and s> s>[10:21:06 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 189562690 s>[10:21:06 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 193086153 s>[10:21:21 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 162102286 s>[10:21:21 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 174412564 s>[10:21:36 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 163761580 s>[10:21:36 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 178587294 s> s>then i kill snmpd and launch bsnmpd.. and i know it's growing but probably s>just like everything else, it's not going to be at 90mbit already. s> s>[10:21:52 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 824582 s>[10:21:52 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 726172 s>[10:21:52 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 810400 s>[10:21:52 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 714542 s>[10:21:53 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 8073610 s>[10:21:53 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 8263915 s>[10:21:54 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 8950868 s>[10:21:54 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 10064090 s>[10:21:55 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 8734086 s>[10:21:55 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 9477418 s>[10:21:56 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 8764476 s>[10:21:56 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 9738831 s>[10:21:57 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 9398614 s>[10:21:57 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 9894332 s>[10:21:58 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 9497888 s>[10:21:58 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 10337890 s>[10:21:59 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 10057064 s>[10:21:59 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 10657596 s>[10:22:00 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 10379198 s>[10:22:00 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 11772401 s>[10:22:01 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 10863412 s>[10:22:01 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 12284506 s>[10:22:02 5/29] IF-MIB::ifHCInOctets.1 /1 sec: 10204962 s>[10:22:02 5/29] IF-MIB::ifHCOutOctets.1 /1 sec: 10745774 s> s> s>bsnmpd does it every second. s> s>also, as far as this " s>options=bb" s> s>jumbo is disabled on the switch. s> s>in comparison to another gigabit, (em0) on that switch. s>options=9b s> s>they're both at MTU 1500 though. s> s>thanks s> s>Harti Brandt wrote: s>> On Fri, 29 May 2009, smallpox wrote: s>> s>> s>well, from what im told by snmp people, it's what's happening at that s>> time, so s>> s>up and down is normal... but not at the rate that the non-working one is s>> s>going. and this one's upload and download are spread out normallly, 24 s>> mbit s>> s>out, 2mbit in... s>> s> s>> s>current figures on the messed up system: s>> s> s>> s>[07:25:32 5/29] IF-MIB::ifInOctets.1 /1 sec: 238914024 s>> s>[07:25:32 5/29] IF-MIB::ifOutOctets.1 /1 sec: 223977573 s>> s>[07:25:47 5/29] IF-MIB::ifInOctets.1 /1 sec: 235054494 s>> s>[07:25:47 5/29] IF-MIB::ifOutOctets.1 /1 sec: 222830449 s>> s> s>> s>one of the differences between bsnmpd and net-snmpd is net-snmpd updates s>> every s>> s>15 sec, anyway. see how the in/out are so close? that's totally off. s>> s> s>> s>the driver in question is bce... im not sure s>> s>>
Re: bsnmpd + netsnmp & 64bits counters problem, bce interface problems maybe ?
On Fri, 29 May 2009, smallpox wrote: s>well, from what im told by snmp people, it's what's happening at that time, so s>up and down is normal... but not at the rate that the non-working one is s>going. and this one's upload and download are spread out normallly, 24 mbit s>out, 2mbit in... s> s>current figures on the messed up system: s> s>[07:25:32 5/29] IF-MIB::ifInOctets.1 /1 sec: 238914024 s>[07:25:32 5/29] IF-MIB::ifOutOctets.1 /1 sec: 223977573 s>[07:25:47 5/29] IF-MIB::ifInOctets.1 /1 sec: 235054494 s>[07:25:47 5/29] IF-MIB::ifOutOctets.1 /1 sec: 222830449 s> s>one of the differences between bsnmpd and net-snmpd is net-snmpd updates every s>15 sec, anyway. see how the in/out are so close? that's totally off. s> s>the driver in question is bce... im not sure Hmm. Why would these numbers go up and down? As I understand it they should go up and wrap at either 32-bit or 64-bit. There are only two cases when they go down: a wrap or a discontinuity, which would be recorded in ifCounterDiscontinuityTime. Just to check: could you please disable TSO on the interface and look what it does? harti s>Harti Brandt wrote: s>> On Thu, 28 May 2009, smallpox wrote: s>> s>> s>hey guys, i've read s>> s> s>> s>> [SNIP] s>> s>> s> s>> s>in comparison to an intel em.. 32bit, it's linked at a gigabit though.. s>> but no s>> s>heavy traffic there. s>> s> s>> s>--BEGIN WORKING s>> s>IF-MIB::ifInOctets.1 /15 sec: 1932426 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 24270520 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2199107 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 28672350 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2049073 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 22716321 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2036279 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 24361972 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2571021 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 32539047 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2416155 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 30571680 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2583795 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 35712392 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2665891 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 34761228 s>> s>IF-MIB::ifInOctets.1 /15 sec: 2249559 s>> s>IF-MIB::ifOutOctets.1 /15 sec: 27438273 s>> s> s>> s>--END WORKING s>> s>> Do I get it wrong or do the 32-bit counters also go up and down? Given that s>> bsnmpd just retrieves the values from the kernel and sends them over SNMP s>> without looking at the values (for the 32-bit counters) this looks rather s>> like a problem in the kernel/driver. Do these drivers perhaps use multiple s>> threads for receiving? s>> s>> harti s>> s>> s> s> ___ 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: bsnmpd + netsnmp & 64bits counters problem, bce interface problems maybe ?
On Thu, 28 May 2009, smallpox wrote: s>hey guys, i've read s> [SNIP] s> s>in comparison to an intel em.. 32bit, it's linked at a gigabit though.. but no s>heavy traffic there. s> s>--BEGIN WORKING s>IF-MIB::ifInOctets.1 /15 sec: 1932426 s>IF-MIB::ifOutOctets.1 /15 sec: 24270520 s>IF-MIB::ifInOctets.1 /15 sec: 2199107 s>IF-MIB::ifOutOctets.1 /15 sec: 28672350 s>IF-MIB::ifInOctets.1 /15 sec: 2049073 s>IF-MIB::ifOutOctets.1 /15 sec: 22716321 s>IF-MIB::ifInOctets.1 /15 sec: 2036279 s>IF-MIB::ifOutOctets.1 /15 sec: 24361972 s>IF-MIB::ifInOctets.1 /15 sec: 2571021 s>IF-MIB::ifOutOctets.1 /15 sec: 32539047 s>IF-MIB::ifInOctets.1 /15 sec: 2416155 s>IF-MIB::ifOutOctets.1 /15 sec: 30571680 s>IF-MIB::ifInOctets.1 /15 sec: 2583795 s>IF-MIB::ifOutOctets.1 /15 sec: 35712392 s>IF-MIB::ifInOctets.1 /15 sec: 2665891 s>IF-MIB::ifOutOctets.1 /15 sec: 34761228 s>IF-MIB::ifInOctets.1 /15 sec: 2249559 s>IF-MIB::ifOutOctets.1 /15 sec: 27438273 s> s>--END WORKING Do I get it wrong or do the 32-bit counters also go up and down? Given that bsnmpd just retrieves the values from the kernel and sends them over SNMP without looking at the values (for the 32-bit counters) this looks rather like a problem in the kernel/driver. Do these drivers perhaps use multiple threads for receiving? harti ___ 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: bsnmp module for monitoring network flows: bsnmp-pcap
On Tue, 20 Jan 2009, Shteryana Shopova wrote:
SS>> SS>
SS>> SS>This is indeed interesting :)
SS>> SS>One thing to point out is that { begemot 206 } is already allocated
SS>> SS>for begemotVlan - and the two modules will conflict - you might want
SS>> SS>to contact harti for a free OID under begemot.
SS>>
SS>> Argh. Sorry. He contacted me and I messed probably up. I checked my
SS>> mailing archive whether I've allocated those oids, but did not find
SS>> anything.
SS>>
SS>
SS>Maybe check 10 Jul 2006?
Hmmm. A mail from you, but no OIDs there. Maybe I stuck it somewhere
else...
SS>> I probably missed something here. Any other conflicts? Can we move
bsnmp-pcap
SS>> to 207? And does bsnmp-jails conflict with something?
SS>>
SS>
SS>begemot.205 BRIDGE
SS>begemot.206 VLAN
Ok. I've added these now and committed the file.
SS>> Perhaps I should put this list somewhere more public.
SS>>
SS>
SS>Hmm, I thought src/contrib/bsnmp/oid-list served the purpose - I guess
SS>keeping that list up-to-date in CVS/SVN is the best thing to do :))
Yeah, well. I was hoping to move the bsnmp repo to the FreeBSD servers,
but I want my own revision number space... No luck so far.
harti
___
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: bsnmp module for monitoring network flows: bsnmp-pcap
On Tue, 20 Jan 2009, Shteryana Shopova wrote:
SS>Hi,
SS>
SS>On Tue, Jan 20, 2009 at 3:20 AM, Stef wrote:
SS>> Figured this may be interesting for folks...
SS>>
SS>> I've released a bsnmp module which can monitor arbitrary traffic flows
SS>> and expose them as SNMP counters.
SS>>
SS>
SS>This is indeed interesting :)
SS>One thing to point out is that { begemot 206 } is already allocated
SS>for begemotVlan - and the two modules will conflict - you might want
SS>to contact harti for a free OID under begemot.
Argh. Sorry. He contacted me and I messed probably up. I checked my
mailing archive whether I've allocated those oids, but did not find
anything.
My actual oid-list file is
$Begemot: trunk/oid-list 440 2009-01-18 14:51:55Z brandt_h $
enterprises
12325 FOKUS
1 BEGEMOT
1 BEGEMOT-SNMPD
2 BEGEMOT-NETGRAPHsnmpd netgraph module
3 BEGEMOT-IP snmpd IP related stuff.
100 BEGEMOT-ILMID snmpd ILMID module
101 BEGEMOT-ATM snmpd ATM module
200 BEGEMOT-PF snmpd PF module (phil...@freebsd.org)
201 BEGEMOT-NTP snmpd NTP module
202 BEGEMOT-HOSTRES snmpd HOSTRES module private stuff
203 regexData bsnmp-regex (Nate Nielsen
)
204 pingDatabsnmp-ping (Nate Nielsen
)
205 bsnmp-jails per jail networking, cpu, disk, memory
statistics
206 bsnmp-pcap monitor traffic for specific network
flows
300 BEGEMOT-ACM DLR ACM project
405 mysql (vani...@fatpipi.com)
406 varnish (vani...@fatpipi.com)
I probably missed something here. Any other conflicts? Can we move bsnmp-pcap
to 207? And does bsnmp-jails conflict with something?
Perhaps I should put this list somewhere more public.
harti
SS>cheers,
SS>Shteryana
SS>
SS>> FreeBSD port attached, more info here:
SS>>
SS>> http://memberwebs.com/stef/software/bsnmp-pcap/
SS>>
SS>> Cheers,
SS>>
SS>> Stef Walter
SS>>
SS>> ___
SS>> freebsd-net@freebsd.org mailing list
SS>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
SS>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
SS>>
SS>___
SS>freebsd-net@freebsd.org mailing list
SS>http://lists.freebsd.org/mailman/listinfo/freebsd-net
SS>To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
SS>
SS>
___
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: bsnmpd & 64bits counters problem
On Tue, 16 Dec 2008, Bruce Simpson wrote: BS>Harti Brandt wrote: BS>> The highspeed counters are only there if this is a high-speed interface. BS>> High speed means that the baudrate in the interface MIB (the one in the BS>> kernel) must be larger than 20Mbaud. BS>> BS> BS>Does it look at the if_baudrate member? BS> BS>em(4) and other drivers will set if_baudrate according to the speed detected BS>from Ethernet link beat, this could be creating a situation where bsnmpd is BS>not exposing the high-speed counters at runtime? BS> BS>I imagine this could really confuse an SNMP-oriented Network Management BS>System such as Nagios or OpenNMS. Yes, it looks at ifi_baudrate. The reason is that the HC counters are mandatory only for interfaces with > 20MBit/second according to the compliance statememnt of the MIB. The HC counters come add additional cost, because the daemon has to poll the kernel's 32 bit counters and detect wrap arounds. So the daemon adapts dynamically based on the interface with the highest speed. And in any case, network management tools must be prepared to handle both cases. See also RFC2233: For interfaces that operate at 20,000,000 (20 million) bits per second or less, 32-bit byte and packet counters MUST be used. harti ___ 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: bsnmpd & 64bits counters problem
On Tue, 16 Dec 2008, Sergey Matveychuk wrote: SM>Harti Brandt wrote: SM>> On Tue, 16 Dec 2008, Sergey Matveychuk wrote: SM>> SM>> SM>Hello. SM>> SM> SM>> SM>Some weird thing has happened with 64bit counters: SM>> SM> SM>> SM>% snmpwalk -v2c -cpublic localhost ifInOctets SM>> SM>IF-MIB::ifInOctets.1 = Counter32: 4107815474 SM>> SM>... SM>> SM>IF-MIB::ifInOctets.16 = Counter32: 2894713654 SM>> SM> SM>> SM>% snmpwalk -v2c -cpublic localhost ifHCInOctets SM>> SM>IF-MIB::ifHCInOctets.1 = Counter64: 7911064279758 SM>> SM>... SM>> SM>IF-MIB::ifHCInOctets.4 = Counter64: 13143091216588 SM>> SM> SM>> SM>There are all 16 32bits counters but only 4 64bits. That's less than SM>> physical SM>> SM>interfaces on this router (em0-em5). SM>> SM> SM>> SM>7.1-PRERELEASE SM>> SM>> The highspeed counters are only there if this is a high-speed interface. SM>> High speed means that the baudrate in the interface MIB (the one in the SM>> kernel) must be larger than 20Mbaud. SM> SM>Well, these is lagg interfaces: SM>lagg0: flags=8843 metric 0 mtu 9000 SM>options=19b SM>ether 00:30:48:67:d4:68 SM>media: Ethernet autoselect SM>status: active SM>laggproto lacp SM>laggport: em2 flags=1c SM>laggport: em0 flags=1c SM> SM>There is no baudrate on them. But they are really high-speed however. All interfaces have a baudrate. Its in net/if.h ifi_baudrate. We had the problem in the past with other interface types. 'virtual' interfaces must take care to somehow propagate the rate of the underlying physical interfaces up to the virtual one. harti ___ 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: bsnmpd & 64bits counters problem
On Tue, 16 Dec 2008, Sergey Matveychuk wrote: SM>Hello. SM> SM>Some weird thing has happened with 64bit counters: SM> SM>% snmpwalk -v2c -cpublic localhost ifInOctets SM>IF-MIB::ifInOctets.1 = Counter32: 4107815474 SM>... SM>IF-MIB::ifInOctets.16 = Counter32: 2894713654 SM> SM>% snmpwalk -v2c -cpublic localhost ifHCInOctets SM>IF-MIB::ifHCInOctets.1 = Counter64: 7911064279758 SM>... SM>IF-MIB::ifHCInOctets.4 = Counter64: 13143091216588 SM> SM>There are all 16 32bits counters but only 4 64bits. That's less than physical SM>interfaces on this router (em0-em5). SM> SM>7.1-PRERELEASE The highspeed counters are only there if this is a high-speed interface. High speed means that the baudrate in the interface MIB (the one in the kernel) must be larger than 20Mbaud. harti ___ 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 and syncache question
Hi Andre,
On Mon, 17 Nov 2008, Andre Oppermann wrote:
AO>This is a bit more complicated because of interactions with tcp_input()
AO>where syncache_expand() is called from.
AO>
AO>The old code (as of December 2002) behaved slightly different. It would
AO>not remove the syncache entry when (SND.UNA == SEG.ACK) but send a RST.
AO>The (RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND) test wasn't done at
AO>all. Instead a socket was opened whenever (SND.UNA == SEG.ACK) succeeded.
AO>This gave way to the "LAND" DoS attack which was mostly fixed with a test
AO>for (RCV.IRS < SEG.SEQ).
AO>
AO>See the attached patch for fixed version of syncache_expand(). This patch
AO>is untested though. My development machine is currently down. Harti, Rui
AO>and Bjoern, please have a look at the patch and review it.
Some small problems:
AO>--- tcp_input.c.1.390Mon Nov 17 21:33:25 2008
AO>+++ tcp_input.c.1.390.modMon Nov 17 21:35:22 2008
AO>@@ -642,10 +642,13 @@ findpcb:
AO> if (!syncache_expand(&inc, &to, th, &so, m)) {
AO> /*
AO> * No syncache entry or ACK was not
AO>- * for our SYN/ACK. Send a RST.
AO>+ * for our SYN/ACK. Send a RST or
AO>+ * an ACK for re-synchronization.
AO> * NB: syncache did its own logging
AO> * of the failure cause.
AO> */
AO>+if (so == 1)
Need a cast here: if (so == (struct socket *)1)
AO>+goto dropunlock;
AO> rstreason = BANDLIM_RST_OPENPORT;
AO> goto dropwithreset;
AO> }
AO>--- tcp_syncache.c.1.160 Mon Nov 17 16:49:01 2008
AO>+++ tcp_syncache.c.1.160.mod Mon Nov 17 23:35:39 2008
AO>@@ -817,59 +817,47 @@ syncache_expand(struct in_conninfo *inc,
AO> INP_INFO_WLOCK_ASSERT(&V_tcbinfo);
AO> KASSERT((th->th_flags & (TH_RST|TH_ACK|TH_SYN)) == TH_ACK,
AO> ("%s: can handle only ACK", __func__));
AO>+*lsop = NULL;
This leads to a panic on sonewconn. *lsop points to the listening socket
when the function is entered and this socket is needed below in
syncache_socket(). I just removed this line.
AO>
AO> sc = syncache_lookup(inc, &sch);/* returns locked sch */
AO> SCH_LOCK_ASSERT(sch);
AO> if (sc == NULL) {
AO> /*
AO> * There is no syncache entry, so see if this ACK is
AO>- * a returning syncookie. To do this, first:
AO>- * A. See if this socket has had a syncache entry dropped in
AO>- * the past. We don't want to accept a bogus syncookie
AO>- * if we've never received a SYN.
AO>- * B. check that the syncookie is valid. If it is, then
AO>- * cobble up a fake syncache entry, and return.
AO>+ * a returning syncookie. If the syncookie is valid,
AO>+ * cobble up a fake syncache entry and create a socket.
AO>+ *
AO>+ * NB: Syncache head is locked for the syncookie access.
AO> */
AO> if (!tcp_syncookies) {
AO>-SCH_UNLOCK(sch);
AO> if ((s = tcp_log_addrs(inc, th, NULL, NULL)))
AO> log(LOG_DEBUG, "%s; %s: Spurious ACK, "
AO> "segment rejected (syncookies disabled)\n",
AO> s, __func__);
AO>-goto failed;
AO>+goto sendrst;
AO> }
AO> bzero(&scs, sizeof(scs));
AO> sc = syncookie_lookup(inc, sch, &scs, to, th, *lsop);
AO>-SCH_UNLOCK(sch);
AO> if (sc == NULL) {
AO> if ((s = tcp_log_addrs(inc, th, NULL, NULL)))
AO> log(LOG_DEBUG, "%s; %s: Segment failed "
AO> "SYNCOOKIE authentication, segment rejected
"
AO> "(probably spoofed)\n", s, __func__);
AO>-goto failed;
AO>+goto sendrst;
AO> }
AO>-} else {
AO>-/* Pull out the entry to unlock the bucket row. */
AO>-TAILQ_REMOVE(&sch->sch_bucket, sc, sc_hash);
AO>-sch->sch_length--;
AO>-V_tcp_syncache.cache_count--;
AO>-SCH_UNLOCK(sch);
AO>+goto expand;/* fully validated through syncookie */
AO> }
AO>+SCH_LOCK_ASSERT(sch);
AO>
AO> /*
AO> * Segment validation:
AO>- * ACK must match our initial sequence number + 1 (the SYN|ACK).
AO>- */
AO>-if (th->th_ack != sc->sc_iss + 1 && !TOEPCB_ISSET(sc)) {
AO>-if ((s = tcp_log_addrs(inc, th, NULL, NULL)))
AO>-log(LOG_DEBUG, "%s; %s: ACK %u != ISS+1 %u, segment "
AO>-
Re: TDMA / Interrupts / Pre-emptible
On Fri, 7 Dec 2007, Bruce M. Simpson wrote: BMS>I can't comment on kernel scheduler jitter though, so someone who is working BMS>directly in that area will hopefully respond -- arch@ or hackers@ might be a BMS>better place to field that question. BMS> BMS>I believe microsecond resolution for your app should be possible in the BMS>kernel. If it isn't, I'd like to know why. [It would be really, really nice BMS>to have better real-time support in FreeBSD, i.e. a deadline scheduler.] A couple of years I did exactly the same as the OP - implementing a satellite MAC layer (FM-TDMA) on a cluster of 5 FreeBSD machines. I think it was the time when we moved from 4.X to 5.0 or 5.1. I could not get it reliable because the jitter in the kernel (I implemented everything in netgraph over ethernet) was in the order of several 100 usec. I had HZ at 1 (all my simulation machines run on that). I tried really hard to find out where these jitters came from, but failed. Trying to trace the timing of execution changed the figures completely each time. Finally I gave up, because the project luckily ended :-/ At one point I tried to bump HZ to 2 or so, but at this point TCP broke. I think this might have come from the RTT computation which is/was done in ticks and the square of something would overflow the variable. One must also carefully choose the ethernet adapter for this kind of things, because it may add any kind of jitter/delay. At that time the best where the DEC/intel if_dc types. Of course with the actual kernel the situation may be quite different. Don't know what influence have interrupt threads and this stuff. I would be interested to hear how things work out and, yeah, better real-time support would be great :-) Regards, harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
TCP conformance question
Hi, I was browsing through our TCP implementation and found the following: according to RFC 793 if a segment with length 0 is received its sequence number must hold: RCV.NXT <= SEG.SEQ < RCV.NXT + RCV.WND. That is, the sequence number must be within the window. Otherwise the segment is not acceptable and an ACK must be sent (see table on p. 69 of the RFC). This is meant to re-synchronize the TCPs. Our TCP responds with an ACK for all sequence numbers outside the window, except for SEG.SEQ == RCV.NXT + RCV.WND. I've no idea whether this can be a problem in bizarre loss situations or not. In any case it would be interesting to know whether this was done on purpose, or is just an implementation effect. The BSD code in 'TCP/IP Illustrated' has the same 'problem' so I suppose that behaviour is rather old. Has anybody insight into this effect? harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Disable Exponential Backoff (retry) on Ethernet?
On Sat, 20 Oct 2007, Peter Jeremy wrote: PJ>On Wed, Oct 17, 2007 at 08:51:34PM -0700, Len Gross wrote: PJ>>I'm doing some protocol development and it is convenient to start it on PJ>>Ethernet. I will need to send a packet to the Ethernet device and only have PJ>>it be sent once, even if there is a colision. PJ> PJ>I know we've still got some hubs lying around in a backroom at work PJ>but I don't know of anything that will let you disable the retry-on-CD. PJ> PJ>Have you considered simulating the network at a slightly higher lever: PJ>Use ipfw pipes or similar to simulate packet loss (either set a queue PJ>length of 1 or probabilistically). This could be done either as a PJ>bridge or by tunneling your protocol over IP or UDP. Some years ago I wrote a netgraph node that connected to ethernet nodes and simulated a wireless broadcast channel including collisions, timevariable delay, loss and shaping. Can be done in a couple of hundreds of lines and easily allows >100MBit/sec with gigabit ethernet. The ethernet is just the physical transport medium for the packets and does not take part in the emulation. All that was controlled by bsnmpd and a remote command line tool and/or Java-GUI. Unfortunately I cannot release this (yet) due to licensing... harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/110720: [net] [patch] support for interface descriptions
Nice feature, although it would be nice to align the maximum length with IF-MIB::ifDescr (255 byte + \0). Also I suppose that the field more naturally fits into struct if_data (see net/if.h) given the comment for that struct: /* * Structure describing information about an interface * which may be of interest to management entities. */ harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: a MIB for a SNMP vlan monitoring module
Hi, On Tue, 9 Jan 2007, Shteryana Shopova wrote: SS>Work is about to start on a vlan monitoring module for bsnmpd(1) - I'm SS>attaching the private BEGEMOT MIB that the module will implement. Any SS>comments or suggestions are very welcome. I'm not an expert on the VLAN stuff, so I cannot comment on this. The only thing I see is that you might add a ...DiscontinuityTime variable to the statistics table so that a managemnt station can correctly catch fast destroy/create cycles on the VLANs (if that makes sense). You might want to look at ifCounterDiscontinuityTime in ifMIB:ifXTable. harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD NFS Client, Windows 2003 NFS server
On Thu, 7 Dec 2006, Harti Brandt wrote: HB>On Thu, 7 Dec 2006, M. Warner Losh wrote: HB> HB>MWL>In message: <[EMAIL PROTECTED]> HB>MWL>Harti Brandt <[EMAIL PROTECTED]> writes: HB>MWL>: MWL>Does anybody have experience with using FreeBSD 4.x or 6.x NFS clients HB>MWL>: MWL>against a Windows 2003 NFS server? What is the performance relative HB>MWL>: MWL>to using a FreeBSD NFS server? What is the stability? Does locking HB>MWL>: MWL>work? Does the Windows 2003 server have extensions that grok file HB>MWL>: MWL>system flags? HB>MWL>: HB>MWL>: I use this regularily (well, -CURRENT). I have no numbers, but performance HB>MWL>: is ok. I have the home directories on a W2003k server and it 'feels' fast HB>MWL>: enough. HB>MWL> HB>MWL>We see FreeBSD to FreeBSD NFS feeling fast enough for most things, but HB>MWL>when we do a full build of our system from scratch it takes 10 hours HB>MWL>over NFS vs 1 hour on a local disk. We're worried that if we were to HB>MWL>try to do heavy NFS traffic to a Win2003 server with SFU this would be HB>MWL>even slower. HB> HB>Ok. I did a very short test (no time to do much more). Read performance HB>with dd if=/nfs/bigfile of=/dev/null bs=4k is around 9MByte/sec. Write HB>performance with dd if=/dev/zero of=/nfs/bigfile bs=4k is 4MByte/sec. HB> HB>Client is something around 1GHz with a 100Mbps link. Fileserver is a HB>double proc Xeon with a 1Gbps link. The Server has a load of around 30% HB>(from the antivirus scanner). HB> HB>72Mbps on a 100Mbps link looks actually ok for me. I've no FreeBSD on a HB>Gigabit link to test with. HB> HB>If you want I could try to do a buildworld. Ok. To answer my own mail. A buildworld with a local /usr/src takes 2:50h on that machine, with /usr/src on the W2003 server 3:50h. Looks not that bad. harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD NFS Client, Windows 2003 NFS server
On Thu, 7 Dec 2006, M. Warner Losh wrote: MWL>In message: <[EMAIL PROTECTED]> MWL> Harti Brandt <[EMAIL PROTECTED]> writes: MWL>: MWL>Does anybody have experience with using FreeBSD 4.x or 6.x NFS clients MWL>: MWL>against a Windows 2003 NFS server? What is the performance relative MWL>: MWL>to using a FreeBSD NFS server? What is the stability? Does locking MWL>: MWL>work? Does the Windows 2003 server have extensions that grok file MWL>: MWL>system flags? MWL>: MWL>: I use this regularily (well, -CURRENT). I have no numbers, but performance MWL>: is ok. I have the home directories on a W2003k server and it 'feels' fast MWL>: enough. MWL> MWL>We see FreeBSD to FreeBSD NFS feeling fast enough for most things, but MWL>when we do a full build of our system from scratch it takes 10 hours MWL>over NFS vs 1 hour on a local disk. We're worried that if we were to MWL>try to do heavy NFS traffic to a Win2003 server with SFU this would be MWL>even slower. Ok. I did a very short test (no time to do much more). Read performance with dd if=/nfs/bigfile of=/dev/null bs=4k is around 9MByte/sec. Write performance with dd if=/dev/zero of=/nfs/bigfile bs=4k is 4MByte/sec. Client is something around 1GHz with a 100Mbps link. Fileserver is a double proc Xeon with a 1Gbps link. The Server has a load of around 30% (from the antivirus scanner). 72Mbps on a 100Mbps link looks actually ok for me. I've no FreeBSD on a Gigabit link to test with. If you want I could try to do a buildworld. MWL>: The only problem I see is a lot of 'file server not reponding' and 'file MWL>: server up again' (with 2-3 seconds in between). This is usually when MWL>: saving a large mail from pine. Linux clients see the same problem, so I MWL>: suppose it is a problem on the SFU side. MWL> MWL>So building large binaries might be a problem? Hmm. I just discovered, that these messages are gone since approx. two weeks. No idea why! MWL> MWL>: Locking seems to work. MWL> MWL>Does "seems to work" mean it really does work, or does SFU just do the MWL>old trick of saying 'ok, your lock worked'? I just did the following test: tty0 # lockf /nfs/foo sleep 100 tty1 # lockf /nfs/foo sh -c 'while true ; do echo -n '.' ; sleep 1 ; done' When I interrupt the lockf on tty0 with ^C, the process on tty1 starts to print dots. So I suppose it actually works. MWL> MWL>: Problems MWL>: are with filenames that are illegal for NTFS - hosting a 2.11BSD source MWL>: tree on a W2003 NFS share does not work because of filenames containing MWL>: ':' :-). I've not tested what other characters are illegal. MWL> MWL>That would be a problem for hosting a ports tree on the NTFS nfs MWL>partition, no? I suppose so. Interestinly enough the SFU documentation says, that these file names are actually allowed, so this seems like a bug. MWL>: Another problem is that on the NTFS side there is no good way to backup, MWL>: copy, whatever the trees, because while NTFS handles Makefile and MWL>: makefile, no Windows tool can access both of them. Even worse thinks like MWL>: ADSM backup sometimes die with internal errors. MWL> MWL>That's ugly. Yes. While NTFS can handle lower/uppercase, the access layer between NTFS and applications make 'a'=='A'. My plan here is to mount the NFS share on a UNIX host and make the backups from there. MWL>: Mapping of UIDs and GIDs is rather magic. The FreeBSD side, the SFU tools MWL>: and cygwin all see different numbers which is rather annoying. The same is MWL>: with symbolic links. MWL> MWL>Symblic links point elsewhere? or have different destinations? Does MWL>it matter absolute or relative? NTFS has no symbolic links, so they are implemented above in the application layer (SFU or the cygwin libraries). Obviously everybody implements them differently. So if you create a symbolic link on the NFS share. Then cygwin on the server just sees a short data file. MWL>: The file flags are not supported by the server. There are no extensions MWL>: that I know of. MWL> MWL>Same problem with FreeBSD to FreeBSD NFS. harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD NFS Client, Windows 2003 NFS server
Hi Warner, On Wed, 6 Dec 2006, M. Warner Losh wrote: MWL>Does anybody have experience with using FreeBSD 4.x or 6.x NFS clients MWL>against a Windows 2003 NFS server? What is the performance relative MWL>to using a FreeBSD NFS server? What is the stability? Does locking MWL>work? Does the Windows 2003 server have extensions that grok file MWL>system flags? I use this regularily (well, -CURRENT). I have no numbers, but performance is ok. I have the home directories on a W2003k server and it 'feels' fast enough. The only problem I see is a lot of 'file server not reponding' and 'file server up again' (with 2-3 seconds in between). This is usually when saving a large mail from pine. Linux clients see the same problem, so I suppose it is a problem on the SFU side. Locking seems to work. Problems are with filenames that are illegal for NTFS - hosting a 2.11BSD source tree on a W2003 NFS share does not work because of filenames containing ':' :-). I've not tested what other characters are illegal. Another problem is that on the NTFS side there is no good way to backup, copy, whatever the trees, because while NTFS handles Makefile and makefile, no Windows tool can access both of them. Even worse thinks like ADSM backup sometimes die with internal errors. Mapping of UIDs and GIDs is rather magic. The FreeBSD side, the SFU tools and cygwin all see different numbers which is rather annoying. The same is with symbolic links. The file flags are not supported by the server. There are no extensions that I know of. harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: paket loss on freebsd router if (b)snmpd is running##SPAM
On Fri, 27 Oct 2006, Thomas wrote: T>Hello Harti T> T>Harti Brandt schrieb: T>> On Fri, 27 Oct 2006, Thomas wrote: T>> T>> T>Hello T>> T> T>> T>I use several 5.4 and 6.1 FBSD machines as router (with quagga). The T>> T>average traffic is 300mbit/s (em interfaces with polling enabled). It T>> T>works more or less. T>> T> T>> T>Problem: T>> T>If bsnmpd is running and I'm doing a snmpwalk from a remote machine the T>> T>router has some significant packet loss. We are talking about 3-15% of T>> T>packet loss. It's a simple snmpwalk (ipRouteTable and the interfaces stats). T>> T>> Does this happen also if you walk only the interface tables? What size is T>> your routing table? T> T>The routing table has approx. 200k entries. I've to correct my T>statement. I don't walk over the RoutingTable. Oh. That would be a nice test how good the RB-tree implementation of the routing table is :-) T>It's only an interface table walk (IF-MIB). bsnmpd consumes approx. T>6-10% cpu. I already have significant packet loss if bsnmpd is started. T> T>bsnmpd not running: T> T>ping www.switch.ch T> T>--- oreius.switch.ch ping statistics --- T>44 packets transmitted, 44 packets received, 0% packet loss T>round-trip min/avg/max/stddev = 6.825/7.425/8.007/0.252 ms T> T>zero packet loss. T> T> T>netstat -w 1 shows no error. T> T>input(Total) output T> packets errs bytespackets errs bytes colls T> 39877 0 34330807 38614 0 34087518 0 T> 45522 0 38730142 44124 0 38424881 0 T> 44671 0 38783909 43455 0 38604698 0 T> 43140 0 36939542 42059 0 36691583 0 T> 43428 0 36858817 42213 0 36700954 0 T> 43748 0 37994949 42687 0 37780190 0 T> 42698 0 36451927 41409 0 36270936 0 T> 38695 0 32184588 37119 0 31791417 0 T> T> T> T> T>bsnmpd started: T> T>ping www.switch.ch T>--- oreius.switch.ch ping statistics --- T>57 packets transmitted, 53 packets received, 7% packet loss T>round-trip min/avg/max/stddev = 6.715/12.638/95.183/19.041 ms T> T>7% packet loss. T> T> T>netstat shows some errors too. T>netstat -w 1 T>input(Total) output T> packets errs bytespackets errs bytes colls T> 33597 0 27508009 32433 0 27344720 0 T> 38204 0 32117848 36950 0 31852251 0 T> 39171 0 33870984 37999 0 33696346 0 T> 32160 0 26825650 31065 0 26591079 0 T> 26915 726 20902878 25771 0 20791170 0 T> 35167 0 29173014 33945 0 28904867 0 T> 33282 370 27478393 32140 0 27297079 0 T> 29738 0 23859586 28464 0 23524984 0 T> 38456 598 31559055 36881 0 31313396 0 T> 34738 0 28088584 33247 0 27743827 0 T> 38193 648 30854513 36657 0 30556948 0 T> T> T>A snmpwalk makes it a bit worse but not much. I already have packet loss T>if bsnmpd is just started without any walks. You mean, you have loss if it is just ideling around? The only thing bsnmpd does in this situation is polling the interface statistics, which is needed because the kernel has only 32-bit counters. Could you please check what the polling interval is? You find this in the BEGEMOT-MIB2-MIB. Something like snmpwalk ... begemotMib2 given that /usr/share/snmp/mibs is in your MIB path. harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: paket loss on freebsd router if (b)snmpd is running##SPAM
On Fri, 27 Oct 2006, Thomas wrote: T>Hello T> T>I use several 5.4 and 6.1 FBSD machines as router (with quagga). The T>average traffic is 300mbit/s (em interfaces with polling enabled). It T>works more or less. T> T>Problem: T>If bsnmpd is running and I'm doing a snmpwalk from a remote machine the T>router has some significant packet loss. We are talking about 3-15% of T>packet loss. It's a simple snmpwalk (ipRouteTable and the interfaces stats). Does this happen also if you walk only the interface tables? What size is your routing table? harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Instructing dhclient to set hostname of client
On Mon, 23 Oct 2006, Joe Holden wrote: JH>Andrey V. Elsukov wrote: JH>> Doug Barton wrote: JH>>> If you're talking about a laptop where you're not sure what the DHCP JH>>> server is going to send you, then I have this in /etc/rc.local: JH>> JH>> Hi, Doug. JH>> JH>> What you think about adding a new feature to dhclient - Alternate IP JH>> Configuration. This configuration can be specified in dhclient.conf JH>> and take effect when a DHCP server not respond. MS Windows have a JH>> similar feature. JH>> JH>Really I was hoping dhclient would have this sort of functionality where JH>it would resolve the ip given and set that as hostname, as as far as im JH>aware, isc-dhcpd will not send hostnames? Sure it does. On my machines I set hostname to "" in rc.conf and let dhclient set it. Works fine. harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/net if_vlan.c
On Tue, 4 Jul 2006, Brooks Davis wrote: BD>On Tue, Jul 04, 2006 at 09:02:32PM +0200, Harti Brandt wrote: BD>> On Tue, 4 Jul 2006, Julian Elischer wrote: BD>> BD>> JE>Harti Brandt wrote: BD>> JE> BD>> JE>> On Tue, 4 Jul 2006, Brooks Davis wrote: BD>> JE>> BD>> JE>> BD>On Tue, Jul 04, 2006 at 10:25:39AM -0600, M. Warner Losh wrote: BD>> JE>> BD>> In message: <[EMAIL PROTECTED]> BD>> JE>> BD>> Brooks Davis <[EMAIL PROTECTED]> writes: BD>> JE>> BD>> : and act as though the interface is not there. We could then BD>> JE>> consider BD>> JE>> BD>> : either holding the interface for a configurable or computed length BD>> JE>> BD>> : of time or adding some sort of refcounting (probably impractical). BD>> JE>> BD>> BD>> Refcounting would be good for the 'macro' things (coming and BD>> JE>> going) BD>> JE>> BD>> that are infrequent, but we might have mulitple people doing. You are BD>> JE>> BD>> right it likely is too inefficient to do with mbugs. One other option BD>> JE>> BD>> might be to have a configurable time after the last time that it was BD>> JE>> BD>> accessed via the 'safe' routines that were setup. This way we'd tie BD>> JE>> BD>> the removal of the interface to a period of time after it was last BD>> JE>> BD>> used, rather than after it was removed. I don't know if such a BD>> JE>> BD>> difference would matter much in practice. BD>> JE>> BD> BD>> JE>> BD>We might get some mielage out of last used, but then we'd have to keep BD>> JE>> BD>that timestamp updated. For normal applications, once we've torn down BD>> JE>> BD>the sockets and drained their queues, I believe we should not have to BD>> JE>> BD>wait more than a few seconds unless dummynet or some other mechanism BD>> JE>> BD>that queues mbufs for a significant period of time is enabled. If BD>> JE>> BD>dummynet is enabled we need to wait a bit longer, but it isn't outside BD>> JE>> BD>the relm of possibility for dummynet to be modified to tell us how long BD>> JE>> BD>it will be until the last mbuf it currenly holds will be released. In BD>> JE>> BD>practice, 121 seconds is probably a good default number since a 60 BD>> JE>> BD>second max RTT is assumed in TCP and thus delays longer than that BD>> JE>> BD>would break everything anyway. BD>> JE>> BD> BD>> JE>> BD>> The only other 'issue' that I see with this approach is if I remove a BD>> JE>> BD>> card, and then insert it again before the timeout happens. Does that BD>> JE>> BD>> card get a new interface name? And would people care or not... BD>> JE>> BD> BD>> JE>> BD>The name is unregistered with the call to if_detach because if_detach BD>> JE>> BD>removes the interface from the ifnet list. My guess is that BD>> JE>> BD>we'll either zero the name field or set to something like _zombie. The BD>> JE>> BD>unit will remain reserved until later. We'll need to add an SNMP index BD>> JE>> BD>mananaged in userland to satisfy come current if_index consumers. BD>> JE>> BD>> JE>> bsnmp does this anyway because of the rules for ifIndex. It has some BD>> JE>> heuristic to guess whether an interface is a physical one or not and if it BD>> JE>> is, it uses the same index again. The downside of this is that the BD>> JE>> interface index you see via SNMP has nothing to do with the interface index BD>> JE>> you see in the system and this does not work accross reboots and daemon BD>> JE>> restarts as required by the RFC. BD>> JE> BD>> JE>If we had a way to to this in the system (e.g. kept the mac address BD>> JE>with the ifnum in a hash) then we could just keep the ifnum in the mbuf BD>> JE>instead of the ifp pointer, as that is only occasionally used, and a BD>> JE>ifnum2ipf() macro could check the validity wheheve it is used. BD>> BD>> This would be helpful for the SNMP daemon, because this would also allow BD>> to reuse the ifnum if the same interface is plugged in back. However care BD>> must be taken that non-physical interfaces get a new ifnum always (iftun BD>> for example). BD> BD>This belongs in userland. It's too complex to handle in the kernel. We BD>probably need to store the index in the kernel as a rondivues point, BD>but the actual decision on deciding which interfaces are the "same" and BD>which are "different" as defined by the SNMP spec is too difficult and BD>has too many edge cases to try to do in the kernel. I think the right BD>answer is a daemon (or devd triggered script) that sets the SNMP index BD>based on a database containing previous lladdrs and units. That's probably true and that's what bsnmp is doing, although a hint from the kernel whether the interface is a physical one or not could be very helpful (the driver should know). harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/net if_vlan.c
On Tue, 4 Jul 2006, Julian Elischer wrote: JE>Harti Brandt wrote: JE> JE>> On Tue, 4 Jul 2006, Brooks Davis wrote: JE>> JE>> BD>On Tue, Jul 04, 2006 at 10:25:39AM -0600, M. Warner Losh wrote: JE>> BD>> In message: <[EMAIL PROTECTED]> JE>> BD>> Brooks Davis <[EMAIL PROTECTED]> writes: JE>> BD>> : and act as though the interface is not there. We could then JE>> consider JE>> BD>> : either holding the interface for a configurable or computed length JE>> BD>> : of time or adding some sort of refcounting (probably impractical). JE>> BD>> BD>> Refcounting would be good for the 'macro' things (coming and JE>> going) JE>> BD>> that are infrequent, but we might have mulitple people doing. You are JE>> BD>> right it likely is too inefficient to do with mbugs. One other option JE>> BD>> might be to have a configurable time after the last time that it was JE>> BD>> accessed via the 'safe' routines that were setup. This way we'd tie JE>> BD>> the removal of the interface to a period of time after it was last JE>> BD>> used, rather than after it was removed. I don't know if such a JE>> BD>> difference would matter much in practice. JE>> BD> JE>> BD>We might get some mielage out of last used, but then we'd have to keep JE>> BD>that timestamp updated. For normal applications, once we've torn down JE>> BD>the sockets and drained their queues, I believe we should not have to JE>> BD>wait more than a few seconds unless dummynet or some other mechanism JE>> BD>that queues mbufs for a significant period of time is enabled. If JE>> BD>dummynet is enabled we need to wait a bit longer, but it isn't outside JE>> BD>the relm of possibility for dummynet to be modified to tell us how long JE>> BD>it will be until the last mbuf it currenly holds will be released. In JE>> BD>practice, 121 seconds is probably a good default number since a 60 JE>> BD>second max RTT is assumed in TCP and thus delays longer than that JE>> BD>would break everything anyway. JE>> BD> JE>> BD>> The only other 'issue' that I see with this approach is if I remove a JE>> BD>> card, and then insert it again before the timeout happens. Does that JE>> BD>> card get a new interface name? And would people care or not... JE>> BD> JE>> BD>The name is unregistered with the call to if_detach because if_detach JE>> BD>removes the interface from the ifnet list. My guess is that JE>> BD>we'll either zero the name field or set to something like _zombie. The JE>> BD>unit will remain reserved until later. We'll need to add an SNMP index JE>> BD>mananaged in userland to satisfy come current if_index consumers. JE>> JE>> bsnmp does this anyway because of the rules for ifIndex. It has some JE>> heuristic to guess whether an interface is a physical one or not and if it JE>> is, it uses the same index again. The downside of this is that the JE>> interface index you see via SNMP has nothing to do with the interface index JE>> you see in the system and this does not work accross reboots and daemon JE>> restarts as required by the RFC. JE>> JE>> JE> JE>If we had a way to to this in the system (e.g. kept the mac address JE>with the ifnum in a hash) then we could just keep the ifnum in the mbuf JE>instead of the ifp pointer, as that is only occasionally used, and a JE>ifnum2ipf() macro could check the validity wheheve it is used. This would be helpful for the SNMP daemon, because this would also allow to reuse the ifnum if the same interface is plugged in back. However care must be taken that non-physical interfaces get a new ifnum always (iftun for example). harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/net if_vlan.c
On Tue, 4 Jul 2006, Brooks Davis wrote: BD>On Tue, Jul 04, 2006 at 10:25:39AM -0600, M. Warner Losh wrote: BD>> In message: <[EMAIL PROTECTED]> BD>> Brooks Davis <[EMAIL PROTECTED]> writes: BD>> : and act as though the interface is not there. We could then consider BD>> : either holding the interface for a configurable or computed length BD>> : of time or adding some sort of refcounting (probably impractical). BD>> BD>> Refcounting would be good for the 'macro' things (coming and going) BD>> that are infrequent, but we might have mulitple people doing. You are BD>> right it likely is too inefficient to do with mbugs. One other option BD>> might be to have a configurable time after the last time that it was BD>> accessed via the 'safe' routines that were setup. This way we'd tie BD>> the removal of the interface to a period of time after it was last BD>> used, rather than after it was removed. I don't know if such a BD>> difference would matter much in practice. BD> BD>We might get some mielage out of last used, but then we'd have to keep BD>that timestamp updated. For normal applications, once we've torn down BD>the sockets and drained their queues, I believe we should not have to BD>wait more than a few seconds unless dummynet or some other mechanism BD>that queues mbufs for a significant period of time is enabled. If BD>dummynet is enabled we need to wait a bit longer, but it isn't outside BD>the relm of possibility for dummynet to be modified to tell us how long BD>it will be until the last mbuf it currenly holds will be released. In BD>practice, 121 seconds is probably a good default number since a 60 BD>second max RTT is assumed in TCP and thus delays longer than that BD>would break everything anyway. BD> BD>> The only other 'issue' that I see with this approach is if I remove a BD>> card, and then insert it again before the timeout happens. Does that BD>> card get a new interface name? And would people care or not... BD> BD>The name is unregistered with the call to if_detach because if_detach BD>removes the interface from the ifnet list. My guess is that BD>we'll either zero the name field or set to something like _zombie. The BD>unit will remain reserved until later. We'll need to add an SNMP index BD>mananaged in userland to satisfy come current if_index consumers. bsnmp does this anyway because of the rules for ifIndex. It has some heuristic to guess whether an interface is a physical one or not and if it is, it uses the same index again. The downside of this is that the interface index you see via SNMP has nothing to do with the interface index you see in the system and this does not work accross reboots and daemon restarts as required by the RFC. harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone heard about Broadband over power lines???
On Tue, 23 May 2006, Mark Jayson Alvarez wrote: MJA>Hi, MJA> MJA>A while ago, a group of individuals have demonstrated MJA>us with devices that can be used to extend your MJA>network throughout every corner of your company MJA>through the use of electric outlet... A quick googling MJA>tells me that such technologies are already existing MJA>long time ago and some Electric companies in other MJA>parts of the world also are now providing Internet MJA>services to their costumers at an added cost.. Do you MJA>know any ongoing opensource initiative regarding this MJA>technologies?? As somebody else said, that's a hardware thing. In any case there is an Austrian city (don't remember the name) where the provider is forced to put this down, because they cannot meet the requirements for off-band emission. harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bsnmp-regex SNMP module
On Fri, 7 Apr 2006, Andrey V. Elsukov wrote: AVE>Harti Brandt wrote: AVE>> That would not help people running current, because the port is only build AVE>> for version that don't have bsnmpd in the tree. AVE> AVE>I can make it like bind9, PORT_REPLACES_BASE_BSNMPD :) AVE>Can you include all bsnmp modules with bsnmpd sources? There are two reasons that I would not like to do this: - My long term goal is to make bsnmp more usable on other operating systems. I've done this for the daemon itself, the library and the atm module. The mibII module is very FreeBSD specific and would require some work to split it into OS independent and OS dependent parts and I have currently no time to do this. We would also need to split the other modules accordingly and for things like snmp_netgraph I even don't know what to do, because this is just FreeBSD-only. - It requires more management work than I can do at the moment. I would need to integrate patches from the developers into the bsnmp tree and so on. I just feel that this is out of my time contingent for this. Perhaps the main port (bsnmp) could just be a wrapper that installs the other ports depending on the system version? (Just thinking loud - I'm not an expert in the ports area. harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bsnmp-regex SNMP module
On Fri, 7 Apr 2006, Andrey V. Elsukov wrote: AVE>Nate Nielsen wrote: AVE>> Anyone want to help with the FreeBSD port? AVE> AVE>I can try to include this module as optional AVE>part of net-mgmt/bsnmpd. That would not help people running current, because the port is only build for version that don't have bsnmpd in the tree. harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bsnmp-regex SNMP module
On Fri, 7 Apr 2006, Nate Nielsen wrote: NN>-BEGIN PGP SIGNED MESSAGE- NN>Hash: SHA1 NN> NN>Bjoern A. Zeeb wrote: NN>> On Thu, 6 Apr 2006, Nate Nielsen wrote: NN>> NN>>> A thousand apologies if announcing this here is inappropriate, but since NN>>> it's related to FreeBSD's very own bsnmpd... NN>>> NN>>> bsnmp-regex is an SNMP module that allows one to create arbitrary NN>>> counters from logs, program output or other text. NN>>> NN>>> If you're interested: NN>>> http://memberwebs.com/nielsen/software/bsnmp-regex/ NN>> NN>> could you make it a port and submit it? NN> NN>Anyone want to help with the FreeBSD port? NN> NN>Never done a port before. I could figure it out, but I have a bunch more NN>software waiting for me to open source (ie: autotool, document, round NN>out, licensing). NN> NN>A bunch of it is SNMP stuff: NN> * bsnmp-ping module (measures latencies/reachability) NN> * bsnmp-host module (RFC 2790 ie: uptime, cpu load, memory, disks) Is that different from the hostres module we have in the tree? harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bsnmp with vlan, no speed values are set
On Fri, 31 Mar 2006, Thomas wrote: T>Hi T> T>I use bsnmpd-1.11_3 with FreeBSD 5.4-RELEASE on my router. It works very T>well. The only problem are my vlans on my em interfaces. T> T>As you see below it doesn't set any speed values for vlans. Afaik this T>means I can't use 64bit counter (ifHCInOctets). Is there a way set it T>the speed value? I think this was fixed in -current in rev. 1.93 so that the vlan reports the speed of the underlying interface. You might try to use that fix. Alternativly you can patch bsnmp to set the speed to some arbitrary high value if it is 0. This would be in snmp_mibII/mibII.c mib_fetch_ifmib(). Add something like: if (ifp->mib.ifmd_data.ifi_baudrate == 0) ifp->mib.ifmd_data.ifi_baudrate = 10; just after the HIGHSPEED and VERYHIGHSPEED flags have been cleared. (CC: to Andrey) harti T> T>snmpwalk -v 1 -c public localhost If T>IF-MIB::ifIndex.1 = INTEGER: 1 T>IF-MIB::ifIndex.2 = INTEGER: 2 T>IF-MIB::ifIndex.3 = INTEGER: 3 T>IF-MIB::ifIndex.4 = INTEGER: 4 T>IF-MIB::ifIndex.5 = INTEGER: 5 T>IF-MIB::ifIndex.6 = INTEGER: 6 T>IF-MIB::ifIndex.7 = INTEGER: 7 T>IF-MIB::ifIndex.8 = INTEGER: 8 T>IF-MIB::ifDescr.1 = STRING: em0 T>IF-MIB::ifDescr.2 = STRING: em1 T>IF-MIB::ifDescr.3 = STRING: lo0 T>IF-MIB::ifDescr.4 = STRING: lo1 T>IF-MIB::ifDescr.5 = STRING: lo2 T>IF-MIB::ifDescr.6 = STRING: vlan8 T>IF-MIB::ifDescr.7 = STRING: vlan507 T>IF-MIB::ifDescr.8 = STRING: vlan200 T>IF-MIB::ifType.1 = INTEGER: ethernetCsmacd(6) T>IF-MIB::ifType.2 = INTEGER: ethernetCsmacd(6) T>IF-MIB::ifType.3 = INTEGER: softwareLoopback(24) T>IF-MIB::ifType.4 = INTEGER: softwareLoopback(24) T>IF-MIB::ifType.5 = INTEGER: softwareLoopback(24) T>IF-MIB::ifType.6 = INTEGER: l2vlan(135) T>IF-MIB::ifType.7 = INTEGER: l2vlan(135) T>IF-MIB::ifType.8 = INTEGER: l2vlan(135) T>IF-MIB::ifMtu.1 = INTEGER: 1546 T>IF-MIB::ifMtu.2 = INTEGER: 1546 T>IF-MIB::ifMtu.3 = INTEGER: 16384 T>IF-MIB::ifMtu.4 = INTEGER: 16384 T>IF-MIB::ifMtu.5 = INTEGER: 16384 T>IF-MIB::ifMtu.6 = INTEGER: 1546 T>IF-MIB::ifMtu.7 = INTEGER: 1546 T>IF-MIB::ifMtu.8 = INTEGER: 1546 T>IF-MIB::ifSpeed.1 = Gauge32: 10 T>IF-MIB::ifSpeed.2 = Gauge32: 10 T>IF-MIB::ifSpeed.3 = Gauge32: 0 T>IF-MIB::ifSpeed.4 = Gauge32: 0 T>IF-MIB::ifSpeed.5 = Gauge32: 0 T>IF-MIB::ifSpeed.6 = Gauge32: 0 T>IF-MIB::ifSpeed.7 = Gauge32: 0 T>IF-MIB::ifSpeed.8 = Gauge32: 0 T> T> T>snmpwalk -v 1 -c public localhost IfX T>IF-MIB::ifName.1 = STRING: em0 T>IF-MIB::ifName.2 = STRING: em1 T>IF-MIB::ifName.3 = STRING: lo0 T>IF-MIB::ifName.4 = STRING: lo1 T>IF-MIB::ifName.5 = STRING: lo2 T>IF-MIB::ifName.6 = STRING: vlan8 T>IF-MIB::ifName.7 = STRING: vlan507 T>IF-MIB::ifName.8 = STRING: vlan200 T>IF-MIB::ifInMulticastPkts.1 = Counter32: 27763749 T>IF-MIB::ifInMulticastPkts.2 = Counter32: 39112192 T>IF-MIB::ifInMulticastPkts.3 = Counter32: 0 T>IF-MIB::ifInMulticastPkts.4 = Counter32: 0 T>IF-MIB::ifInMulticastPkts.5 = Counter32: 0 T>IF-MIB::ifInMulticastPkts.6 = Counter32: 66425 T>IF-MIB::ifInMulticastPkts.7 = Counter32: 597199434 T>IF-MIB::ifInMulticastPkts.8 = Counter32: 2886152 T>IF-MIB::ifOutBroadcastPkts.8 = Counter32: 0 T>IF-MIB::ifHCInOctets.1 = Counter64: 1905469523 T>IF-MIB::ifHCInOctets.2 = Counter64: 4004579218 T>IF-MIB::ifHCInUcastPkts.1 = Counter64: 3374758879 T>IF-MIB::ifHCInUcastPkts.2 = Counter64: 2260898668 T>IF-MIB::ifHCInMulticastPkts.1 = Counter64: 27763749 T>IF-MIB::ifHCInMulticastPkts.2 = Counter64: 39112192 T>IF-MIB::ifHCInBroadcastPkts.1 = Counter64: 0 T>IF-MIB::ifHCInBroadcastPkts.2 = Counter64: 0 T>IF-MIB::ifHCOutOctets.1 = Counter64: 1859205456 T>IF-MIB::ifHCOutOctets.2 = Counter64: 2149535104 T>IF-MIB::ifHCOutUcastPkts.1 = Counter64: 1060004524 T>IF-MIB::ifHCOutUcastPkts.2 = Counter64: 1136546470 T>IF-MIB::ifHCOutMulticastPkts.1 = Counter64: 1580694 T>IF-MIB::ifHCOutMulticastPkts.2 = Counter64: 4601834 T>IF-MIB::ifHCOutBroadcastPkts.1 = Counter64: 0 T>IF-MIB::ifHCOutBroadcastPkts.2 = Counter64: 0 T>IF-MIB::ifLinkUpDownTrapEnable.1 = INTEGER: enabled(1) T>IF-MIB::ifLinkUpDownTrapEnable.2 = INTEGER: enabled(1) T>IF-MIB::ifLinkUpDownTrapEnable.3 = INTEGER: disabled(2) T>IF-MIB::ifLinkUpDownTrapEnable.4 = INTEGER: disabled(2) T>IF-MIB::ifLinkUpDownTrapEnable.5 = INTEGER: disabled(2) T>IF-MIB::ifLinkUpDownTrapEnable.6 = INTEGER: disabled(2) T>IF-MIB::ifLinkUpDownTrapEnable.7 = INTEGER: disabled(2) T>IF-MIB::ifLinkUpDownTrapEnable.8 = INTEGER: disabled(2) T>IF-MIB::ifHighSpeed.1 = Gauge32: 1000 T>IF-MIB::ifHighSpeed.2 = Gauge32: 1000 T>IF-MIB::ifHighSpeed.3 = Gauge32: 0 T>IF-MIB::ifHighSpeed.4 = Gauge32: 0 T>IF-MIB::ifHighSpeed.5 = Gauge32: 0 T>IF-MIB::ifHighSpeed.6 = Gauge32: 0 T>IF-MIB::ifHighSpeed.7 = Gauge32: 0 T>IF-MIB::ifHighSpeed.8 = Gauge32: 0 T> T>em0: flags=18843 mtu T>1546 T>options=4b T>inet x netmask 0xffe0 broadcast x T>ether 00:30:48:2c:6e:9a T>media: Ethernet autoselect (1000baseTX ) T>status: active T>em1: flags=18843 mtu T>1546 T>options=
64-bit SNMP interface counters
This new version has the 64-bit HC counters in the ifXTable really 64-bit on all our platforms. If anybody has interfaces > 1GBit/sec I would be interested how this works. harti On Mon, 27 Feb 2006, Hartmut Brandt wrote: HB>harti 2006-02-27 16:16:18 UTC HB> HB> FreeBSD src repository HB> HB> src/contrib/bsnmp - Imported sources HB> Update of /home/ncvs/src/contrib/bsnmp HB> In directory repoman.freebsd.org:/tmp/cvs-serv18547 HB> HB> Log Message: HB> Virgin import of bsnmpd 1.12 HB> HB> Status: HB> HB> Vendor Tag:BEGEMOT HB> Release Tags: BSNMP_1_12 HB> HB> U src/contrib/bsnmp/oid-list HB> U src/contrib/bsnmp/VERSION HB> U src/contrib/bsnmp/TODO HB> U src/contrib/bsnmp/README HB> U src/contrib/bsnmp/NEWS HB> U src/contrib/bsnmp/snmp_mibII/mibII.c HB> U src/contrib/bsnmp/snmp_mibII/mibII.h HB> U src/contrib/bsnmp/snmp_mibII/mibII_ifmib.c HB> U src/contrib/bsnmp/snmp_mibII/mibII_ifstack.c HB> U src/contrib/bsnmp/snmp_mibII/mibII_interfaces.c HB> U src/contrib/bsnmp/snmp_mibII/mibII_ip.c HB> U src/contrib/bsnmp/snmp_mibII/mibII_ipaddr.c HB> U src/contrib/bsnmp/snmp_mibII/mibII_nettomedia.c HB> U src/contrib/bsnmp/snmp_mibII/mibII_rcvaddr.c HB> U src/contrib/bsnmp/snmp_mibII/mibII_route.c HB> U src/contrib/bsnmp/snmp_mibII/mibII_tcp.c HB> U src/contrib/bsnmp/snmp_mibII/mibII_tree.def HB> U src/contrib/bsnmp/snmp_mibII/mibII_udp.c HB> U src/contrib/bsnmp/snmp_mibII/snmp_mibII.3 HB> U src/contrib/bsnmp/snmp_mibII/snmp_mibII.h HB> N src/contrib/bsnmp/snmp_mibII/mibII_begemot.c HB> N src/contrib/bsnmp/snmp_mibII/BEGEMOT-MIB2-MIB.txt HB> N src/contrib/bsnmp/snmp_mibII/BEGEMOT-IP-MIB.txt HB> U src/contrib/bsnmp/snmp_ntp/BEGEMOT-NTP-MIB.txt HB> U src/contrib/bsnmp/snmp_ntp/NTP-PROXY-MIB.txt HB> U src/contrib/bsnmp/snmp_ntp/ntp_tree.def HB> U src/contrib/bsnmp/snmp_ntp/snmp_ntp.c HB> U src/contrib/bsnmp/snmp_ntp/NTP-MIB.txt HB> U src/contrib/bsnmp/lib/asn1.3 HB> U src/contrib/bsnmp/lib/asn1.c HB> U src/contrib/bsnmp/lib/asn1.h HB> U src/contrib/bsnmp/lib/bsnmpagent.3 HB> U src/contrib/bsnmp/lib/bsnmpclient.3 HB> U src/contrib/bsnmp/lib/bsnmplib.3 HB> U src/contrib/bsnmp/lib/snmp.c HB> U src/contrib/bsnmp/lib/snmp.h HB> U src/contrib/bsnmp/lib/snmpagent.c HB> U src/contrib/bsnmp/lib/snmpagent.h HB> U src/contrib/bsnmp/lib/snmpclient.c HB> U src/contrib/bsnmp/lib/snmpclient.h HB> U src/contrib/bsnmp/lib/snmppriv.h HB> U src/contrib/bsnmp/lib/support.c HB> U src/contrib/bsnmp/lib/support.h HB> U src/contrib/bsnmp/gensnmptree/gensnmptree.1 HB> U src/contrib/bsnmp/gensnmptree/gensnmptree.c HB> U src/contrib/bsnmp/gensnmpdef/gensnmpdef.1 HB> U src/contrib/bsnmp/gensnmpdef/gensnmpdef.c HB> U src/contrib/bsnmp/snmpd/BEGEMOT-MIB.txt HB> U src/contrib/bsnmp/snmpd/BEGEMOT-SNMPD.txt HB> U src/contrib/bsnmp/snmpd/FOKUS-MIB.txt HB> U src/contrib/bsnmp/snmpd/action.c HB> U src/contrib/bsnmp/snmpd/bsnmpd.1 HB> U src/contrib/bsnmp/snmpd/config.c HB> U src/contrib/bsnmp/snmpd/export.c HB> U src/contrib/bsnmp/snmpd/main.c HB> U src/contrib/bsnmp/snmpd/snmpd.config HB> U src/contrib/bsnmp/snmpd/snmpd.h HB> U src/contrib/bsnmp/snmpd/snmpd.sh HB> U src/contrib/bsnmp/snmpd/snmpmod.3 HB> U src/contrib/bsnmp/snmpd/snmpmod.h HB> U src/contrib/bsnmp/snmpd/trans_lsock.c HB> U src/contrib/bsnmp/snmpd/trans_lsock.h HB> U src/contrib/bsnmp/snmpd/trans_udp.c HB> U src/contrib/bsnmp/snmpd/trans_udp.h HB> U src/contrib/bsnmp/snmpd/trap.c HB> U src/contrib/bsnmp/snmpd/tree.def HB> HB> No conflicts created by this import HB> HB> HB> HB> ___ 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)
On Wed, 15 Feb 2006, Gleb Smirnoff wrote: GS>On Tue, Feb 14, 2006 at 11:58:21AM +0100, Anders Nordby wrote: GS>A> Some things popping off my mind: GS> GS>- A SMUX interface, allowing a process to provide a MIB branch GS> available via bsnmpd. May be in future I will have time to GS> make a SNMP branch in mpd, that will allow to manage a PPP GS> access concetrator via SNMP. Actually an agentx interface would be nice, but that's non-trivial, to put it mild. Currently I use shared memory in all projects where the daemon needs to communicate with other programs. SMUX might be a starting point though. I'll put it on the list as soon as I get my login-name/password recovered for the WiKi :-) harti ___ 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)
On Tue, 14 Feb 2006, Anders Nordby wrote: AN>On Tue, Feb 14, 2006 at 01:39:01PM +0300, Gleb Smirnoff wrote: AN>> A> I should make a list of "what bsnmpd needs" to be more usable, in case AN>> A> Harti is interested. ;-P AN>> Where is such list? AN> AN>Some things popping off my mind: AN> AN>- Ability to run as a different user. I suppose we should add a snmp AN>user to the base system. Running as root is not OK, when it is not AN>necessary (net-snmp snmpd can run as a different user, it has a related AN>-r option to not exit if it has privilege problems). AN> AN>- Ability to chroot itself (yes please, for security). I don't have enough rc-foo for this. Perhaps someone can jump in here? AN>- Ability to execute programs and return values on given OIDs, and also AN>cache their results so that the programs doesn't have to be run for AN>every time. It's necessary to cache values to avoid running resource AN>intensive scripts/programs more than necessary. Sounds interesting and is certainly doable. AN>I am using net-snmp snmpd mostly currently, but consider switching as I AN>now can get my 64-bit counters from bsnmpd. It seems net-snmp snmpd can AN>not give ifHCInOctets/ifHCOutOctets (Counter64) in FreeBSD yet. At least AN>the exec issue above must be resolved for me to switch to bsnmpd. AN> AN>Oh, and a couple of questions. If I only want read access enabled, is AN>commenting "write :=" and "trap :=" out all that is necessary? If not, AN>how do I do it? Normally, I only want to read from my SNMP agents. I AN>would prefer to have trap/write disabled completely. Two or three weeks ago I committed a patch that sets the default communities to NULL and comments out the corresponding lines in the config file. In this configuration the daemon ignores all incoming messages. If you then just set the read community, it gets read-only. You definitely need rev 1.1.1.11 or later of snmpd/main.c. The trap community is only for outgoing traps. AN>Another thing. The trap support in bsnmpd, it's only for forwarding AN>traps? Does bsnmpd have, or will it ever get an ability to generate AN>traps upon failures in FreeBSD? No, trap support is only for sending traps. There is a begemotTrapSinkTable where you configure all trap destinations. The distributed config file populates just one row of it. Each trap is then send to all destinations. Currently the only traps that are ever sent are: - authentication traps (if enabled) sent by the daemon itself - linkUp and linkDown traps from snmp_mibII harti ___ 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, 14 Feb 2006, Gleb Smirnoff wrote: GS>On Tue, Feb 14, 2006 at 11:37:23AM +0100, Anders Nordby wrote: GS>A> I should make a list of "what bsnmpd needs" to be more usable, in case GS>A> Harti is interested. ;-P GS> GS>Where is such list? I was thinking to setup such a list on my FreeBSD WiKi page for some time now, just never came around to do it. I can do it when I come back from lunch :-) harti ___ 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, 14 Feb 2006, Oleg Polyakov wrote: OP>--- Gleb Smirnoff <[EMAIL PROTECTED]> wrote: OP> OP>> On Tue, Feb 14, 2006 at 09:39:00AM +0100, Harti Brandt wrote: OP>> H> AN>I changed port to 163 cause I am actually using net-snmp snmpd on port OP>> H> AN>161 still. Anyway, it seems bsnmpd insists these are 10 mbps OP>> interfaces? OP>> H> AN>Why so? OP>> H> OP>> H> The driver reports a speed of 10Mbits/sec. ifHighSpeed is ifi_baudrate OP>> H> divided by 10^6 (and rounded). This is the default set by ether_ifattach() OP>> OP>> H> if the driver did not set another value. It seems that bge never sets that OP>> OP>> H> value so you end up with the default. This looks like a bug. OP>> OP>> Harti, we are thinking in parallel :) OP> OP>Parallel, yes ;) Wow! Seems the massive introduction of dual-core CPUs and multiprocessor machines starts to give results :-) And all that without mutexes and locks. harti ___ 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, 14 Feb 2006, Gleb Smirnoff wrote: GS>On Tue, Feb 14, 2006 at 09:39:00AM +0100, Harti Brandt wrote: GS>H> AN>I changed port to 163 cause I am actually using net-snmp snmpd on port GS>H> AN>161 still. Anyway, it seems bsnmpd insists these are 10 mbps interfaces? GS>H> AN>Why so? GS>H> GS>H> The driver reports a speed of 10Mbits/sec. ifHighSpeed is ifi_baudrate GS>H> divided by 10^6 (and rounded). This is the default set by ether_ifattach() GS>H> if the driver did not set another value. It seems that bge never sets that GS>H> value so you end up with the default. This looks like a bug. GS> GS>Harti, we are thinking in parallel :) :-) GS>Andres, pls try the attached patch. I wonder however, whether this could be done somewhere in mii? When setting ifmedia also the speed could be set. In this case SNMP would report the actual current speed. harti ___ 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, 14 Feb 2006, Anders Nordby wrote: AN>On Tue, Feb 14, 2006 at 09:07:42AM +0100, Harti Brandt wrote: AN>>>It seems ifHCInOctets and ifHCOutOctets are missing. How come? Do I need AN>>>to use SNMP v3? Another query tool? AN>> 10 bits/seconds seems utterly wrong for bge interfaces :-) The HC counters AN>> appear only for speeds >= 20Mbit/sec according to the RFC. AN> AN>I have two servers running bsnmpd in FreeBSD 6.0-RELEASE here now. Both AN>have bge gigabit interfaces. AN> AN>1) A HP Proliant DL 380 G4 (FreeBSD/i386), with (forced) 100baseTX AN>full-duplex link: AN> AN># ifconfig bge0 AN>bge0: flags=8843 mtu 1500 AN>options=1a AN>inet X.X.X.X netmask 0xfff0 broadcast 80.91.38.111 AN>ether 00:14:c2:61:5c:95 AN>media: Ethernet 100baseTX AN>status: active AN># snmpwalk -v 2c -c XX localhost:163 AN>ifMIB.ifMIBObjects.ifXTable.ifXEntry AN>IF-MIB::ifName.1 = STRING: bge0 AN>IF-MIB::ifName.2 = STRING: bge1 AN>IF-MIB::ifName.3 = STRING: lo0 AN>IF-MIB::ifInMulticastPkts.1 = Counter32: 3430507 AN>IF-MIB::ifInMulticastPkts.2 = Counter32: 0 AN>IF-MIB::ifInMulticastPkts.3 = Counter32: 0 AN>IF-MIB::ifInBroadcastPkts.1 = Counter32: 0 AN>IF-MIB::ifInBroadcastPkts.2 = Counter32: 0 AN>IF-MIB::ifInBroadcastPkts.3 = Counter32: 0 AN>IF-MIB::ifOutMulticastPkts.1 = Counter32: 0 AN>IF-MIB::ifOutMulticastPkts.2 = Counter32: 0 AN>IF-MIB::ifOutMulticastPkts.3 = Counter32: 0 AN>IF-MIB::ifOutBroadcastPkts.1 = Counter32: 0 AN>IF-MIB::ifOutBroadcastPkts.2 = Counter32: 0 AN>IF-MIB::ifOutBroadcastPkts.3 = Counter32: 0 AN>IF-MIB::ifLinkUpDownTrapEnable.1 = INTEGER: enabled(1) AN>IF-MIB::ifLinkUpDownTrapEnable.2 = INTEGER: enabled(1) AN>IF-MIB::ifLinkUpDownTrapEnable.3 = INTEGER: disabled(2) AN>IF-MIB::ifHighSpeed.1 = Gauge32: 10 AN>IF-MIB::ifHighSpeed.2 = Gauge32: 10 AN>IF-MIB::ifHighSpeed.3 = Gauge32: 0 AN>IF-MIB::ifPromiscuousMode.1 = INTEGER: false(2) AN>IF-MIB::ifPromiscuousMode.2 = INTEGER: false(2) AN>IF-MIB::ifPromiscuousMode.3 = INTEGER: false(2) AN>IF-MIB::ifConnectorPresent.1 = INTEGER: true(1) AN>IF-MIB::ifConnectorPresent.2 = INTEGER: true(1) AN>IF-MIB::ifConnectorPresent.3 = INTEGER: false(2) AN>IF-MIB::ifAlias.1 = STRING: AN>IF-MIB::ifAlias.2 = STRING: AN>IF-MIB::ifAlias.3 = STRING: AN>IF-MIB::ifCounterDiscontinuityTime.1 = Timeticks: (0) 0:00:00.00 AN>IF-MIB::ifCounterDiscontinuityTime.2 = Timeticks: (0) 0:00:00.00 AN>IF-MIB::ifCounterDiscontinuityTime.3 = Timeticks: (0) 0:00:00.00 AN> AN>2) A HP Proliant DL 385 G1 (FreeBSD/amd64), with gigabit link: AN> AN># ifconfig bge0 AN>bge0: flags=8843 mtu 1500 AN>options=1a AN>inet X.X.X.X netmask 0xffe0 broadcast 80.91.39.159 AN>ether 00:13:21:b3:01:f6 AN>media: Ethernet autoselect (1000baseTX ) AN>status: active AN># snmpwalk -v 2c -c XX localhost:163 AN>ifMIB.ifMIBObjects.ifXTable.ifXEntry AN>IF-MIB::ifName.1 = STRING: bge0 AN>IF-MIB::ifName.2 = STRING: bge1 AN>IF-MIB::ifName.3 = STRING: lo0 AN>IF-MIB::ifInMulticastPkts.1 = Counter32: 13303 AN>IF-MIB::ifInMulticastPkts.2 = Counter32: 0 AN>IF-MIB::ifInMulticastPkts.3 = Counter32: 0 AN>IF-MIB::ifInBroadcastPkts.1 = Counter32: 0 AN>IF-MIB::ifInBroadcastPkts.2 = Counter32: 0 AN>IF-MIB::ifInBroadcastPkts.3 = Counter32: 0 AN>IF-MIB::ifOutMulticastPkts.1 = Counter32: 0 AN>IF-MIB::ifOutMulticastPkts.2 = Counter32: 0 AN>IF-MIB::ifOutMulticastPkts.3 = Counter32: 0 AN>IF-MIB::ifOutBroadcastPkts.1 = Counter32: 0 AN>IF-MIB::ifOutBroadcastPkts.2 = Counter32: 0 AN>IF-MIB::ifOutBroadcastPkts.3 = Counter32: 0 AN>IF-MIB::ifLinkUpDownTrapEnable.1 = INTEGER: enabled(1) AN>IF-MIB::ifLinkUpDownTrapEnable.2 = INTEGER: enabled(1) AN>IF-MIB::ifLinkUpDownTrapEnable.3 = INTEGER: disabled(2) AN>IF-MIB::ifHighSpeed.1 = Gauge32: 10 AN>IF-MIB::ifHighSpeed.2 = Gauge32: 10 AN>IF-MIB::ifHighSpeed.3 = Gauge32: 0 AN>IF-MIB::ifPromiscuousMode.1 = INTEGER: false(2) AN>IF-MIB::ifPromiscuousMode.2 = INTEGER: false(2) AN>IF-MIB::ifPromiscuousMode.3 = INTEGER: false(2) AN>IF-MIB::ifConnectorPresent.1 = INTEGER: true(1) AN>IF-MIB::ifConnectorPresent.2 = INTEGER: true(1) AN>IF-MIB::ifConnectorPresent.3 = INTEGER: false(2) AN>IF-MIB::ifAlias.1 = STRING: AN>IF-MIB::ifAlias.2 = STRING: AN>IF-MIB::ifAlias.3 = STRING: AN>IF-MIB::ifCounterDiscontinuityTime.1 = Timeticks: (0) 0:00:00.00 AN>IF-MIB::ifCounterDiscontinuityTime.2 = Timeticks: (0) 0:00:00.00 AN>IF-MIB::ifCounterDiscontinuityTime.3 = Timeticks: (0) 0:00:00.00 AN> AN>I changed port to 163 cause I am actually using net-snmp snmpd on port AN>161 still. Anyway, it seems bsnmpd insists these are 10 mbps interfaces? AN>Why so? The driver reports a speed of 10Mbits/sec. ifHighSp
Re: 64-bit SNMP counters for FreeBSD && graphing bandwidth usage
On Mon, 13 Feb 2006, Anders Nordby wrote: AN>Hi, AN> AN>On Tue, Feb 07, 2006 at 05:11:31PM +0300, Gleb Smirnoff wrote: AN>>> Is there any way to have 64-bit SNMP counters in FreeBSD? Especially for AN>>> ifInOctets/ifOutOctets. It seems the built-in bsnmpd only has AN>>> Counter32, and net-snmpd the same (--enable-mfd-rewrites, which is AN>>> supposed to help, seems to only work in Linux). AN>> Extended counters live in a separate subtree and bsnmpd supports them: AN>> AN>>> snmpwalk -v 2c host community ifMIB.ifMIBObjects.ifXTable.ifXEntry AN> AN>Running FreeBSD 6.0-RELEASE and using net-snmp 5.2.2 to walk the tree, I AN>get: AN> AN># snmpwalk -v 2c -c XXXYYY localhost AN>ifMIB.ifMIBObjects.ifXTable.ifXEntry AN>IF-MIB::ifName.1 = STRING: bge0 AN>IF-MIB::ifName.2 = STRING: bge1 AN>IF-MIB::ifName.3 = STRING: lo0 AN>IF-MIB::ifInMulticastPkts.1 = Counter32: 3430126 AN>IF-MIB::ifInMulticastPkts.2 = Counter32: 0 AN>IF-MIB::ifInMulticastPkts.3 = Counter32: 0 AN>IF-MIB::ifInBroadcastPkts.1 = Counter32: 0 AN>IF-MIB::ifInBroadcastPkts.2 = Counter32: 0 AN>IF-MIB::ifInBroadcastPkts.3 = Counter32: 0 AN>IF-MIB::ifOutMulticastPkts.1 = Counter32: 0 AN>IF-MIB::ifOutMulticastPkts.2 = Counter32: 0 AN>IF-MIB::ifOutMulticastPkts.3 = Counter32: 0 AN>IF-MIB::ifOutBroadcastPkts.1 = Counter32: 0 AN>IF-MIB::ifOutBroadcastPkts.2 = Counter32: 0 AN>IF-MIB::ifOutBroadcastPkts.3 = Counter32: 0 AN>IF-MIB::ifLinkUpDownTrapEnable.1 = INTEGER: enabled(1) AN>IF-MIB::ifLinkUpDownTrapEnable.2 = INTEGER: enabled(1) AN>IF-MIB::ifLinkUpDownTrapEnable.3 = INTEGER: disabled(2) AN>IF-MIB::ifHighSpeed.1 = Gauge32: 10 AN>IF-MIB::ifHighSpeed.2 = Gauge32: 10 AN>IF-MIB::ifHighSpeed.3 = Gauge32: 0 AN>IF-MIB::ifPromiscuousMode.1 = INTEGER: false(2) AN>IF-MIB::ifPromiscuousMode.2 = INTEGER: false(2) AN>IF-MIB::ifPromiscuousMode.3 = INTEGER: false(2) AN>IF-MIB::ifConnectorPresent.1 = INTEGER: true(1) AN>IF-MIB::ifConnectorPresent.2 = INTEGER: true(1) AN>IF-MIB::ifConnectorPresent.3 = INTEGER: false(2) AN>IF-MIB::ifAlias.1 = STRING: AN>IF-MIB::ifAlias.2 = STRING: AN>IF-MIB::ifAlias.3 = STRING: AN>IF-MIB::ifCounterDiscontinuityTime.1 = Timeticks: (0) 0:00:00.00 AN>IF-MIB::ifCounterDiscontinuityTime.2 = Timeticks: (0) 0:00:00.00 AN>IF-MIB::ifCounterDiscontinuityTime.3 = Timeticks: (0) 0:00:00.00 AN> AN>It seems ifHCInOctets and ifHCOutOctets are missing. How come? Do I need AN>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. harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: interface cleanup
On Thu, 21 Jul 2005, Anders Persson wrote: AP>I have not had time to go through netgraph enough yet, but does anyone have AP>some ideas how to avoid using kvm to obtain netgraph info? Add a control message to the ng_socket type that returns you the info you need. harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: debugging hatm
On Wed, 25 May 2005, Donatas wrote: D>hello, D>has anyone any ideas on how enable debug on hatm (HE155) interface? D> D>hw.atm.hatmN.debug D> D>sysctl -a |grep hw.atm doesn't show such viariable and I don't see any parameters in if_hatmvar.h exept debug flags. You must build the driver with the HATM_DEBUG option. harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hatm(4) and freebsd4.11
On Wed, 27 Apr 2005, Donatas wrote: D>is there any posibility to use Fore Marconi HE155 under 4.11? No. That would probably require to backport some ATM infrastructure first. harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [OT] aal5 pdu CRC
On Thu, 27 Jan 2005, Jose M Rodriguez wrote: JMR>El Jueves, 27 de Enero de 2005 16:10, Harti Brandt escribi?: JMR>> On Thu, 27 Jan 2005, Jose M Rodriguez wrote: JMR>> JMR>> JMR>Hi, JMR>> JMR> JMR>> JMR>get some free time to work in uadsl, but have a problem. Hope someone JMR>> that JMR>can read ITU I.363 can answer this. JMR>> JMR> JMR>> JMR>Every usb adsl modem implementation I see doesn't obey aal5 pdu JMR>> encoding JMR>standards, which requires that the PDU trailer come at the JMR>> begin of a fresh JMR>cell. JMR>> JMR>> That is not true. The trailer must be on the END of a cell. Before the JMR>> trailer there will be padding bytes so that this happens. If, for example, JMR>> you have a one byte PDU the AAL5 PDU will consist of 1 byte information, JMR>> 39 bytes padding and 8 bytes trailer. JMR>> JMR> JMR>At last, rfc1483 and the received logic side seems to point that this is true. JMR>Most implementations sync the begin of a new PDU after detect the last cell JMR>by header test. Also, PDU lenght and crc is decode from a fixed ptr on the JMR>ENDPDU cell (lenght=cell[2]..cell[3], crc=cell[4]..cell[7]). Well, you can trust me. The reference is the ITU-T recommendation in any case. The AAL5 CPCS PDU consists of: 1...65535 information bytes 0...47PAD bytes 1 UU byte 1 CPI byte 2 length field 4 CRC with the padding done so that the sum is a multiple of 48 byte. Sure you can use fixed offsets to access the header. It's always at cell[40] for the last cell. JMR>> JMR> JMR>> JMR>So, I think that the modem must rework this and generate two cells on JMR>> the JMR>wire. Due how this modems works, I doubt that the modem JMR>> recalculate PDU CRC JMR>itself, So... JMR>> JMR> JMR>> JMR>Can someone confir if the CRC covers the PAD? I'm begin to think that JMR>> the CRC JMR>only covers the playload and the pdu-trailer. JMR>> JMR>> The CRC covers everything but the CRC. The PAD must be filled with zeros JMR>> though. JMR>> JMR> JMR>This is not so clean. This pad may be take as a cell pad or as a PDU pad. If JMR>this is take as a cell pad, it may not be part of the CRC (the ENDPDU cell is JMR>also paded from 8 to 48). JMR> JMR>My first guest is that the pad is part of the PDU, but I really doubt that the JMR>modem may be able to do a full CRC reclaculation. The CRC is computed from everything except the CRC field. PAD must be zero as must be CPI. I've written this code several times :-/. harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [OT] aal5 pdu CRC
On Thu, 27 Jan 2005, Jose M Rodriguez wrote: JMR>Hi, JMR> JMR>get some free time to work in uadsl, but have a problem. Hope someone that JMR>can read ITU I.363 can answer this. JMR> JMR>Every usb adsl modem implementation I see doesn't obey aal5 pdu encoding JMR>standards, which requires that the PDU trailer come at the begin of a fresh JMR>cell. That is not true. The trailer must be on the END of a cell. Before the trailer there will be padding bytes so that this happens. If, for example, you have a one byte PDU the AAL5 PDU will consist of 1 byte information, 39 bytes padding and 8 bytes trailer. JMR> JMR>So, I think that the modem must rework this and generate two cells on the JMR>wire. Due how this modems works, I doubt that the modem recalculate PDU CRC JMR>itself, So... JMR> JMR>Can someone confir if the CRC covers the PAD? I'm begin to think that the CRC JMR>only covers the playload and the pdu-trailer. The CRC covers everything but the CRC. The PAD must be filled with zeros though. harti ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: netgraph cpcsinit + vcc parrameters
On Wed, 8 Sep 2004, donatas wrote:
d>hello,
d>I use netgraph for :
d>
d>hatm: <-> atmllc <->em
d>
d>also I use vcc chanels:
d>
d>ngctl msg hatm0: cpcsinit {name="sig1" aal=5 vci=55}
d>
d>I need to set some more vcc parameters ( ubr, pixel-rate, burst-size)
d>
d>it was possible to do using atmconfig
d>( atmconfig natm add 1.1.1.1 hatm0 0 55 LLC/SNAP vbr 1331 1330 50)
d>
d>but how to realize those settings using cpcsinit ? it sets some default values
That's easy. Have a look at /usr/include/netgraph/atm/ng_atm.h and locate
the definition of NGM_ATM_CPCS_INIT_INFO. There you see all the applicable
paremeters to cpcsinit. 'traffic' is the traffic type - see
/usr/include/net/if_atm.h for the ATMIO_TRAFFIC_* values.
Note however, that for UBR there is no sense in specifying PCR or burst
size. Perhaps you mean VBR? If you need VBR you must use an IDT77252 based
card - the others don't support VBR.
harti
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: netgraph only on i386/ia64 - why ?
On Wed, 18 Aug 2004, John Polstra wrote: JP>On 18-Aug-2004 Julian Elischer wrote: JP>> John Polstra wrote: JP>>> JP>>> There is one problem with netgraph on 64-bit platforms. The ng_msghdr JP>>> struct is 52 bytes / 4-byte aligned (see ng_message.h). That means JP>>> the message payload is not well-aligned for 64-bit platforms. It JP>>> would be nice to fix that (and bump NG_VERSION, of course). Nobody JP>>> ever guaranteed that the message payload would be aligned, but it JP>>> makes things a lot more convenient. JP>> JP>> if we do this we should do it now so that we have a consistent ABI from 5.3 on.. JP>> JP>> scott (et al), should we pad an extra 4 bytes in this now? JP>> it's low/no risk, but better now than after 5.3 has been released.. JP> JP>I'd really like to see this change happen. Julian, would it require Yes. Please do it. JP>bumping just NG_VERSION, or should NG_ABI_VERSION change too? harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: netgraph only on i386/ia64 - why ?
On Wed, 18 Aug 2004, Ruslan Ermilov wrote: RE>On Tue, Aug 17, 2004 at 11:49:47AM +0300, Ruslan Ermilov wrote: RE>> On Mon, Aug 16, 2004 at 07:13:27PM +, Bjoern A. Zeeb wrote: RE>> > On Mon, 16 Aug 2004, Bjoern A. Zeeb wrote: RE>> > RE>> > > On Mon, 16 Aug 2004, Ruslan Ermilov wrote: RE>> > > RE>> > > > On Mon, Aug 16, 2004 at 06:03:33PM +, Bjoern A. Zeeb wrote: RE>> > > > > Hi, RE>> > > > > RE>> > > > > It seems netgraph is only build on ia64 and i386. RE>> > > > > Can someone please explain why ? RE>> > > > > RE>> > > > I think this is an omission from the old days. If it RE>> > > > survives ``make universe'', this should probably be RE>> > > > committed. Gleb, do you feel like testing this with RE>> > > > ``make universe''? RE>> > > RE>> > > modules at least compiled on amd64 (with warnings in two of them). RE>> > > haven't rebooted yet. RE>> > RE>> > and they load: RE>> > RE>> [...] RE>> > unfortunately I neither do not have the resources for a make universe RE>> > at the moment. RE>> > RE>> I'm testing the patch with "make universe" -- will take some time on RE>> a 800MHz CPU. RE>> RE>Universe built; patch committed to 6.0-CURRENT. Thanks. harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: netgraph only on i386/ia64 - why ?
On Tue, 17 Aug 2004, John Polstra wrote: JP>On 17-Aug-2004 Harti Brandt wrote: JP>> On Mon, 16 Aug 2004, Bjoern A. Zeeb wrote: JP>> JP>> BAZ>Hi, JP>> BAZ> JP>> BAZ>It seems netgraph is only build on ia64 and i386. JP>> BAZ>Can someone please explain why ? JP>> JP>> Until around april I used all the ATM related Ng stuff regularily (this JP>> include ng_socket, all the stuff under netgraph/atm). I think this should JP>> just be enabled. Unless build problems have been introduced since then, JP>> it should just be enabled. JP> JP>There is one problem with netgraph on 64-bit platforms. The ng_msghdr JP>struct is 52 bytes / 4-byte aligned (see ng_message.h). That means JP>the message payload is not well-aligned for 64-bit platforms. It JP>would be nice to fix that (and bump NG_VERSION, of course). Nobody JP>ever guaranteed that the message payload would be aligned, but it JP>makes things a lot more convenient. Oh. That would be good to fix. I assumed that the payload is correctly aligned and never checked that. This seems magically to work (even in the kernel). I suppose that cannot be fixed by check that a universe can be built? harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: netgraph only on i386/ia64 - why ?
On Mon, 16 Aug 2004, Bjoern A. Zeeb wrote: BAZ>Hi, BAZ> BAZ>It seems netgraph is only build on ia64 and i386. BAZ>Can someone please explain why ? Until around april I used all the ATM related Ng stuff regularily (this include ng_socket, all the stuff under netgraph/atm). I think this should just be enabled. Unless build problems have been introduced since then, it should just be enabled. harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packing netgraph structs
On Thu, 1 Jul 2004, Anil Madhavapeddy wrote: AM>On 1 Jul 2004, at 13:48, Roman Kurakin wrote: AM>> AM>> If this is a problem why can't you make some wrapper that will pack/unpack AM>> written on C, AM>> which will be a lib for you? AM> AM>Because I want to minimise the size of the foreign bindings - this would AM>require C code for every single Netgraph struct. If they were packed, I AM>could just do it all in OCaml. AM> AM>Isn't this a problem for other language bindings as well, or is everyone AM>doing Netgraph userland hacking in C at the moment? Packing structs is a evil thing to do because this requires non-standard compiler support. Traditionally this was done with carefully designing the struct and inserting explicit spare fields where the compiler would pad. Unfortunately with decreasing $/bit for memory this knowledge has been lost and in any case it helps only for a concrete compiler/platform combination. So why can't you just guess the padding and handle it explicitely? Have a look at ng_parse.c. harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 2 Harti
Hello,
On Thu, 1 Jul 2004 [EMAIL PROTECTED] wrote:
Your supplied exampel of connection between two bsd/hatm machines using NG
nodes and Inet hooks works fine.
But those 2 machines works as an IP Bridge. We need Ethernet bridge. So
we've tried to connect hatm<->em adapters through netgraph and this
connection also works fine. We have an ethernet bride now.
We've extended vpi bits as you suggested, but one problem stil remains.
the control message
"msg hatm0: cpcsinit {name="sig1" aal=5 vci=5} sets default flag to
0x10.
This configuration works between 2 BSD Machines, but doesn't when one of
the is for example ATM Switch with RFC 1483 feature. Would you provide us
with some information of how to make Ethernet bride connection between
FreeBSD and other vendor supporting RFC 1483 (usin netgraph).
We've tried to change connection parameter for vcc channel usig:
"msg hatm0: cpcsinit {name="sig1" flags=xx aal=5 vci=5}, where x
was 0x0002, and many others, but found that atmconfig always shows only
0x10.
I don't fully understand what you want to do. If you want just to route
your traffic through the FreeBSD machine, then that should work without
any additional flags:
--- -
If machine1 and ATM-switch speak RFC1483 and you just need to tunnel the
traffic through the FreeBSD that you should be fine with just connecting
the hooks from the en0 and the hatm0 together and cpcsinit both with aal=5
and no flags. This way the FreeBSD machine transparently moves the AAL5
frames between the two links (think of a poor man's ATM switch with a
PVC). The FreeBSD's IP stack doesn't see any of the traffic in this case.
The LLC flag comes into the game if you want to pass the AAL5 frames
to/from the FreeBSD's IP stack. The LLC encapsulation is done just above
the AAL layer and below the IP layer. But in this case you need to route
the packets through FreeBSD's IP layer.
What you cannot easily do is have the packets transparently routed between
machine1 and ATM-switch AND see them in FreeBSD's IP layer. That would be
a kind of hub at the AAL layer.
If you want to speak with the ATM switch from FreeBSD per RFC 1483:
--
then you can just use the 'atm natm' command. The LLC flag (0x2) is
attached to the route, not the VC in the driver, because the LLC
encapsulation is done above the driver (see also natmip(4) byte 0 of the
LL address in the route command) so you wont see it in atm's output of the
VC table, but you'll see it in netstat -r output.
harti
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problems in NATM0 and NG0 interfaces
On Wed, 30 Jun 2004 Donatas_G./[EMAIL PROTECTED] wrote:
Hello,
You CAN use hatm with harp. Just list your interfaces in the
natm_interfaces variable in /etc/rc.conf. For example:
natm_interfaces="hatm0 hatm1"
hmmbut in NOTES file, there is a comment before describing hatm driver:
"ATM realated options (Canor version)
This driver cannot be used with HARP ATM stack"
it seems to be true, as it is not possible to create virtual ATM interfaces
using ATM command.
Truth, atmconfig seems to be working with hatm driver, but HOW to create
virtual ATM interfaces using that command line?I did not found anything
realated to virtual interfaces it manual of atmcinfig.
Well, as I said, you need to load if_harp:
kldload if_harp
AFTER loading if_hatm.
The you will see an hatm0 physical interface via 'atm show interface'. This
interface should behave exactly like other HARP interfaces. The comment
in NOTES is insofar correct as you cannot directly use hatm with HARP, but you
need the if_harp pseudo-driver between.
We've tried to attach iface type ng nodes (inet or atm hooks) to hatm0,
but
no atm parametres was possible to set to ng interfaces.
can anyone tell a short way in crating different ng atm interfaces?
Generally this is done with the atmconfig tool (see natmip(4) and the
natm sub-command of atmconfig(8)).
we are now going to try it
ps: thanx for netgraph example. It really works fine. But vpi parameter is
not accepted by hatm0 using cpscinit {name="hook" all=5 vpi=5 vci=5} -
interesting why?In ng_atm manual, in cpcsinit explenation there is such
parametter described. Also we cannot create vlan's yet, because IFACE Inet
type nodes are not ethernet nodes. So we'r going to try to use eiface-type
nodes instead of iface.
You may want to change HE_CONFIG_VPI_BITS and HE_CONFIG_VCI_BITS in
/usr/src/sys/dev/hatm/if_hatmconf.h (the sum must be 12 so you must change
both). Currently it is configured for 2 VPI bits. That gives you a maximum VPI
of 3.
harti
PS: your e-mail address seems not to work. Mail sent directly to you is
bounced. harti.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problems in NATM0 and NG0 interfaces
On Tue, 29 Jun 2004 Donatas_G./[EMAIL PROTECTED] wrote:
we have HE155 Series ForeRunner adapters used with intel rack systems.
hatm0 driver is not supported by harp, so in order to use atm interfaces,
we've decided to configure hetgraph interfaces (ng) on FreeBsd 5.2.1
You CAN use hatm with harp. Just list your interfaces in the
natm_interfaces variable in /etc/rc.conf. For example:
natm_interfaces="hatm0 hatm1"
will load the if_harp driver (that is the glue between the NgATM drivers
and harp, and it will issue an ifconfig up for both hatm0 and hatm1.
You'll then find physical HARP interfaces with the same names.
interfaces are needed to split common internet flow to the national and
world flows. Also different interfaces are needed to support different
types of clients.
I can't parse this. Do you mean you need several virtual interfaces on top
of a physical interface?
We've tried to attach iface type ng nodes (inet or atm hooks) to hatm0, but
no atm parametres was possible to set to ng interfaces.
can anyone tell a short way in crating different ng atm interfaces?
Generally this is done with the atmconfig tool (see natmip(4) and the
natm sub-command of atmconfig(8)).
It is also possible to put virtual interfaces on top of single ATM
PVCs, although there is no single configuration tool for this yet:
you just connect your interface NG node to any hook of the ATM node (use
any name except the four fixed in ng_atm(4)). Then you issue an
cpcsinit command to the ng_atm node to initialize the PVC. This goes
something like this:
ngctl connect hatm0: iface: foo link
(given that the hook 'link' of the node 'iface:' is the lower end of the
virtual interface).
ngctl msg hatm0: cpcsinit '{aal=5 vci=77 name="foo"}
you can also specify traffic parameters. See ng_atm(4).
ng_eiface might be a candidate node type for the virtual interface
although I didn't try this.
harti
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: shutdown node VS disconnect all hooks
On Fri, 28 May 2004, Julian Elischer wrote: JE>> If you do that, I suppose you need to edit all the nodes, right?. In that JE>> case could you please convert the initialisation of the typestructs JE>> to use C99 sparse initialisation? In that case future changes will be a good JE>> deal easier. JE> JE>actually I don't know if you do need to edit the nodes JE>types.. At one time it was true that unassigned elements on JE>the end will be NULL. Sure they will, but this will confuse the next one who is adding a new operation. I was just thinking: 'In the case that Gleb has nothing else to do he could as well just take the chance...' :-) harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: shutdown node VS disconnect all hooks
[Sorry, I just deleted the original mail, so I use Julian's to answer] On Thu, 27 May 2004, Julian Elischer wrote: JE>On Fri, 28 May 2004, Gleb Smirnoff wrote: JE> JE>> So, what about adding one more netgraph method into struct ng_type, say JE>> ng_preshutdown_t? This method is called first in ng_rmnode(), and then JE>> current shutdown sequence is followed. We will set it to NULL in all existing JE>> nodes, and create a method in ng_tee, which calls ng_bypass(). Future JE>> implementations may use this method to send "goodbye" messages down hooks when JE>> shutting down. JE> JE>That sounds like a much better solution. Node shutdown is done in 2 JE>parts just as node connection is done in 2 parts. JE> JE>> And this will be a POLA-friendly solution - we will not lose functionality JE>> of RELENG_4 (which mpd relies on), and we will not break nodes which JE>> rely on current shutdown sequence. JE>> JE>> What's your opinion? If it is positive - I'll send patches. JE>> JE> JE>That is a very workable solution. If you do that, I suppose you need to edit all the nodes, right?. In that case could you please convert the initialisation of the typestructs to use C99 sparse initialisation? In that case future changes will be a good deal easier. harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to reset admin's password on 3com superstack ?
On Mon, 24 May 2004, [iso-8859-1] Supote Leelasupphakorn wrote: SL>Hi...lists SL> SL> As the subject said, I have forgot admin's password SL>of my 3com switching it's model is "3300 SuperStack" SL>I'd like to know is there any way to reset admin's password ? SL> SL>CC to my email address is appreciated. If you google around on the net you'll find two possible ways: 1. You're lucky and your software version has one of the backdoors that you find on the net. 2. You connect your switch to another via those special connectors on the back. For me neither of those worked, but fortunately SNMP was enabled on the switch and the write community was something like 'private' (don't remember exactly). The passwords are in the MIB and I could write them via snmpset. If neither of those work, you'll better get a new one, because 3com appears to charge real money for help in those cases. harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: protecting netgraph calls from outside of the network context
On Thu, 20 May 2004, Dmitri Denissov wrote: DD>Currently netgraph code uses splnet/splx to protect timeout calls. DD>This doesn't work with 5.2 SMP kernel. What is the proper method DD>here for a custom netgraph node? Is the Giant lock only the way? Have a lock at the ng_timeout/ng_untimeout functions in ng_base.c. These should do the proper locking. harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: new arp code snapshot for review...
On Tue, 18 May 2004, Luigi Rizzo wrote: LR>On Tue, May 18, 2004 at 02:00:28PM +0100, Doug Rabson wrote: LR>> On Tue, 2004-05-18 at 09:48, Luigi Rizzo wrote: LR>> > I will try to remove as many assumptions as possible. LR>> > thanks for the feedback. LR>> LR>> I think that in your prototype, the only assumption was in struct LR>> llentry. I would suggest defining it as something like: LR> LR>to be really flexible, both l3_addr and ll_addr should be LR>variable size (v4,v6,v8 over 802.x,firewire,appletalk,snail-mail), LR>then things rapidly become confusing and inefficient. LR>I would like to keep the ipv4 over ethernet case simple and quick, even LR>if this means replicating the code for the generic case (and this LR>is one of the reasons i have stalled a bit on this code -- i want LR>to make up my mind on what is a reasonable approaxch). The most common use of that table is to have an l3_addr and search the ll_addr, right? In that case making ll_addr variable shouldn't have a measurable influence on speed. Variable l3_addr could be different though. harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: new arp code snapshot for review...
On Sun, 16 May 2004, Doug Rabson wrote: DR>On Sunday 25 April 2004 17:49, Luigi Rizzo wrote: DR>> Here is a snapshot of the new arp code that i have been working on DR>> lately, based a on Andre's ideas. (I say 'ARP' for brevity, what i DR>> mean is the layer3-to-layer2 address translation code -- arp, aarp, DR>> nd6 all fit in the category). DR> DR>Sorry for the delay but I've only just had reason to look at the arp DR>code since I've recently been working on an implementation of rfc2734 DR>IP over firewire. In your patch, you assume that the size of the DR>link-level address is always six bytes. This assumption is not valid - DR>from the looks of the existing arp code, people went to great lengths DR>to avoid making this assumption throughout the networking code. DR> DR>For IP over firewire, the link-level address is sixteen bytes. Other DR>link types have various sizes. You must use ifp->if_addrlen in the DR>generic code to cope with this correctly. Sorry to step in that late, but I'm currently moving jobs. I had the same comment. The ARP table could be used for the various IP over ATM address mappings. In that case it needs to support 20 byte NSAPs with and optional subaddress (also 20 byte) and variable size E.164 addresses. harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: what is the story on if_index allocation ?
On Wed, 21 Apr 2004, Petri Helenius wrote: > Luigi Rizzo wrote: > > >Can someone explain what is the goal ? Reuse a number if an > >interface has the same name of a previously existing one and > >the index is free ? And does it make sense, anyways, or > >we could just simplify that code and just reuse the first > >available entry in ifindex_table[] ? > > > > > The optimal course of action (from management software point of view) is > to retain as static ifName to ifIndex mapping. If the index changes for > the same interface, you're supposed to have lower sysUpTime than on > previous query. That mapping certainly has problems with interface renaming. Currently there is no way of getting at the driver's name of the interface. harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: what is the story on if_index allocation ?
On Mon, 19 Apr 2004, Bill Fumerola wrote: > i disagree that this logic belongs outside the kernel in the snmp agent. > an inconsistant if_index makes it difficult and error prone for using > the index in multiple utilities whose data may be combined/joined/scaled > with information from the snmp agent's IF-MIB/ifXTable tables. The question is based on what do you decide to give an interface the same index? Same hardware name? Same PCI slot? Same MAC address (what about interfaces without MAC addresses and virtual interfaces)? Same IP address (what about interfaces without IP address)? In the bSNMP daemon currently I have two classes of interfaces: real ones and 'dynamic' ones. For real ones I remember their name through the uptime of the daemon and assign them the same index when they re-appear (by loading/unloading the driver) with the same name. Actually I think that an application (statistics or others) should look at the timestamp of the last change of an interface and assume that the interface is another one even if it has the same index if the timestamp changed. harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: what is the story on if_index allocation ?
On Mon, 19 Apr 2004, Brooks Davis wrote: > On Mon, Apr 19, 2004 at 11:09:12AM -0700, Luigi Rizzo wrote: > > > > I am a bit unclear -- how do we allocate if_index values for > > network interfaces ? > > I thought the strategy was allocate them sequentially, and > > only reuse numbers at the top of the allocated range. > > But then i see if_findindex() is quite complicated, and > > seems to look for hints using resource_string_value() and > > resource_find_dev() to possibly recycle old indexes below > > if_index. > > > > Can someone explain what is the goal ? Reuse a number if an > > interface has the same name of a previously existing one and > > the index is free ? And does it make sense, anyways, or > > we could just simplify that code and just reuse the first > > available entry in ifindex_table[] ? > > Even the current allocation strategy does not guarantee that > > indexes reflect the order of creation of interfaces, if that > > is what we care about. > > harti recently mentioned that the SNMP RFC requires that interfaces > keep the same index across various events including loading and > unloading the driver. I suspect this code is an attempt to handle that > case. Keying off of lladdrs is probably as close as you're going to get > to obeying that requirement in the kernel. I'm not convinced we should > worry about it in the kernel. The whole concept of the "same interface" > is rather dependent on the particular application context. For > instance, when dealing with virtual interfaces on a tunnel server, > interfaces could be created and destroyed on demand and if you wanted to > do accounting via SNMP indexs should be consistant for each account. > I'm tempted to push the whole problem off to userland where appropriate > application dependent policies can be implemented. After some thinking about the issue I think that the concept of 'the same interface' isn't valid anymore - it comes from times, where you had only hardware interfaces that you could change only by opening the computer. Nowadays with hot-plugable and several kinds of virtual interfaces that becomes very moot. Even with normal interfaces the whole thing is questionable. If you have, for example, a router that has xl0 to the outer world and xl1 to you local network and you swap these two interfaces, then you probably want (from the management point of view) xl0 now to become the 'same' as xl1 was - just the connection to the local network. It would be extremly hard to implement this in the kernel or even in a general purpose SNMP daemon. Given the complexity of that stuff, I think I throw it out of the SNMP daemon in the next release. harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI ADSL card and PPPoA
On Sun, 28 Mar 2004, User Ernie wrote: UE>> On Sat, Mar 27, 2004 at 11:32:55PM +1000, User Ernie wrote: UE>> > Is it possible to use some like ng_ppp and mpd to hook to this card so I UE>> > can establish a PPPoA session? If so can anyone suggest an mpd config? UE>> UE>> Far simpler; if it supports the NATM API, you should be able to run UE>> userland ppp to begin with over it. This is documented in the Handbook UE>> now. Whilst userland PPP is 'teh suck', for the purposes of verifying that UE>> your configuration is working, it's useful. UE>> UE>> BMS UE>> UE> UE>I looked in the handbook orgilginally, chapter 18.6 is where I learnt about UE>mpd. The userland PPP example for PPPoA seemed to use and externam USB UE>modem. Which section is the NATM example in? I think there is no. I tried to contact Brian Somers to get some hints about the ppp/netgraph interface, to write a corresponding section, but without luck. harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Nodes having common properties. Was: kern/63864: [patch] new control message for ng_iface(4) - getifindex
On Fri, 19 Mar 2004, Gleb Smirnoff wrote:
GS>On Fri, Mar 19, 2004 at 12:13:37PM +0100, Harti Brandt wrote:
GS>H> It would be nice if it would be possible to classify a node to belong to
GS>H> more than one family. I think, that the functionality provided by the
GS>H> family stuff is more like the 'interface' stuff in Java. One example where
GS>H> this can be used are specialisation of interface nodes. I'm about to
GS>H> commit an ATM pseudo device node that will (among other uses) be very
GS>H> helpful for automatic testing of the ATM stuff. As such it implements the
GS>H> network interface messages (GET_IFINDEX, ...) plus common messages with
GS>H> the real ATM device node (ng_atm; GET_CONFIG, GET_VCCS, ...). I think
GS>H> there are other uses too.
GS>H>
GS>H> I see at least two ways of implementing this:
GS>H>
GS>H> 1) by handling the assignment to a family via a generic function, that,
GS>H> for example, manages an array of family/data pairs for each node. Instead
GS>H> of simply checking the family type when receiving a message you'll have
GS>H> to loop around (control messages handling performance shouldn't be a
GS>H> bottleneck).
GS>H>
GS>H> 2) making family message handling explicite instead of implicite. In
GS>H> foo_rcvmsg you would have something like:
GS>H>
GS>H> switch (cookie) {
GS>H>
GS>H> ...
GS>H>
GS>H> case NGM_IFACE_FAMILY_COOKIE:
GS>H> ng_handle_iface_family_msg(...);
GS>H> break;
GS>H>
GS>H> case NGM_ATMIFACE_FAMILY_COOKIE:
GS>H> ng_handle_atmiface_family_msg(...);
GS>H> break;
GS>H>
GS>H> ...
GS>H> }
GS>H>
GS>H> The 2nd variant seems slightly more easy to implement and more flexible
GS>H> than the first.
GS>
GS> The 2nd variant seems very familiar (may be even same) as my first
GS>proposal. In private discussion with Ruslan, he said that this approach
GS>looks like a hack, and is not extendible. And he convinced me. Really,
GS>this approach means that message handlers are in the ng_foo.c files, and
GS>joining family doesn't mean automagic support of family messages. Also,
GS>it leads to code dublication, which is bad.
GS>
GS> I'd prefer first idea. In its case all you need to support family
GS>messages, is to call two methods
GS>
GS> NG_JOIN_FAMILY(NG_FAMILY_ATM, (void *)some_atm_data);
GS> NG_JOIN_FAMILY(NG_FAMILY_IFACE, (void *)priv->ifp);
GS>
GS> from your constructor method. Family messages must be supported by
GS>netgraph, not by nodes.
>From the point of code duplication and extendibility both approaches are
equivalent. In the second case you have the same three lines in the rcvmsg
function of every node that supports a given familiy (this is reduceable
to 1 line by defining appropriate macros), in the first one you have the
same line in every constructor. Perhaps I made not clear that the message
handling function for the familiy is not in the node's code nor in the
netgraph base code, but in a family file (in both cases) and module.
But I have no strong opinion: either way does it as long as it allows
multiple interfaces to a given node.
harti
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Nodes having common properties. Was: kern/63864: [patch] new control message for ng_iface(4) - getifindex
On Wed, 17 Mar 2004, Gleb Smirnoff wrote:
GS>So I have proposed a different approach, and ru liked it. What will
GS>you say about it?
GS>
GS>Two new fields in struct ng_type are introduced:
GS>- u_int32_t family, a generic node type. All current nodes have this field
GS> as 0, they have no similar properties. For example, interface node family
GS> has value of 1.
GS>- void *family_data, a pointer to a family specific data. In case of interface
GS> family, it'll be struct ifnet *.
GS>
GS>A macro for assigning to a specific family is written. This macro sets type
GS>and sets pointer to proper data.
GS>
GS>Within this approach we have got kind of inherited properties. The only thing
GS>node needs to join some family, is to set its family and pass pointer to data.
GS>After this, it will support all family messages. Family specific messages really
GS>never reach the node code. They are handled in ng_base.c.
It would be nice if it would be possible to classify a node to belong to
more than one family. I think, that the functionality provided by the
family stuff is more like the 'interface' stuff in Java. One example where
this can be used are specialisation of interface nodes. I'm about to
commit an ATM pseudo device node that will (among other uses) be very
helpful for automatic testing of the ATM stuff. As such it implements the
network interface messages (GET_IFINDEX, ...) plus common messages with
the real ATM device node (ng_atm; GET_CONFIG, GET_VCCS, ...). I think
there are other uses too.
I see at least two ways of implementing this:
1) by handling the assignment to a family via a generic function, that,
for example, manages an array of family/data pairs for each node. Instead
of simply checking the family type when receiving a message you'll have
to loop around (control messages handling performance shouldn't be a
bottleneck).
2) making family message handling explicite instead of implicite. In
foo_rcvmsg you would have something like:
switch (cookie) {
...
case NGM_IFACE_FAMILY_COOKIE:
ng_handle_iface_family_msg(...);
break;
case NGM_ATMIFACE_FAMILY_COOKIE:
ng_handle_atmiface_family_msg(...);
break;
...
}
The 2nd variant seems slightly more easy to implement and more flexible
than the first.
harti
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to test my own netgraph node ?
On Tue, 16 Mar 2004, [iso-8859-1] manish gautam wrote: mg> mg>Hi sir... mg> mg>I have modified ng_tee.c to design my own netgraph mg>node. But i dont know how to test that it is working. mg> mg>1.Tell me the right procedure to test it. mg> mg>2.How can i pass incoming packet through it ? mg> mg>3.How can i print incoming packet info on prompt ? That heavily depends on what your node does. You may want to have a look at nghook(8). You may put it on top of other nodes that emit traffic (ng_ether). harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Byte counters reset at ~4GB
On Mon, 15 Mar 2004, Brooks Davis wrote:
BD>On Mon, Mar 15, 2004 at 07:48:21PM -0500, Mike Jakubik wrote:
BD>> Max Laier said:
BD>>
BD>> > Sure, you measure it ;) ... no, of course it is more expensive to update a
BD>> > 64bit counter on a 32bit arch, but the key (once again) is descision:
BD>> > While
BD>> > (almost) all of the pf counters are 64bit types you can configure it not
BD>> > to
BD>> > use the loginterface or whatsoever more. So it's up to you: You need 64bit
BD>> > counters? You shall have them! You need *fast* 64bit counters? AMD sells
BD>> > nice processors (they say)! ... you get the idea.
BD>>
BD>> Got it. In just curious though... realistically, how big of an impact on
BD>> performance is this on a modern CPU? Is it not simply the original 32bit
BD>> calculation x 2?
BD>
BD>No, you have to do overflow handling so that adds some to the cost.
BD>
BD>I was curious what the actual overhead was so I ran the following
BD>program with both uint32_t and uint64_t counters. With 64-bit counters,
BD>it was a bit over four times slower on a the dual 2.2GHz Xeon (~2sec vs
BD>~8.4sec). On a dual opteron, the 32-bit math had a slight edge, but
BD>not much. Intestingly, runtime was longer then on the Xeon (~3.1s for
BD>32-bit and ~3.8 for 64-bit.)
BD>
BD>If you do this test, be sure not to use any optimizer flags or the whole
BD>loop gets optimized out.
BD>
BD>-- Brooks
BD>
BD>#include
BD>#include
BD>
BD>int
BD>main (int argc, char **argv)
BD>{
BD> uint32_t j = 0;
BD>
BD> for (j = 0; j < 10; j++) {}
BD> printf("%d\n", j);
BD>}
Isn't the actual problem the required atomicity? While on 32-bit
architectures you can increment a 32-bit value without taking a lock,
you need a lock to increment a 64-bit value.
harti
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Who wants SACK? (Re: was My planned work on networking stack)
On Tue, 9 Mar 2004, Mike Silbersack wrote: MS> MS>On Tue, 9 Mar 2004, Kevin Oberman wrote: MS> MS>> Selective ACKnowledgment (SACK) allows acknowledgment of received MS>> packets in a TCP window so that only the missing/damaged packet needs to MS>> be re-transmitted. This is normally of little value on a LAN where ACKs MS>> arrive quickly and windows are smaller and no use on slow circuits. On MS>> fat pipes with latency and big windows it is a huge win as it allows you to MS>> recover much faster from a packet drop. If you don't have SACK, you need MS>> to re-transmit all of the packets in flight within the window while MS>> with SACK, you need only retransmit the dropped packet(s). If you have a MS>> 10 or 20 MB window, this is a big deal. MS> MS>That's not correct. Non-SACK TCP doesn't drop any additional packets vs MS>SACK. The difference is that SACK allows the transmitter to transmit the MS>packet which fills the "hole" and then immediately start transmitting new MS>data (or fill other holes.) Non-SACK senders have to wait to receive an MS>ACK after retransmitting the hole in order to find out if there are other MS>holes which must be filled or if new data can be transmitted. MS> MS>SACK itself really doesn't do much, it's all the new congestion control MS>schemes (FACK, Rate Halving, etc) that come shipped with most SACK MS>implementations that do the work and contain most of the complexity. For satellite pipes with drops that are not the result of congestion, but of transmission errors SACK helps. With congestion control only you get no throughput no matter what you do (I did some tests with a simulated 50MBit/sec GEO link with errors). But this is a rather limited application. harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/63864: [patch] new control message for ng_iface(4) - getifindex
On Mon, 8 Mar 2004, Gleb Smirnoff wrote: GS>On Sun, Mar 07, 2004 at 03:02:28PM -0800, Ruslan Ermilov wrote: GS>R> Synopsis: [patch] new control message for ng_iface(4) - getifindex GS>R> GS>R> State-Changed-From-To: open->closed GS>R> State-Changed-By: ru GS>R> State-Changed-When: Sun Mar 7 15:01:03 PST 2004 GS>R> State-Changed-Why: GS>R> Committed with tiny modifications, thanks! GS> GS> I have one more idea. Currently we have got 3 interface nodes: ng_ether, ng_iface, GS>ng_eiface. 2 of them already support "getifindex" message, imagine I (or someone else) send GS>you patch tomorrow, which adds support to ng_eiface. OK, now all three support. May be GS>in future some new interface nodes will be developed. Don't forget about ng_atm... harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Viewing multicast group membership?
On Mon, 10 Nov 2003, Bruce M Simpson wrote:
BMS>On Mon, Nov 10, 2003 at 08:49:40PM +0100, Harti Brandt wrote:
BMS>> I have a patch that creates a sysctl that returns the per-interface
BMS>> multicast address lists that mimics the sysctl that returns the interface
BMS>> address lists. If you can wait until tomorrow I'll send you the patch.
BMS>> This is running for more than two years on all my machines.
BMS>
BMS>Sounds like what I was planning to do anyway. Ok, look forward to it. :^)
Here you are. This was even once (about a year ago) reviewed by someone,
but did make it into the tree, because I did not insist.
harti
--
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]Index: sys/socket.h
===
RCS file: /export/cvs/freebsd/src/sys/sys/socket.h,v
retrieving revision 1.72
diff -u -r1.72 socket.h
--- sys/socket.h5 Mar 2003 19:24:24 - 1.72
+++ sys/socket.h11 Nov 2003 08:29:35 -
@@ -351,13 +351,15 @@
#define NET_RT_DUMP1 /* dump; may limit to a.f. */
#define NET_RT_FLAGS 2 /* by flags, e.g. RESOLVING */
#define NET_RT_IFLIST 3 /* survey interface list */
-#defineNET_RT_MAXID4
+#defineNET_RT_IFMALIST 4 /* return multicast address list */
+#defineNET_RT_MAXID5
#define CTL_NET_RT_NAMES { \
{ 0, 0 }, \
{ "dump", CTLTYPE_STRUCT }, \
{ "flags", CTLTYPE_STRUCT }, \
{ "iflist", CTLTYPE_STRUCT }, \
+ { "ifmalist", CTLTYPE_STRUCT }, \
}
#endif /* __BSD_VISIBLE */
Index: net/rtsock.c
===
RCS file: /export/cvs/freebsd/src/sys/net/rtsock.c,v
retrieving revision 1.94
diff -u -r1.94 rtsock.c
--- net/rtsock.c8 Nov 2003 23:36:30 - 1.94
+++ net/rtsock.c11 Nov 2003 08:29:35 -
@@ -85,6 +85,7 @@
static int rt_xaddrs(caddr_t, caddr_t, struct rt_addrinfo *);
static int sysctl_dumpentry(struct radix_node *rn, void *vw);
static int sysctl_iflist(int af, struct walkarg *w);
+static int sysctl_ifmalist(int af, struct walkarg *w);
static int route_output(struct mbuf *, struct socket *);
static voidrt_setmetrics(u_long, struct rt_metrics *, struct rt_metrics *);
static voidrt_dispatch(struct mbuf *, struct sockaddr *);
@@ -684,6 +685,10 @@
len = sizeof(struct if_msghdr);
break;
+ case RTM_NEWMADDR:
+ len = sizeof(struct ifma_msghdr);
+ break;
+
default:
len = sizeof(struct rt_msghdr);
}
@@ -1014,6 +1019,59 @@
return (error);
}
+int
+sysctl_ifmalist(af, w)
+ int af;
+ register struct walkarg *w;
+{
+ register struct ifnet *ifp;
+ struct ifmultiaddr *ifma;
+ struct rt_addrinfo info;
+ int len, error = 0;
+
+ bzero((caddr_t)&info, sizeof(info));
+ /* IFNET_RLOCK(); *//* could sleep XXX */
+ TAILQ_FOREACH(ifp, &ifnet, if_link) {
+ if (w->w_arg && w->w_arg != ifp->if_index)
+ continue;
+ TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) {
+ if (af && af != ifma->ifma_addr->sa_family)
+ continue;
+ if (jailed(curproc->p_ucred) &&
+ prison_if(curproc->p_ucred, ifma->ifma_addr))
+ continue;
+ info.rti_info[RTAX_IFA] = ifma->ifma_addr;
+ info.rti_info[RTAX_IFP] = NULL;
+ if (TAILQ_FIRST(&ifp->if_addrhead))
+ info.rti_info[RTAX_IFP] =
+ TAILQ_FIRST(&ifp->if_addrhead)->ifa_addr;
+
+ info.rti_info[RTAX_GATEWAY] = NULL;
+ if (ifma->ifma_addr->sa_family != AF_LINK)
+ info.rti_info[RTAX_GATEWAY] = ifma->ifma_lladdr;
+
+ len = rt_msg2(RTM_NEWMADDR, &info, 0, w);
+ if (w->w_req && w->w_tmem) {
+ register struct ifma_msghdr *ifmam;
+
+ ifmam = (struct ifma_msghdr *)w->w_tmem;
+ ifmam->ifmam_index = ifma->ifma_ifp->if_index;
+ ifmam->ifmam_flags = 0;
+ ifmam->ifmam_addrs = info.rti_addrs;
+ error = SYSCTL_OUT(w->w_req, w->w_tmem, len);
+ if (error)
+ goto d
Re: Viewing multicast group membership?
On Mon, 10 Nov 2003, Bruce M Simpson wrote: BMS>On Mon, Nov 10, 2003 at 01:14:59PM -0500, Robert Watson wrote: BMS>> I can't speak to existing code for this, but I can say I have a preference BMS>> for having a sysctl version of the code available in the vague hopes that BMS>> someday we can drop the setgid kmem bit from netstat... BMS> BMS>During operation, the kernel routing socket will report multicast group BMS>joins/leaves using RTM_NEWMADDR/RTM_DELADDR messages. These contain an BMS>ifma_msghdr structure, which encapsulates multicast addresses in an address BMS>family independent manner. However, there is no mechanism to report currently BMS>existing associations. BMS> BMS>Maybe the way to go is to extend getifaddrs(), or create a new API BMS>a lot like it. Right now, it uses the NET_RT_IFLIST sysctl to retrieve BMS>the interface list; the kernel appends RTM_NEWADDR messages to the BMS>buffer contents returned by the sysctl to report each address family. BMS>The function sysctl_iflist() in net/rtsock.c is responsible for this. BMS> BMS>However, not all getifaddrs() consumers are likely to be interested in BMS>multicast associations, so this could end up adding bloat. The getifaddrs() BMS>libc function and sysctl_iflist() kernel code do not touch BMS>ifnet->if_multiaddrs at all. BMS> BMS>So my next question is: Do I create a new API function and sysctl, or BMS>integrate into the existing code path? I have a patch that creates a sysctl that returns the per-interface multicast address lists that mimics the sysctl that returns the interface address lists. If you can wait until tomorrow I'll send you the patch. This is running for more than two years on all my machines. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 64 bit packet counters
On Fri, 7 Nov 2003, Alex Hoff wrote: AH>Hi, AH> AH>We are attempting to implement the IF-MIB, which requires the use of 64 bit AH>packet counters and the differentiation between multicast and broadcast AH>pkts. Since changing the if_data (by adding new counters and changing the AH>existing to u_int64) is a bad idea, does anyone have any good ideas on how AH>to do this? I was thinking of tacking on a new struct (lets call it AH>ifx_data) on at the end of the current if_net struct with the appropriate AH>counters (i/opacket, i/obyte, i/obcast, i/omcast). Apart from having to do a AH>little double counting is there any obvious pitfals with this approach? Does AH>anyone have an better ideas? Is there currently any plans to update the AH>network stack to handle this properly? You may lookup the discussions in the mailing lists. As far as I remember the problem with 64 bit counting was that this needs locks because not on all architectures you have atomic 64bit add operations. A simple method that does not involve kernel changes (and that I plan to implement in my snmp daemon) is to periodically monitor the counters (depending on the interface speed) and detect wraps in the daemon. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: adding if_dev member to struct ifnet
On Tue, 30 Sep 2003, Brooks Davis wrote: BD>All are within other code. One example is in dev/mii/brgphy.c which a BD>phy feature is not enabled when it is attached to some MACs. A messier BD>example is in the new ATM code where interfaces are looked up by name. Where is this? harti BD>In all cases, usage is limited to a narrow set of code, but it's not BD>generally in the driver itself (in those cases, the softc is often BD>already used, say to hold the unit). BD> BD>-- Brooks BD> BD> -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ADSL PPoA or RFC1483, any solutions ?
On Sat, 4 Oct 2003, Bruce M Simpson wrote: BMS>On Thu, Oct 02, 2003 at 09:53:08AM +0200, Harti Brandt wrote: BMS>> Does PPPoA really need signalling? I tried to find any pointers to PPPoA BMS>> specification, but this seems to be not easy to find. BMS> BMS>I was probably half asleep when I wrote that answer :) it's been a stressful BMS>week. BMS>I should correct myself - more often than not ISPs just use PVCs. The userland BMS>PPP could probably be run on top of a device node exporting the PVC. What kind of device node would that need to be? A tty node? Something like ng_tty only the other way 'round? BMS>I prefer the idea of in-kernel ppp, though, for 1Mbps+ xDSL use. I suppose something like pppoed would do it by just stacking the pppoed node on top of an ng_atm node instead of ng_ether's orphan. How is PPPoE different from PPPoA? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ADSL PPoA or RFC1483, any solutions ?
On Thu, 2 Oct 2003, Petri Helenius wrote: PH>Harti Brandt wrote: PH> PH>>On Wed, 1 Oct 2003, Bruce M Simpson wrote: PH>> PH>>BMS>On Wed, Oct 01, 2003 at 02:17:59PM -0400, Barney Wolff wrote: PH>>BMS>> Are you talking about running the phone line directly to the fbsd box PH>>BMS>> with no dsl modem? PH>>BMS> PH>>BMS>Yes. Also, PPPoA in FreeBSD is currently only implemented if you use ngatm, PH>>BMS>because of the signalling involved. RFC 1483 framing is a simple bolt-on PH>>BMS>to the existing HARP drivers, but those don't support xDSL PHYs. PH>> PH>>Does PPPoA really need signalling? I tried to find any pointers to PPPoA PH>>specification, but this seems to be not easy to find. PH>> PH>> PH>Usually it does not, one just runs PPP over AAL5SNAP or AAL5VCMUX PVC. PH>However most providers seem to go for RFC1483B because it practically PH>eliminates PH>CPE configuration issues. In that case just stacking of ng_ppp (or ng_pppoe, what's the difference?) on top of ng_atm and enabling the right VCC should do it. Well, you also need to get rid of the LLC/SNAP header in between (I'm think of creating an ng_llc node). This configuration stuff could be built in into atmconfig. If someone is able to test this (has an xDSL mode, a connection and a driver for the modem) I would try to help to get this up. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ADSL PPoA or RFC1483, any solutions ?
On Wed, 1 Oct 2003, Bruce M Simpson wrote: BMS>On Sun, Jun 15, 2003 at 06:55:28AM +0200, Gianmarco Giovannelli wrote: BMS>> 1) Any viable solution with FreeBSD for doing that kinds (PPPoA or RFC BMS>> 1483) of encapsulation. BMS> BMS>Using xDSL will be difficult. There is a driver I have picked up for the BMS>Lanai chip (Efficient Networks SpeedStream 30x0 series), using an Alcatel BMS>PHY, but it's nowhere near ready for primetime yet, and I have no timeline BMS>for working on it (or funding/resources). BMS> BMS>> 2) Why FreeBSD doesn't support PPPoA in the same way it support PPPoE ? BMS>> Which are the difficulties of doing this ? BMS>> The "experts" that came to sell this migration said that PPPoA is a far BMS>> more efficient and better than PPPoE, is it true ? If PPPeA is the same protocol as PPPoE you just need to plug ng_pppoe on top of ng_atm with the VCC opened that carries the traffic and you're done. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ADSL PPoA or RFC1483, any solutions ?
On Wed, 1 Oct 2003, Bruce M Simpson wrote: BMS>On Wed, Oct 01, 2003 at 02:17:59PM -0400, Barney Wolff wrote: BMS>> Are you talking about running the phone line directly to the fbsd box BMS>> with no dsl modem? BMS> BMS>Yes. Also, PPPoA in FreeBSD is currently only implemented if you use ngatm, BMS>because of the signalling involved. RFC 1483 framing is a simple bolt-on BMS>to the existing HARP drivers, but those don't support xDSL PHYs. Does PPPoA really need signalling? I tried to find any pointers to PPPoA specification, but this seems to be not easy to find. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: adding if_dev member to struct ifnet
On Wed, 1 Oct 2003, Brooks Davis wrote:
BD>On Wed, Oct 01, 2003 at 09:34:22AM +0200, Harti Brandt wrote:
BD>> On Tue, 30 Sep 2003, Brooks Davis wrote:
BD>>
BD>> BD>All are within other code. One example is in dev/mii/brgphy.c which a
BD>> BD>phy feature is not enabled when it is attached to some MACs. A messier
BD>> BD>example is in the new ATM code where interfaces are looked up by name.
BD>>
BD>> Where is this?
BD>
BD>One example would be in sys/netatm/atm_if.c around line 1081.
Well, that's the old ATM code (HARP). An this place is not a problem,
because HARP physical interfaces live in their own name space - they
don't have a struct ifnet. A worse example is around line 1125. But, I
suppose we could just use the usual way to lookup an interface via it's
name and after that check that it is an HARP nif.
A more serious problem is how HARP allocates NIFs: the user specifies
a prefix and a number N. HARP then generates interfaces with names from
prefix0 to prefixN. This is the only place, where HARP really needs
a name and a unit number, but this is only to create a name for new
interfaces - the names are not parsed after that, so it should be no
problem to keep this stuff, except that we stuff the complete name into
if_xname.
All the other uses of if_name seem to be ("%s%d", if_name, if_unit)...
harti
--
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [netgraph] NGF_RESP
On Wed, 4 Jun 2003, Vincent Jardin wrote: VJ>Hi, VJ> VJ>I'm trying to understand how does NGF_RESP work and how can it be used ? VJ> VJ>According to ng_message.h, it is a flag that describes a response message, VJ>however are all the response messages synchronous to a request or could some VJ>messages be asynchronous ? If some messages could be asynchronous, what does VJ>receive these messages ? If you look at the NG_MKRESPONSE macro you'll see that a response has the same cookie, token and cmd code as the original command. The difference is, that the response flag is set. There is no need to send a response immediately, you can do it anytime later. I use asynchronuous messages in my ng_atm node for things like carrier change and PVC changes. I have defined a message code for this just like other message codes for the node (just with command codes above 1). The node defines a special hook 'manage'. If this hook is connected, these messages are sent to the node at the other end of the hook. The SNMP daemon connects this hook when it starts to manage the interface and so receives these asynchronuous messages. Another possibility is to configure a node number or path into the node, where it should send messages to. This technique, however, may be subject to races when nodes are created/destroyed. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
locking in network if attach again
Hi all, the following problem occured just to me. Suppose the last lines in my attach() function look something like: if_attach(...) bus_setup_intr(...) Last time we had the locking discussion it was more or less the concensus, that no locking is needed in attach() and that the last thing I do is setting up the interrupt. It seems to me, however, that the following may happen here: 1. After if_attach but before setup_intr() a process on another processor calls if_ioctl to make the interface UP and if_start() to start output. 2. while the attach routine is blocked (perhaps while an interrupt is serverd) if_start initiates output. 3. The device tries to interrupt but cannot do that (setup_intr() has not been called yet). 4. The device gets stuck, because the interrupt is lost. 5. setup_intr() is called but that does not help. Is this a possible scenario? I must admit, that such a scenarion has a rather low probability, but according to Murphy's Law, it will happen. Maybe if_attach and bus_setup_intr can be reversed. In this case the interrupt routine must be careful to not call into the network system, because the network system doesn't know anything about the interface until if_attach(). Another solution would be to lock softc before if_attach, but this would probably provoke an LOR (as I remember). Regards, harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: mallocing from if_start
On Wed, 12 Mar 2003, Jonathan Lemon wrote: JL>In article you write: JL>> JL>>Hi all, JL>> JL>>I was under the impression that the if_start function is NOT called from JL>>an interrupt context, so I should be able to call uma_zalloc_arg(..., JL>>M_WAITOK) there. I get however JL>> JL>>Mar 12 18:12:49 catssrv kernel: malloc() of "en dma maps" with the JL>>following non-sleepablelocks held: JL>>Mar 12 18:12:49 catssrv kernel: exclusive sleep mutex netisr lock r = 0 JL>>(0xc022d9c0) locked @ /usr/src/sys/net/netisr.c:209 JL>> JL>>I'm wrong with my assumption? JL> JL>if_start() can be called from interrupt context from the bridging, JL>fast-forwarding, (and now) direct dispatch codepaths. That being JL>said, the message can be ignored, I'll rework things to use a gate JL>instead of a mutex, although this seems to be catching some hidden bugs. Is there a fast method to get rid of exactly this one warning until you rework the code? It really makes debugging and testing a driver very hard. I'm working on mutexifying the driver so I need witness. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
mallocing from if_start
Hi all, I was under the impression that the if_start function is NOT called from an interrupt context, so I should be able to call uma_zalloc_arg(..., M_WAITOK) there. I get however Mar 12 18:12:49 catssrv kernel: malloc() of "en dma maps" with the following non-sleepablelocks held: Mar 12 18:12:49 catssrv kernel: exclusive sleep mutex netisr lock r = 0 (0xc022d9c0) locked @ /usr/src/sys/net/netisr.c:209 I'm wrong with my assumption? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Proper -current if_attach locking?
On Fri, 3 Jan 2003, Nate Lawson wrote: NL>I was looking into some "could sleep messages" and found some bogus NL>locking in the attach routine of many drivers. Several init a mtx in NL>their softc and then lock/unlock it in their attach routine. This, of NL>course, does nothing to provide exclusive access to a device. I assume NL>there is going to be a global IF_LOCK or something to be used in attach NL>routines. Can someone fill me in on the intended design? Probably not. I asked the same question a couple of month ago and got 0 answers. I think, there is no way, the driver itself can assure exclusive access to the device it is attaching. It *must* assume, that there is some kind of locking around the call to the attach routine. Getting the lock in the softc inside the attach routine may be neccessary, because the routine may call other functions that assume they have the lock. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: can't get trpt to run
On Wed, 13 Nov 2002, James B. Wilkinson wrote: JBW>When I try to run trpt, it reports "no namelist". If I do "nm JBW>/kernel" I get an extensive namelist. At this point I have no idea JBW>where else to look. Does anybody here have any ideas? Kernel is JBW>4.6.1-RC2. Did you build the kernel with the TCPDEBUG option. Even if you get trpt to find the namelist, you will get no usefull output, because the TCPDEBUG option is utterly screwed up. All the people patching around in tcp_input and tcp_output didn't care about TCPDEBUG so there are a lot of cases where you don't get a debug record. I have a patch for current, that let you at least trace normal TCP connections and use dbsd. If I get some spare time, I may make a bug report. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: NFS functions does *NOT* check if they really have allocatedany memory
On Wed, 6 Nov 2002, Iasen Kostov wrote: IK> IK> IK>On Tue, 5 Nov 2002, Archie Cobbs wrote: IK> IK>> Iasen Kostov writes: IK>> > As I experience system crushes at time of mbufs exhaustion I've compiled IK>> > a debug kernel and traced the problem. I seems the NFS functions IK>> > (nfsm_rpchead, nfsm_reqh ...) does *NOT* chek if they really have IK>> > allocated memory by MGET macro. IK>> IK>> No check is necessary if M_WAIT is specified; the M_GET() function IK>> is always successful in that case. Same for malloc(). Wrong. malloc() returns always successful with M_WAIT, M_GET not. There is a timeout the M_GET() will wait, but the it will return NULL. harti To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: How to add bpf support to if_atmsubr.c?
On Tue, 15 Oct 2002, Bruce M Simpson wrote: BMS>On Mon, Oct 14, 2002 at 11:13:05PM -0700, Guy Harris wrote: BMS>> The current CVS versions of libpcap and tcpdump, and the current BMS>> released version of Ethereal, support a DLT_SUNATM DLT_ type. SunATM's BMS>> DLPI interface supplies packets with a 4-byte pseudo-header, consisting of: BMS>[snip] BMS> BMS>Just FYI... BMS> BMS>This sounds very similar to the promiscuous cell receive option on ENI's BMS>SpeedStream 5861 router. I found the raw hex cell output was essentially BMS>a 4 byte ATM UNI header omitting the CRC byte, and the 48 bytes of the raw BMS>AAL5 cell payload. The marconi HE cards have the same format although they have no promiscous mode (although it would be easy to configure all unused connections to receveive to a free receive group, the question is whether you want this (35/packets per second for OC3)). My driver allows you to receive cells (i.e. AAL0) on any of the supported connections. BMS>Is there any open source support for the SunATM PCI cards? I see a few of BMS>them cropping up on eBay from time to time. It might be worth finding out BMS>which ASICs they use, I doubt Sun would engineer their own. Does Sun still make ATM cards? As far as I remember I saw the last SBUS cards a couple of years ago. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: How to add bpf support to if_atmsubr.c?
On Sun, 13 Oct 2002, Craig Rodrigues wrote:
CR>Hi,
CR>
CR>I am on a -current system, using patches from Harti Brandt's
CR>Netgraph ATM work:
CR>http://www.fokus.fhg.de/research/cc/cats/employees/hartmut.brandt/ngatm/
CR>
CR>I am trying to add bpf support to /src/sys/net/if_atmsubr.c so that
CR>I can use tcpdump when sending traffic over my ATM card.
CR>
CR>I've got things mostly working, but I think I'm using the
CR>wrong arguments in the bpfattach() call (I'm not familiar with
CR>bpf and just guessed, based on looking at files in the same directory).
CR>
CR>Here is the line I used:
CR>bpfattach(ifp, DLT_ATM_RFC1483, sizeof(u_int));
CR>
CR>What should I really be using?
CR>
CR>I am attaching the patch I am using, which incorporates
CR>patches from Harti Brandt, and bpf fixes from me.
You my look at dev/en. In revision 1.7 of if_atmsub.c bpf support was
moved from the generic file to the ENI driver ('as it should be').
Maybe its time to move it back. The problem is, that at attach time you
don't know what link-level encapsulation is used, because this can be
select when you establish the VCC (via the parameter 'z' (see en(4))).
So BPF_DLC_RFC1483 will not work without LLC/SNAP encapsulation.
harti
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Comments Please
On Sat, 12 Oct 2002, Luigi Rizzo wrote:
LR>On Sat, Oct 12, 2002 at 08:07:47PM -0600, M. Warner Losh wrote:
LR>...
LR>> : reveals the use of an explicit constant (6) in net/if_arp.h and
LR>> : netinet/if_ether.c; there is more of the same in net/bridge.c
LR>> : (my fault), net/if_atmsubr.c, netinet/if_ether.c, netncp/ncp_subr.c
LR>>
LR>> atmsubr? Doesn't ATM have its own constants?
LR>
LR>eh, that's the problem with explicit constants, you can never tell
LR>whether "6" is english, german or italian... in any case the
LR>relevant piece of code is:
LR>
LR> net/if_atmsubr.c: if (bcmp(alc, ATMLLC_HDR, 6)) {
LR>
LR>I have no idea if it has any relation with ethernet header sizes.
No, this is the length of an LLC/SNAP header minus the type field.
harti
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
