Re: Ordering for network-sensitive rc scripts

2014-05-12 Thread Fabian Keil
David Chisnall thera...@freebsd.org wrote:

 On 11 May 2014, at 20:23, Adrian Chadd adr...@freebsd.org wrote:
 
  On 11 May 2014 12:01, David Chisnall thera...@freebsd.org wrote:
  On 17 Apr 2014, at 09:30, Adrian Chadd adr...@freebsd.org wrote:
  
  Can't we add a devd hook to do that?
  
  I tried doing this, but it turns out that wlan devices don't appear to 
  send devd LINK_UP / LINK_DOWN events.  It would be nice to have a clean 
  solution to this.  By default, using the stock rc scripts, my router is 
  currently not able to forward packets from the WiFi until I've logged into 
  it and manually run 'service pf restart', which is a bit crazy.  I've 
  hacked around it by having a script run from rc.local that sleeps for 60 
  seconds and then restarts a few things, but that's really, really ugly.
  
  On closer inspection, pf doesn't fail silently, it complains about a 
  syntax error in my config file because wlan0 is not a known interface.
  
  We therefore have an rc ordering problem if you want to use pf and WiFi at 
  the same time.  This problem was introduced some time between 9.2 and 10.0.
  
  Is there a PR for this? It's the first I've heard of it.
 
 Not yet.  This is the result of my investigations as of 10 minutes ago.  I'll 
 file a PR, if no one can tell me I'm doing something obviously wrong...

I'm not saying that you did something wrong or shouldn't file a PR,
but on my laptop (11-CURRENT) pf works as expected without service
restarts.

The relevant configuration excerpt:

ext_if  = wlan0
int_if  = bge0
jail_if = lo1
[...]
nat pass on $ext_if from  $int_if:network to any - $ext_if
nat on $ext_if from $jail_if:network to any - $ext_if

wlan0 is a wlandev on iwn0.

I'm usually using static IP addresses, but it worked with dynamic
IP addresses (and ext_if and int_if reversed) in the past.

Fabian


signature.asc
Description: PGP signature


Re: Ordering for network-sensitive rc scripts

2014-05-12 Thread Mark Felder

On Apr 17, 2014, at 3:21, David Chisnall thera...@freebsd.org wrote:

 Hi all,
 
 For a little while, I've had an issue with the machine that sits on the edge 
 of my network deciding to start avahi as soon as a network is available, 
 meaning that it then runs mDNS advertisements on the external interface and 
 not the wireless one, requiring a manual restart once the machine boots.  I'm 
 now seeing something similar with pf - it manages to start before the 
 external interface comes up and so silently ignores all of the rules for 
 routing packets off the network.
 
 Do we have a mechanism for stating that certain services should not be 
 started until ALL of the interfaces are up, rather than just the first one?  
 Or even of restarting them when a new network appears?
 

I always thought the proper solution here was pf's built-in keywords egress 
and ingress interface names so you don't have to specify interface names that 
may or may not exist at the time the pf rules load.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Ordering for network-sensitive rc scripts

2014-05-11 Thread David Chisnall
On 17 Apr 2014, at 09:30, Adrian Chadd adr...@freebsd.org wrote:

 Can't we add a devd hook to do that?

I tried doing this, but it turns out that wlan devices don't appear to send 
devd LINK_UP / LINK_DOWN events.  It would be nice to have a clean solution to 
this.  By default, using the stock rc scripts, my router is currently not able 
to forward packets from the WiFi until I've logged into it and manually run 
'service pf restart', which is a bit crazy.  I've hacked around it by having a 
script run from rc.local that sleeps for 60 seconds and then restarts a few 
things, but that's really, really ugly.  

On closer inspection, pf doesn't fail silently, it complains about a syntax 
error in my config file because wlan0 is not a known interface.

We therefore have an rc ordering problem if you want to use pf and WiFi at the 
same time.  This problem was introduced some time between 9.2 and 10.0.

David

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Ordering for network-sensitive rc scripts

2014-05-11 Thread Adrian Chadd
On 11 May 2014 12:01, David Chisnall thera...@freebsd.org wrote:
 On 17 Apr 2014, at 09:30, Adrian Chadd adr...@freebsd.org wrote:

 Can't we add a devd hook to do that?

 I tried doing this, but it turns out that wlan devices don't appear to send 
 devd LINK_UP / LINK_DOWN events.  It would be nice to have a clean solution 
 to this.  By default, using the stock rc scripts, my router is currently not 
 able to forward packets from the WiFi until I've logged into it and manually 
 run 'service pf restart', which is a bit crazy.  I've hacked around it by 
 having a script run from rc.local that sleeps for 60 seconds and then 
 restarts a few things, but that's really, really ugly.

 On closer inspection, pf doesn't fail silently, it complains about a syntax 
 error in my config file because wlan0 is not a known interface.

 We therefore have an rc ordering problem if you want to use pf and WiFi at 
 the same time.  This problem was introduced some time between 9.2 and 10.0.

Is there a PR for this? It's the first I've heard of it.


-a
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Ordering for network-sensitive rc scripts

2014-05-11 Thread David Chisnall
On 11 May 2014, at 20:23, Adrian Chadd adr...@freebsd.org wrote:

 On 11 May 2014 12:01, David Chisnall thera...@freebsd.org wrote:
 On 17 Apr 2014, at 09:30, Adrian Chadd adr...@freebsd.org wrote:
 
 Can't we add a devd hook to do that?
 
 I tried doing this, but it turns out that wlan devices don't appear to send 
 devd LINK_UP / LINK_DOWN events.  It would be nice to have a clean solution 
 to this.  By default, using the stock rc scripts, my router is currently not 
 able to forward packets from the WiFi until I've logged into it and manually 
 run 'service pf restart', which is a bit crazy.  I've hacked around it by 
 having a script run from rc.local that sleeps for 60 seconds and then 
 restarts a few things, but that's really, really ugly.
 
 On closer inspection, pf doesn't fail silently, it complains about a syntax 
 error in my config file because wlan0 is not a known interface.
 
 We therefore have an rc ordering problem if you want to use pf and WiFi at 
 the same time.  This problem was introduced some time between 9.2 and 10.0.
 
 Is there a PR for this? It's the first I've heard of it.

Not yet.  This is the result of my investigations as of 10 minutes ago.  I'll 
file a PR, if no one can tell me I'm doing something obviously wrong...

David

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Ordering for network-sensitive rc scripts

2014-04-19 Thread Warner Losh

On Apr 17, 2014, at 2:21 AM, David Chisnall thera...@freebsd.org wrote:
 For a little while, I've had an issue with the machine that sits on the edge 
 of my network deciding to start avahi as soon as a network is available, 
 meaning that it then runs mDNS advertisements on the external interface and 
 not the wireless one, requiring a manual restart once the machine boots.  I'm 
 now seeing something similar with pf - it manages to start before the 
 external interface comes up and so silently ignores all of the rules for 
 routing packets off the network.
 
 Do we have a mechanism for stating that certain services should not be 
 started until ALL of the interfaces are up, rather than just the first one?  
 Or even of restarting them when a new network appears?

devd network events will allow you to do this on a per-network basis. The 
script that you run can then determine if the relevant criteria are in place 
and then do something...

Warner

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Ordering for network-sensitive rc scripts

2014-04-17 Thread David Chisnall
Hi all,

For a little while, I've had an issue with the machine that sits on the edge of 
my network deciding to start avahi as soon as a network is available, meaning 
that it then runs mDNS advertisements on the external interface and not the 
wireless one, requiring a manual restart once the machine boots.  I'm now 
seeing something similar with pf - it manages to start before the external 
interface comes up and so silently ignores all of the rules for routing packets 
off the network.

Do we have a mechanism for stating that certain services should not be started 
until ALL of the interfaces are up, rather than just the first one?  Or even of 
restarting them when a new network appears?

David

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Ordering for network-sensitive rc scripts

2014-04-17 Thread Adrian Chadd
Can't we add a devd hook to do that?


-a


On 17 April 2014 01:21, David Chisnall thera...@freebsd.org wrote:
 Hi all,

 For a little while, I've had an issue with the machine that sits on the edge 
 of my network deciding to start avahi as soon as a network is available, 
 meaning that it then runs mDNS advertisements on the external interface and 
 not the wireless one, requiring a manual restart once the machine boots.  I'm 
 now seeing something similar with pf - it manages to start before the 
 external interface comes up and so silently ignores all of the rules for 
 routing packets off the network.

 Do we have a mechanism for stating that certain services should not be 
 started until ALL of the interfaces are up, rather than just the first one?  
 Or even of restarting them when a new network appears?

 David

 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org