ipfw and timeout - BSD

This is a discussion on ipfw and timeout - BSD ; Hi Recently acquired an iPhone and it's showing terrible battery life when used in combination with an Exchange server for push-mail. People have reported that it could be due to how the iPhone handle the heartbeat signal back to the ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: ipfw and timeout

  1. ipfw and timeout

    Hi

    Recently acquired an iPhone and it's showing terrible battery life when
    used in combination with an Exchange server for push-mail.

    People have reported that it could be due to how the iPhone handle the
    heartbeat signal back to the server and that following recommendations
    as described by Microsoft there:
    http://support.microsoft.com/?kbid=905013
    could help

    Microsoft recommends a minimum timeout session for the htttps
    communication with the exchange server to be 15 minutes.

    I use a FreeBSD 6.3 server, acting as a firewall using IPFW. I only use
    static rules.

    I was wondering if when using static rules there was actually a timeout
    settings and what would be the default value used by ipfw rules.
    If there is such timeout, what would be the way to change it, and if
    possible only for the rule concerned.

    All the various references I found talk about timeout for dynamic
    rules, but nothing regarding static ones.

    I wanted to eliminate all potential explanations as to why the iphone
    behaved so poorly when used with exchange.

    Thanks in advance.
    Jean-Yves

    --
    They who would give up an essential liberty for temporary security,
    deserve neither liberty or security (Benjamin Franklin)


  2. Re: ipfw and timeout

    Begin <488099bd$0$17350$426a74cc@news.free.fr>
    On Fri, 18 Jul 2008 23:25:15 +1000, JYA wrote:
    > I was wondering if when using static rules there was actually a timeout
    > settings and what would be the default value used by ipfw rules.


    The timeout value of static rules is ``until removal'', which is an
    external action not performed by ipfw (in contract to dynamic rules).

    Note that ipfw(8) does explicitly mention that dynamic rules have a limited
    lifetime, which is a big hint even when it doesn't explicitly mention it,
    that static rules do not have a lifetime limited in that way.


    > I wanted to eliminate all potential explanations as to why the iphone
    > behaved so poorly when used with exchange.


    Turn off your packet filter while debugging. Personally I'd remove
    exchange from the equation and find something that can be configured in
    a sensible manner. If only to remove the risk of it rotting your brain.


    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

  3. Re: ipfw and timeout

    JYA wrote:

    > Hi
    >
    > Recently acquired an iPhone and it's showing terrible battery life when
    > used in combination with an Exchange server for push-mail.
    >
    > People have reported that it could be due to how the iPhone handle the
    > heartbeat signal back to the server and that following recommendations
    > as described by Microsoft there:
    > http://support.microsoft.com/?kbid=905013
    > could help
    >
    > Microsoft recommends a minimum timeout session for the htttps
    > communication with the exchange server to be 15 minutes.


    This is an http session timeout. It is different than a TCP connection
    timeout.

    > I use a FreeBSD 6.3 server, acting as a firewall using IPFW. I only use
    > static rules.


    The above referenced URI also refers to ISA server, or some other firewall
    that works on higher layers in the OSI stack, ie up to Layer 7. The ipfw
    firewall is a packet filter and only examines traffic to layer 4. Hence,
    there is no such thing as an 'http session timeout' that can be configured.
    You'll have to operate at the TCP connection layer that carries the http
    traffic if using ipfw.

    > I was wondering if when using static rules there was actually a timeout
    > settings and what would be the default value used by ipfw rules.
    > If there is such timeout, what would be the way to change it, and if
    > possible only for the rule concerned.
    >
    > All the various references I found talk about timeout for dynamic
    > rules, but nothing regarding static ones.


    If you are using NAT, you can set the timeout values for how long a 'keep
    state' session is kept around. I think this is the first step I'd look at.
    Although it is questionable to set all of NAT traffic to some arbitrary
    high value, but that devil's in the fine grain details you'll need to dig
    out after getting the basics figured out.

    > I wanted to eliminate all potential explanations as to why the iphone
    > behaved so poorly when used with exchange.
    >


    As far as the actual filter rule(s) itself, if you are initiating the
    session from behind your firewall and state is being kept for return
    traffic, this is not what the 'push' technology on the Exchange end is
    expecting. What the 'push' from Exchange is going to want is an open
    port(s) which allows it to initiate connections. This may be what's at the
    center of the slowness you're seeing. You initiate, some traffic starts,
    the heartbeat fails, then it's a while before your client notices and
    initiates again. The Exchange being a 'push' is going to want to be able to
    initiate a new connection if/whenever it feels like.

    I use pf these days and haven't used ipfw in many years now. Think: "ALTQ".
    But make note of the fact that ipfw does not examine traffic at Layer 7 and
    the directionality associated with the problem. If you have a 'pull'
    configuration setup in a 'push' environment it might actually work
    somewhat, but be very slow.

    Hope this helps some. I could very well be wrong in my analysis. I am trying
    to point out 2 things - The difference between 'http session' vs firewall
    timeout, and the 'directionality of push vs pull. The onus is still with
    you dig into the down and dirty details.

    -Jason



  4. Re: ipfw and timeout

    On Sat, 19 Jul 2008 00:08:38 GMT,
    Jason Bourne wrote:
    >> I use a FreeBSD 6.3 server, acting as a firewall using IPFW. I only use

    ^^^^^^^^^^
    >> static rules.

    ^^^^^^^^^^^^

    If this is true...


    > If you are using NAT, you can set the timeout values for how long a 'keep
    > state' session is kept around. I think this is the first step I'd look at.


    .... then this shouldn't be the case, and ...


    > As far as the actual filter rule(s) itself, if you are initiating the
    > session from behind your firewall and state is being kept for return
    > traffic,


    .... this the OP explicitly claimed was not the case.


    > The difference between 'http session' vs firewall timeout, and the
    > 'directionality of push vs pull. The onus is still with you dig into
    > the down and dirty details.


    You're right there, though.


    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

  5. Re: ipfw and timeout

    jpd wrote:

    [snip]

    I'm not the best linguist when it comes to expressing things correctly. I'm
    no tech doc writer for sure. I do understand your points and consider them
    perfectly valid.

    However, and I am somewhat loath to admit to this in this list, I am the
    ISA/IIS/Exchange admin at work with FreeBSD in use at home. So I have the
    luxury of being on both ends of the connection.

    I also know that if there is an ISA server somewhere in the middle and it is
    not configured correctly then no matter what the user does on the 'at home'
    endpoint he will never be able to fix the misconfiguration. Most likely the
    OP has no control over this, so I concentrate on the endpoint. This is
    easily excluded from the scenario if others in his organization do not
    experience the same slowdown as the OP.

    I am definitely not the sharpest knife in the drawer, but all my stuff
    works. Including Activesync. Just trying to point the OP into the knowledge
    he'll need to aquire/understand as he attacks the problem. As I said, it is
    also very possible that my analysis is flawed as well.

    Just trying to help with my $.02, YMMV, and all other disclaimers...

    -Jason



  6. Re: ipfw and timeout

    On 2008-07-18 23:56:57 +1000, jpd said:
    >
    > Turn off your packet filter while debugging. Personally I'd remove
    > exchange from the equation and find something that can be configured in
    > a sensible manner. If only to remove the risk of it rotting your brain.


    Problem is find me a push email/calendar/addressbook alternative that
    you can host at your site and won't cost you an arm.
    How forgot to add that it has to work with windows mobile pda, nokia
    phones and the like ...

    Not everything Microsoft does is bad ...
    --
    They who would give up an essential liberty for temporary security,
    deserve neither liberty or security (Benjamin Franklin)


  7. Re: ipfw and timeout

    Hi

    On 2008-07-19 10:08:38 +1000, Jason Bourne
    said:
    > The above referenced URI also refers to ISA server, or some other firewall
    > that works on higher layers in the OSI stack, ie up to Layer 7. The ipfw
    > firewall is a packet filter and only examines traffic to layer 4. Hence,
    > there is no such thing as an 'http session timeout' that can be configured.
    > You'll have to operate at the TCP connection layer that carries the http
    > traffic if using ipfw.


    I forgot to add that there is NAT happening as well, however it works
    as static NAT using natd
    In natd I have:
    redirect_address 192.168.0.12 123.1.2.3
    where 123.1.2.3 is the public address
    and 192.168.0.12 is the internal IP address of the Windows Server
    machine running exchange.

    My firewall rules are:
    #Exchange Server
    $cmd allow tcp from any to 192.168.0.12 http,3389,https,5900,993,135 in
    recv $pif setup
    $cmd allow udp from any to 192.168.0.12 2883 in recv $pif
    $cmd $skip udp from 192.168.0.12 2883 to any out xmit $pif
    $cmd $skip udp from 192.168.0.12 to any 2883 out xmit $pif

    $pif being the public interface
    $skip is the rule performing nat out (forward the traffic out to natd).

    The way I configured my firewall rules are:
    NAT in
    rules ....
    NAT out

    > As far as the actual filter rule(s) itself, if you are initiating the
    > session from behind your firewall and state is being kept for return
    > traffic, this is not what the 'push' technology on the Exchange end is
    > expecting. What the 'push' from Exchange is going to want is an open
    > port(s) which allows it to initiate connections. This may be what's at the
    > center of the slowness you're seeing. You initiate, some traffic starts,
    > the heartbeat fails, then it's a while before your client notices and
    > initiates again. The Exchange being a 'push' is going to want to be able to
    > initiate a new connection if/whenever it feels like.


    Oh, note that exchange and push works perfectly fine with various
    devices: several nokia phones, a few Windows Mobile devices etc...

    It also works fine with the iPhone, however when used with the iPhone I
    never managed to get more than 12 hours of battery. Whick kind of sucks!

    I read in various forums about people talking about increaing timeout value.
    I was pretty sure that it didn't apply in my case due to the firewall I
    used and how it was configured.

    But it never hurts to investigate anyway


    >
    > I use pf these days and haven't used ipfw in many years now. Think: "ALTQ".
    > But make note of the fact that ipfw does not examine traffic at Layer 7 and
    > the directionality associated with the problem. If you have a 'pull'
    > configuration setup in a 'push' environment it might actually work
    > somewhat, but be very slow.


    I can't say it is very slow ...
    Speed has never been my concern at all.
    I fail to see why my current configuration would make the push slower
    in any case.
    The relevant ports used by exchange are directly available on the
    public IP address that I've allocated for that machine.


    >
    > Hope this helps some. I could very well be wrong in my analysis. I am trying
    > to point out 2 things - The difference between 'http session' vs firewall
    > timeout, and the 'directionality of push vs pull. The onus is still with
    > you dig into the down and dirty details.


    Very much appreciated answer. You shed some lights on some interesting
    topic anyway...

    Jean-Yves
    --
    They who would give up an essential liberty for temporary security,
    deserve neither liberty or security (Benjamin Franklin)


  8. Re: ipfw and timeout


    "JYA" wrote in message
    news:48814694$0$2333$426a74cc@news.free.fr...
    > Hi
    >
    > On 2008-07-19 10:08:38 +1000, Jason Bourne
    > said:
    > > The above referenced URI also refers to ISA server, or some other

    firewall
    > > that works on higher layers in the OSI stack, ie up to Layer 7. The ipfw
    > > firewall is a packet filter and only examines traffic to layer 4. Hence,
    > > there is no such thing as an 'http session timeout' that can be

    configured.
    > > You'll have to operate at the TCP connection layer that carries the http
    > > traffic if using ipfw.

    >
    > I forgot to add that there is NAT happening as well, however it works
    > as static NAT using natd


    JYA,

    You are wasting your time. The KB article says nothing about battery
    life and is ONLY applicable IF you are getting your Application log stuffed
    full of Warning events. If your not seeing the Warning events in your
    Application log then you do not have the problem that is mentioned in
    the KB. You can screw around all you want with settings, it won't
    fix it.

    Clearly, the battery life issue is because the Exchange connector was
    designed to allow the Exchange server to push out stuff to the client.
    Regardless of what the client settings are, every 9 minutes the Exchange
    server sends data to the client.

    Now, think for a moment from the perspective of the i-phone software
    developer. His i-phone client software must be written so that it can
    receive these exchange server notifications every 9 minutes. Now, 9
    minutes on an i-phone isn't going to be -precisely the same- as 9 minutes
    on any given system running exchange, it could be more, it could be less.
    Plus you have varying network latency. Thus you cannot easily write
    the i-phone Exchange client to go into sleep mode then wake up every
    8.75 minutes and start listening for an exchange push, then go back to
    sleep when it gets it. What if it doesen't get it? Does it not get it
    because
    the exchange server crashed or because the network is down? Or because
    the clocks are different enough that it's now out-of-sync? There
    are enormous numbers of variables here.

    The easy and simple way to do it is to not pay attention to the 9 minute
    push packet interval and just leave the i-phone NOT in sleep mode,
    and ready to accept incoming push packets, for as long as you have your
    exchange connector active on the i-phone. Obviously this is going to
    chew up battery life with a vengence.

    >
    > It also works fine with the iPhone, however when used with the iPhone I
    > never managed to get more than 12 hours of battery. Whick kind of sucks!
    >
    > I read in various forums about people talking about increaing timeout

    value.
    > I was pretty sure that it didn't apply in my case due to the firewall I
    > used and how it was configured.
    >


    What you
    have here is a classic case of 2 systems, one system (exchange) designed
    with certain assumptions, the other system (i-phone) designed with certain
    assumptions, and it just so happens that neither system's assumptions match.
    You can't change the assumptions used for either system's design, at least,
    not easily. You can use the KB article to, for example, jack the alert
    threshold way up into God's ass - but the i-phone doesen't know you did
    that and so is still going to be listening for those packets all-the-time.

    > But it never hurts to investigate anyway


    No, and to your credit you at least asked. Believe me, if there was an easy
    way to fix this Microsoft would have posted a KB titled "too short battery
    life for i-phone" or some such. But since there isn't, Microsoft will do
    it's
    SOP and merely ignore that there's a problem.

    Ted



  9. Re: ipfw and timeout

    Hi

    On 2008-07-21 03:43:13 +1000, "Ted Mittelstaedt" said:
    >
    > No, and to your credit you at least asked. Believe me, if there was an easy
    > way to fix this Microsoft would have posted a KB titled "too short battery
    > life for i-phone" or some such. But since there isn't, Microsoft will do
    > it's
    > SOP and merely ignore that there's a problem.


    IMO, the exchange implementation in the iPhone is utter crap.

    I will not manage more than a day on a single charge when using
    Exchange and push...
    When using IMAP (against courier-imap running on FreeBSD), the battery
    will last over 2 days.

    I've never seen a device with such a poor battery life, even using
    exchange and push.
    My HTC windows mobile device will do over 2 days no problem of regular use...

    My iPhone on exchange is something like: charge at 1PM, by 7PM need to
    charge it again...

    But we're getting OT.

    Jean-Yves

    --
    They who would give up an essential liberty for temporary security,
    deserve neither liberty or security (Benjamin Franklin)


  10. Re: ipfw and timeout

    Begin <48899352$0$14095$426a74cc@news.free.fr>
    On Fri, 25 Jul 2008 18:48:18 +1000, JYA wrote:
    >
    > IMO, the exchange implementation in the iPhone is utter crap.


    If you're convinced of that, then that leaves you little choice but to
    complain to apple and hope they'll fix it.


    --
    j p d (at) d s b (dot) t u d e l f t (dot) n l .
    This message was originally posted on Usenet in plain text.
    Any other representation, additions, or changes do not have my
    consent and may be a violation of international copyright law.

  11. Re: ipfw and timeout

    JYA wrote:
    > I will not manage more than a day on a single charge when using Exchange
    > and push...


    I have never used an iPhone, so bear with me for a moment here.
    On the phones I'm used to (Nokia, symbian, MailForExchange) push mail is
    actually pull mail.
    And you can configure how often the phone will check for mail.
    Currently I have it set to check mail every 15 minutes during business
    hours, and every 4 hour outside of business hours.
    This is a compromise, but improves battery life very much.

    Is something like that possible with iPhone?
    --
    Torfinn Ingolfsen,
    Norway

  12. Re: ipfw and timeout

    Hi
    On 2008-07-26 19:40:41 +1000, Torfinn Ingolfsen said:
    > And you can configure how often the phone will check for mail.
    > Currently I have it set to check mail every 15 minutes during business
    > hours, and every 4 hour outside of business hours.
    > This is a compromise, but improves battery life very much.
    >
    > Is something like that possible with iPhone?


    Yes... However the iPhone doesn't have any settings for off-peak time.
    It gives you the choice to pull ever 15, 30 , 60 and 4 hours ...

    However, the advantage of push isn't just for email, but also having
    calendars and contacts always up to date with the exchange server.

    --
    They who would give up an essential liberty for temporary security,
    deserve neither liberty or security (Benjamin Franklin)


  13. Re: ipfw and timeout

    On Mon, 28 Jul 2008 22:44:15 +1000, JYA wrote:

    >Hi
    >On 2008-07-26 19:40:41 +1000, Torfinn Ingolfsen said:
    >> And you can configure how often the phone will check for mail.
    >> Currently I have it set to check mail every 15 minutes during business
    >> hours, and every 4 hour outside of business hours.
    >> This is a compromise, but improves battery life very much.
    >>
    >> Is something like that possible with iPhone?

    >
    >Yes... However the iPhone doesn't have any settings for off-peak time.
    >It gives you the choice to pull ever 15, 30 , 60 and 4 hours ...
    >
    >However, the advantage of push isn't just for email, but also having
    >calendars and contacts always up to date with the exchange server.


    Though an up-to-date calendar is useless unless you look at it! We use
    pull and our users sync. the 'phones (HTC SPV650 in our case) when
    they need to view the information. It pays dividends in battery life
    and charges.

    Steve.

+ Reply to Thread