Re: sscanf in kernel
- Original message - > sscanf() has a kernel version declared in kernel.h. > http://www.gelato.unsw.edu.au/lxr/source/include/linux/kernel.h#L196 > > -- Saleh You must have missed the name of this mailing list, it is freebsd-net not linux-net. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: nfe driver
On Saturday 19 July 2008 14:44:02 Adam Stylinski wrote: > The controller definitely supports jumbo frames. What proof do you have of this? > I guess another question to ask would be if the newer kernel sources in > freebsd-stable have support for jumbo frames on the MCP67 in the nfe > driver. No. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/128833: [bge] Network packets corrupted when bge card is in 64-bit PCI slot
On Tuesday 18 November 2008 17:50:04 Marius Strobl wrote: > The following reply was made to PR kern/128833; it has been noted by GNATS. > > From: Marius Strobl <[EMAIL PROTECTED]> > To: =?unknown-8bit?Q?Aur=E9lien_M=E9r=E9?= <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: kern/128833: [bge] Network packets corrupted when bge card is > in 64-bit PCI slot Date: Tue, 18 Nov 2008 23:46:21 +0100 > > On Mon, Nov 17, 2008 at 02:37:51AM +0100, Aurlien Mr wrote: > > Hi > > As first check, when device is being attached, here are the values > > reported and the diff : > > > > in 32 bit slot : > > BGE_PCI_PCISTATE = 0x96 (0x86 | BGE_PCISTATE_32BIT_BUS) > > bge_flags = 0x120E (0x100E | BGE_FLAG_PCIX) > > > > in 64 bit slot : > > BGE_PCI_PCISTATE = 0x8E (0x86 | BGE_PCISTATE_PCI_BUSSPEED) > > bge_flags = 0x1A0E (0x100E | BGE_FLAG_PCIX | BGE_FLAG_64BIT) > > > > Seems logical so far, I'll try to look further. > > Apart from the problem described by davidch@ (I'm not sure > you actually have a BCM5701 A3 though, at least bge(4) doesn't > seem to be aware of that revision) the BGE_PCI_PCISTATE and > bge_flags pairs you reported don't match though; according > to BGE_PCI_PCISTATE the card isn't in a PCI-X slot in either > case (BGE_PCISTATE_PCI_BUSMODE is always set, which means > PCI) and AFAICT your motherboard chipset also doesn't > support PCI-X. However, as you noted BGE_FLAG_PCIX is set > for whatever reason in both cases, which leads to some > inappropriate initialization of the controller. As a quick > test could you please check whether replacing the "#if > __FreeBSD_version > 602101" in the driver with an "#if 0" > makes any difference to your problem? The PCI-X check which is used for I'm guessing FreeBSD 7 and newer is wrong. Older versions get it right. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bgp, is-is, ...
On Friday 05 December 2008 03:43:41 Randy Bush wrote: > openbgp is said to be the best bsd implementation of bgp. but i see > that ports/openbgpd has not been updated in a while. it is at 4.0 while > 4.3 is the current public release. Actually 4.4 is the latset release, although only available in CVS. I have prodded Henning again about updating the website/FTP site. The OpenOSPF port could use an update to 4.4. > for two full bgp feeds, is 4g of ram gonna last? or should i get 8g? A machine with 512MB of memory should have no problem with 3 maybe 4 feeds depending on BGP implementation and setup. So 2GB should be more than enough -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bgp, is-is, ...
On Friday 05 December 2008 04:28:41 Randy Bush wrote: > but no is-is? not to start an emacs/vi debate, but most of us old > pharts are is-is, as are the big old backbones (and the smarter new > ones:-). Not yet. You're welcome to help start an isisd. ;) So far BGP, OSPF, RIP and DVMRP working. OSPF6d started. > >> for two full bgp feeds, is 4g of ram gonna last? or should i get 8g? > > > > A machine with 512MB of memory should have no problem with 3 maybe 4 > > feeds depending on BGP implementation and setup. So 2GB should be more > > than enough > > cool. this will have at least two ibgp peers who have full external > transit feeds, i.e. 200k prefixes each. Ya, with how cheap memory is for anything you will most likely use there is no point not having at least 1GB and that will provide more than enough memory to work with. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Relayd (former hoststated) status for freebsd 7.0RC1
On Tuesday 15 January 2008 15:24:52 Bruce M. Simpson wrote: > Alexandre Vieira wrote: > > Hello all, > > > > I remember that there was a port (net/hoststated) where I could install > > hoststated to use with PF. Anyone can shed a light on what is the status of > > this software implementation on 7.0? > > > > Perhaps ports/net/ifstated is the answer? > > BMS ifstated and relayd (used to be hoststated) are for totally different purposes. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multilink PPP Download Speeds With Round-Robin Packets
On Thursday 17 January 2008 05:53:34 Sten Daniel Soersdal wrote: > Michael MacLeod wrote: > > Hello all, > > > > I've got two DSL lines running to my house, and two WAN NIC's > > installed in my FreeBSD router. I've been trying to get multilink ppp > > working through my ISP (TekSavvy in Canada) for the last little while, > > with mixed results. Each of my DSL lines sync's at 6016 kbits down and > > 800 kbits up. I have traffic working through the bonded connection, > > and the upload speed is 1350 kb, which is about right for a 1.6 > > megabit connection minus network overhead. The problem I'm running > > into is the download speed is only that of one of my downlinks (approx > > 5000kb, which is about right for 6 megabits minus network overhead). > > > > It is quite possible that the ISP is employing bandwidth limiting and > the limits are set to that of one ppp link (since this multilink > combines two ppp links into a single link and thus logically it could be > limited to that of one ppp connection). Read his whole post again.. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FBSD 1GBit router?
On Sunday 02 March 2008 11:23:16 Ingo Flaschberger wrote: > The 4 port card use 4x lanes. There are also 6 port adapters which use 4x lanes. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jumbo em
On Thu, Mar 16, 2006 at 08:42:09AM -0800, Jack Vogel wrote: > On 3/16/06, Yuriy N. Shkandybin <[EMAIL PROTECTED]> wrote: > > Hello > > > > I have 2 freebsd servers connected by dedicated wire via em interfaces. > > systems = 6.1-PRERELEASE #0: Tue Mar 14 11:58:23 MSK 2006 > > > > 1st) > > man em says > > MTU size for Jumbo Frames is 16114 and i'm sure i've setup this on > > freebsd-5 and probably ealier 6.0 > > But now > > ifconfig em1 mtu 16114 > > ifconfig: ioctl (set mtu): Invalid argument > > 16110 - max possible > > With newer hardware the FIFO has been getting smaller, so jumbos > even this large wont be allowed, I'm away from the code right now > but on the 82571 adapter its max is in the 9K range. > > And the man page is more than likely out of date. > > Whether you can do jumbos at all, and if so, what size you are allowed > to make them is adpater specific. > > Jack The maximum MTU size for 82571 and 82572 based adapters is 10,482. 82573 has no Jumbo support and the rest can have up to 16k. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problem with Marwell gigabit performance
On Thu, Mar 16, 2006 at 07:52:13PM +0100, OxY wrote: > media: Ethernet autoselect (1000baseTX ) > > - Original Message - > From: "Pertti Kosunen" <[EMAIL PROTECTED]> > To: "Sten Daniel S?rsdal" <[EMAIL PROTECTED]> > Cc: "OxY" <[EMAIL PROTECTED]>; > Sent: Thursday, March 16, 2006 7:18 PM > Subject: Re: problem with Marwell gigabit performance > > > >Sten Daniel S?rsdal wrote: > >>You might have a duplex mismatch problem. > > > >Isn't there only full-duplex in 1000baseTX? No. Some network cards cannot be hardcoded to a particular speed/duplex at all and can only do auto, but there is definitely half-duplex in the 1Gbps spec. 10Gbps Ethernet has finally dropped half-duplex. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OT - Quagga/CARP
On Thu, Mar 16, 2006 at 09:52:07PM +, Bruce M Simpson wrote: > On Thu, Mar 16, 2006 at 10:36:20PM +0100, Bart Van Kerckhove wrote: > > ECMP was indeed one of the features i was looking for at that time, which i > > found to be impossible. > > I just don't like the idea of moving towards another platform just for this > > reason, since I'm very happy with freebsd's performance. > > There used to be a patch for ECMP, but it was a huge hack. very dirty at > > best. > > itojun recently committed a set of ECMP related changes to OpenBSD. > Unfortunately I have not had free time to review them in any detail. > > I hope andre@ is watching this thread, it's probably on his laundry list too. > I believe other parties may have implemented the hack you are referring to. Heh. At first I read this and wasn't sure what ECMP was, I've never seen anyone use that acronym before. The code Itojun commited to the OpenBSD tree consisted of code to add multipath support for radix trees. The routing code still needs to be modified to use this new support though. radix tree with multipath support. from kame. deraadt ok user visible changes: - you can add multiple routes with same key (route add A B then route add A C) - you have to specify gateway address if there are multiple entries on the table (route delete A B, instead of route delete A) kernel change: - radix_node_head has an extra entry - rnh_deladdr takes extra argument TODO: - actually take advantage of multipath (rtalloc -> rtalloc_mpath) http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/radix.c http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/radix_mpath.c ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OT - Quagga/CARP
On Thu, Mar 16, 2006 at 11:51:44PM +0100, Bart Van Kerckhove wrote: > > Heh. At first I read this and wasn't sure what ECMP was, I've never > > seen anyone use that acronym before. > > Hmm, sorry if I used a non-common term there, it's the only abbreviation i > know of ;> I have always just used the expanded form. :) > > The code Itojun commited to the > > OpenBSD tree consisted of code to add multipath support for radix > > trees. The routing code still needs to be modified to use this new > > support though. > > > > > > radix tree with multipath support. from kame. deraadt ok > > user visible changes: > > - you can add multiple routes with same key (route add A B then route > > add A C) > > - you have to specify gateway address if there are multiple entries > > on the table (route delete A B, instead of route delete A) > > kernel change: > > - radix_node_head has an extra entry > > - rnh_deladdr takes extra argument > > I have looked into KAME before, and was puzzled to see it was in KAME, but > not in *bsd :-> There are lots of things in the KAME CVS repo that has not been integrated into any of the *BSD's. > > > > TODO: > > - actually take advantage of multipath (rtalloc -> rtalloc_mpath) > > > > > > http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/radix.c > > http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/radix_mpath.c > > I have no kernel coding experience whatsoever. How hard would it be to merge > this with freebsd? I am not a FreeBSD developer or even a user for that matter so I cannot really comment. Andre would probably be the best person to comment on how much work would be required to integrate this code. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 802.3ad?
On Tue, Mar 28, 2006 at 08:56:24PM +, Baldur Gislason wrote: > Following an unrelated discussion about "interface grouping" in OpenBSD, > I'd like to know if there are any known or planned implementations of LACP > (802.3ad) > interface teaming in FreeBSD? > FreeBSD currently has etherchannel support, but to my knowledge that will only > work for a link to a single switch and not provide the possibility of having > layer > 2 resiliance with paths to 2 switches in the same network. > Any thoughts on this? 802.3ad is the standards track replacement for EtherChannel, thus it is not what you are looking for. What you are asking for is L2 failover. OpenBSD's trunk(4) is such an implementation. I don't see anything in FreeBSD that would have the same functionality. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 802.3ad?
On Tue, Mar 28, 2006 at 07:20:15PM -0500, Richard A Steenbergen wrote: > On Tue, Mar 28, 2006 at 04:59:11PM -0500, Brad wrote: > > On Tue, Mar 28, 2006 at 08:56:24PM +, Baldur Gislason wrote: > > > Following an unrelated discussion about "interface grouping" in OpenBSD, > > > I'd like to know if there are any known or planned implementations of > > > LACP (802.3ad) > > > interface teaming in FreeBSD? > > > FreeBSD currently has etherchannel support, but to my knowledge that will > > > only > > > work for a link to a single switch and not provide the possibility of > > > having layer > > > 2 resiliance with paths to 2 switches in the same network. > > > Any thoughts on this? > > > > 802.3ad is the standards track replacement for EtherChannel, thus it is not > > what you > > are looking for. What you are asking for is L2 failover. OpenBSD's trunk(4) > > is such > > an implementation. I don't see anything in FreeBSD that would have the same > > functionality. > > Ah nothing says fun like watching systems people try to figure out > networking. As I read it, he's looking for what ye olde networking people > call "equal cost multi-path" (ECMP) layer 3 load balancing, which is of > course very different from layer 2 load balancing. :) He was not asking for ECMP. He clearly asked for a failover mechanism for two switches within the SAME Layer *2* domain. > 802.3ad/etherchannel and L2 failover are actually the same thing, just > with the load balancing algorithm turned off. Simple classic etherchannel > is really nothing more than configuring both sides to know that these are > trunk ports, and turning off forwarding among trunk members (i.e. you > don't want a frame which came in one member to go out another member, > unless you like forwarding loops). Everything else is pretty much > automagic, you don't even need to have matching hashing algorithms on each > end, just do whatever you need to do to shove the packets down the member > ports as you see fit. What does link aggregation have to do with trunk ports? Link aggregation and trunk ports can be configured separately or in a combined fashion but in this scenario there is no need or use for trunking. What you have described is still not what trunk(4) does. > 802.3ad is the standardization of Cisco's (tm) etherchannel, but the only > thing it really brings to the table is the negotiation protocol. Cisco > used a proprietary protocol called PagP, 802.3ad defines a standard > version of the same thing called LACP. Essentially all this does is signal > trunk membership information over the individual links, to prevent stupid > misconfigurations that blackhole X percent of your traffic. For example > say that you have 2 devices talking to each other with 4 trunk members, > and someone disconnects a port from one and plugs it into a third device > which has no knowledge of the trunks. The device that is still connected > to that forth port has no way to know it is blindly blackholing 1/4th of > the traffic going through this channel, without a signaling protocol. The > operation of the L2 channel itself is really no different w/LACP or PagP > or nothing, it just adds another mechanism besides "hey we don't have link > any more" to shut individual members off if they're up to no good (or if > for some reason you really don't want them utilized unless another link > goes offline). 802.3ad = EtherChannel PAgP = LACP PAgP is the negotiation protocol for EtherChannel. So LACP is not bringing anything new to the table, except getting away from Cisco propreitary standards, which is a really good thing. > As I read the man page, trunk(4) is just a classic protocolless > implementation of simple etherchannel style trunking. The round robin > option is a Bad Idea (tm) though, unless you like reordering your packets > and pissing off tcp royally. I believe FreeBSD has a netgraph > implementation of this, though I've personally never used it. In theory round robin is bad but in reality it is not as bad as is typically made out, plus it also depends on the protocols being used over this link. trunk(4) can also provide L2 failover with a primary uplink and one or more backup uplinks. trunk(4) can also work in other scenarios like for example failover between a wireless uplink and a Ethernet uplink, when the AP is within the same L2 domain (bridging AP, as opposed to a router) as the Ethernet uplink. > At the present time I don't believe fbsd makes any effort to even consider > the possibility of supporting the installation of multiple nexthops for a > route, let alone how to do it corr
Re: 802.3ad?
On Tue, Mar 28, 2006 at 10:56:46PM -0500, Richard A Steenbergen wrote: > > He was not asking for ECMP. He clearly asked for a failover mechanism > > for two switches within the SAME Layer *2* domain. > > Hrm ok I misread the original post, but I'm still not exactly sure what > the original poster wanted. 2 redundant paths out via two switches? Sounds > like an application for VRRP to me. Yes, 2 redundant paths represented by a virtual L2 interface is what he is asking for. VRRP is for providing L3 redundancy for the next hop. A completely different scenario. > The operations you're really trying to support are: > > a) Routing or bridging directly on an interface, > b) Creating a virtual L2 interface (such as link-agg) and then routing or >bridge on it, or > c) Bridging on the physical interfaces, making them members of the same >vlan, and then creating a common virtual L3 interface for the vlan. > > C) is probably what the original poster is going for, so that they can > talk to two different switches on two different physical interfaces via a > common L3 interface. And bridging would imply both interfaces active which obviously won't work, otherwise you're relying on STP to disable the other interfaces, and you don't want this for all your servers/firewalls. This is not what trunk(4) does. There is no bridging involved. > A properly designed system should be seperating out these layers > internally, in order to tie all of these features together under a common > framework. Whether you configure your L3 interface on one physical > interface, a virtual L2 interface composed of multiple member links, or an > L2 vlan which may be mapping to one or many physical ports (or having > multiple L2 vlans map to a single physical interface doing 802.1q), it > should all be the same. It should be designed this way from the lower > layers up, not from the higher layers down, with funky bridging hacks and > funky vlan hacks and funky link-agg hacks. I'm not sure what exactly it is that you're describing above. It almost sounds as if you want a flat config with no config information split up by interfaces be it physical, virtual L2 or virtual L3. I can't say as I've seen *any* OS that can do that *exactly* as you describe. With your comment about the layers stuff it sounds like you don't know how the implementation actually works. > > What does link aggregation have to do with trunk ports? Link aggregation > > and trunk ports can be configured separately or in a combined fashion but > > in this scenario there is no need or use for trunking. What you have > > described is still not what trunk(4) does. > > Ok so, I'm not sure what you think trunking means (in all fairness it IS > probably one of the most abused terms out there :P), but link aggregation > and "trunking" as it is used in this context are the exact same thing. > You're taking two seperate physical L2 channels, binding them together > under a common virtual L3 interface, applying certain rules like "don't > create forwarding loops", and using some mechanism to decide what traffic > to send to what links. Methods like "round robin" and "backup only" just > happen to be really bad/unusual hashes, but in all other respects it is > link aggregation. trunking = 801.Q/ISL and nothing else. No they're not the same. I can't help it if you confuse the terminology and do not use the terminology correctly. and this is a virtual L2 interface. The OS provides the TCP/IP stack, not the network card. > > trunk(4) can also provide L2 failover with a primary uplink and one or more > > backup uplinks. trunk(4) can also work in other scenarios like for example > > failover between a wireless uplink and a Ethernet uplink, when the AP is > > within the same L2 domain (bridging AP, as opposed to a router) as the > > Ethernet uplink. > > Like I said, that is actually just link aggregation, but with an unusual > "member aware" hash that isn't often implemented in commercial networking > devices. link aggregation implies that all links are active. this is FAILOVER. there is no hash involved. > > You can think it sucks all you want, but it makes me sleep sounder at night > > knowing I can engineer my system with higher availability in mind with > > trunk(4) > > in use than is currently possible with a FreeBSD/NetBSD/DragonFly system. > > Well, just to be clear, its the implementation that sucks not the concept. > I still think you're confused about what the "trunking" is actually buying > you though. The original motivation behind creating etherchannel style > link aggregation was for L2 switches to be able to talk to each other with > more capacity than a single link can provide. The inability to create > operational parallel paths without forwarding loops or a specific > etherchannel construct is an issue that only exists at L2. You still need > this L2 construct in order to happily work with all the devices out there > (thou
Re: Marvell 88E8053 lan controller support
On Tue, Apr 25, 2006 at 08:49:34AM +0900, Pyun YongHyeon wrote: > On Mon, Apr 24, 2006 at 07:51:05AM -0700, othermark wrote: > > Bjoern A. Zeeb wrote: > > > > > On Sun, 23 Apr 2006, OxY wrote: > > > > > >> hi! > > >> > > >> my question is when will this chip being supported by 6.x? > > > > > > for x>1 maybe. > > > > > >> or is it supported now and i didn't find the proper driver? :) > > > > > > search freebsd-net archive of Jan 2006, posting from andre oppermann > > > and do not forget to read the follow-ups. > > > > Just so other people don't have to do the rummaging, here's the link from > > gmane.org. > > > > http://thread.gmane.org/gmane.os.freebsd.current/79126/focus=79126 > > > > I too am hoping someone will step up to the plate and this support will be > > integrated into -current. > > > > I've tried their driver on CURRENT(It needs a minor modification to > compile on CURRENT). But the driver didn't recognize link and even > it panicked with numeros witness warnings when I enabled jumbo frame > support. > In addition it didn't attach for DGE530T. I think there driver is > in experimental stage not for production use. In order to support > Yukon II we need a documentation from Marvell. It is *extremely* unlikely that you will ever see documentation for the Yukon II from Marvell. At this point the only option is to reverse engineer the existing driver and/or use the new Linux driver as a source of information. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Marvell 88E8053 lan controller support
On Tue, Apr 25, 2006 at 09:18:51AM +0900, Pyun YongHyeon wrote: > On Mon, Apr 24, 2006 at 08:01:06PM -0400, Brad wrote: > > On Tue, Apr 25, 2006 at 08:49:34AM +0900, Pyun YongHyeon wrote: > > > On Mon, Apr 24, 2006 at 07:51:05AM -0700, othermark wrote: > > > > Bjoern A. Zeeb wrote: > > > > > > > > > On Sun, 23 Apr 2006, OxY wrote: > > > > > > > > > >> hi! > > > > >> > > > > >> my question is when will this chip being supported by 6.x? > > > > > > > > > > for x>1 maybe. > > > > > > > > > >> or is it supported now and i didn't find the proper driver? :) > > > > > > > > > > search freebsd-net archive of Jan 2006, posting from andre oppermann > > > > > and do not forget to read the follow-ups. > > > > > > > > Just so other people don't have to do the rummaging, here's the link > from > > > > gmane.org. > > > > > > > > http://thread.gmane.org/gmane.os.freebsd.current/79126/focus=79126 > > > > > > > > I too am hoping someone will step up to the plate and this support > will be > > > > integrated into -current. > > > > > > > > > > I've tried their driver on CURRENT(It needs a minor modification to > > > compile on CURRENT). But the driver didn't recognize link and even > > > it panicked with numeros witness warnings when I enabled jumbo frame > > > support. > > > In addition it didn't attach for DGE530T. I think there driver is > > > in experimental stage not for production use. In order to support > > > Yukon II we need a documentation from Marvell. > > > > It is *extremely* unlikely that you will ever see documentation for the > > Yukon II from Marvell. At this point the only option is to reverse > > engineer the existing driver and/or use the new Linux driver as a source > > of information. > > :-( > > Since they released source code for FreeBSD I can't see any point > not releasing the documentation. Source exists for newer Broadcom Gig chips (575x and derivatives) yet there is no documentation available for that either. > However I'm happy as they didn't released binary only driver such as nve(4). True, though nve(4) never really worked. Work has been done to resolve the binary blob issue and have a working driver. FreeBSD needs to catch up. > Getting hardware information from Linux driver source would be more > better option due to the complexity of Marvell's driver, I guess. This is most likely the right approach. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Marvell 88E8053 lan controller support
On Tue, Apr 25, 2006 at 11:36:17AM -0700, Paul Saab wrote: > Brad wrote: > > > >Source exists for newer Broadcom Gig chips (575x and derivatives) yet > >there is no documentation available for that either. > > > > > Documentation does exist, just not publically. Ya, just as documentation does exist for Yukon II but it is also not available publically. As goes for numerous other MAC/PHY/SCSI/RAID chipsets. If it's not in the hands of the right people then it does not do us any good. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can't turn on Jumbo Frames on bge0
On Fri, Jun 09, 2006 at 07:49:07PM -0400, Mikhail Teterin wrote: > Hello! > > I have a bge card, that's identified as: > > bge0: mem > 0xfe8f-0xfe8f irq 16 at device 0.0 on pci2 > > According to > http://h18000.www1.hp.com/products/quickspecs/12131_div/12131_div.HTML, > the BCM5751 support jumbo frames up to 9Kb. > > However, when I try to increase the MTU on the card even by a little bit, > I get: > > [EMAIL PROTECTED]:/misha/mi (122) ifconfig bge0 mtu 1501 > ifconfig: ioctl (set mtu): Invalid argument > > Is the hardware lacking the capability, or am I doing something wrong? There is a mistake on that web-page. None of Broadcom's PCI Express chipsets support Jumbo frames. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can't turn on Jumbo Frames on bge0
On Fri, Jun 09, 2006 at 08:05:47PM -0400, Mikhail Teterin wrote: > ?'?? 09 ??? 2006 19:57, Brad ???: > > There is a mistake on that web-page. None of Broadcom's PCI Express > > chipsets support Jumbo frames. > > Indeed. Our bge(4) manual page says: > > The BCM570x also supports jumbo frames, which can be configured via the > interface MTU setting. Selecting an MTU larger than 1500 bytes with the > ifconfig(8) utility configures the adapter to receive and transmit jumbo > frames. Using jumbo frames can greatly improve performance for certain > tasks, such as file transfers and data streaming. > > Mine is BCM5751 -- I guess, I'm out of luck... I made sure the OpenBSD man page is very clear as to what models do support Jumbo frames after having a few end-users ask similar questions. The BCM5700, BCM5701, BCM5703, BCM5704, BCM5714 and BCM5780 are capable of supporting Jumbo frames, which can be configured via the interface MTU setting. Selecting an MTU larger than 1500 bytes with the ifconfig(8) utility configures the adapter to receive and transmit Jumbo frames. Us- ing Jumbo frames can greatly improve performance for certain tasks, such as file transfers and data streaming. I would suggest doing the same thing for the FreeBSD man page since there are a number of chipset revisions which do not support Jumbo's. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LACP 802.3ad and ng_fec ?
On Sat, Sep 23, 2006 at 09:20:02AM +1000, Antony Mawer wrote: > On 23/09/2006 4:47 AM, Bart Van Kerckhove wrote: > >?zkan KIRIK <[EMAIL PROTECTED]> wrote: > >>Thanks for your reply, > >> > >>It seems that HP ProCurve 5400 series doesn't support fec trunking : > >> > >>hp(config)# trunk A3-a5 trk1 fec > >>Invalid input: fec > >> > >>hp(config)# trunk A3-a5 trk1 ? > >> trunk Do not use any protocol to create or maintain > >>the trunk. > >> lacp Use IEEE 802.1ad Link Aggregation protocol. > >> > >>hp(config)# > >> > >>Can ng_fec handshake with switch via "trunk" option instead of "fec" ? > >According to HP docs, FEC should "work" with the 'trunk' setting. > >It will loose all features tough, and just become a 'dumb' bonding-style > >thing, with no redundancy and other features. > > Yes, I was reading some HP docs yesterday and they implied that they > were removing FEC on newer switches in favour of using the IEEE > standards-based methods of trunking. even Cisco doesn't support FEC on their own switches with some of the newer gear. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Why the IPFilter version on FreeBSD6.2 is former than the one on FreeBSD6.0 ?
On Fri, 16 Mar 2007 23:27:58 +0800 "speedo chen" <[EMAIL PROTECTED]> wrote: > Hi all: > > Below links show that > > *IPFilter* has been updated from 3.4.35 to 4.1.18. On > FreeBSD6.0 *IPFilter* has been updated from 4.1.8 to 4.1.13. On > FreeBSD6.2 > > http://www.freebsd.org/releases/6.0R/relnotes-i386.html#CONTRIB > http://www.freebsd.org/releases/6.2R/relnotes-i386.html#CONTRIB > > > Could someone tell me why the version of IPFilter on FreeBSD6.2 is > former than FreeBSD6.0 ? > Thanks. The release notes for 6.0 has a typo in it. > Sincerely, > Y.T. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/147824: [msk]: watchdog timeouts
The following reply was made to PR kern/147824; it has been noted by GNATS. From: Brad Degnan To: Ihsan Junaidi Ibrahim Cc: bug-follo...@freebsd.org Subject: Re: kern/147824: [msk]: watchdog timeouts Date: Tue, 17 Aug 2010 16:57:03 -0700 On 8/17/2010 11:29 AM, Ihsan Junaidi Ibrahim wrote: > Hi, > > I'm also having this issue on the same model of motherboard except that > I'm running on a 100mbps network. I would get watchdog timeouts and TX > descriptor errors more frequently then not even there is minimal network > activity i.e. just SSH in the box. I'm running 8.1-RELEASE. > > mskc0: port 0xe800-0xe8ff mem > 0xfebfc000-0xfebf irq 18 at device 0.0 on pci2 > msk0: on > mskc0 > msk0: Ethernet address: 00:ea:01:15:c6:52 > miibus0: on msk0 > mskc0: [ITHREAD] > msk0: link state changed to UP > msk0: watchdog timeout > msk0: link state changed to DOWN > msk0: link state changed to UP > > Having TSO and MSI disabled in sysctl and loader respectively does not > appear to have any improvement. > I had to change the network interface to 100mbps half-duplex before the watchdog timeouts disappeared. It's definitely not optimal but works for me in the mean time. Full-duplex at 1000 and 100 and half-duplex at 1000 give me the watchdog timeouts and tx descriptor errors. Hope that helps > Additionally the kernel would panic when booting, this happens 1 in > every 2 tries: > > Aug 18 01:35:26 kernel: mskc0: > port 0xe800-0xe8ff mem 0xfebfc000-0xfebf irq 18 at device 0.0 on pci2 > Aug 18 01:35:26 kernel: msk0: Ultra Id 0xb4 Rev 0x05> on mskc0 > Aug 18 01:35:26 kernel: msk0: Ethernet address: ff:ff:ff:ff:ff:ff > Aug 18 01:35:26 kernel: msk0: No PHY found! > ... > Panic message ensues > > This happens regardless whether the cable is plugged or not. I haven't seen this yet, but I'm still on 8.1-PRERELEASE. I have no idea if downgrading would help. Do you have the latest bios? best, Brad ___ 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: Network performance 6.0 with netperf
At 10:49 PM +1000 2005-10-20, Michael VInce wrote: The 4 ethernet ports on the Dell server are all built-in so I am assuming they are on the best bus available. In my experience, the terms "Dell" and "best available" very rarely go together. Dell has made a name for themselves by shipping the absolutely cheapest possible hardware they can, with the thinnest possible profit margins, and trying to make up the difference in volume. Issues like support, ease of management, freedom from overheating, etc... get secondary or tertiary consideration, if they get any consideration at all. But maybe that's just me. -- Brad Knowles, <[EMAIL PROTECTED]> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Network performance 6.0 with netperf
At 9:57 AM -0500 2005-10-20, Karl Denninger wrote: Other than that, I've been pretty happy with their stuff. Sure beats a lot of other "PC" vendors out there in terms of reliability, heat management, BIOS updates, etc. Have you tried Rackable or IronSystems? I've heard that they've been pretty successful at building servers to compete pretty well on price with Dell, while also providing much better customer service, including custom-building servers to your precise requirements. -- Brad Knowles, <[EMAIL PROTECTED]> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
IPSec/NAT single gateway?
Hey there, all you network gurus, I'm attempting to connect two office LANs over the Net with a VPN. I was originally looking at vpnd, but it appears that everything I need is available in the 4.3 kernel via IPsec. The two offices are running Windows (95, 98, & NT4) on the desktop and are connected to the net via DSL. While I will have static external IPs to work with, it's likely that the DSL router is set up in PPP mode with NAT enabled. Assuming DSL router's inside address is 10.0.0.1, would I want to set my gateway's outside IF to 10.0.0.2 and the inside to 10.0.1.1, with all the desktops on the 10.0.1 network? Here's what I'm thinking: < PC net on 10.0.3.0 > | | | 10.0.3.1 | | FBSD | | 10.0.2.2 | | | | 10.0.2.1 | |DSL Router| | Inet addr ---| | | (~) ( ) ( The Big I ) ( ) (_) | | | Inet addr ---| |DSL Router| | 10.0.0.1 | | | | 10.0.0.2 | | FBSD | | 10.0.1.1 | | | < PC net on 10.0.1.0 > Will this work, or will the DSL router's NAT break IPsec? Also, are there problems with traffic to/from the Internet? Should I NAT that, or just use a 255.255.0.0 mask? Thanks much in advance, Brad Waite [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Problems with IPsec tunnel
Hello,
I'm having quite the time trying to set up a IPsec tunnel on 4.3-RELEASE.
Host-to-host IPsec works fine - I can make connections all day long between my
two gateways. But for the life of me, I can't get my windows boxen on each end
to talk to the other. I've got identical psk.txt files (rw---) on both
gateways, but 10.0.1.2 can't ping 10.0.0.2 to save its life. I've told the PCs
on each end to route the other's traffic through the near gate's inside addr,
and still no go. IP forwarding is turned on and NAT is off on both gates as
well as an "OPEN" fw ruleset. I've gone through the couple of HOW-TOs on the
net, but while I understand exactly what they're saying, and I repeat the
process, I can't get it working.
I'm pulling my hair out.
Here's a script I've borrowed from the net. The second set of spdadds for each
host is for the host-to-host IPsec.
HELP!
#!/bin/ksh
#
GW1_OUT="206.140.250.252"
GW1_IN="10.0.0.1"
GW1_NET="10.0.0.0/24"
GW2_NET="10.0.1.0/24"
GW2_IN="10.0.1.1"
GW2_OUT="206.140.251.252"
NETMASK="255.255.255.0"
HOSTNAME=`/bin/hostname`
echo "\nStarting ipsec tunnel... "
case $HOSTNAME in
gw1.domain.com)
/usr/sbin/gifconfig gif0 $GW1_OUT $GW2_OUT
/sbin/ifconfig gif0 inet $GW1_IN $GW2_IN netmask $NETMASK
/usr/sbin/setkey -FP
/usr/sbin/setkey -F
/usr/sbin/setkey -c << EOF
spdadd $GW1_NET $GW2_NET any -P out ipsec
esp/tunnel/${GW1_IN}-${GW2_IN}/require;
spdadd $GW2_NET $GW1_NET any -P in ipsec
esp/tunnel/${GW2_IN}-${GW1_IN}/require;
spdadd ${GW1_OUT}/32 ${GW2_OUT}/32 any -P out ipsec
esp/transport/${GW1_OUT}-${GW2_OUT}/require;
spdadd ${GW2_OUT}/32 ${GW1_OUT}/32 any -P in ipsec
esp/transport/${GW2_OUT}-${GW1_OUT}/require;
EOF
/sbin/route add $GW2_NET $GW1_IN
;;
gw2.domain.com)
/usr/sbin/gifconfig gif0 $GW2_OUT $GW1_OUT
/sbin/ifconfig gif0 inet $GW2_IN $GW1_IN netmask $NETMASK
/usr/sbin/setkey -FP
/usr/sbin/setkey -F
/usr/sbin/setkey -c << EOF
spdadd $GW2_NET $GW1_NET any -P out ipsec
esp/tunnel/${GW2_IN}-${GW1_IN}/require;
spdadd $GW1_NET $GW2_NET any -P in ipsec
esp/tunnel/${GW1_IN}-${GW2_IN}/require;
spdadd ${GW2_OUT}/32 ${GW1_OUT}/32 any -P out ipsec
esp/transport/${GW2_OUT}-${GW1_OUT}/require;
spdadd ${GW1_OUT}/32 ${GW2_OUT}/32 any -P in ipsec
esp/transport/${GW1_OUT}-${GW2_OUT}/require;
EOF
/sbin/route add $GW1_NET $GW2_IN
;;
esac
/usr/local/sbin/racoon -f /usr/local/etc/racoon/racoon.conf
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Problems with IPsec tunnel
Soichi, Thanks for the response. As it turns out, the problem my own stupidity - I forgot to turn on IP forwarding on one of the gateways. sysctl -w net.inet.ip.forwarding=1 fixed things right up. :) And since you're coming from KAME, maybe you can answer something else for me. Can you tell me if I will run into any problems running NAT on my gateways? Thanks, Brad On Fri, 22 Jun 2001, Shoichi Sakane wrote: > > I'm having quite the time trying to set up a IPsec tunnel on 4.3-RELEASE. > > Host-to-host IPsec works fine - I can make connections all day long between my > > two gateways. But for the life of me, I can't get my windows boxen on each end > > to talk to the other. I've got identical psk.txt files (rw---) on both > > gateways, but 10.0.1.2 can't ping 10.0.0.2 to save its life. I've told the PCs > > on each end to route the other's traffic through the near gate's inside addr, > > and still no go. IP forwarding is turned on and NAT is off on both gates as > > well as an "OPEN" fw ruleset. I've gone through the couple of HOW-TOs on the > > net, but while I understand exactly what they're saying, and I repeat the > > process, I can't get it working. > > Did you see any message on your gateways or your hosts ? > I think debugging message of raccoon and system messages could be help you. > and tcpdump also can be help to know what happened your network. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Problems with IPsec tunnel
Soichi, As it turns out, NAT works fine. Thanks for all your help. -Brad On Fri, 22 Jun 2001, Shoichi Sakane wrote: > > Can you tell me if I will run into any problems running NAT on my gateways? > > I have never used NAT with IPSec. You should tell this mailing list your > problem. Because there are probably people who have same problem of you. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
monitoring bandwidth usage
Hello, I was wondering if there was a way that I could monitor the bandwidth usage live? I have heard of a linux program called iptraf, is there something similar to that for FreeBSD? Thank You, Brad Davis _ Send and receive Hotmail on your mobile device: http://mobile.msn.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
mpd 3.15
I'm having trouble configuring mpd 3.15, Im trying to create a vpn tunnel to a friends network throguh the internet who is using windows 2003 at the moment but will be using freebsd and mpd as well. the vpn will allow incomming connections but not outgoing. i will attach the configuration files below mpd.links ~ vpn: set link type pptp set pptp self 172.25.161.45/27 set pptp peer 172.25.161.51/27 set pptp enable originate incoming outcall mpd.conf ~ default: load vpn vpn: new -i ng1 vpn vpn set iface disable on-demand set iface addrs 172.25.144.1 172.25.145.1 set iface idle 0 set bundle session 28800 set iface route 172.25.145.0/24 set bundle disable multilink set bundle authname "BRADTOP\\tom_brad" set bundle password "rotaredom" set bundle enable compression set link yes acfcomp protocomp set link no pap set link yes chap set link mtu 1500 set link enable no-orig-auth set link keep-alive 60 100 set ipcp yes vjcomp set ipcp ranges 172.25.144.0/24 172.25.145.0/24 set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set bundle enable crypt-reqd set ccp yes mpp-s open The log output to the screen when i try to establish and outgoing connection is: Multi-link PPP for FreeBSD, by Archie L. Cobbs. Based on iij-ppp, by Toshiharu OHNO. mpd: pid 607, version 3.15 ([EMAIL PROTECTED] 04:02 5-Dec-2003) [vpn] ppp node is "mpd607-vpn" mpd: local IP address for PPTP is 172.25.161.45 [vpn] using interface ng1 set bundle session: unknown command. Try "help". [vpn] IFACE: Open event [vpn] IPCP: Open event [vpn] IPCP: state change Initial --> Starting [vpn] IPCP: LayerStart [vpn:vpn] [vpn] bundle: OPEN event in state CLOSED [vpn] opening link "vpn"... [vpn] link: OPEN event [vpn] LCP: Open event [vpn] LCP: state change Initial --> Starting [vpn] LCP: LayerStart [vpn] device: OPEN event in state DOWN pptp0: connecting to 172.25.161.51:1723 [vpn] device is now in state OPENING pptp0: connected to 172.25.161.51:1723 pptp0: attached to connection with 172.25.161.51:1723 pptp0-0: outgoing call connected at -2131151101 bps [vpn] PPTP call successful [vpn] device: UP event in state OPENING [vpn] device is now in state UP [vpn] link: UP event [vpn] link: origination is local [vpn] LCP: Up event [vpn] LCP: state change Starting --> Req-Sent [vpn] LCP: phase shift DEAD --> ESTABLISH [vpn] LCP: SendConfigReq #1 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM aa4072b4 AUTHPROTO CHAP MSOFTv2 [vpn] LCP: rec'd Configure Request #0 link 0 (Req-Sent) MRU 1400 AUTHPROTO CHAP MSOFTv2 MAGICNUM 6ed15b39 PROTOCOMP ACFCOMP CALLBACK Not supported MP MRRU 1614 ENDPOINTDISC [LOCAL] 43 b0 65 0f 83 4e 42 24 b8 53 b2 3b a9 1a d8 f7 00 00 00 00 BACP Not supported [vpn] LCP: SendConfigRej #0 CALLBACK MP MRRU 1614 BACP [vpn] LCP: rec'd Configure Ack #1 link 0 (Req-Sent) ACFCOMP PROTOCOMP MRU 1500 MAGICNUM aa4072b4 AUTHPROTO CHAP MSOFTv2 [vpn] LCP: state change Req-Sent --> Ack-Rcvd [vpn] LCP: rec'd Configure Request #1 link 0 (Ack-Rcvd) MRU 1400 AUTHPROTO CHAP MSOFTv2 MAGICNUM 6ed15b39 PROTOCOMP ACFCOMP ENDPOINTDISC [LOCAL] 43 b0 65 0f 83 4e 42 24 b8 53 b2 3b a9 1a d8 f7 00 00 00 00 [vpn] LCP: SendConfigAck #1 MRU 1400 AUTHPROTO CHAP MSOFTv2 MAGICNUM 6ed15b39 PROTOCOMP ACFCOMP ENDPOINTDISC [LOCAL] 43 b0 65 0f 83 4e 42 24 b8 53 b2 3b a9 1a d8 f7 00 00 00 00 [vpn] LCP: state change Ack-Rcvd --> Opened [vpn] LCP: phase shift ESTABLISH --> AUTHENTICATE [vpn] LCP: auth: peer wants CHAP, I want CHAP [vpn] CHAP: sending CHALLENGE [vpn] LCP: LayerUp [vpn] CHAP: rec'd CHALLENGE #0 Name: "BRADTOP" Using authname "BRADTOP\tom_brad" [vpn] CHAP: sending RESPONSE [vpn] CHAP: rec'd SUCCESS #0 MESG: S=14B3226FA5A3C3ACD9074A862DEF0130008868E9 [vpn] LCP: rec'd Configure Request #3 link 0 (Opened) MRU 1400 AUTHPROTO CHAP MSOFTv2 MAGICNUM 6f953262 PROTOCOMP ACFCOMP CALLBACK Not supported MP MRRU 1614 ENDPOINTDISC [LOCAL] 43 b0 65 0f 83 4e 42 24 b8 53 b2 3b a9 1a d8 f7 00 00 00 00 BACP Not supported [vpn] LCP: LayerDown [vpn] LCP: SendConfigReq #2 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM aa4072b4 AUTHPROTO CHAP MSOFTv2 [vpn] LCP: SendConfigRej #3 CALLBACK MP MRRU 1614 BACP [vpn] LCP: state change Opened --> Req-Sent [vpn] LCP: phase shift AUTHENTICATE --> ESTABLISH [vpn] LCP: rec'd Configure Reject #2 link 0 (Req-Sent) AUTHPROTO CHAP MSOFTv2 [vpn] LCP: SendConfigReq #3 ACFCOMP PROTOCOMP MRU 1500 MAGICNUM aa4072b4 AUTHPROTO CHAP MSOFTv2 pptp0: CID 0x57d3 in SetLinkInfo not found [vpn] LCP: rec'd Configure Request #4 link 0 (Req-Sent) MRU 1400 AUTHPROTO CHAP MSOFTv2 MAGICNUM 6f953262 PROTOCOMP ACFCOMP ENDPOINTDISC [LOCAL] 43 b0 65 0f 83 4e 42 24 b8 53 b2 3b a9 1a d8 f7 00 00 00 00 [vpn] LCP: SendConfigAck #4 MRU 1400 AU
Re: My planned work on networking stack
At 11:26 AM +0300 2004/03/02, Gleb Smirnoff wrote: Is there any plans about integration of BGP routing daemon (Zebra or Quagga) into FreeBSD? With BGP routing daemon onboard, FreeBSD will be a strong alternative against expensive commercial routers. I have successfull experience of running FreeBSD STABLE with 2 full BGP views for half a year. Modern i386 PC can route/filter/shape much more traffic than expensive Cisco 36xx. I haven't yet compared with 7000 series... Talk to people who have real-world experience in running zebra/quagga in ISP environments with multiple upstreams and taking full views. The guy who is designing bgpd for OpenBSD gave a talk on the subject at FOSDEM, and it was very enlightening to hear about the problems with zebra (which went commercial and the open source version basically hasn't been touched in years) and quagga (which is a community of zebra users trying desperately to fix the worst of the bugs), and how he has used this information during his design of a replacement, and the methodology he used to make sure that the resulting system is robust and capable of being used in real-world production environments. His only issue with using exclusively PC equipment for handling routing is all those strange WAN protocols and cards for which hardware cards are rarely available beyond vendors like cisco or Juniper. That's why he's going pure Ethernet protocols/hardware throughout all his networks, including his upstream feeds, so that he can dump all that expensive ancient legacy routing hardware. If anything, I'd be inclined to look towards his work for OpenBSD and see if that could be imported into FreeBSD (and maybe improved, with contributions given back to him), rather than mess around with crap like zebra or quagga. Oh, and it would be nice if someone somewhere started thinking about a mesh routing implementation for *BSD, either AODV or something else. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: My planned work on networking stack
At 3:59 PM +0300 2004/03/02, Gleb Smirnoff wrote: Haven't you understand? I'm the "person who has real-world experience in running zebra in ISP environments with multiple upstreams and taking full views". Do you have multiple connectivity to two separate metro area exchanges, with multiple upstreams at each? Most large cities are lucky to have a single major metro area exchange, and the author of bgpd for OpenBSD works at an ISP located in Hamburg which is lucky enough to have two major NAPs, and he has multiple connectivity to both. He was the one ragging on zebra/quagga. Among other things, he said he had real problems keeping sessions up with zebra/quagga when neighbors were flapping. IIRC, he's also got some pretty big cisco equipment (75xx or whatever), and he is going to be switching over to OpenBSD+bgpd as his secondary core router in the very near future, with plans to complete the switch over soon thereafter. He's putting his money where his mouth is. Certainly, I have noticed that zebra hasn't done much recently, and at least on the surface quagga doesn't seem to have gone that far beyond where zebra was a couple of years ago. Browse zebra CVS to make sure that author is commiting bugfixes. For example: last commit to BGP code is done 2 weeks ago. Right, and that bugfix took how long to apply? When was the previous bugfix before that? When was the last real "new" development for zebra? I can't say a word about quagga, since I haven't use it, but I have positive experience with zebra (see above). If you're a zebra fan, then I suggest you check out quagga. I stop replying... Do not like flame. Before flaming anyone further, you might want to check out pages like <http://www.fosdem.org/2004/index/interviews/interviews_brauer>, and then take a look and see what Henning Brauer has actually been up to. You might also want to check out <http://www.commsdesign.com/design_corner/OEG20010323S0048> and ask yourself if zebra/quagga handles resiliency the way it should. If this problem isn't already addressed by bgpd, I'm sure it will be before Henning can go production with using this for his core routers at his ISP. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: My planned work on networking stack
At 3:59 PM +0100 2004/03/02, Andre Oppermann wrote: Zebra is definatly *not* a piece of s*** as you make it sound here. Well, that was certainly the impression I got from Henning Brauer at FOSDEM. Maybe I misunderstood him, or maybe he has different views on this software than you do. To properly clarify this matter, you should probably talk to him directly and find out if his opinions on zebra/quagga really are as different from yours, and if so then I'll be glad to make a public apology. However, until then, I will stand by what I remember of his talk, and neither you nor anyone else is going to make me change my mind, certainly not by beating your chest. You need GigE, T1/E1, E3/T3 and STM-1 these days. Everything else is dead. From what I understand from Henning, he's going to be dumping E-1/T-1, E3-T3, and probably also STM-1, because you can't get those kinds of interfaces for regular PC-type boxes. I'm not sure I agree with him 100%, but I can certainly understand why he'd want to simplify his life. Ok, again Zebra/Quagga is not "crap". The same with DJBware which is no "crap" either. If you don't like it just say so but refrain from dirt-talking it. It doesn't make your point any stronger. Beating your chest louder is not likely to make me believe that you're right. If you want to get off onto a "Church of Dan" rant, I can certainly do that, and I can point out a whole ark-load of flaws -- most of which are simple basic facts which Dan himself admits to, but when he says them they're "facts" and when I say them they're "libel" or "slander". Yeah, riight. The bgpd from OpenBSD will surely make it's way into FreeBSD [*]. The main developer besides Henning sits about 5 meters away from me in my office. If you look at it then you'll find out that I'm not really innocent that bgpd ;-) I'm glad to hear that. [*] In FreeBSD it will be a port. I don't know why a bgpd should be in the base system. I don't know. Why should we have any routing software at all in the base system? It would be nice if you could calm down, stop your mis-informed accusations and rants and actually try to be helpful and progressive to the projects which try to do it better. Thank you very much. Show me the words from Henning himself where I have mis-represented his views on zebra/quagga, and I will gladly apologize in public. Until then, I stand by what I have said. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: My planned work on networking stack
At 4:08 PM +0100 2004/03/02, Andre Oppermann wrote: Gleb is doing the same, and so am I. However you are not. Do you run BGP in your network? I'm not running an ISP that is multiply connected to at least two metro-area NAPs and has multiple upstreams at both sites, no. I would be very interested to be involved in the network management of a medium to large-sized ISP, however. At least for me on FreeBSD Zebra has been very stable for me. There is no need to always "change" things. That's wonderful for you. However, that doesn't change the criticism that Henning has levelled at zebra/quagga. What is you point? Do you use Zebra? Are you affected by it? Or are you just ranting? My point is that zebra/quagga have significant limitations that restrict their usefulness, due to the design of the system. Moreover, the development on zebra has effectively stalled since the author got hired away to do that kind of work professionally, and development on quagga has apparently been sporadic and relatively limited, presumably due to the fact that they don't have replacement developers of the same caliber. If we want to get to the point where we can have a reasonable expectation of throwing away all cisco, juniper, Foundry, and other routing hardware and replace them with something that is easier to install, configure, monitor, and manage, then I think we need to be looking beyond zebra/quagga. And you should stop flaming anyone if you haven't ever used or done what you are blabbering about. If you think this is flaming, then you have never seen flaming. At this stage, this is nothing more than a luke-warm disagreement. Sorry, but OpenBSDs bgpd wont to any of that either. This is mostly hardware that needs to be redundant. Not much you can in bgpd. Not in bgpd per se, no. But by then you'd have added more protocol support to the daemon and that name would no longer be appropriate. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: My planned work on networking stack
At 11:02 AM +0200 2004/03/02, Andrew Degtiariov wrote: What's difference (*currently*) beetwen FreeBSD+Zebra and Cisco routers? Support for VRRP? Support for various other routing protocols not covered by zebra/quagga -- at least not yet, if ever? Support for line cards and other devices that do not exist in a format you can plug into a PC? Maybe there's nothing you can do about this last item, but there's plenty that can be done on the software side -- just take a look at all the protocols that have been identified as being desirable, but not yet implemented by zebra/quagga. Oh, and then there are all the operational issues where zebra/quagga can't keep sessions going when a neighbor flaps, etc Those would require re-architecting the whole routing system, at which point it might make a lot more sense to go with a different implementation -- such as bgpd from OpenBSD. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: My planned work on networking stack
At 3:52 PM +0200 2004/03/02, Andrew Degtiariov wrote: Oh, and then there are all the operational issues where zebra/quagga can't keep sessions going when a neighbor flaps, etc Those would require re-architecting the whole routing system, at ^^^ Congratulation. That's namely what the conversation was about. Right. We can either re-architect zebra/quagga, or we can start with something that addresses the weaknesses in these tools, or we can do something else. I'm advocating that we at least take a long hard look at what Henning Brauer has done, and seriously consider whether it would make sense for us to start with that to give us a leg up on the re-architecting process. If nothing else, this would at least give us an interesting insight to what some of the weaknesses are in this category, and maybe help us identify better solutions faster and more easily. In particular, if there are such serious problems with zebra/quagga that they would need to be completely re-architected in order to be useful, then I don't see that as being a particularly fruitful line of work to pursue. I'd rather start with something that requires less re-work, and would presumably allow us to more easily add in any additional bits that we feel are necessary or desirable. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: My planned work on networking stack
At 4:18 PM +0100 2004/03/02, Andre Oppermann wrote: I'd like to see you do any real work in this area instead of producing many and longs emails with lots of mis-informed rants in them. Yes, this my official put-up-or-shut-up call to you. I'm not a programmer. I haven't done anything that I consider to be proper "programming" in over fifteen years. If there is anything I can do to help with the skills I have as a senior unix systems administrator and a small network of machines downstairs that I need to put together (four UltraSPARC 10 clones, a dishwasher-size four-processor Intel OEM fileserver-to-be, an ancient SPARC-4 clone, and an ancient Pentium-133 laptop w/ 48MB of RAM), then I'll be glad to do what I can to help. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [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)
At 3:32 PM -0800 2004/03/08, Jeffrey Hsu wrote: What Luigi says is absolutely correct. It doesn't take a lot to get this done. I've talked to a number of companies about implementing SACK for them and while there was interest, no one wanted to fund it all themselves, potentially for the benefit of their competitors. Out of curiosity, can someone provide some pointers as to where SACK really helps? Is this just for high-speed WANs and doesn't help on LANs, or is it useful in both contexts? Also, at what speeds/packet sizes does SACK start to become really useful? I'm just wondering if there aren't a lot of people who could benefit from something like this, only they don't know it. If they were to find out, it might help provide funding and other resources to spur development. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Yukon 2 NIC chipset support
Hi, Can anyone tell me if the Yukon 2 NIC chipset is currently supported by FreeBSD (under any revision) ? Thanks, Brad ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Yukon 2 NIC chipset support
Hi Bjoern, Thanks for your response. Can anyone tell me if the Yukon 2 NIC chipset is currently supported by FreeBSD (under any revision) ? http://lists.freebsd.org/pipermail/freebsd-net/2006-January/009543.html (be sure to read the entire thread) Looks like its not properly supported then :-( Brad - Original Message - From: "Bjoern A. Zeeb" <[EMAIL PROTECTED]> To: "Brad du Plessis" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: 06 June 2006 09:40 Subject: Re: Yukon 2 NIC chipset support On Tue, 6 Jun 2006, Brad du Plessis wrote: Hi, Can anyone tell me if the Yukon 2 NIC chipset is currently supported by FreeBSD (under any revision) ? http://lists.freebsd.org/pipermail/freebsd-net/2006-January/009543.html (be sure to read the entire thread) -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB Modem support
Hi, I've looked high and low and the only USB ISDN TA's I've found that work under BSD are the 3Com ISDN Pro TA's. All the others I've tried are software TA's and don't work. Could someone please give me advice on what will work under BSD, I've run out of ideas completely. Thanks, Brad ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
USB Modem support
Where can I get a list of USB modems supported by BSD Thanks Brad ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB Modem support
How do I find out before I go and buy a usb modem that its going to be detected as a umodem or a ugen device. I assume when its detected as a ugen then the modem is some type of usb winmodem and its not going to work under bsd. Are usb modems with CAPI support always winmodems? Thanks Brad > < said: > > Where can I get a list of USB modems supported by BSD > > You can't. FreeBSD supports any USB modem that (1) claims in the USB > control protocol to be a modem and (2) doesn't require a firmware > download to make it work. It does not look for specific product > identifiers. > > -GAWollman > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RTM_LOSING: Kernel Suspects Partitioning
Hi, I've tried a NetBSD mailing list to no avail and was hoping that someone here could help me. I have the following setup: A - B == C Box A and Box B are on a LAN both on the same subnet. Now from box B I make a pppd modem dialup to box C. Manual routes are setup on A and C to allow a connection between A and C. It appears that if while a connection is active and access to C is momentarily lost, but the ppp interface remains up, packets that were being sent to B from A are redirected to B's default gateway. If that dialup is closed and then reopened a connection to C from A will fail because all packets to C through B are being routed to B's default gateway. In fact, the only way I'm able to get the connection to work again is either to delete the default gateway on B, do a ping from C to A, or to reboot box B. Now I've looked through the kernel and it appears that in netinet/in_pcb.c the function "in_losing(inp)" is called when this happens. I've put printouts in the kernel and found that the route to redirect the packets (which I presume was setup by the kernel) from A to the default gateway has been setup as a static route. (rt->rt_flags & RTF_DYNAMIC == 0) I would've thought that this route should be dynamic, my reasoning being that the route would then be deleted in in_losing(inp) and packets could then be redirected through a valid route if one were available. Has anyone come across this before, is this a bug in the kernel? (I assume it does the same thing in FreeBSD) Any help would be most appreciated! Thanks, Brad ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DHCPCD in base
On 11/26/2020 5:44 AM, Tom Marcoen wrote: Hey Meka You say DHCPD (which to me means the DHCP daemon) but you also mention "DHCP client"? I assume the software can be one or the other but not both. Which of the two do you mean? Or is there something I am missing? That's not what he said. Read what he said. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
