Windows X
I am a new user to FreeBSD. Is Windows X an extremely basic windows program. I loaded your CD that I purchased from Microcenter onto my computer and I was not able to see anything except a very primitive windows program. If this is what is then I'm fine with it, but if there is more how can I get to it? Thank You for you Time, Christopher Smith [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Weird memory detection problem on Compaq M700
Apologies for the cross-post - this is mainly a hardware problem, but I've thrown it into -questions as well in case someone has already seen and fixed this issue. I have a Compaq Armada M700 that I used for a firewall. I've recently upgraded the memory in it to 320MB (64MB onboard + 256MB). The machine detects the memory fine. The FreeBSD bootloader detects the memory fine. However, when the kernel boots it only detects 64MB. What's weird, is that if I stick in a 128MB memory module then the kernel detects the full amount (192MB) fine. I realise I can use options MAXMEM to manually specify the amount of RAM in the machine, but it just struck me as rather strange that it detects 192MB fine but not 320MB (particularly since the bootloader sees it all). This is with FreeBSD 5.2.1. I've not tried it with 4.x. Has anyone else encountered this problem (and maybe fixed it) ? -- +~~+ | Chris Smith | Flick Pest Control | | Systems Administrator | Suite G4, Zenith Data Centre | | p: +61 2 9495 9633| 821-843 Pacific Highway | | f: +61 2 9495 9688| Chatswood, NSW 2067 | | e: [EMAIL PROTECTED] | Australia| +--+ -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering. http://www.mailguard.com.au/mg ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Weird traceroute problem
On Thursday, April 3, 2003, at 06:47 PM, Toni Schmidbauer wrote: On Thu, Apr 03, 2003 at 03:08:52PM +1000, Christopher Smith wrote: I have two firewalls - the second is being prepped to replace the first. All networking from the second machine appears to be fine *except* traceroute looks broken. This happens: could it be that your second maschine blocks all incoming icmp traffic? so the traceroute udp packets are leaving your network but the time exceeded or port unreachable icmp packets coming back are blocked? There are no rules on the second machine yet. From a tcpdump, it appears there are no icmp messages being returned by the routers. However, I don't understand why this only happens to this one machine - both the other firewall and the target host can traceroute through the same routers fine... Is there some weird bug in 4.8 that affects whether or not icmp messages are received ? -- +- Christopher Smith, Systems Administrator --+ | Server Security Group, Information Technology Services | | The University of Queensland, Brisbane, Australia, 4072 | +- Ph +61 7 3365 4046 | email [EMAIL PROTECTED] | Fax +61 7 3365 4065 -+ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Weird traceroute problem - SOLVED
It appears I've been bitten by a bug in the vlan code. I noticed while tcpdumping that the icmp time-exceeded packets were getting back to the vlan parent interface, but not to the vlan interface itself. This thread appears to describe the underlying problem: http://groups.google.com/groups?hl=enlr=ie=UTF-8oe=UTF- 8threadm=3E05A429.7080506_obluda.cz%40ns.sol.netrnum=5prev=/ groups%3Fq%3Dfreebsd%2Bhardware%2Bvlan%2Bbug%26hl%3Den%26lr%3D%26ie%3DUT F-8%26oe%3DUTF- 8%26selm%3D3E05A429.7080506_obluda.cz%2540ns.sol.net%26rnum%3D5 And this PR referenced in it has a patch that fixes the problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/46405 I'm guessing this will only affect some people, as the problem was intermittent (depending on the intervening routers). The ones that were sending back the ICMP packets that were triggering the bug were Cisco Catalyst 6500s running native IOS (the networking people here tell me). Presumably these routers change the priority of some ICMP packets ? In any event, can someone please merge the patch in the PR referenced above into the main source tree, because the problem it triggers is rather mystifying :). -- +- Christopher Smith, Systems Administrator --+ | Server Security Group, Information Technology Services | | The University of Queensland, Brisbane, Australia, 4072 | +- Ph +61 7 3365 4046 | email [EMAIL PROTECTED] | Fax +61 7 3365 4065 -+ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Weird traceroute problem
:43.888194 130.102.1.69.34304 130.102.2.15.33444: [no cksum] udp 16 (ttl 4, id 34314, len 44) 15:06:43.888610 130.102.2.15 130.102.1.69: icmp: 130.102.2.15 udp port 33444 unreachable (ttl 61, id 23355, len 56) 15:06:43.888734 130.102.1.69.34304 130.102.2.15.33445: [no cksum] udp 16 (ttl 4, id 34315, len 44) 15:06:43.892707 130.102.2.15 130.102.1.69: icmp: 130.102.2.15 udp port 33445 unreachable (ttl 61, id 23356, len 56) 15:06:43.892788 130.102.1.69.34304 130.102.2.15.33446: [no cksum] udp 16 (ttl 4, id 34316, len 44) 15:06:43.893001 130.102.2.15 130.102.1.69: icmp: 130.102.2.15 udp port 33446 unreachable (ttl 61, id 23358, len 56) -- +- Christopher Smith, Systems Administrator --+ | Server Security Group, Information Technology Services | | The University of Queensland, Brisbane, Australia, 4072 | +- Ph +61 7 3365 4046 | email [EMAIL PROTECTED] | Fax +61 7 3365 4065 -+ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
High interrupt load on firewalls
We have two firewalls sitting on gigabit links. Each has 2 Netgear GA620 (ti driver) fibre cards with about 7 vlans spread across them. Both these machines run at *very* high interrupt loads (95 - 100% during business hours (mostly 100%), 80 - 90 % during off hours). They are 1GHz P3 machines (Dell 1550s) with 256MB of RAM. They're actually dual machines, but enabling the second CPU doesn't help in terms of load, it just halves the numbers top reports. Obviously, these machines process a lot of traffic. However, the interrupt load seems to me to be very, very high and the main reason we are seeing such high rates of packet loss (up to 10%, constantly) through these machines - is there any way it can be lessened, either with a better driver, different network cards, or some other way ? We are currently testing with a dual 2.4GHz P4 (Dell 2650) using the same network cards, and are peaking at around 40% (really 80%). However, that doesn't seem to leave much room to grow, and it's a very expensive way to ease the load. Will FreeBSD 5.0 be able to spread the interrupts across both CPUs ? Is this high interrupt load a problem with the driver, the hardware, FreeBSD itself, or is it something that is normal ? What hardware are other people using to firewall high-volume gigabit links ? -- +- Christopher Smith, Systems Administrator --+ | Server Security Group, Information Technology Services | | The University of Queensland, Brisbane, Australia, 4072| +- Ph +61 7 3365 4046 | email [EMAIL PROTECTED] | Fax +61 7 3365 4065 -+ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Use MFS for /tmp, etc ?
What's the consensus for using an MFS filesystem for places like /tmp. /var/tmp, /var/run, etc ? I see in some oldish postings to -questions this is considered a bad idea, does this still apply in more recent versions of FreeBSD (4.6.2) ? -- +- Christopher Smith, Systems Administrator --+ | Server Security Group, Information Technology Services | | The University of Queensland, Brisbane, Australia, 4072| +- Ph +61 7 3365 4046 | email [EMAIL PROTECTED] | Fax +61 7 3365 4065 -+ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
