Re: SMP and networking under FreeBSD 5.3
Hello, ps: root542 0.0 0.7 1320 812 ?? Ss Tue09AM 2:22.10 /sbin/natd -dynamic -d -log_ipfw_denied -log_denied -dynamic -n dc0 ifconfig: pccard_ifconfig=NO ifconfig_xl0=inet 192.168.0.15 netmask 255.255.255.0 ifconfig_dc0=DHCP So FreeBSD 5.3 isn't production? I had read somewhere that 5.2.1 wasn't production and that 5.3 was supposed to be production. I'll look into upgrading to 5.4, it will take a bit of time to do that though. Joe --- Alex Zbyslaw [EMAIL PROTECTED] wrote: Joe wrote: Okay, I've been looking and looking for duplicate natd's. I have the /etc/rc.conf which has natd stuff below, and the only other place I see it is in ipfw. I was able to change my rc and use /etc/rc.d/natd start and that works. Which is better as it does not require me to reload my firewall rules. I still don't know why natd refuses to start the first time when called from ipfw. If I understand the boot procedure correctly, natd ought to be started as part of the /etc/rc.d/ipfw and that just calls /etc/rc.d/natd start which is what you are typing later from the command line with success, so why it fails at boot, I really don't know at this point. The cannot bind to divert socket error I thought could happen if a) you weren't root (seems unlikely from bootup) or b) something had already bound the socket. After your machine boots, what does ps uagxww | egrep natd show? Google also found this: - In FreeBSD, IPDIVERT must be enabled at compile time. I guess your kernel has this option, or natd would never have worked. what ifconfig lines do you have in /etc.rc.conf egrep ifconfig /etc/rc.conf I have no rc.conf.local Not too surprising. It could be used under 4.X as a second level to rc.conf, but exists nowadays for backwards compatibility and AFAIK isn't created by anything. As a more drastic attempt at a solution, could you try upgrading to 5.4? It has numerous improvements over 5.3, which was never a production release. Maybe some ordering problems was fixed. --Alex Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP and networking under FreeBSD 5.3
Joe wrote: Hello, ps: root542 0.0 0.7 1320 812 ?? Ss Tue09AM 2:22.10 /sbin/natd -dynamic -d -log_ipfw_denied -log_denied -dynamic -n dc0 Is this just after a reboot? If so, it does show that natd is running, so I'm not sure why you're getting the message you were getting. ifconfig: pccard_ifconfig=NO ifconfig_xl0=inet 192.168.0.15 netmask 255.255.255.0 ifconfig_dc0=DHCP That looks right. So FreeBSD 5.3 isn't production? I had read somewhere that 5.2.1 wasn't production and that 5.3 was supposed to be production. I'm not sure if I'm getting the terminology quite right, but I believe 5.4 was the first -STABLE release. Up until then 4.X was still the recommended release to use unless you required 5.X for particular hardware and were prepared to accept that it might not be quite production ready. My memory, when I was tracking this stuff, was that a lot of improvements went into 5.4. (I'm sure a lot went into 5.3 as well, but I'm reasonably sure it was not made the -STABLE or recommended branch or whatever). I'll look into upgrading to 5.4, it will take a bit of time to do that though. I don't think it's as bad as you might think -- my experience is that upgrades within a major release number (4.X, or 5.X) have been very easy. The compiling can take time, but I just try to make it coincide with a good movie on the telly, or a sunny afternoon in the garden. The bit I don't like is mergemaster, just because it's fiddly and hands on and requires lots of concentration. (Mergemaster is a great deal better than anything which preceded it, which if you go back far enough was nothing at all. It's not so much mergemaster that I dislike as just staring at the diffs trying to decipher how the OS-related changes affect my own changes). The handbook has a great section on upgrading. I'd recommend printing it off, especially if upgrading isn't something you have done often. Please note, I'm not saying that upgrading will fix your problem, but it might and 5.4 ought to be better than 5.3. Since no-one else has yet chimed in with any help, it might be worth posting a brand new message (with a more descriptive subject line) and just summarise the relevant bits of config and the natd error you are getting. (Summarise your natd_* config variables, ifconfig_* variables, OS version and an excerpt from your firewall showing any divert rules. That ought to be enough). One final thought. Did you start with a fresh install of 5.3? Did you upgrade from 4.X? If the latter, then make sure that you don't have any stray config/boot script files lying about. The easiest way to do that would be to run mergemaster (I like -s -v as options). You can always say no to everything, but you should study the list of files in /etc which are not in CVS and make sure that you recognize them all. If there are some you don't recognize which sound like they might be network/natd/firewall related, then they may be causing your problem. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP and networking under FreeBSD 5.3
Okay, I've been looking and looking for duplicate natd's.
I have the /etc/rc.conf which has natd stuff below, and the only
other place I see it is in ipfw.
I was able to change my rc and use /etc/rc.d/natd start and that
works. Which is better as it does not require me to reload my
firewall rules.
I still don't know why natd refuses to start the first time when
called from ipfw.
I have no rc.conf.local
Joe
--- Alex Zbyslaw [EMAIL PROTECTED] wrote:
Joe wrote:
Okay, back on topic.
I've changed my rules in ipfw, and no longer get the hostname
..
messages.
Now natd does not start and it complains 'unable to bind
divert
socket, and then cant assign requested address'. I'm using:
natd_enable=YES
natd_interface=dc0
natd_flags=-dynamic -d -log_ipfw_denied -log_denied
These are my parameters below which definitely work -- or you
wouldn't
be seeing this email :) I can't see anything obviously wrong
with
yours; what I would suggest is to start with just -dynamic
since
that's the only one that's *required* for this setup to work
and see how
that does. I can't find your original rules: I assume that a)
dc0 *is*
your external interface (typos are a common source of errors,
though I
don't think that's the case here) b) you have an
ifconfig_dc0=DHCP
line in /etc/rc.conf.
natd_enable=YES # Natd packet
translation
natd_flags=-log -log_denied -dynamic
natd_interface=sis0
ifconfig_sis0=DHCP# External
network
At startup I get a message like:
Jun 18 10:38:58 natd[701]: Aliasing to 0.0.0.0, mtu 1500 bytes
just after the firewall rules start up.
The divert rule in my firewall says:
ipfw add divert natd all from any to any via ${natd_interface}
If you have static rules rather than a script then you need
${natd_interface} to be replaced directly with dc0.
The other things to check, I guess, are that those are the
*only* natd
lines you have:
egrep natd /etc/rc.conf /etc.rc.conf.local
--Alex
__
Discover Yahoo!
Find restaurants, movies, travel and more fun for the weekend. Check it out!
http://discover.yahoo.com/weekend.html
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP and networking under FreeBSD 5.3
Joe wrote:
Okay, back on topic.
I've changed my rules in ipfw, and no longer get the hostname ..
messages.
Now natd does not start and it complains 'unable to bind divert
socket, and then cant assign requested address'. I'm using:
natd_enable=YES
natd_interface=dc0
natd_flags=-dynamic -d -log_ipfw_denied -log_denied
These are my parameters below which definitely work -- or you wouldn't
be seeing this email :) I can't see anything obviously wrong with
yours; what I would suggest is to start with just -dynamic since
that's the only one that's *required* for this setup to work and see how
that does. I can't find your original rules: I assume that a) dc0 *is*
your external interface (typos are a common source of errors, though I
don't think that's the case here) b) you have an ifconfig_dc0=DHCP
line in /etc/rc.conf.
natd_enable=YES # Natd packet translation
natd_flags=-log -log_denied -dynamic
natd_interface=sis0
ifconfig_sis0=DHCP# External network
At startup I get a message like:
Jun 18 10:38:58 natd[701]: Aliasing to 0.0.0.0, mtu 1500 bytes
just after the firewall rules start up.
The divert rule in my firewall says:
ipfw add divert natd all from any to any via ${natd_interface}
If you have static rules rather than a script then you need
${natd_interface} to be replaced directly with dc0.
The other things to check, I guess, are that those are the *only* natd
lines you have:
egrep natd /etc/rc.conf /etc.rc.conf.local
--Alex
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP and networking under FreeBSD 5.3
Okay, back on topic. I've changed my rules in ipfw, and no longer get the hostname .. messages. Now natd does not start and it complains 'unable to bind divert socket, and then cant assign requested address'. I'm using: natd_enable=YES natd_interface=dc0 natd_flags=-dynamic -d -log_ipfw_denied -log_denied Rules get set, natd does not start. Interesting thing is that if I restart ipfw at the end of /etc/rc ( /etc/rc.d/ipfw start ) natd starts. Hmm, I'm confused on this one. Joe --- Alex Zbyslaw [EMAIL PROTECTED] wrote: Joe wrote: Thanks Alex, Below are my rules. I have removed the IP addresses and replaced with x.x.x.x in most cases. Also some ports have been turned to y's instead of the actual port. I don't want to go into the details of your firewall; all I can offer is general advice for you to apply if you wish. There are plenty resources out there from the various man pages to the handbook. Firewalls can be trickier than they look and NAT makes them significantly more complicated to fathom correctly. I don't claim to be any kind of expert and everything I know started life being written by someone else :-) Any mistakes are most likely my own! I will say that it is worth making sure you understand your own firewall. At one point you suggested that you wanted to make your firewall script start later so that you had access to your IP address. I think you are on to a loser there because there is not particular time when DHCP finally gets the IP address. If your provider is down, it might take minutes, hours or even days. You could keep polling in some way to see if you had an IP address and not running your rules script until you did, but it would seem better to just write rules which work even without the IP address. Plus, that would also not work if you ever had a second external interface (e.g. an old-fashioned modem) which needed firewalling irrespective of the status of your ethernet interface. Although a firewall often need to know the actual addresses of hosts other than itself there is, as far as I can figure out, no logical reason for it to need to know it's own IP address if you have the me construct. (If, like my machine, your firewall is just another computer on a small network that is allowed to do exactly the same things as any other host on that network, then it needn't even use me. This makes life much easier because it interferes less with NAT). If you have me then you can always distinguish between your firewall and the rest of your network. Take the non-NAT case first: allow all from me to any out xmit ext_if allow all from any to me in recv ext_if These rules could only be triggered by packets addressed directly to your firewall. If you follow it with e.g. deny all from any to any out via ext_if deny all from any to any in via ext_if then you close off your internal network. NAT makes things more complicated, because before or after NATing (depending on the direction) packets from your network can look like they originate on your machine or are destined for it. E.g. allow all from me to any out xmit ext_if must come before the NAT rule because after NAT-ing all your internal packets are going out ext_if. whereas allow all from any to me in recv ext_if must come after the NAT rule to be sure that it is actually your firewall which is the recipient. If all you have is a small network, then there may be no reason to differentiate your firewall from any other machine. In this case, it is perfectly sufficient to write rules based on the ext_if alone. So I have rules like: # Allow connections initiated from internal network ipfw add allow tcp from any to any out xmit ext_if setup # Allow TCP through if setup succeeded ipfw add pass tcp from any to any via ext_if established The only IP addresses in my whole firewall are the limited number of hosts which can initiate some kind of connection into my network e.g. ipfw add allow tcp from x.x.x.x to any ssh setup (x.x.x.x not because I need to hide the IP but because I can't be bothered to find it in the firewall script :-)) NB that rule says any for recipient because it was written before me existed. But since my network is NATed, it would always be a packet header for my firewall and could only get elsewhere if I explicitly forwarded it. There's no mention of the interface because a prior rule has already allowed internal connections which would match. Looking at it now, I might get picky and put an interface spec in there just to be completist. It's often said that there is no security in obscurity, and while I don't always agree, I do think that if you actually have to hide the IPs in your firewall for it be secure, then it isn't secure. Since my firewall never
Re: SMP and networking under FreeBSD 5.3
Joe wrote: I'm not sure why I get the hostname ``or'' unknown message though. If you still get it once you take away your ifconfig stuff then you'll know that it was responsible. You haven't posted the actual lines you use, so no-one is going to be able to figure out what might be happening. Where you currently have variable=`ifconfig interface | stuff` or whatever, put echo $variable after it and you will see if you got it right or not. From what you've said I think your stuff works fine when there is an ip address and produces some junk when there isn't and you then feed that junk to an ipfw rule which gives you the error. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP and networking under FreeBSD 5.3
Thanks Alex,
Below are my rules. I have removed the IP addresses and
replaced with x.x.x.x in most cases. Also some ports have been
turned to y's instead of the actual port.
Some of these rules are probably not needed, but it works, or
at least it seems to be working.
In looking at the rules, 8 rules are not processed, I get 8
of the messages below, and 8 rules rely on the E_IPADDR to be
set ( The allowTcpConnectionOut shell function sets 3 rules ).
Since E_IPADDR is always used when referering to the
FULL_LAN which includes the interal interface, I'm just going
to switch to using 'me' instead.
Is it better to use 'me' or an ip address?
Joe
#! /bin/sh
# ipfw rules
#
##
# set up the ipf command
ipfw_cmd=/sbin/ipfw -q
#
##
# globals
##
GREP=/usr/bin/grep
E_IPADDR=`/sbin/ifconfig dc0 | $GREP -v inet6|$GREP inet | awk
'{print $2}'`
I_IPADDR=x.x.x.0 # x.x.x has been removed for this email
DNS_LOOKUPS=`$GREP nameserver /etc/resolv.conf|awk '{print $2}'
`
INTERNET_IFACE=dc0
LAN_IFACE=xl0
FULL_LAN={ $E_IPADDR or $I_IPADDR/24 }
DNS_SERVER=x.x.x.x # I've removed this for this email
##
#
##
# function for allowing tcp connections
# takes from to and interface
###
tcpAddAllow=$ipfw_cmd add allow tcp from
setup=setup keep-state
###
allowTcpEst() {
FROM=$1
TOWHO=$2
INTERFACE=$3
$tcpAddAllow $FROM to $TOWHO via $INTERFACE
established
$tcpAddAllow $TOWHO to $FROM via $INTERFACE
established
}
###
allowTcpConnectionOut() {
FROM=$1
TOWHO=$2
INTERFACE=$3
$tcpAddAllow $FROM to $TOWHO out xmit $INTERFACE
$setup
allowTcpEst $FROM $TOWHO $INTERFACE
}
###
allowTcpConnectionIn() {
FROM=$1
TOWHO=$2
INTERFACE=$3
$tcpAddAllow $FROM to $TOWHO in recv $INTERFACE $setup
allowTcpEst $FROM $TOWHO $INTERFACE
}
##
# flush all the rules
$ipfw_cmd -f flush
#
##
# allow from loop back
#$ipfw_cmd set enable 0
#$ipfw_cmd set enable 1
$ipfw_cmd add allow all from any to any via lo0
$ipfw_cmd add deny all from 127.0.0.1 to 127.0.0.1
$ipfw_cmd add deny all from any to 127.0.0.0/8
$ipfw_cmd add deny ip from 127.0.0.0/8 to any
#
##
# from the dsl modem / router , once again masked, they are
fixed IP's here
$ipfw_cmd add allow udp from x.x.x.x y to x.x.255.255 y via
$INTERNET_IFACE
#
##
# deny this shit worm and MS crap and SYN in
$ipfw_cmd add deny tcp from any to any in recv $INTERNET_IFACE
setup
$ipfw_cmd add deny ip from any to any 0-19,135-139,445,1214,1434
in recv $INTERNET_IFACE
#
##
# need to divert all packets to get them where we want them
$ipfw_cmd add divert natd all from any to any via
$INTERNET_IFACE
#
$ipfw_cmd add check-state
#
##
# this is the dc0 interface
###
# tcp
###
allowTcpConnectionOut $FULL_LAN any $INTERNET_IFACE
#
# for passive ftp (port 20) x-fers eek! does MS need this?
#$ipfw_cmd add allow log tcp from any 20 to any in recv
$INTERNET_IFACE
#
###
# this is udp DNS and NTP
###
$ipfw_cmd add allow udp from $FULL_LAN to any 53 out xmit
$INTERNET_IFACE keep-state
#
# ntp
$ipfw_cmd add allow udp from $FULL_LAN to any 123 out xmit
$INTERNET_IFACE keep-state
#
# this is apple talk shit we dont want
$ipfw_cmd add deny udp from any to any 192
#
# this is our new netgear router port crap we dont want, as well
as MS
$ipfw_cmd add deny udp from any to any 137
#
# the rest of UDP that should not have anything in it
$ipfw_cmd add allow log udp from any to any out xmit
$INTERNET_IFACE keep-state
#
###
# this is icmp out
###
$ipfw_cmd add allow icmp from $FULL_LAN to any out xmit
$INTERNET_IFACE keep-state
#
###
# icmp from router to any
###
# this is masked for internat email
$ipfw_cmd add allow icmp from x.x.0.254 to $FULL_LAN icmptypes
3,4
#
###
# for big joe to access mindspring ?
# and yahoo and some other places that like to ping ??
###
$ipfw_cmd add allow log icmp from any to any in recv
$INTERNET_IFACE
Re: SMP and networking under FreeBSD 5.3
Joe wrote: Thanks Alex, Below are my rules. I have removed the IP addresses and replaced with x.x.x.x in most cases. Also some ports have been turned to y's instead of the actual port. I don't want to go into the details of your firewall; all I can offer is general advice for you to apply if you wish. There are plenty resources out there from the various man pages to the handbook. Firewalls can be trickier than they look and NAT makes them significantly more complicated to fathom correctly. I don't claim to be any kind of expert and everything I know started life being written by someone else :-) Any mistakes are most likely my own! I will say that it is worth making sure you understand your own firewall. At one point you suggested that you wanted to make your firewall script start later so that you had access to your IP address. I think you are on to a loser there because there is not particular time when DHCP finally gets the IP address. If your provider is down, it might take minutes, hours or even days. You could keep polling in some way to see if you had an IP address and not running your rules script until you did, but it would seem better to just write rules which work even without the IP address. Plus, that would also not work if you ever had a second external interface (e.g. an old-fashioned modem) which needed firewalling irrespective of the status of your ethernet interface. Although a firewall often need to know the actual addresses of hosts other than itself there is, as far as I can figure out, no logical reason for it to need to know it's own IP address if you have the me construct. (If, like my machine, your firewall is just another computer on a small network that is allowed to do exactly the same things as any other host on that network, then it needn't even use me. This makes life much easier because it interferes less with NAT). If you have me then you can always distinguish between your firewall and the rest of your network. Take the non-NAT case first: allow all from me to any out xmit ext_if allow all from any to me in recv ext_if These rules could only be triggered by packets addressed directly to your firewall. If you follow it with e.g. deny all from any to any out via ext_if deny all from any to any in via ext_if then you close off your internal network. NAT makes things more complicated, because before or after NATing (depending on the direction) packets from your network can look like they originate on your machine or are destined for it. E.g. allow all from me to any out xmit ext_if must come before the NAT rule because after NAT-ing all your internal packets are going out ext_if. whereas allow all from any to me in recv ext_if must come after the NAT rule to be sure that it is actually your firewall which is the recipient. If all you have is a small network, then there may be no reason to differentiate your firewall from any other machine. In this case, it is perfectly sufficient to write rules based on the ext_if alone. So I have rules like: # Allow connections initiated from internal network ipfw add allow tcp from any to any out xmit ext_if setup # Allow TCP through if setup succeeded ipfw add pass tcp from any to any via ext_if established The only IP addresses in my whole firewall are the limited number of hosts which can initiate some kind of connection into my network e.g. ipfw add allow tcp from x.x.x.x to any ssh setup (x.x.x.x not because I need to hide the IP but because I can't be bothered to find it in the firewall script :-)) NB that rule says any for recipient because it was written before me existed. But since my network is NATed, it would always be a packet header for my firewall and could only get elsewhere if I explicitly forwarded it. There's no mention of the interface because a prior rule has already allowed internal connections which would match. Looking at it now, I might get picky and put an interface spec in there just to be completist. It's often said that there is no security in obscurity, and while I don't always agree, I do think that if you actually have to hide the IPs in your firewall for it be secure, then it isn't secure. Since my firewall never mentions my IP address, I can publish the whole thing and even if it has flaws it won't help since you don't know where I am :-) A bit long-winded, but I hope it helps, --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP and networking under FreeBSD 5.3
I'm still learning the firewall thing. I didn't understand the 'me' clause until recently. I'm using it on my UP box. My router actually runs off a cdrom. Its hard to make changes to it :-). Its an SMP box. It wouldn't help telling you my ip addresses anyway, because my system is internet IP - nat(dsl modem) - nat(lan). I have no idea what my real ip address is on the internet. In any case, thanks for the advice. I've been thinking of redoing these rules for 2 years now. So how would your rules look if nat were in the picture? Thanks, Joe --- Alex Zbyslaw [EMAIL PROTECTED] wrote: Joe wrote: Thanks Alex, Below are my rules. I have removed the IP addresses and replaced with x.x.x.x in most cases. Also some ports have been turned to y's instead of the actual port. I don't want to go into the details of your firewall; all I can offer is general advice for you to apply if you wish. There are plenty resources out there from the various man pages to the handbook. Firewalls can be trickier than they look and NAT makes them significantly more complicated to fathom correctly. I don't claim to be any kind of expert and everything I know started life being written by someone else :-) Any mistakes are most likely my own! I will say that it is worth making sure you understand your own firewall. At one point you suggested that you wanted to make your firewall script start later so that you had access to your IP address. I think you are on to a loser there because there is not particular time when DHCP finally gets the IP address. If your provider is down, it might take minutes, hours or even days. You could keep polling in some way to see if you had an IP address and not running your rules script until you did, but it would seem better to just write rules which work even without the IP address. Plus, that would also not work if you ever had a second external interface (e.g. an old-fashioned modem) which needed firewalling irrespective of the status of your ethernet interface. Although a firewall often need to know the actual addresses of hosts other than itself there is, as far as I can figure out, no logical reason for it to need to know it's own IP address if you have the me construct. (If, like my machine, your firewall is just another computer on a small network that is allowed to do exactly the same things as any other host on that network, then it needn't even use me. This makes life much easier because it interferes less with NAT). If you have me then you can always distinguish between your firewall and the rest of your network. Take the non-NAT case first: allow all from me to any out xmit ext_if allow all from any to me in recv ext_if These rules could only be triggered by packets addressed directly to your firewall. If you follow it with e.g. deny all from any to any out via ext_if deny all from any to any in via ext_if then you close off your internal network. NAT makes things more complicated, because before or after NATing (depending on the direction) packets from your network can look like they originate on your machine or are destined for it. E.g. allow all from me to any out xmit ext_if must come before the NAT rule because after NAT-ing all your internal packets are going out ext_if. whereas allow all from any to me in recv ext_if must come after the NAT rule to be sure that it is actually your firewall which is the recipient. If all you have is a small network, then there may be no reason to differentiate your firewall from any other machine. In this case, it is perfectly sufficient to write rules based on the ext_if alone. So I have rules like: # Allow connections initiated from internal network ipfw add allow tcp from any to any out xmit ext_if setup # Allow TCP through if setup succeeded ipfw add pass tcp from any to any via ext_if established The only IP addresses in my whole firewall are the limited number of hosts which can initiate some kind of connection into my network e.g. ipfw add allow tcp from x.x.x.x to any ssh setup (x.x.x.x not because I need to hide the IP but because I can't be bothered to find it in the firewall script :-)) NB that rule says any for recipient because it was written before me existed. But since my network is NATed, it would always be a packet header for my firewall and could only get elsewhere if I explicitly forwarded it. There's no mention of the interface because a prior rule has already allowed internal connections which would match. Looking at it now, I might get picky and put an interface spec in there just to be completist. It's often said that there is no security in obscurity, and while I don't always agree, I do think that if you actually have to hide the IPs in your firewall for
Re: SMP and networking under FreeBSD 5.3
Joe wrote: Hey thanks, it seems that ipfw complains during boot with a message: hostname ``or'' unknown which I have no idea where that is coming from yet, but will look. Then natd doesn't get started. If I run /etc/rc.d/ipfw start then the router is up and natd gets started. For now, I'll probably just add it to rc at the end. I think it has something to do with the order things get run. My firewall script is for a dhcp interface. Since I don't know the IP, I use ifconfig dc0 | grep -v inet6 | grep inet | awk ... to get the IP address for some of the rules. I'm wondering if this is failing and causing the message above. Is there a 'recommended' way to create a rule for ipfw on a dhcp interface using its IP address? You don't need any of your awk/grep palaver. Your ipfw rules should probably be specifying the interface not ip addresses. Natd with -dynamic will do the right thing when dhcp picks up its actual ip address. from man natd -dynamicIf the -n or -interface option is used, natd will monitor the routing socket for alterations to the interface passed. If the interface's IP address is changed, natd will dynamically alter its concept of the alias address. I have, for example: /etc/rc.conf: ifconfig_sis0=DHCP# External network /etc/rc.firewall script ipfw add divert natd all from any to any via sis0 and it all works just fine even though natd starts off saying that it sees an IP address of 0.0.0.0 Your error message is very likely down to your ifconfig | stuff command which may well run when there is no ip address configured. It'll work fine when you run it once the ip address is configured, but probably not before when the script actually runs. Why do you think your firewall rules need to know the IP address? If you do need it then ipfw2 (5.X only?) has me. From man ipfw me matches any IP address configured on an interface in the system. The address list is evaluated at the time the packet is analyzed. If you have that after your natd rule, though, it will (I think) just match everything so the interface name is good enough. e.g. from any to any via sis0 --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP and networking under FreeBSD 5.3
Actually it is not my divert rule that I am using the ip address. In fact my rc.conf has the 'right stuff' for natd, as the same ipfw rules worked in 5.2 and 5.1. Same rc.conf stuff for natd too. The ifconfig stuff is for other rules like: ipfw add allow tcp from $EXT_IPADDR to any out xmit dc0 setup keep-state I use ifconfig stuff to get EXT_IPADDR for the above rule. I suppose I could use 'me' as I usually am referring to both interfaces. I'll probably change to use me and see how that goes. I'm not sure why I get the hostname ``or'' unknown message though. Joe --- Alex Zbyslaw [EMAIL PROTECTED] wrote: Joe wrote: Hey thanks, it seems that ipfw complains during boot with a message: hostname ``or'' unknown which I have no idea where that is coming from yet, but will look. Then natd doesn't get started. If I run /etc/rc.d/ipfw start then the router is up and natd gets started. For now, I'll probably just add it to rc at the end. I think it has something to do with the order things get run. My firewall script is for a dhcp interface. Since I don't know the IP, I use ifconfig dc0 | grep -v inet6 | grep inet | awk ... to get the IP address for some of the rules. I'm wondering if this is failing and causing the message above. Is there a 'recommended' way to create a rule for ipfw on a dhcp interface using its IP address? You don't need any of your awk/grep palaver. Your ipfw rules should probably be specifying the interface not ip addresses. Natd with -dynamic will do the right thing when dhcp picks up its actual ip address. from man natd -dynamicIf the -n or -interface option is used, natd will monitor the routing socket for alterations to the interface passed. If the interface's IP address is changed, natd will dynamically alter its concept of the alias address. I have, for example: /etc/rc.conf: ifconfig_sis0=DHCP# External network /etc/rc.firewall script ipfw add divert natd all from any to any via sis0 and it all works just fine even though natd starts off saying that it sees an IP address of 0.0.0.0 Your error message is very likely down to your ifconfig | stuff command which may well run when there is no ip address configured. It'll work fine when you run it once the ip address is configured, but probably not before when the script actually runs. Why do you think your firewall rules need to know the IP address? If you do need it then ipfw2 (5.X only?) has me. From man ipfw me matches any IP address configured on an interface in the system. The address list is evaluated at the time the packet is analyzed. If you have that after your natd rule, though, it will (I think) just match everything so the interface name is good enough. e.g. from any to any via sis0 --Alex __ Discover Yahoo! Get on-the-go sports scores, stock quotes, news and more. Check it out! http://discover.yahoo.com/mobile.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP and networking under FreeBSD 5.3
On Tue, Jun 14, 2005 at 09:15:01AM -0700, Joe wrote: Hello, Not sure if this is the place to ask this. But this is a freebsd question. I've been running FreeBSD since about 4.6. I have 2 machines running FreeBSD. One is used as a router, its an SMP machine, and the other is used to build the source code. I'm having a problem with the SMP machine. When the machine boots, dmesg shows two messages, that the UP does not show. WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. In v52a I did not get these messages. After doing some research, I understand that this has to do with the kernel locking. It seems that now my networking is not working on the SMP machine. I know others have asked about this, and saw the release notes, about setting debug.mpsafenet=0, but my networking is still not working right. This does not indicate a bug. Rather, the situation is *exactly the same as it was in every previous version of FreeBSD* -- there was just not point in mentioning the condition specifically because it applied to every system. If you remove IPSEC from your kernel (e.g. use FAST_IPSEC instead), you will be able to benefit from improved SMP performance relative to previous versions (actually, you should upgrade to 5.4 which has much better performance than 5.3). Also /dev/kmem and /dev/mem are missing so netstat -ar does not work either. You probably omitted them from your kernel. Kris pgpa0QcRQudz8.pgp Description: PGP signature
Re: SMP and networking under FreeBSD 5.3
On 6/14/05, Joe [EMAIL PROTECTED] wrote: Hello, Not sure if this is the place to ask this. But this is a freebsd question. I've been running FreeBSD since about 4.6. I have 2 machines running FreeBSD. One is used as a router, its an SMP machine, and the other is used to build the source code. I'm having a problem with the SMP machine. When the machine boots, dmesg shows two messages, that the UP does not show. WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. In v52a I did not get these messages. After doing some research, I understand that this has to do with the kernel locking. It seems that now my networking is not working on the SMP machine. I know others have asked about this, and saw the release notes, about setting debug.mpsafenet=0, but my networking is still not working right. Also /dev/kmem and /dev/mem are missing so netstat -ar does not work either. Where do I start to find a solution to this? Does FreeBSD 5.4 exhibit the same behavior? -- Dmitry We live less by imagination than despite it - Rockwell Kent, N by E ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP and networking under FreeBSD 5.3
I haven't tried 5.4 yet. To build a 5.4 could take a couple of days on these old machines. Joe --- Dmitry Mityugov [EMAIL PROTECTED] wrote: On 6/14/05, Joe [EMAIL PROTECTED] wrote: Hello, Not sure if this is the place to ask this. But this is a freebsd question. I've been running FreeBSD since about 4.6. I have 2 machines running FreeBSD. One is used as a router, its an SMP machine, and the other is used to build the source code. I'm having a problem with the SMP machine. When the machine boots, dmesg shows two messages, that the UP does not show. WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. In v52a I did not get these messages. After doing some research, I understand that this has to do with the kernel locking. It seems that now my networking is not working on the SMP machine. I know others have asked about this, and saw the release notes, about setting debug.mpsafenet=0, but my networking is still not working right. Also /dev/kmem and /dev/mem are missing so netstat -ar does not work either. Where do I start to find a solution to this? Does FreeBSD 5.4 exhibit the same behavior? -- Dmitry We live less by imagination than despite it - Rockwell Kent, N by E __ Discover Yahoo! Get on-the-go sports scores, stock quotes, news and more. Check it out! http://discover.yahoo.com/mobile.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP and networking under FreeBSD 5.3
Okay, I've figure it out. natd is not starting via rc.conf, or if it is, it dies. I can start it manually, and it works okay. Also it seems that for some reason some of my ipfw rules don't get set, so I have to rerun ipfw also to make things work. I'll just hack the rc scripts to get this machine up. Joe --- Dmitry Mityugov [EMAIL PROTECTED] wrote: On 6/14/05, Joe [EMAIL PROTECTED] wrote: Hello, Not sure if this is the place to ask this. But this is a freebsd question. I've been running FreeBSD since about 4.6. I have 2 machines running FreeBSD. One is used as a router, its an SMP machine, and the other is used to build the source code. I'm having a problem with the SMP machine. When the machine boots, dmesg shows two messages, that the UP does not show. WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. In v52a I did not get these messages. After doing some research, I understand that this has to do with the kernel locking. It seems that now my networking is not working on the SMP machine. I know others have asked about this, and saw the release notes, about setting debug.mpsafenet=0, but my networking is still not working right. Also /dev/kmem and /dev/mem are missing so netstat -ar does not work either. Where do I start to find a solution to this? Does FreeBSD 5.4 exhibit the same behavior? -- Dmitry We live less by imagination than despite it - Rockwell Kent, N by E __ Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP and networking under FreeBSD 5.3
Joe wrote: Okay, I've figure it out. natd is not starting via rc.conf, or if it is, it dies. I can start it manually, and it works okay. Also it seems that for some reason some of my ipfw rules don't get set, so I have to rerun ipfw also to make things work. I'll just hack the rc scripts to get this machine up. Joe --- Dmitry Mityugov [EMAIL PROTECTED] wrote: rc_debug=YES in rc.conf, then run 'dmesg -a | grep natd' and see if anything pops up. This should tell you everything that's goin on with natd at boot. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP and networking under FreeBSD 5.3
Hey thanks, it seems that ipfw complains during boot with a message: hostname ``or'' unknown which I have no idea where that is coming from yet, but will look. Then natd doesn't get started. If I run /etc/rc.d/ipfw start then the router is up and natd gets started. For now, I'll probably just add it to rc at the end. I think it has something to do with the order things get run. My firewall script is for a dhcp interface. Since I don't know the IP, I use ifconfig dc0 | grep -v inet6 | grep inet | awk ... to get the IP address for some of the rules. I'm wondering if this is failing and causing the message above. Is there a 'recommended' way to create a rule for ipfw on a dhcp interface using its IP address? Joe --- Jarrod Martin [EMAIL PROTECTED] wrote: Joe wrote: Okay, I've figure it out. natd is not starting via rc.conf, or if it is, it dies. I can start it manually, and it works okay. Also it seems that for some reason some of my ipfw rules don't get set, so I have to rerun ipfw also to make things work. I'll just hack the rc scripts to get this machine up. Joe --- Dmitry Mityugov [EMAIL PROTECTED] wrote: rc_debug=YES in rc.conf, then run 'dmesg -a | grep natd' and see if anything pops up. This should tell you everything that's goin on with natd at boot. __ Discover Yahoo! Use Yahoo! to plan a weekend, have fun online and more. Check it out! http://discover.yahoo.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
