Re: Source MAC addresses when bridge(4) used
Peter Jeremy wrote: On Sun, 2007-Jan-07 18:58:18 -0500, Sten Daniel Srsdal wrote: Peter Jeremy wrote: I've just noticed an number of unpexected IP address changed MAC messages on one of the hosts in my network. It is connected via a FreeBSD bridge to the rest of my network (there aren't enuf network ports in my son's bedroom). The configuration looks like: ... Does moving 192.168.123.36 to the bridge interface help? That gets rid of the IP moved from MAC to MAC on NIC messages. It doesn't really address the questions I raised about why I'm getting them but I think getting rid of them will do for now. The exact logic why this happens eludes me. Putting the IP address on the bridge interface has been considered the correct way on the bridge implementations that has an actual logical bridge interface I've come across. It is, as far as i understand, to address the problems you described. -- Sten Daniel Sørsdal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Source MAC addresses when bridge(4) used
from 00:00:24:28:98:9a to 00:20:ed:78:9c:a3 on dc0 Both hosts are running 6.1-STABLE: laptop1: FreeBSD laptop1.vk2pj.dyndns.org 6.1-STABLE FreeBSD 6.1-STABLE #0: Wed Nov 15 18:40:00 EST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/laptop i386 desktop: FreeBSD jashank.vk2pj.dyndns.org 6.1-STABLE FreeBSD 6.1-STABLE #15: Wed Aug 2 18:35:57 EST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/jashank i386 I'm not seeing similar messages on other hosts in my network, it seems that the desktop is always sending traffic to the rest of my network via rl0. This leaves two questions: Firstly, why is laptop1 seeing packets coming from both interfaces on the desktop? I had expected that the desktop would always originate packets from the interface with the IP address (netstat -r on it shows laptop1 associated with rl0). Secondly, why is laptop1 reporting a list of address moved messages from tl0 to rl0 without matching movements from rl0 to tl0? Does moving 192.168.123.36 to the bridge interface help? -- Sten Daniel Sørsdal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vr speed issues
Philipp Ost wrote: Charles Sprickman wrote: [snipped] Performace with scp was around 200KB/s, ftp wavered between 300-500KB/s. This did not appear to be a duplex mismatch - unmanaged switch showed them all at 100/Full, put some other hosts on the same ports/cabling and got near wire speed. I just checked with the boxes I have here. One is an Athon XP on a Asus board with a VIA Rhine II on board; the other is a `old' Celeron 500 on a MSI board with a Intel ``Pro 100/S Desktop Adapter''. I transfered a 538MiB file (some old CURRENT snapshot) via sftp. My result: from box one to box two (vr to fxp) I get 2.3MB/s; from box two to box one (fxp to vr) I get 3.1MB/s. The first box is running 6.2-PRERELEASE from 11/18, the Intel box is running 7.0-CURRENT from 11/24. Output of $ dmesg | grep vr vr0: VIA VT6102 Rhine II 10/100BaseTX port 0x8000-0x80ff mem 0xd600-0xd6ff at device 18.0 on pci0 miibus0: MII bus on vr0 and $ dmesg | grep fxp fxp0: Intel 82550 Pro/100 Ethernet port 0xc000-0xc03f mem 0xdd02-0xdd020fff,0xdd00-0xdd01 irq 11 at device 1.0 on pci1 miibus0: MII bus on fxp0 [...] fxp0: Microcode loaded, int_delay: 1000 usec bundle_max: 6 fxp0: Microcode loaded, int_delay: 1000 usec bundle_max: 6 That sounds awfully lot like a bad cable/connector aside from duplex mismatch. Especially the part about larger packets has more packet loss, which can be indicative of both. Duplex mismatch because a larger packet has a higher probability of getting junked by the part that believes the link is full duplex. Cable/Connector because a larger packet has a higher probability of getting junked by interference/lack of signal. Obtw: SFTP requires alot more due to encryption and is less likely to exhaust the 100mbit connection before exhausting other local resources. Many is surprised to learn that something around 9 out of 10 network failures is due to improper cabling. If in doubt get a good store made cat6 cable to verify and don't buy cheap for the cat5e's there really is a *big* difference. The cheapest is almost always the hardest to get right on the first try. Some cards can be suddenly reset when there are too many errors of one sort or another and the drivers do not reprogram the cards into the previously selected mode (if non autonegotiate settings are used). Drivers for VIA nic's on linux tends to be notorious that way. And NEVER set speed/duplex on any side unless you can set them on both (autoselect will default to half duplex when other end is non-autonegotiate) Try setting the mode to 10mbit/half duplex (and verify on switch) to see if the packet loss goes away. If it does then it's the cable, if it doesn't then it's still possible but less likely to be the cable. Please let us know what you find out. -- Sten Daniel Sørsdal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath0 weak connectivity
Sam Leffler wrote: I've lost context about your problem but it appears you're having trouble associating with trejago sometimes. The failed scan shows that your rssi was only 6 when you were having problems which is a very marginal signal so I'm not at all surprised you're having trouble. You've got strong signal ap's on overlapping channels (5 and 7) which are likely drowning the signal on your ap. I don't see anything the driver could do differently; this seems more an issue of your environment being very busy. I vaguely recall you were comparing the operation of the freebsd to windows. If so then perhaps the windows driver was doing better because it switched to XR mode and operating in XR mode you were able to punch through the noise to get to the ap. freebsd does not support XR mode. Sam Are there any plans to support this? What about fastframes/bursting? 10Mhz, 5Mhz channels? WDS? Virtual AP? Is there any place where i can read about this? Apologies if any of these are already in the works. -- Sten Daniel Sørsdal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_6 does not compile
martinko wrote: Kent Stewart wrote: On Thursday 21 September 2006 18:20, Joerg Pernfuss wrote: On Fri, 22 Sep 2006 02:59:53 +0200 martinko [EMAIL PROTECTED] wrote: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 Chances are you have failing hardware. Kris you must be kidding! :-o no, really, this is a laptop and i hope it's not going to die or something. :-/ well, it would actually be better now before the warranty is over. ;-) anyway, how did you come to your conclusion pls ?? SegFault 11 is normally a strong indicator of dying RAM. But in a laptop it could be related to heat such as a clogged heatsink or the equivalent. In one of my AMD desktop, I blew the dust out of the heat sink and the cpu temp dropped 5oC. There is a list of causes in the FAQ and they can all be the cause. Kent Joerg dears, i booted up knoppix and ran memtest for 4 hours (std test), then all tests for 8 hrs (6 passes), and no error was reported. i searched log for hdd failure messages as mentioned in a thread from a few days ago and did not find anything. my laptop temperature did not exceed the usual level. i haven't had any issue regarding this yet. (nearly two years) i wonder what else i could check or what other tests i could run. any ideas pls ? martin ps: i'll try to locate the FAQ mentioned above. Does the error ocurr at different times in the build process or does the build process stop at the same place? I've had similar problems when the .so's already installed in the system was not correct or corrupt. So something i did 3 months earlier out of boredom cost me half a day of tracking it down (i'm no wiz). Buildworld always stopped at the same location when this happened (with a signal 11) -- Sten Daniel Sørsdal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Network performance 6.0 with netperf
Michael VInce wrote: I reinstalled the netperf to make sure its the latest. I have also decided to upgrade Server-C (the i386 5.4 box) to 6.0RC1 and noticed it gave a large improvement of network performance with a SMP kernel. As with the network setup ( A --- B --- C ) with server B being the gateway, doing a basic 'fetch' from the gateway (B) to the Apache server (C) it gives up to 700mbits/sec transfer performance, doing a fetch from server A thus going through the gateway gives slower but still decent performance of up to 400mbits/sec. Are you by any chance using PCI NIC's? PCI Bus is limited to somewhere around 1 Gbit/s. So if you consider; Theoretical maxium = ( 1Gbps - pci_overhead ) -- Sten Daniel Sørsdal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Routes not deleted after link down
Gleb Smirnoff wrote: My vote is that we should implement this functionality and make it switchable via sysctl. I'd leave the default as is. What is opinion of other networkers? How about also adding a sysctl for setting a delay time between event and disabling of the route? Then even people with roaming wlan cards can benefit. Also it is in my opinion that the route be disabled (moved to a passive route table maybe?) and not deleted. At my old job i came across situations where the lack of this feature caused headaches and once or twice the loss of a customer. -- Sten Daniel Srsdal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: wi0 and mtu setting [bad idea]
How about a configuration of two Ad-hoc cards pointing towards eachother between two buildings and an IPSec tunnel is applied. Wouldn't it be great if (unencrypted) packets destined to go through that IPSec tunnel could go through in full ethernet size, without fragmentation, pr host tcp stack adjustments or resending because of DF flag? What about transporting VLANs over wireless? There is a lot of equipment out there, especially wireless but also wired (ATM?) that allows larger MTUs for special circumstances. It's like buying a car with all the extra features - but only a handful of the features work. Just my 2 nkr --- Med vennlig hilsen / Best regards Sten Daniel Sørsdal Wireless Manager WAN Norway AS --- -Original Message- From: Wright, Michaelx L [mailto:[EMAIL PROTECTED]] Sent: 3. januar 2003 19:28 To: Evren Yurtesen; [EMAIL PROTECTED] Cc: Michael Sierchio; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: wi0 and mtu setting [bad idea] Good Afternoon All, I am curious to know if you are taking into account MTU limitations imposed by link-partners i.e. switches, hubs, routers and the like. Some if not most ( for Unix) require end-nodes to be approximately 22 bytes less than the link-partner device's maximum supported MTU. I am not sure if, but would somewhat expect, a wireless access point to have some impact on the sizing and/transfer at above the 1500 MTU setting. Cheers M. L. Wright Intel UNIX-NQL 503.264.8300 -Original Message- From: Evren Yurtesen [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 10:07 AM To: [EMAIL PROTECTED] Cc: Michael Sierchio; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: wi0 and mtu setting [bad idea] You are definetely right, setting the MTU might be really bad thing, but why dont you let the person setting it decide it for himself? Thus FreeBSD wi driver can support setting this value higher than 1500 in your own risk. Its a functionality request only. I dont suggest that you set the default mtu for wi driver something higher than 1500! Evren On Fri, 3 Jan 2003 [EMAIL PROTECTED] wrote: On Fri, 3 Jan 2003 02:22:34 +0200 (WET) Evren Yurtesen wrote: I definetely agree and obviously since mikrotikos supports this then linux should do since mikrotikos is built on linux. Why shouldnt FreeBSD support setting mtu of wireless interfaces higher than 1500 Setting a wireless interface to a MTU of higher than 1500 octets is ill-advised unless you are in very specific, unusual conditions. The subject header talks about wi0, which implies IEEE Ethernet 802.11b standard interface. The IEEE maintains the Ethernet standards. Start with: http://www.ieee.org or http://www.ieee802.org From a quick glance at the standard: IEEE Std 802.11b-1999 (Supplement to ANSI/IEEE Std 802.11, 1999 Edition) Supplement to IEEE Standard for Information technology Telecommunications and information exchange between systems Local and metropolitan area networks Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Higher-Speed Physical Layer Extension in the 2.4 GHz Band it is not clear to me that MTU 1500 octets are legal with 802.11b. If your system is connected to the Internet, setting the MTU on your FreeBSD system, which is probably not a core router, to anything above 1500 is a stupid idea. If you don't already know this, and don't understand the reasons why, you would be best advised not to mess with the MTU at all. Stick with the default until you gain more experience. You might want to read up on packet fragmentation and MTU discovery for explanations why this is a good idea. good luck, fletcher To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
RE: wi0 and mtu setting
I believe I read somewhere that 802.11b standard supports larger MTUs than 1500. I know basic ethernet MTU is 1500 but even my crappy old Nortel 8603 routing switch supports up to MTU 1960 Any corrections appreciated // Sten -Original Message- From: David Magda [mailto:[EMAIL PROTECTED]] Sent: 2. januar 2003 21:59 To: Evren Yurtesen Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: wi0 and mtu setting Evren Yurtesen [EMAIL PROTECTED] writes: I wonder how come wi driver doesnt let me to set mtu higher than 1500 even though I know the card supports it? Because the maximum size of the data poriton in a frame for 10Mbit and 100Mbit Ethernet is 1500. Will this be changed in a new version of the driver? Not unless they change the standard. I believe 1Gbit Ethernet is slightly different but would have to look up specifics. -- David Magda dmagda at ee.ryerson.ca Because the innovator has for enemies all those who have done well under the old conditions, and lukewarm defenders in those who may do well under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
