Re: bus width and PCIe version
On Tue, Mar 27, 2012 at 09:55:45AM -0700, Adarsh Joshi wrote: > Hello, > > Is there a command or log message where I can find out the bus width and PCIe > version number on which my adapter is put on? > > I did take a look at pciconf and devinfo and also the dmesg logs but could > not find anything. > > I know it is visible on lspci on linux systems. You can use lspci on FreeBSD as well. It is included in the sysutils/pciutils port. -- Erik Trulsson ertr1...@student.uu.se ___ 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: Broadcom Docs
On Tue, Oct 04, 2011 at 11:16:52AM -0400, Arnaud Lacombe wrote: > Hi, > > On Tue, Oct 4, 2011 at 10:39 AM, Adrian Chadd wrote: > > The non-embedded atheros NICs (ie, not the ath6k series stuff) is all > > run by the host CPU. There's no firmware that runs on the NIC. > > This was why the HAL was binary for so long. Note it is no longer > > binary and hasn't been for a few years. > > > OOTH, AFAIK, Linux folks never used the binary HAL, and had it > working, but it was GPL licensed from the beginning. For Atheros wireless controllers Linux people used to use the madwifi driver which did use the binary HAL and otherwise was dual-licensed (BSD/GPL). Nowadays Linux people use the ath5k/ath9k drivers which do not use the binary HAL and which had just about reached the level of actually being usable when source code for the HAL was released. (The madwifi driver was never included in the standard Linux kernel, mostly due to the binary HAL. The ath5k/ath9k drivers are nowadays included in the Linux kernel.) -- Erik Trulsson ertr1...@student.uu.se ___ 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: [POLLING] strange interrupt/system load
On Sun, Sep 13, 2009 at 07:33:06PM +0500, rihad wrote: > Barney Cordoba wrote: > > > > --- On Sun, 9/13/09, rihad wrote: > >> What's wrong with 64 bits? > > > > I haven't spent a large portion of my life trying to figure > > it out exactly, but I'd guess that the larger size of the > > structures and code results in fewer cache hits. > > Then what's wrong with also doubling cache sizes? Increasing the size of the CPU cache not only makes it more expensive to manufacture, but also makes it slightly slower to access. > Besides, apart from other benefits, 64-bit makes every-day big number > arithmetic a single CPU instruction as opposed to several instructions > required on 32-bit CPUs through bignum emulation. True, and if you need to perform a lot of 64-bit arithmetic then the extra register width can indeed be a major win. Most people, on most systems, have very limited need of 64-bit arithmetic. -- Erik Trulsson ertr1...@student.uu.se ___ 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: Observations from an old timer playing with 64 bit numbers...
On Thu, Jun 24, 2010 at 05:19:29AM -0700, Randall Stewart wrote: > Bob: > > Thats strange... when I do > > man byteorder > > (on my FreeBSD 8.0 system upgraded to head .. buildworld/installworld/ > et.al) > > I get the same man age showing for both > > man ntohl > > and > > man byteorder But if you do 'man 9 byteorder' you will get a different manpage. (byteorder(3) and byteorder(9) are different manpages, and even reference each other in the SEE ALSO sections.) -- Erik Trulsson ertr1...@student.uu.se ___ 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: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp]
On Mon, Jul 07, 2008 at 10:30:53PM +1000, Bruce Evans wrote: > On Mon, 7 Jul 2008, Andre Oppermann wrote: > > > Bruce Evans wrote: > >> What are the other overheads? I calculate 1.644Mpps counting the > >> inter-frame > >> gap, with 64-byte packets and 64-header_size payloads. If the 64 bytes > >> is for the payload, then the max is much lower. > > > > The theoretical maximum at 64byte frames is 1,488,100. I've looked > > up my notes the 1.244Mpps number can be ajusted to 1.488Mpps. > > Where is the extra? I still get 1.644736 Mpps (10^9/(8*64+96)). > 1.488095 is for 64 bits extra (10^9/(8*64+96+64)). A standard ethernet frame (on the wire) consists of: 7 octets preamble 1 octet Start Frame Delimiter 6 octets destination address 6 octets source address 2 octets length/type 46-1500 octets data (+padding if needed) 4 octets Frame Check Sequence Followed by (at least) 96 bits interFrameGap, before the next frame starts. For minimal packet size this gives a maximum packet rate at 1Gbit/s of 1e9/((7+1+6+6+2+46+4)*8+96)/ = 1488095 packets/second You probably missed the preamble and start frame delimiter in your calculation. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Realtek network driver
On Sun, Oct 12, 2008 at 08:06:23PM +0600, Aleksandr Litvinov wrote: > Hi, > Let's ask. Why in cvsweb existing a two drivers for network interface > realtek: rl & re? They can be united? What objective reasons prevent > to make? Realtek makes many different ethernet controllers. The rl(4) driver supports several of the older chips (10/100M capable) while re(4) supports most of the newer models (mostly gigabit capable.) These two groups of controllers are different enough to warrant different drivers. Of course one could, in theory, unite the rl and re drivers, but they do not have enough in common for this to be a good idea. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Interrupts + Polling mode (similar to Linux's NAPI)
On Wed, Apr 29, 2009 at 05:46:32AM -0700, Barney Cordoba wrote: > > > > > --- On Tue, 4/28/09, Andrew Snow wrote: > > > From: Andrew Snow > > Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) > > To: "Luigi Rizzo" > > Cc: "FreeBSD Net" > > Date: Tuesday, April 28, 2009, 5:09 PM > > Luigi Rizzo wrote: > > > If i am not mistaken we don't have generic support > > for interrupt moderation > > > in the kernel but that's a specific NIC feature: > > it works if the > > > hardware supports it, and it doesn't otherwise. > > > > > > Of course it would be possible to modify polling to > > implement > > > generic interrupt mitigation even without hardware > > support, so > > > you get the best of the two worlds. > > > > It seems to me that you're wasting your time if you are > > trying to achieve a high throughput in FreeBSD without using > > an Intel Pro/1000 or 10gbe networking card. > > > > So I don't know if anyone would really miss out if > > generic polling support was completely removed from the > > kernel and all efforts were then placed into improving other > > parts of network flow in the kernel which need more help. > > > > > > - Andrew > > I'm not sure if those specific NICs are the "only" choices. But I am > concerned that so much brainpower is being put to extending the life > of antiquated science projects and so little (maybe none?) is being > put to improving drivers and the general network threading and > performance. > > You spend 3 years redesigning the kernel, yet there are no resources to > create a decent 10gb/s solution, to get rid of netgraph and to do > network integration properly, or to improve the large number of mediocre > drivers that were written what might as well be 100 years ago. If you think that more resources should be applied on certain areas, then feel free to provide said resources yourself. Other people are unlikely to change what they work on just because you want them to. > > When the collective answer to better network performance is polling, it > makes it appear as if the FreeBSD project is a bunch of dudes working on > stuff they feel like doing, rather than there being some centralized plan > to make the project successful. That appearance is probably due to the fact the the FreeBSD project actually is a bunch of dudes working on what they feel like doing (or in a few cases on what they get paid for doing), and that there is very little centralized planning being done. (And even if there was, there is no way of enforcing that people work according to such a plan.) -- Erik Trulsson ertr1...@student.uu.se ___ 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: Download 5.4 ISO file?
On Sun, May 03, 2009 at 10:43:25PM +1000, Sam Wan wrote: > > Hi, > > I want to download iso file of freebsd 5.4 release. > Can anyone tell me a link? > > I want build a ipvs box in freebsd. > > Thanks > ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/ -- Erik Trulsson ertr1...@student.uu.se ___ 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, Jun 16, 2009 at 04:37:32PM +0530, saravana perumal wrote: > Hi Louie. > > As per Testing > > 1.Sending SYN and reaching the SYN_SENT state INTIALLY [Active open] > 2. Then Expects to RECEIVE SYN packet and > 3. To Send SYN & ACK to reach SYN-RCVD state. That does not sound quite correct. The normal sequence for the TCP three-way handshake is: -> SYN <- SYN+ACK -> ACK while you for some reason seem to be expecting -> SYN <- SYN -> SYN+ACK which is not what I would expect. > > In Free BSD active SYN-RCVD state is not happening . > > In TCP state tranistion my expectation is represented for SYN_RCVD state. > > > Thanks. > Saravanan > > > --- On Tue, 6/16/09, saravana perumal wrote: > > > From: saravana perumal > Subject: Re: TCP Free-BSD setup behaviour. > To: "Louis Mamakos" > Cc: "FreeBSD Mailer List" > Date: Tuesday, June 16, 2009, 3:15 PM > > > > > > > > Hi Louie > > We are trying to make Active Sync Received state. > > 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. > > 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 > > I hope the expectation should be rite in case of ACTIVE-SYN received State. > > Thanks. > Saravanan > > > > --- On Tue, 6/16/09, Louis Mamakos wrote: > > > From: Louis Mamakos > Subject: Re: TCP Free-BSD setup behaviour. > To: "saravana perumal" > Cc: freebsd-net@freebsd.org, sarba...@gmail.com > Date: Tuesday, June 16, 2009, 3:05 AM > > > > On Jun 15, 2009, at 3:44 AM, saravana perumal wrote: > > > Hi Louie , > > > > > > Thanks for the Response on my Queries. > > > > For QUERY 3, > > ACTIVE open frm Free BSD end: > > > > FREE BSD APPLICATION > > Send -> syn > > Receive < SYN > > > > Expect SYN & ACK-> Getting only ACK in this Scenario, > > > > Now Expects FREE BSD to respond back with the SYN & ACK , but BSD is > >sending only ACK message as the response. > > 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? > > > 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 > > > > > > For this Issue mentioned above, Last TCP packet is jst a Testing packet > > with the > > following Field set in TIME-WAIT state , > > > > > > TCP: TCP Packet > > TCP: > > TCP: Source Port = 16815 (16815) > > TCP: Destination Port = 16816 (16816) > > TCP: Sequence Number = 3865716731 (0xE66A27FB) > > TCP: Acknowledgment Number = 0 (0x) > > TCP: Data Offset = 5 (20 bytes) > > TCP: Reserved = 0 > > TCP: Control Bits = 0x10 > > TCP: |543210 > > TCP: |0. = Urgent Pointer Isn't Significant > > TCP: |.1 = Acknowledgment Is Significant > > TCP: |..0... = No Push Function > > TCP: |...0.. = No Reset Connection > > TCP: |0. = No Synchronize Sequence Numbers > > TCP: |.0 = More Data From Sender > > TCP: Window = 32752 bytes > > TCP: Checksum = 0x41A0 (Correct) > > TCP: Urgent Pointer = 0 (Not Significant) > > TCP: > > TCP: --- Trailing Data [12 bytes] --- > > TCP: 53 61 6D 70 6C 65 20 44 61 74 61 00 Sample Data. > > TCP: --- Trailing Data End --- > > From machine Sending to the FREE BSD machine, > > > > This is to verify that Free BSD is in TIME-WAIT state. > > 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 th
Re: Inline/Bypass ethernet NIC for FreeBSD
On Sat, Sep 22, 2007 at 05:07:52PM +0700, Affan Basalamah wrote: > Hi all, > > I just curious about the availability of inline/bypass ethernet NIC > for FreeBSD. Maybe my google search skill is low, but I cannot find > any information about that. I think there are few ethernet adapter that support bypass operation (for any OS, not just FreeBSD.) Your google search skill must be low, because simply googling on 'ethernet bypass adapter' and following the first link would lead you to http://www.silicom.co.il/pgx.php?p2=127 where they list several models that are claimed to work with FreeBSD. > > The only thing that comes to me is this URL from Intel > (http://www.intel.com/network/connectivity/products/pro1000_quad_bypass_server_adapters.htm), > which I know by just looking at it, that thing won't come in cheap > price. I am fairly certain that just about all alternatives will fall into one or both of the following categories: a) Hard to find b) Expensive > > I just want to use it as a NIC for my firewall, to eliminate the > possibilities of traffic went down when the firewall is unable to > operate. So you are saying that if somebody manages to crash your firewall then they should be able to bypass any protection the firewall was supposed to give? I am not at all sure that is a good idea. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Test changes to em
On Fri, Nov 02, 2007 at 12:10:59AM -0800, Jack Vogel wrote: > Although I see it at least one person claims the message > came thru with only the header file, so I am going > to send if_em.c thru again. > Attachments are usually stripped off by the mailing list software, so you are probably better off putting the files on a webpage somewhere and just telling us the URL. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FBSD 1GBit router?
On Sat, Mar 01, 2008 at 01:27:46PM -0800, Barney Cordoba wrote: > > --- Ingo Flaschberger <[EMAIL PROTECTED]> wrote: > > > Dear Barney, > > > > > It seems absolutely ridiculous to buy such > > hardware > > > and not install a PCIx or 4x PCIe card for another > > > $100. or less. Saying a 1x is "fast enough" is > > like > > > saying a Celeron is "fast enough". > > > > The box is a small 1HE appliance and can boot from a > > CF-Card. > > I trust them more than a "al cheapo" pc. > > 1x axiomtek NA-820 > > 1x P4 3Ghz cpu > > 1x 1gb ddr2 > > --- > > 850eur without taxes. > > > > A good chipset, good cpu, good ram, good harddisk, > > god powersupply has > > same price. > > And don't forget that in exchanges you pay for each > > HE. > > > > And back to 1x is not fast enough: > > There are no 1gbit single port network cards that > > support more than 1 > > lane, even if you plug it into a 16 lane slot. > > (and I'm not talking about 10gbit cards; if you have > > 10gbit upstream you > > have enough $$ to buy good gear) > > Ok, well I've never seen a router with 1 port. I > thought we were talking about building a router? He did not say anything about a single port router. He talked about single port network cards. You can use more than one of them when building a router. > > The lack of PCIe cards is a good reason to consider a > PCIX machine. What lack of PCI-E cards? These days there are quite a few to choose between. > On the systems that we have, the 1x PCIe > ports are a lot slower than a PCI-X card in the slot. > > You need 4Gb/s of throughput to handle a gigablt > router. (1 GB/s full duplex times 2). 1x is 4Gb/s > maximum. In my view, you always need twice the > bandwidth on the bus to avoid contention issues. What contention issues? With PCI-E each device is essentially on its own bus and does not need to contend with other devices for bandwidth on that bus. A PCI-E 1x connection provides more bandwidth than one gigabit ethernet connection can use. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FBSD 1GBit router?
On Sat, Mar 01, 2008 at 04:39:57PM -0800, Barney Cordoba wrote: > > --- Erik Trulsson <[EMAIL PROTECTED]> wrote: > > > On Sat, Mar 01, 2008 at 01:27:46PM -0800, Barney > > Cordoba wrote: > > > > > > --- Ingo Flaschberger <[EMAIL PROTECTED]> wrote: > > > > > > > Dear Barney, > > > > > > > > > It seems absolutely ridiculous to buy such > > > > hardware > > > > > and not install a PCIx or 4x PCIe card for > > another > > > > > $100. or less. Saying a 1x is "fast enough" is > > > > like > > > > > saying a Celeron is "fast enough". > > > > > > > > The box is a small 1HE appliance and can boot > > from a > > > > CF-Card. > > > > I trust them more than a "al cheapo" pc. > > > > 1x axiomtek NA-820 > > > > 1x P4 3Ghz cpu > > > > 1x 1gb ddr2 > > > > --- > > > > 850eur without taxes. > > > > > > > > A good chipset, good cpu, good ram, good > > harddisk, > > > > god powersupply has > > > > same price. > > > > And don't forget that in exchanges you pay for > > each > > > > HE. > > > > > > > > And back to 1x is not fast enough: > > > > There are no 1gbit single port network cards > > that > > > > support more than 1 > > > > lane, even if you plug it into a 16 lane slot. > > > > (and I'm not talking about 10gbit cards; if you > > have > > > > 10gbit upstream you > > > > have enough $$ to buy good gear) > > > > > > Ok, well I've never seen a router with 1 port. I > > > thought we were talking about building a router? > > > > He did not say anything about a single port router. > > He talked about single port network cards. You can > > use more than one of them when building a router. > > His argument is that there are only 1x PCIe cards that > have 1 port. Since he needs 2 ports, and there are 2 > port > PCIe cards, then his argument makes no sense. But the > point is that PCIe NICs are implemented with 1 port > per lane in the chip. So a 2 port card will use 2 > lanes No, the argument was that all 1-port PCI-E cards are only x1, ergo a x1 card must be fast enough for 1 port, else there would be 1-port cards manufactured that used more than one lane. > > > > > > > > > The lack of PCIe cards is a good reason to > > consider a > > > PCIX machine. > > > > What lack of PCI-E cards? These days there are > > quite a > > few to choose between. > > Yes, but they are all 1x, while there are many 1 and 2 > port PCIx cards which are twice as fast. There are dual- and quad-port PCI-E cards available too, and they are generally x4 lane models. Today there really is very little reason to use PCI-X instead of PCI-E when one is putting together a brand new system. > > > > > > On the systems that we have, the 1x PCIe > > > ports are a lot slower than a PCI-X card in the > > slot. > > > > > > You need 4Gb/s of throughput to handle a gigablt > > > router. (1 GB/s full duplex times 2). 1x is 4Gb/s > > > maximum. In my view, you always need twice the > > > bandwidth on the bus to avoid contention issues. > > > > What contention issues? With PCI-E each device is > > essentially on its own > > bus and does not need to contend with other devices > > for bandwidth on that > > bus. > > > > A PCI-E 1x connection provides more bandwidth than > > one gigabit ethernet > > connection can use. > > Does each PCIe slot have its own dedicated memory > controller? The concept that there is some sort of > mutually exclusive, independent path for each > controller is simply not the case in practice. You're > accessing the same memory; you're going through > shared hubs and bridges. You're doing I/O on the same > bus. North bridges typically have a 512 Byte payload > maximum, so you can't even burst a full packet. You > have transaction overhead for each transfer. There are > many factors that will chip away at your realizable > bandwidth. Its not like a hose gushing a continuos > stream of water. Sure, but those limitations apply equally regardless of what kind of slots you use. A x8 lane PCI-E card will suffer just as much of contention on the FSB between the CPU and the chipset as a x1 lane card will. Having a wider channel between the NIC and the chip
Re: FBSD 1GBit router?
On Sun, Mar 02, 2008 at 04:11:28PM +0100, Ingo Flaschberger wrote: > Dear Bareney, > >>> And back to 1x is not fast enough: >>> There are no 1gbit single port network cards that >>> support more than 1 >>> lane, even if you plug it into a 16 lane slot. >>> (and I'm not talking about 10gbit cards; if you have >>> 10gbit upstream you >>> have enough $$ to buy good gear) >> >> Ok, well I've never seen a router with 1 port. I >> thought we were talking about building a router? > > Have you ever read the link? > Have you noticed that the axiomtek appliance has 7 gigabit ports? > Each one connected with 1 lane pci-e? > >> The lack of PCIe cards is a good reason to consider a >> PCIX machine. On the systems that we have, the 1x PCIe >> ports are a lot slower than a PCI-X card in the slot. > > Perhaps, but: pci-x: 4gbit for the whole bus system. PCI-X actually has up to twice that: 133 MHz * 64 bits = 8.512 Gbit/s ( = 1.066 GB/s ) That's assuming only a single PCI-X device on the bus. If you have two devices connected to the same PCI-X bus then most motherboards will lower the clock frequency to 100MHz for reliability reasons. If there are 3 or more devices connected to the same PCI-X bus then the clock frequency is usually lowered to 66 MHz. (Yes, the more devices you connect to a PCI-X bus, the less bandwidth you get to share among them.) > pci-e: 2gbit/lane In each direction. The total bandwidth available is 4Gbit/s per lane. (This is similar to Gigabit ethernet which can only send 1Gbit/s in each direction, but can send and receive at the same time, thus using a total bandwidth of up to 2Gbit/s.) > >> You need 4Gb/s of throughput to handle a gigablt >> router. (1 GB/s full duplex times 2). 1x is 4Gb/s >> maximum. In my view, you always need twice the >> bandwidth on the bus to avoid contention issues. > > sample1: > 3 pci-cards: > card 1: 1x = 2gbit (dedicated) > card 2: 1x = 2gbit (dedicated) > card 3: 1x = 2gbit (dedicated) > > sum: 6gbit > (but the use only 3) > > sample2: > 2 pci-x cards > card 1: 4gbit (shared) > card 2: 4gbit (shared) > card 3: 4gbit (shared) > - > sum:4gbit > > homework: > calculate with 7 ports. > > Kind regards, > Ingo Flaschberger > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG-7 tcp connectivity problems with certain clients
On Fri, Mar 07, 2008 at 05:53:37PM -0600, David DeSimone wrote: > Jake Rizzo <[EMAIL PROTECTED]> wrote: > > > > 16:04:31.445390 IP (tos 0x20, ttl 109, id 41184, offset 0, flags [DF], proto > > TCP (6), length 48) x.comcastbusiness.net.22625 > 192.168.1.104.http: S, > > cksum 0x81e2 (correct), 3539746141:3539746141(0) win 16384 > 1380,nop,nop,sackOK> > > 16:04:31.445405 IP (tos 0x0, ttl 64, id 55077, offset 0, flags [DF], proto > > TCP (6), length 48, bad cksum 0 (->b21)!) 192.168.1.104.http > > > x.comcastbusiness.net.22625: S, cksum 0x58a4 (incorrect (-> 0x8f6e), > > tcpdump is pointing out some bad checksums in your outgoing packets. Yes, of course it does, since tcpdump sees the packet before the card has filled in the checksum. This will always happen whenever you use tcpdump with a NIC that has hardware checksums enabled. > > Maybe you should try ifconfig -txcsum? -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Trouble with IPFW or TCP?
On Fri, Apr 04, 2008 at 01:34:07AM +0200, Ivan Voras wrote: > In which case would an ipfw ruleset like this: > > 00100 114872026 40487887607 allow ip from any to any via lo0 > 00200 00 deny ip from any to 127.0.0.0/8 > 00300 00 deny ip from 127.0.0.0/8 to any > 00600 1585 112576 deny ip from table(0) to me > 01000 90279 7325972 allow icmp from any to any > 05000 475961039 334422494257 allow tcp from me to any setup keep-state > 05100634155 65779377 allow udp from me to any keep-state > 06022409604 69177326 allow tcp from any to me dst-port 22 setup > keep-state > 06080 52159025 43182548092 allow tcp from any to me dst-port 80 setup > keep-state > 06443 6392366 2043532158 allow tcp from any to me dst-port 443 setup > keep-state > 07020517065292377553 allow tcp from any to me dst-port 8080 setup > keep-state > 65400 12273387629703212 deny log ip from any to any > 65535 00 deny ip from any to any If you are using 'keep-state' should there not also be some rule containing 'check-state' ? > > Generate syslog messages like these: > > Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:60725 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:57387 > my.ip.my.ip:443 in via em0 > Apr 4 01:02:06 my.ip kernel: ipfw: 65400 Deny TCP xx.xx.xx.xx:57387 [snip] -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfs-server silent data corruption
On Mon, Apr 21, 2008 at 08:43:33AM -0700, Jeremy Chadwick wrote: > On Mon, Apr 21, 2008 at 04:52:55PM +0200, Arno J. Klaassen wrote: > > Kris Kennaway <[EMAIL PROTECTED]> writes: > > > Uh, you're getting server-side data corruption, it could definitely be > > > because of the memory you added. > > > > yop, though I'm still not convinced the memory is bad (the very same > > Kingston ECC as the 2*1G in use for about half a year already) : > > Can you download and run memtest86 on this system, with the added 2G ECC > insalled? memtest86 doesn't guarantee showing signs of memory problems, > but in most cases it'll start spewing errors almost immediately. > > One thing I did notice in the motherboard manual below is something > called "Hammer Configuration". It appears to default to 800MHz, but > there's an "Auto" choice. Does using Auto fix anything? > > > I added it directly to the 2nd CPU (diagram on page 9 of > > http://www.tyan.com/manuals/m_s2895_101.pdf) and the problem > > seems to be the interaction between nfe0 and powerd : > > That board is the weirdest thing I've seen in years. > > Two separate CPUs using a single (shared) memory controller, No. Each CPU contains its own memory controller (just like all AMD's Opteron/Athlon64 CPUs does.) > two > separate (and different!) nVidia chipsets, More like one chipset consisting of several physical chips. (Which is actually quite common. The most common division is a "nortbridge/southbridge" division, but other ways are possible too.) The only unusual thing is that there are several chips connected directly to the CPUs, instead of having the CPUs talk to a single chip which in turn talks to another chip which can easily create bottlenecks. > a SMSC I/O controller > probably used for serial and parallel I/O Just like almost all other motherboards. >, two separate nVidia NICs with > Marvell PHYs (yet somehow you can bridge the two NICs and PHYs?) What is so wierd about that? If you want to have more than one ethernet connection, then you normally have more than one NIC. Bridging can easily (and commonly) be done over separate NICs. >, two > separate PCI-e busses (each associated with a separate nVidia chipset), Since it is always the case that each PCI-E slot or PCI-E device sits on its own bus I fail to see anything strange about that. (And it is actually very common to have the PCI-E slots on motherboards be connected to different chips.) > two separate PCI-X busses... the list continues. Having more than one PCI-X bus used to be fairly common on server boards for performance reasons. Nowadays PCI-X is slowly being replaced with PCI-E so on the latest generation of serverboards there are usually no more than one PCI-X bus. > > I know you don't need opinions at this point, but what a behemoth. I > can't imagine that thing running reliably. I would rather say it is a quite elegant design for a high-end motherboard intended for server/workstation installations. It is a dual-socket Opteron board. Each Opteron has its own memory-controller and uses HyperTransport to connect to other components. Each dual-socket Opteron has three HyperTransport links available. One from each CPU will be needed to the other CPU, leaving two links from each CPU available to connect to other chips. From that starting point it is a fairly obvious design. To maximise the available bandwidth one would want to spread out the chips over these links, which this motherboard does fairly well, using three of the four available links. (And hanging the most important things from CPU0, so you can actually use the board even if you have only one CPU installed.) As for reliability I see no particular reason for that board to be less reliable than any other multi-CPU board. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Interfaces order
On Wed, Jun 16, 2004 at 03:21:05PM +0100, Carlos Matos wrote: > Hi, > >I'm trying to implement a mobile network. My Mobile router have two >interfaces (sis0 and wi0). My problem is that the daemon "rtsold" >that I am using, need to select the interface wi0, but is selecting >the interface sis0. This appens because the sis0 interface appears >first in the startup. There is some way to change the order of the >interfaces that are configured in the startup? > >Thanks for the attention >From the manpage for rtsold it seems as if one of the parameters the daemon takes is which interface to use. Relying on the order in which interfaces are configured seems like a bad idea. -- Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Simple port forwarding question
On Tue, Nov 02, 2004 at 04:36:30PM -0800, John Fox wrote: > Hi, folks. > > I'm experimenting, trying to setup a situation where connections > to port 25 on machine A are forwarded to port 25 on machine B. > I've read the ipfw manpage and it looks as though what I'm doing > is correct. > > > The IPFW rules on machine A are: >00100 fwd machineB tcp from any to any 25 >65535 allow ip from any to any > > And there is a sendmail listening on B's port 25. > > But when I telnet to machine A's port 25, all I get is > a perpetual "Trying" message that just sits there. Don't use "fwd" for this - it doesn't work that way (for one thing B is unlikely to handle an IP-packet that is still adressed to A.) Use natd and the '-redirect_port' option to natd instead - that works. -- Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: programatically list all local IP addresses ?
On Thu, Jul 18, 2002 at 07:27:08AM -0700, Chuck T. wrote: > I'm sure this is a FAQ, but I sure can't find the answer. I've tried the > usually suggested gethostname()/gethostbyname() approach, but that only > returns the *first* match in /etc/hosts. In one case that was 127.0.0.1. > Clearly this was a case where /etc/host.conf gave priority to the host file. Use gethostname()/gethostbyname() (or gethostbyaddr()) and then look through the 'h_addr_list' array in the 'struct hostent' returned by gethostbyname(). That should contain all the network addresses that were found for the given host. Another possibility is of course to run 'ifconfig -a' and then parse the output to find out what IP-addresses are configured on the machine. > > I don't want to call gethostent() because (if I understand the man page > correctly) that would limit me entries /etc/hosts ignoring DNS. > > I guess I could do a gethostname()/gethostbyname() and then if I fail to > find > a usable (non-rfc1918) address gethosten(). Is there a better way? > > Also is listing 127.0.0.1 as the actual host name in addition to "localhost" > in /etc/hosts considered to be proper ? That might be the only IP-address the machine has, so why not? -- Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: programatically list all local IP addresses ?
On Thu, Jul 18, 2002 at 09:52:14AM -0700, Chuck T. wrote: > Excellent, that's just what I was looking for! Thanks. > >do a man getifaddrs(3) > > > >Bruce Just be aware that getifaddrs(3) (which does seem to be a quite useful function) is not very portable. It appears to be available on recent releases of all the *BSDs, but it does not seem to exist on Solaris or Linux. Now, if you don't need your program to be portable this is of course not a problem, but writing unportable code should be an informed decision rather than done out of ignorance. -- Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: How to use if_bridge
On Tue, Apr 18, 2006 at 04:41:42PM +0200, Fabian Keil wrote: > Sten Daniel Sørsdal <[EMAIL PROTECTED]> wrote: > > > Fabian Keil wrote: > > > > > The example section has the following sentence "Such a con- > > > figuration could be used to implement a simple 802.11-to-Ethernet bridge > > > (assuming the 802.11 interface is in ad-hoc mode)." > > > > > > I don't get the meaning of the ad-hoc mode part. In my tests if_bridge > > > worked in hostap mode as well, but failed in infrastructure mode. Could > > > you clarify if (or why not) bridging in infrastructure mode should work? > > > > hostap should work, ad-hoc should work. by infrastructure you mean that > > the card operates as a 'station'? then it shouldn't work (correctly) as > > defined by the standard. commercial products tend to implement "mac-nat" > > or just simple dumb passthrough (which requires support on the ap side > > and is very much like ad-hoc mode). > > By infrastructure mode I mean the card is connected to an access > point, in other words the default mode. > > > you would want to look into WDS for a standard way of dealing with > > bridging on 802.11 > > Thanks for the tip, but I'm not sure if it would help in my case. > Wikipedia says WDS "enables the interconnection of access points", > which is not what I wanted. > > I tried if_bridge to let QEMU on my laptop talk to the wireless > network. It worked if the Laptop's NIC was in ad-hoc or hostap mode, > but failed if the NIC was connected to an access point. > > NAT solved the problem, but I still don't understand why if_bridge > didn't work. If it was expected to fail I think it should be mentioned > in the man page. Because when a station sends a packet to an AP the source ethernet address must be that of the station. A bridge should not modify the packets passed through it so then the source address should be that of the originating computer instead of that of the station and then things will not work correctly. This can be solved with "4-address" frames that add a 'station' field to the transmitted frames. This requires that both station and AP support 4-address frames, which few do. The wireless code in FreeBSD does not have such support yet. (4-address frames is a necessary component for WDS, but WDS needs a bit more than that. 4-address frames can be used with a normal AP-station connection if both sides support it, but as I said few devices support it currently.) (The four addresses involved are: source, dest, station, AP; as compared to the three addresses used in normal 802.11 frames: source, dest, AP.) -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to change order of NICs in FreeBSD?
On Mon, Apr 24, 2006 at 03:29:52PM +0200, Ferdinand Goldmann wrote:
> Hi there,
>
> this might be an easy one, but I seem to be unable to come up with a google'd
> solution. :(
>
> I have a machine with four network cards using the em driver:
>
> [EMAIL PROTECTED]:12:0: class=0x02 card=0x10028086 chip=0x10268086
> rev=0x04 hdr=0x00
> [EMAIL PROTECTED]:11:0: class=0x02 card=0x10028086 chip=0x10268086
> rev=0x04 hdr=0x00
> [EMAIL PROTECTED]:7:0: class=0x02 card=0x016d1028 chip=0x10768086
> rev=0x05 hdr=0x00
> [EMAIL PROTECTED]:8:0: class=0x02 card=0x016d1028 chip=0x10768086
> rev=0x05 hdr=0x00
>
> Two of the cards are onboard, namely em2 and em3, and the other two (em0, em1)
> are sitting in expansion slots. I would like to change the order of the cards,
> so that the onboard cards are recognized as em0 and em1.
>
> I tried using the device.hints file, but without much success. Is there any
> way how to do this?
>
I don't think there is any way to change in what order the kernel detects
and configures them, but it is possible to rename the interfaces
somewhat later in the boot process.
You could try using the 'name' option to ifconfig(8).
I believe the syntax is:
ifconfig [oldifname] name [newifname]
This can also be done via /etc/rc.conf.
Read the the section on network_interfaces in the manpage for rc.conf(5) for
syntax.
You will probably have a minor problem if you wish to rename {em2, em3} to
{em0, em1} while at the same time renaming the original {em0,em1} to
{em2,em3} but that should be easily resolved using temporary names.
--
Erik Trulsson
[EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fxp(4) checksum (offloading?) errors
On Wed, Jan 31, 2007 at 09:47:05PM +0100, Cédric Jonas wrote: > Hi, > > I get TCP/UDP checksum errors with fxp(4). I noticed it after using > Wireshark today: > > Checksum: 0xac18 [incorrect, should be 0xfbc7 (maybe caused by > checksum offloading?)] > > for example. Is that for incoming or outgoing packets? If it is for outgoing it is perfectly normal and nothing to be worried about (assuming that your NIC does checksum offloading.) If it is for incoming packets it could be a real problem. > > If I understand it more or less correctly, checksum offloading is > performed by or with help of the NIC - only for TCP and UDP, where the > checksum fails exactly... Checksum offloading means that the calculation of the checksum is done by the NIC instead of by the main CPU. For outgoing packets this means that wireshark or tcpdump and all similar programs see the packets before they have been handed over to the NIC, which means that the correct checksum has not yet been calculated and probably contains garbage. > I didn't found a way to disable it, so I assume it's a bug in the > driver... I don't know exactly which infos I must provide additionally > to the following, so don't hesitate to ask more :) > > Used NIC: > > fxp0: port 0xa400-0xa43f mem > 0xfb03-0xfb030fff,0xfb00-0xfb01 irq 16 at device > 7.0 on pci2 > > Used system: > > FreeBSD ganymed 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sun Jan 21 > 16:07:51 CET 2007 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GANYMED i386 > -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fxp(4) checksum (offloading?) errors
On Wed, Jan 31, 2007 at 04:25:34PM -0500, Wesley Shields wrote: > On Wed, Jan 31, 2007 at 09:47:05PM +0100, C?dric Jonas wrote: > > Hi, > > > > I get TCP/UDP checksum errors with fxp(4). I noticed it after using > > Wireshark today: > > > > Checksum: 0xac18 [incorrect, should be 0xfbc7 (maybe caused by > > checksum offloading?)] > > > > for example. > > > > If I understand it more or less correctly, checksum offloading is > > performed by or with help of the NIC - only for TCP and UDP, where the > > checksum fails exactly... > > Yes, the checksums are offloaded to the card. Maybe I missed it, but > you were not very clear on where you were seeing the invalid checksums. > In the case of wireshark running on the machine which is doing the > offloading then this makes sense as the checksums are computed AFTER > wireshark sees them. The best way to know for sure if the checksums > were computed correctly is to check them on the destination or somewhere > along the wire to the destination. > > > I didn't found a way to disable it, so I assume it's a bug in the > > driver... I don't know exactly which infos I must provide additionally > > to the following, so don't hesitate to ask more :) > > According to ifconfig(8) they can be toggled using -rxcsum and -txcsum, > but it is dependent upon the NIC/driver in use. A quick glance through > fxp(4) indicates that it doesn't do checksum offloading. I'm sure > someone will correct me if I am wrong. :) Some fxp(4) NICs support checksum offloading, but most don't. The fairly common 82559 controller chip does not support checksum offloading. The 82550 (which can be found on the Intel PRO/100 S cards) does support checksum offloading. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dest vs source ports ...
On Tue, Oct 22, 2002 at 11:34:28AM -0300, Marc G. Fournier wrote: > > Just a quick question ... how does the OS determine the 'source port' when > connecting to a remote site? is it reasonably safe to assume that the > lower of the two ports is the dest port? for instance, if I try to telnet > to a remote site where the remote site is running a service on port 6667, > is it a pretty safe bet that FreeBSD will pick a port >6667 to go out on? > or is there an equal chance of it being lower? If one does not specify the source port that is to be used the OS just picks one at random from the set of available port numbers. (Alright, it's not quite random, but it could as well be.) There is normally no relationship between source and destination port numbers. -- Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Simple question, what is an inOctet ... ?
On Wed, Mar 24, 2004 at 12:01:39PM -0400, Marc G. Fournier wrote: > > Just setup net-snmp, and zabbix to monitor it ... what exactly is an > Octet? 1 byte? An octet is eight bits. A byte is also usually eight bits, but this is not universally true. 'Octet' is used in many standards-documents to have an unambigous term for a collection of eight bits, since 'byte' does not have a well-defined size. -- Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
