rc(8) script -- waiting for the network to become usable

[Jeremy Chadwick]

Foremost, sorry for the cross-post, but more eyes in this case means
overall more discussion.  Secondly, please keep me CC'd as I'm not on
either -rc or -net.

I recently proposed addition of a new script to the rc framework which
verifies (using ping) that layer 3 network connectivity is up/functional
before continuing on with daemons which require network access:

http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056400.html

The overall response was positive, with full acknowledgement that this
is indeed a hack -- yet necessary -- and that something more appropriate
could probably be introduced into the base system to provide a much
cleaner solution (launchd was mentioned).

I'd like folks (particularly on -rc) to chime in here, and please see
about adding this to the base system.

Please note there's one typo in the script (a line which needs to be
commented out) in my original post which I've since fixed in the version
that's available via HTTP.

Thank you!

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
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: net/mpd5, ppp, proxy-arp issues

[Stefan Esser]

Am 22.04.2010 20:43, schrieb Marin Atanasov:
> Hello,
> 
> Thanks a lot for the patch, Qing!
> 
> It works fine. However I've noticed one thing, after I start mpd5 and
> connect to my home network:
> 
> kernel: WARNING: attempt to domain_add(netgraph) after domainfinalize()
> 
> Not very sure if this is something to worry about or not?

There was a problem with the initialization order of network "domains",
which caused kernel crashes with ISDN+INET6 some two years ago. The
reason was, that there was an implicit assumption, that all domains
were initialized when the network interfaces are initialized, with
NULL dereferences if domains are added (and relevant to a device)
after the device has been initialized.

I debugged this problem and prepared a patch for discussion, which
later was committed by Max Laier (if memory serves me right). The
message was added in order to identify further situations, where
network domains are added after network interfaces have been
initialized. This message ought to be informational right now, since
the interface init is repeated whenever a network domain is added
as part of above mentioned patch. Init order should be fixed, if
this message is printed for compiled in drivers, but in case of a
kernel module (like netgraph) that adds a domain, it is unadvoidable
that the init order is reversed.

Perhaps the message should be made conditional on the start-up of
the kernel not having finished, or it should be completely removed,
since time has shown, that the init order is correct in general.

I'll remove that message (or make it conditional on "bootverbose")
unless there is opposition to this change ...

Regards, STefan
___
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: rc(8) script -- waiting for the network to become usable

[Guido Falsi]

On Mon, Apr 26, 2010 at 01:08:15AM -0700, Jeremy Chadwick wrote:
> Foremost, sorry for the cross-post, but more eyes in this case means
> overall more discussion.  Secondly, please keep me CC'd as I'm not on
> either -rc or -net.
> 
> I recently proposed addition of a new script to the rc framework which
> verifies (using ping) that layer 3 network connectivity is up/functional
> before continuing on with daemons which require network access:
> 
> http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056400.html
> 
> The overall response was positive, with full acknowledgement that this
> is indeed a hack -- yet necessary -- and that something more appropriate
> could probably be introduced into the base system to provide a much
> cleaner solution (launchd was mentioned).

I did read the original thread, and like the idea. I myself have servers
winth ntpd failing to configure tiself at boot due to this problem and
was thinking of some hack to force the behaviour you suggest.

So I obviously like your idea and would like to see this in the base
system.

Regarding launchd, I don't know much about it, but I do like the rc
system and having the boot sequence managed by scripts one can easily
modify to taste. I'd rather not modify this system with some daemon
performing obscure tasks based on some configuration file. The
flexibility given by scripts is imho, quite superior to any configurable
daemon's.

This is just my opinion, obviously. As stated I don't know much about
launchd, and it is quite possible that I have misconceptions about it,
so please don't flame me if I insulted it!

Thank you for your effort and work to bring this to the masses!

-- 
Guido Falsi 
___
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: rc(8) script -- waiting for the network to become usable

[Jordi Espasa Clofent]

I did read the original thread, and like the idea. I myself have servers
winth ntpd failing to configure tiself at boot due to this problem and
was thinking of some hack to force the behaviour you suggest.




	If you use the OpenNTPd instead of classical ntpd one, you won't suffer 
this odd behaviour:


http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/ntpd/ntp_dns.c



--
I must not fear. Fear is the mind-killer. Fear is the little-death that 
brings total obliteration. I will face my fear. I will permit it to pass 
over me and through me. And when it has gone past I will turn the inner 
eye to see its path. Where the fear has gone there will be nothing. Only 
I will remain.


Bene Gesserit Litany Against Fear.
___
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"

Current problem reports assigned to freebsd-net@FreeBSD.org

[FreeBSD bugmaster]

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker  Resp.  Description

o kern/146037  net[panic] mpd + CoA = kernel panic
o kern/145918  net[ae] After spontaneous ae0 "watchdog timeout", "stray 
o kern/145826  net[ath] Unable to configure adhoc mode on ath0/wlan0
o kern/145825  net[panic] panic: soabort: so_count
o kern/145777  net[wpi] Intel 3945ABG driver breaks the connection after
o kern/145728  net[lagg] Stops working lagg between two servers.
o kern/145621  net[bge] [panic] bge watchdog timeout --resetting -> cras
o kern/145462  net[netgraph] [patch] panic kernel when ng_ipfw send ip p
o kern/144987  net[wpi] [panic] injecting packets with wlaninject using 
o kern/144898  net[wpi] [panic] wpi panics system
o kern/144882  netMacBookPro =>4.1 does not connect to BSD in hostap wit
o kern/144874  net[if_bridge] [patch] if_bridge frees mbuf after pfil ho
o kern/144777  net[arp] proxyarp broken in 8.0 [regression]
o kern/144755  net[iwi] [panic] iwi panic when issuing /etc/rc.d/netif r
o kern/144724  net[bwn] if_bwn does not pass traffic when in PIO mode
o conf/144700  net[rc.d] async dhclient breaks stuff for too many people
o kern/144680  net[em] em(4) problem with dual-port adapter
o kern/144642  net[rum] [panic] Enabling rum interface causes panic
o kern/144616  net[nat] [panic] ip_nat panic FreeBSD 7.2
o kern/144572  net[carp] CARP preemption mode traffic partially goes to 
o kern/144561  net[ixgbe] [patch] ixgbe driver errors
o kern/144529  net[sctp] sctp over ipv6 appears to not calculate checksu
o kern/144505  net[bwn] [patch] Error in macro CALC_COEFF2.
o kern/144494  net[ixgbe] ixgbe driver not built as module
f kern/144315  net[ipfw] [panic] freebsd 8-stable reboot after add ipfw 
o kern/144206  netMarvell Yukon NIC not working under FreeBSD
o kern/144000  net[tcp] setting TCP_MAXSEG by setsockopt() does not seem
o kern/143939  net[ipfw] [em] ipfw nat and em interface rxcsum problem
o kern/143874  net[wpi] Wireless 3945ABG error. wpi0 could not allocate 
o kern/143868  net[ath] [patch] allow Atheros watchdog timeout to be tun
o kern/143846  net[gif] bringing gif3 tunnel down causes gif0 tunnel to 
s kern/143673  net[stf] [request] there should be a way to support multi
s kern/143666  net[ip6] [request] PMTU black hole detection not implemen
o kern/143622  net[pfil] [patch] unlock pfil lock while calling firewall
o kern/143595  net[wpi] [panic] Creating virtual interface over wpi0 in 
o kern/143593  net[ipsec] When using IPSec, tcpdump doesn't show outgoin
o kern/143591  net[ral] RT2561C-based DLink card (DWL-510) fails to work
o kern/143573  net[em] em(4) NIC crashes intermittently
o kern/143285  net[em] [regression] jumbo frames broken in 8.0
o kern/143208  net[ipsec] [gif] IPSec over gif interface not working
o conf/143079  nethostapd(8) startup missing multi wlan functionality
o kern/143074  net[wi]: wi driver triggers panic
o kern/143034  net[panic] system reboots itself in tcp code [regression]
o kern/142907  net[wpi] if_wpi unstable on ibm/lenovo x60 -- suspect fir
o kern/142877  net[hang] network-related repeatable 8.0-STABLE hard hang
o kern/142774  netProblem with outgoing connections on interface with mu
o kern/142772  net[libc] lla_lookup: new lle malloc failed
o kern/142766  net[ipw] [regression] ipw(4) with Intel PRO/wireless 2100
o kern/142518  net[em] [lagg] Problem on 8.0-STABLE with em and lagg
o kern/142019  net[em] em needs "ifconfig em0 down up" when link was gon
o kern/142018  net[iwi] [patch] Possibly wrong interpretation of beacon-
o kern/141861  net[wi] data garbled with WEP and wi(4) with Prism 2.5
o kern/141843  net[em] [vlan] Intel txcsum and assigned vlan invoke wron
o kern/141777  net[rum] [patch] Support usbdevs / rum(4) for Buffalo WLI
f kern/141741  netEtherlink III NIC won't work after upgrade to FBSD 8, 
o kern/141720  net[sctp] [lor] [hang] sctp-create vs. sctp-it causes sys
o kern/141698  net[sctp] [panic] Own lock on stcb at return from input
o kern/141697  net[sctp] [panic] lock (sleep mutex) sctp-tcb not locked
o kern/141696  net[rum] [panic] rum(4)+ vimage = kernel panic
o kern/141695  net[sctp] [panic] kernel page fault with non-sleepable lo
o kern/141314 

multi-homed systems stop answering ARP on local addresses w/ifconfig aliases

[Александр]

On Sun, May 17, 2009 at 4:35 PM, Steven Hartland
http://lists.freebsd.org/mailman/listinfo/freebsd-net>> wrote:

/ Silly question but something else on the network isn't doing a arp spoof

/>/ attack is it?
/>/
/
No, there isn't any ARP at all on that address on the network when
this is a problem, verified with tcpdump. That also shouldn't impact
the system's ability to talk to its own IPs.

thanks for the response though!



/ - Original Message - From: "Chris Buechler"

/>/ http://lists.freebsd.org/mailman/listinfo/freebsd-net>>
/>/ To: http://lists.freebsd.org/mailman/listinfo/freebsd-net>>
/>/ Sent: Sunday, May 17, 2009 9:08 PM
/>/ Subject: multi-homed systems stop answering ARP on local addresses
/>/ w/ifconfig aliases
/>/
/>/
/>>/ There seems to be a regression between 6.x and 7.0 and 7.1 related to
/>>/ ifconfig aliases on multi-homed hosts. Not sure on anything newer than 7.1
/>>/ (this is pfSense, we're just starting to test 7.2 builds). For periods of
/>>/ time, the system will stop answering ARP on some of its own addresses and
/>>/ hence anything on that network completely stops functioning. The same setup
/>>/ worked fine on 6.2.
/>>/
/>>/ The particular system illustrated here is a router on part of an ISP's
/>>/ network. IPs are all public, in the info provided here they've been 
replaced
/>>/ with 10. IPs. The subnets on the inside interfaces are routed to the 
outside
/>>/ interface. When this problem occurs, the IPs assigned locally on the system
/>>/ will still respond from the Internet, but the system itself loses all
/>>/ connectivity with that subnet and nothing on that subnet can communicate
/>>/ with the host due to the lack of ARP. That makes some sense, I presume when
/>>/ routing to a locally assigned address via another interface, the system
/>>/ doesn't need ARP on the address to respond. But while it still responds 
from
/>>/ the Internet, even the host itself can't initiate a ping to that IP. It
/>>/ behaves the same whether pf is enabled or disabled.
/>>/
/>>/ I see two similar issues in the past, one with a PR:
/>>/ http://www.freebsd.org/cgi/query-pr.cgi?pr=121437&cat= 

/>>/ that's exactly the same issue, it's not limited to VLANs, any multi-homed
/>>/ host is affected.
/>>/
/>>/ And another:
/>>/ http://thread.gmane.org/gmane.os.freebsd.stable/57125
/>>/
/>>/ fxp0 is the outside interface. It doesn't make any difference whether the
/>>/ ifconfig aliases are on the em0 or fxp1 interfaces, they both behave the
/>>/ same if they have any ifconfig aliases assigned.
/>>/
/>>/ # ifconfig
/>>/ fxp0: flags=8843 metric 0 mtu 1500
/>>/   options=8
/>>/   ether 00:90:27:86:8b:9d
/>>/   inet6 fe80::290:27ff:fe86:8b9d%fxp0 prefixlen 64 scopeid 0x1
/>>/   inet 10.11.185.146 netmask 0xfff8 broadcast 10.11.185.151
/>>/   media: Ethernet 100baseTX 
/>>/   status: active
/>>/ em0: flags=8843 metric 0 mtu 1500
/>>/   options=9b
/>>/   ether 00:11:43:2c:62:03
/>>/   inet 10.10.0.1 netmask 0xff00 broadcast 10.10.0.255
/>>/   inet6 fe80::211:43ff:fe2c:6203%em0 prefixlen 64 scopeid 0x2
/>>/   inet 10.13.40.1 netmask 0xff00 broadcast 10.13.40.255
/>>/   inet 10.13.41.1 netmask 0xff00 broadcast 10.13.41.255
/>>/   inet 10.13.42.1 netmask 0xff00 broadcast 10.13.42.255
/>>/   inet 10.13.43.1 netmask 0xff00 broadcast 10.13.43.255
/>>/   inet 10.13.44.1 netmask 0xff00 broadcast 10.13.44.255
/>>/   inet 10.13.45.1 netmask 0xff00 broadcast 10.13.45.255
/>>/   inet 10.13.46.1 netmask 0xff00 broadcast 10.13.46.255
/>>/   inet 10.13.47.1 netmask 0xff00 broadcast 10.13.47.255
/>>/   media: Ethernet autoselect (100baseTX )
/>>/   status: active
/>>/ fxp1: flags=8843 metric 0 mtu 1500
/>>/   options=8
/>>/   ether 00:d0:b7:5d:25:9f
/>>/   inet 10.1.242.1 netmask 0xff00 broadcast 10.1.242.255
/>>/   inet6 fe80::2d0:b7ff:fe5d:259f%fxp1 prefixlen 64 scopeid 0x3
/>>/   inet 10.1.243.1 netmask 0xff00 broadcast 10.1.243.255
/>>/   media: Ethernet autoselect (100baseTX )
/>>/   status: active
/>>/
/>>/
/>>/
/>>/ When the problem is occurring, you can't even ping the affected locally
/>>/ assigned addresses from the box itself:
/>>/ # ping 10.10.0.1
/>>/ PING 10.10.0.1 (10.10.0.1): 56 data bytes
/>>/ ping: sendto: Network is unreachable
/>>/ ping: sendto: Network is unreachable
/>>/ ping: sendto: Network is unreachable
/>>/
/>>/ And when trying to ping something on one of the affected attached subnets,
/>>/ you get:
/>>/ # ping 10.10.0.30
/>>/ PING 10.10.0.30 (10.10.0.30): 56 data bytes
/>>/ ping: sendto: Invalid argument
/>>/ ping: sendto: Invalid argument
/>>/
/>>/
/>>/ In the logs, you get a flood of these messages:
/>>/ May 14 02:55:12kernel: arpresolve: can't allocate route for 10.10.0.1
/>>/ May 14 02:55:12kernel: arplookup 10.10.0.1 failed: host is not on
/>>/ local network
/>>/ May 

Re: rc(8) script -- waiting for the network to become usable

[Julian Elischer]

On 4/26/10 1:08 AM, Jeremy Chadwick wrote:

Foremost, sorry for the cross-post, but more eyes in this case means
overall more discussion.  Secondly, please keep me CC'd as I'm not on
either -rc or -net.

I recently proposed addition of a new script to the rc framework which
verifies (using ping) that layer 3 network connectivity is up/functional
before continuing on with daemons which require network access:


a down side is that you can't boot if some OTHER machine is not up.



http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056400.html

The overall response was positive, with full acknowledgement that this
is indeed a hack -- yet necessary -- and that something more appropriate
could probably be introduced into the base system to provide a much
cleaner solution (launchd was mentioned).


there does need to be some dependency tracking to do with networks.
maybe there acn be a selection of ways to pass that milestone..

(carrier detect, ping, incoming packets non-0) etc.
my favourite is:

INPUT_PACKETS=`netstat -i | awk "/${IP}/"'{print $5}'`
if [ -n "${INPUT_PACKETS}" -a "${INPUT_PACKETS}" != "0" ]
them
echo  "It's UP!"
fi




I'd like folks (particularly on -rc) to chime in here, and please see
about adding this to the base system.

Please note there's one typo in the script (a line which needs to be
commented out) in my original post which I've since fixed in the version
that's available via HTTP.

Thank you!



___
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: net/mpd5, ppp, proxy-arp issues

[Julian Elischer]

On 4/26/10 1:11 AM, Stefan Esser wrote:

Am 22.04.2010 20:43, schrieb Marin Atanasov:

Hello,

Thanks a lot for the patch, Qing!

It works fine. However I've noticed one thing, after I start mpd5 and
connect to my home network:

kernel: WARNING: attempt to domain_add(netgraph) after domainfinalize()

Not very sure if this is something to worry about or not?


There was a problem with the initialization order of network "domains",
which caused kernel crashes with ISDN+INET6 some two years ago. The
reason was, that there was an implicit assumption, that all domains
were initialized when the network interfaces are initialized, with
NULL dereferences if domains are added (and relevant to a device)
after the device has been initialized.

I debugged this problem and prepared a patch for discussion, which
later was committed by Max Laier (if memory serves me right). The
message was added in order to identify further situations, where
network domains are added after network interfaces have been
initialized. This message ought to be informational right now, since
the interface init is repeated whenever a network domain is added
as part of above mentioned patch. Init order should be fixed, if
this message is printed for compiled in drivers, but in case of a
kernel module (like netgraph) that adds a domain, it is unadvoidable
that the init order is reversed.

Perhaps the message should be made conditional on the start-up of
the kernel not having finished, or it should be completely removed,
since time has shown, that the init order is correct in general.

I'll remove that message (or make it conditional on "bootverbose")
unless there is opposition to this change ...

please do..

it's an unavoidable thing that domains added after boot
are done after boot completes   :-)


Regards, STefan
___
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"


___
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: rc(8) script -- waiting for the network to become usable

[Jeremy Chadwick]

On Mon, Apr 26, 2010 at 09:00:07AM -0700, Julian Elischer wrote:
> On 4/26/10 1:08 AM, Jeremy Chadwick wrote:
> >Foremost, sorry for the cross-post, but more eyes in this case means
> >overall more discussion.  Secondly, please keep me CC'd as I'm not on
> >either -rc or -net.
> >
> >I recently proposed addition of a new script to the rc framework which
> >verifies (using ping) that layer 3 network connectivity is up/functional
> >before continuing on with daemons which require network access:
> 
> a down side is that you can't boot if some OTHER machine is not up.

The boot-up process will still continue regardless if the ping check
passed or failed.  It just means that daemons/services attempting to use
the network and *expect* connectivity to work may not function
correctly (meaning: they'll behave just like they already do.  ;-) )

I indirectly tried to cover the "if some other machine is not up" point
in my initial post on -stable:

  "1) This script requires the $waitnetwork_ip box/router/whatever respond
  to ICMP ECHO requests.  Please do not bikeshed on this point; we need
  something that works, and this requirement shouldn't be that bad to deal
  with (firewall/ACL-wise).  For most folks (co-located in particular),
  this could be your default gateway, but you can use whatever you want."

It would be possible to extend the script to loop through multiple IPs
specified in $waitnetwork_ip (space-delimited); the first one to cause
ping to exit with code 0 (ICMP ECHO reply seen) would therefore deem the
network usable and continue on.

> >http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056400.html
> >
> >The overall response was positive, with full acknowledgement that this
> >is indeed a hack -- yet necessary -- and that something more appropriate
> >could probably be introduced into the base system to provide a much
> >cleaner solution (launchd was mentioned).
> 
> there does need to be some dependency tracking to do with networks.
> maybe there acn be a selection of ways to pass that milestone..
> 
> (carrier detect, ping, incoming packets non-0) etc.
> my favourite is:
> 
> INPUT_PACKETS=`netstat -i | awk "/${IP}/"'{print $5}'`
> if [ -n "${INPUT_PACKETS}" -a "${INPUT_PACKETS}" != "0" ]
> them
> echo  "It's UP!"
> fi

This isn't the same thing as doing a ping check though.  As I understand
it, netstat -i shows you how many Ethernet packets have been seen --
that includes ARP.  The intended goal of the script is to verify that a
usable network connection exists -- usable in this case means "whatever
host you device in $waitnetwork_ip responds to ICMP".  If this is an
Internet host (e.g. 4.2.2.1), then said IP responding to ICMP would
indicate Internet connectivity is available.

I think most users would fall into the latter class, not the "I want to
verify my LAN connectivity is up and working, except the other box on my
LAN is powered off..." class.

Basically what I'm saying is that I fully acknowledge there's no
absolute 100% failsafe method that's going to work for every single
user's environment.  My script's goal isn't to address every single
problem/scenario -- just the most common one, and one I (we?) server
administrators deal with regularly.

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
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: m_copymdata() bug?

[Brandon Gooch]

On Tue, Apr 13, 2010 at 8:30 AM, Jacques Fourie
 wrote:
> It seems as if the m_copymdata() function defined in uipc_mbuf.c has a
> bug. It uses m_apply to copy data from the source mbuf to the target
> but in the callback function m_bcopyxxx() the arguments are
> interpreted in the wrong order. Swapping the 's' and 't' arguments in
> the declaration of m_bcopyxxx() fixes the problem for me.

Perhaps you should file a PR with an included patch:

http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/article.html

http://www.freebsd.org/send-pr.html

Thanks!

-Brandon
___
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: multi-homed systems stop answering ARP on local addresses w/ifconfig aliases

[Chris Buechler]

2010/4/26 Александр :
> On Sun, May 17, 2009 at 4:35 PM, Steven Hartland
>  > wrote:
>>
>> / Silly question but something else on the network isn't doing a arp spoof
>
> />/ attack is it?
> />/
> /
> No, there isn't any ARP at all on that address on the network when
> this is a problem, verified with tcpdump. That also shouldn't impact
> the system's ability to talk to its own IPs.
>
> thanks for the response though!
>
>
>> / - Original Message - From: "Chris Buechler"
>
> />/  >
> />/ To:  >
> />/ Sent: Sunday, May 17, 2009 9:08 PM
> />/ Subject: multi-homed systems stop answering ARP on local addresses
> />/ w/ifconfig aliases
> />/
> />/
> />>/ There seems to be a regression between 6.x and 7.0 and 7.1 related to
> />>/ ifconfig aliases on multi-homed hosts. Not sure on anything newer than
> 7.1
> />>/ (this is pfSense, we're just starting to test 7.2 builds). For periods
> of
> />>/ time, the system will stop answering ARP on some of its own addresses
> and
> />>/ hence anything on that network completely stops functioning. The same
> setup
> />>/ worked fine on 6.2.
> />>/
> />>/ The particular system illustrated here is a router on part of an ISP's
> />>/ network. IPs are all public, in the info provided here they've been
> replaced
> />>/ with 10. IPs. The subnets on the inside interfaces are routed to the
> outside
> />>/ interface. When this problem occurs, the IPs assigned locally on the
> system
> />>/ will still respond from the Internet, but the system itself loses all
> />>/ connectivity with that subnet and nothing on that subnet can
> communicate
> />>/ with the host due to the lack of ARP. That makes some sense, I presume
> when
> />>/ routing to a locally assigned address via another interface, the system
> />>/ doesn't need ARP on the address to respond. But while it still responds
> from
> />>/ the Internet, even the host itself can't initiate a ping to that IP. It
> />>/ behaves the same whether pf is enabled or disabled.
> />>/
> />>/ I see two similar issues in the past, one with a PR:
> />>/ http://www.freebsd.org/cgi/query-pr.cgi?pr=121437&cat=
> 
> />>/ that's exactly the same issue, it's not limited to VLANs, any
> multi-homed
> />>/ host is affected.
> />>/
> />>/ And another:
> />>/ http://thread.gmane.org/gmane.os.freebsd.stable/57125
> />>/
> />>/ fxp0 is the outside interface. It doesn't make any difference whether
> the
> />>/ ifconfig aliases are on the em0 or fxp1 interfaces, they both behave
> the
> />>/ same if they have any ifconfig aliases assigned.
> />>/
> />>/ # ifconfig
> />>/ fxp0: flags=8843 metric 0 mtu
> 1500
> />>/       options=8
> />>/       ether 00:90:27:86:8b:9d
> />>/       inet6 fe80::290:27ff:fe86:8b9d%fxp0 prefixlen 64 scopeid 0x1
> />>/       inet 10.11.185.146 netmask 0xfff8 broadcast 10.11.185.151
> />>/       media: Ethernet 100baseTX 
> />>/       status: active
> />>/ em0: flags=8843 metric 0 mtu
> 1500
> />>/       options=9b
> />>/       ether 00:11:43:2c:62:03
> />>/       inet 10.10.0.1 netmask 0xff00 broadcast 10.10.0.255
> />>/       inet6 fe80::211:43ff:fe2c:6203%em0 prefixlen 64 scopeid 0x2
> />>/       inet 10.13.40.1 netmask 0xff00 broadcast 10.13.40.255
> />>/       inet 10.13.41.1 netmask 0xff00 broadcast 10.13.41.255
> />>/       inet 10.13.42.1 netmask 0xff00 broadcast 10.13.42.255
> />>/       inet 10.13.43.1 netmask 0xff00 broadcast 10.13.43.255
> />>/       inet 10.13.44.1 netmask 0xff00 broadcast 10.13.44.255
> />>/       inet 10.13.45.1 netmask 0xff00 broadcast 10.13.45.255
> />>/       inet 10.13.46.1 netmask 0xff00 broadcast 10.13.46.255
> />>/       inet 10.13.47.1 netmask 0xff00 broadcast 10.13.47.255
> />>/       media: Ethernet autoselect (100baseTX )
> />>/       status: active
> />>/ fxp1: flags=8843 metric 0 mtu
> 1500
> />>/       options=8
> />>/       ether 00:d0:b7:5d:25:9f
> />>/       inet 10.1.242.1 netmask 0xff00 broadcast 10.1.242.255
> />>/       inet6 fe80::2d0:b7ff:fe5d:259f%fxp1 prefixlen 64 scopeid 0x3
> />>/       inet 10.1.243.1 netmask 0xff00 broadcast 10.1.243.255
> />>/       media: Ethernet autoselect (100baseTX )
> />>/       status: active
> />>/
> />>/
> />>/
> />>/ When the problem is occurring, you can't even ping the affected locally
> />>/ assigned addresses from the box itself:
> />>/ # ping 10.10.0.1
> />>/ PING 10.10.0.1 (10.10.0.1): 56 data bytes
> />>/ ping: sendto: Network is unreachable
> />>/ ping: sendto: Network is unreachable
> />>/ ping: sendto: Network is unreachable
> />>/
> />>/ And when trying to ping something on one of the affected attached
> subnets,
> />>/ you get:
> />>/ # ping 10.10.0.30
> />>/ PING 10.10.0.30 (10.10.0.30): 56 data bytes
> />>/ ping: sendto: Invalid argument
> />>/ ping: sendto: I

ifa_free panic in 8 stable

[Erik Klavon]

Hi

I have a dual processor, single core amd64 machine running a recent
cvsup of 8 stable. On this development machine I use netgraph(3) to
implement one to one NAT with one ng_nat(4) node. I use ipfw(8) rules
to direct traffic to netgraph nodes as needed based on table entries
using an ng_ipfw(4) node. When I load test ng_nat on the development
system using iperf(1) running on the independent system, the
development system panics after a couple of days as follows.

panic: negative refcount 0xff0002a344d4
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
panic() at panic+0x182
ifa_free() at ifa_free+0x5d
ip_output() at ip_output+0x49d
ip_forward() at ip_forward+0x199
ip_input() at ip_input+0x4cd
ng_ipfw_rcvdata() at ng_ipfw_rcvdata+0xadVOP_STRATEGY: bp is not
locked but should be

KDB: enter: lock violation
n[thread pid 17 tid 100042 ]
Stopped at  kdb_enter+0x3d: movq$0,0x6bb730(%rip)

This panic is repeatable on this machine. I am unable to obtain a core
dump after these panics; after I attempt to dump core using panic the
system does not respond and must be power cycled. I first encountered
this problem with 8.0p1. I've reproduced this problem with both em and
bge interfaces.

I've looked around in the functions mentioned in the backtrace, but
haven't made any progress in identifying why this panic
occurs. Please share any suggestions you think of for tracking down
the source of this problem.

My kernel is configured with options DEBUG=-g, KDB, DDB, KDB_TRACE,
BREAK_TO_DEBUGGER, INVARIANTS, INVARIANT_SUPPORT, WITNESS,
DEBUG_LOCKS, DEBUG_VFS_LOCKS, DIAGNOSTIC, SW_WATCHDOG, DEADLKRES,
IPFIREWALL, IPFIREWALL_VERBOSE, IPFIREWALL_VERBOSE_LIMIT=100,
IPFIREWALL_FORWARD, and IPDIVERT.

I use the following ipfw(8) rules to direct traffic from the
independent system to netgraph and vice versa. (x and y below replace
the first two octets of the globally routable addresses I'm using in
this test.)

# direct traffic from the independent system into ng_nat
01100 netgraph tablearg ip from table(87) to any in
# direct traffic from the internet into ng_nat
01110 netgraph tablearg ip from any to table(88) in via vlan615
# forward NATed traffic to the subnet's router if it isn't local
01120 fwd x.y.254.1 ip4 from x.y.254.0/25 to not x.y.254.0/25 in via vlan613
# pass traffic after it is NATed, so the default deny rule doesn't block it
01130 allow ip from any to table(87)
01140 allow ip from table(88) to any

ipfw(8) table 87 contains the entry 10.10.0.10/32 200254017 and table
88 contains the entry x.y.254.17/32 100254017

The above two table entries direct traffic to the following ng_nat(4)
node.

  Name: NAT0254017 Type: nat ID: 000b   Num hooks: 2
  Local hook  Peer name   Peer typePeer ID Peer hook  
  --  -   ---- -  
  in  ipfwipfw 0001100254017  
  out ipfwipfw 0001200254017  

This ng_nag(4) node was created using the following commands.

ngctl mkpeer ipfw: nat 100254017 out
ngctl name ipfw:100254017 NAT0254017
ngctl connect ipfw: NAT0254017: 200254017 in
ngctl msg NAT0254017: setaliasaddr x.y.254.17
ngctl msg NAT0254017: redirectaddr { "local_addr=10.10.0.10" 
"alias_addr=x.y.254.17" 'description="Static NAT" }

I've assigned the independent system the address 10.10.0.10 on
vlan613 with a default router of 10.10.0.1. The development system's
address on vlan613 is 10.10.0.1. Based on the above setup, traffic
from the independent system is NATed by the development syste to IP
address x.y.254.17. I use iperf -d -U -P 20 for the load testing with
another system outside of the test setup acting as an iperf server.

Erik
___
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: kern/144315: [ipfw] [panic] freebsd 8-stable reboot after add ipfw rules with netgraph ng_car

[shelma shelmec]

The following reply was made to PR kern/144315; it has been noted by GNATS.

From: shelma shelmec 
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: kern/144315: [ipfw] [panic] freebsd 8-stable reboot after add 
ipfw rules with netgraph ng_car
Date: Tue, 27 Apr 2010 11:29:42 +0600

 --00151747927a44169a0485312e62
 Content-Type: text/plain; charset=ISO-8859-1
 
 In last FreeBSD 8-stable system going to cycle panic reboot.
 I`m going back to FreeBSD 7-stable and panic repeat after add ipfw rules.
 
 shape# uname -a
 FreeBSD shape.hostelnet.ru 7.3-STABLE FreeBSD 7.3-STABLE #11: Mon Apr 26
 19:18:38 YEKST 2010 she...@shape.hostelnet.ru:/usr/obj/usr/src/sys/SHAPE
 i386
 
 (kgdb) bt
 #0 doadump () at pcpu.h:196
 #1 0x80849207 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
 Variable "fmt" is not available.
 #2 0x808494d9 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:574
 #3 0x80bc6e0c in trap_fatal (frame=0x852cdacc, eva=12)
 at /usr/src/sys/i386/i386/trap.c:950
 #4 0x80bc7090 in trap_pfault (frame=0x852cdacc, usermode=0, eva=12)
 at /usr/src/sys/i386/i386/trap.c:863
 #5 0x80bc7a85 in trap (frame=0x852cdacc) at
 /usr/src/sys/i386/i386/trap.c:541
 #6 0x80baa87b in calltrap () at /usr/src/sys/i386/i386/exception.s:166
 #7 0x8089f476 in m_copym (m=0x0, off0=1500, len=1480, wait=1)
 at /usr/src/sys/kern/uipc_mbuf.c:539
 #8 0x8099cf55 in ip_fragment (ip=0x85e40010, m_frag=0x852cdc00, mtu=1500,
 if_hwassist_flags=6, sw_csum=3841) at /usr/src/sys/netinet/ip_output.c:731
 #9 0x8099dc66 in ip_output (m=0x85e3d900, opt=0x0, ro=0x852cdbd4, flags=1,
 imo=0x0, inp=0x0) at /usr/src/sys/netinet/ip_output.c:570
 #10 0x80960141 in ng_ipfw_rcvdata (hook=0x8629f500, item=0x861dd080)
 at /usr/src/sys/netgraph/ng_ipfw.c:247
 #11 0x8094dd51 in ng_apply_item (node=0x8569b400, item=0x861dd080, rw=0)
 at /usr/src/sys/netgraph/ng_base.c:2336
 #12 0x80950067 in ngthread (arg=0x0) at /usr/src/sys/netgraph/ng_base.c:3304
 #13 0x808221f9 in fork_exit (callout=0x8094fe00 , arg=0x0,
 frame=0x852cdd38) at /usr/src/sys/kern/kern_fork.c:811
 #14 0x80baa8f0 in fork_trampoline () at
 /usr/src/sys/i386/i386/exception.s:271
 (kgdb) bt full
 #0 doadump () at pcpu.h:196
 No locals.
 #1 0x80849207 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
 _giantcnt = Variable "_giantcnt" is not available.
 
 --00151747927a44169a0485312e62
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 In last FreeBSD 8-stable system going to cycle panic reboot.I`m going back to FreeBSD 7-stable and panic repeat after add ipfw rules.<=
 br>shape# uname -aFreeBSD http://s=
 hape.hostelnet.ru">shape.hostelnet.ru 7.3-STABLE FreeBSD 7.3-STABLE #11=
 : Mon Apr 26 19:18:38 YEKST 2010 she...@shape.hostelnet.ru:/usr/obj/usr=
 /src/sys/SHAPE  i386
 (kgdb) bt#0  doadump () at pcpu.h:196#1  =
 0x80849207 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:418Variable "fmt" is not available.#2  0x808494d9 in panic (fm=
 t=3D) at /usr/src/sys/kern/kern_shutdown.c:574
 #3  0x80bc6e0c in trap_fatal (frame=3D0x852cdacc, eva=3D12)at /usr/=
 src/sys/i386/i386/trap.c:950#4  0x80bc7090 in trap_pfault (frame=3D0x85=
 2cdacc, usermode=3D0, eva=3D12)at /usr/src/sys/i386/i386/trap.c:863=
 #5  0x80bc7a85 in trap (frame=3D0x852cdacc) at /usr/src/sys/i386/i386/t=
 rap.c:541
 #6  0x80baa87b in calltrap () at /usr/src/sys/i386/i386/exception.s:166=
 #7  0x8089f476 in m_copym (m=3D0x0, off0=3D1500, len=3D1480, wait=3D1) =
at /usr/src/sys/kern/uipc_mbuf.c:539#8  0x8099cf55 in ip_fragment (i=
 p=3D0x85e40010, m_frag=3D0x852cdc00, mtu=3D1500,
 if_hwassist_flags=3D6, sw_csum=3D3841) at /usr/src/sys/netinet/ip_outpu=
 t.c:731#9  0x8099dc66 in ip_output (m=3D0x85e3d900, opt=3D0x0, ro=3D0x8=
 52cdbd4, flags=3D1,imo=3D0x0, inp=3D0x0) at /usr/src/sys/netinet/ip=
 _output.c:570
 #10 0x80960141 in ng_ipfw_rcvdata (hook=3D0x8629f500, item=3D0x861dd080)at /usr/src/sys/netgraph/ng_ipfw.c:247#11 0x8094dd51 in ng_apply_i=
 tem (node=3D0x8569b400, item=3D0x861dd080, rw=3D0)at /usr/src/sys/n=
 etgraph/ng_base.c:2336
 #12 0x80950067 in ngthread (arg=3D0x0) at /usr/src/sys/netgraph/ng_base.c:3=
 304#13 0x808221f9 in fork_exit (callout=3D0x8094fe00 , =
 arg=3D0x0,frame=3D0x852cdd38) at /usr/src/sys/kern/kern_fork.c:811<=
 br>#14 0x80baa8f0 in fork_trampoline () at /usr/src/sys/i386/i386/exception=
 .s:271
 (kgdb) bt full#0  doadump () at pcpu.h:196No locals.#1  0x80849=
 207 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:418 =
_giantcnt =3D Variable "_giantcnt" is not available.
 
 --00151747927a44169a0485312e62--
___
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"