ipfw and timeout
JYA
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)
jpd
On Fri, 18 Jul 2008 23:25:15 +1000, JYA <nos...@nospam.blah> 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.
Jason Bourne
> 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
jpd
Jason Bourne <j_bourne_...@hotmail.com> 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.
Jason Bourne
[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
JYA
>
> 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 ...
JYA
On 2008-07-19 10:08:38 +1000, Jason Bourne
<j_bourne_...@hotmail.com> 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...
jpd
On Sat, 19 Jul 2008 11:29:04 +1000, JYA <nos...@nospam.blah> wrote:
> On 2008-07-18 23:56:57 +1000, jpd <read_t...@do.not.spam.it.invalid> said:
>
> Problem is find me a push email/calendar/addressbook alternative that
> you can host at your site and won't cost you an arm.
Interesting problem. Though I have no fetish for ``syncing'' mobile
devices so that I can be bombarded with the latest inane blatherings[1]
from a crowd that can't be bothered to spell or punctuate, much less
write coherently. So I'm not up to speed on the subject.
> How forgot to add that it has to work with windows mobile pda, nokia
> phones and the like ...
>
> Not everything Microsoft does is bad ...
That's like saying that because our infrastructure is built on oil and
nuclear power, both of those don't have nasty nasty side effects.
Besides, I thought blackberry was the first to market with their solution,
though it also was an exchange-only addon. If exchange can do it without
the RIM addon right away, then that was not something they came up with
first -- which would be entirely par for the course for them.
I'll take your point that you feel you have no choice, but I do contest
assertions that that somehow makes bricks out of straw.
On another note, I wouldn't mind figuring out how to do it with a
different platform, though I lack devices to test with, server hardware,
documentation, money, in short everything but time.
[1] Contrast http://www-cs-faculty.stanford.edu/~knuth/email.html
Ted Mittelstaedt
"JYA" <nos...@nospam.blah> wrote in message
news:48814694$0$2333$426a...@news.free.fr...
> Hi
>
> On 2008-07-19 10:08:38 +1000, Jason Bourne
> <j_bourne_...@hotmail.com> 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
JYA
On 2008-07-19 19:32:30 +1000, jpd <read_t...@do.not.spam.it.invalid> said:
>
> I'll take your point that you feel you have no choice, but I do contest
> assertions that that somehow makes bricks out of straw.
I didn't say I have no choice, just that Microsoft actually provides
the best and cheapest solution here.
RIM still requires an exchange server anyway..
There are unfortunately, no good open-source solution allowing you on a
mobile device to create calendar entries, invite people and check their
availability for a given time etc..
The push side of email is something you get very quickly get used to.
But the online/push calendar and address book is something that is
really essential in today's business...
Apple just released their own solution called MobileMe but you can't
host it yourself and you can't use your own email address, it has to be
something with blah...@me.com
I've tried plenty of other solutions to fill that purpose, none of them
work as well and is as well integrated as Exchange.
There was open-xchange that started to look promising, but really it
was utter crap: huge java solution, very hard if not impossible to
upgrade from one version to another (you pretty much had to start from
scratch each time)
And so bloddy hard to install and configure....
>
> On another note, I wouldn't mind figuring out how to do it with a
> different platform, though I lack devices to test with, server hardware,
> documentation, money, in short everything but time.
The best solution so far IMO is the horde project, but no mobile interface ...
Jean-Yves
JYA
On 2008-07-21 03:43:13 +1000, "Ted Mittelstaedt" <te...@toybox.placo.com> 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.
jpd
On Fri, 25 Jul 2008 18:48:18 +1000, JYA <nos...@nospam.blah> 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.
jpd
On Fri, 25 Jul 2008 18:43:34 +1000, JYA <nos...@nospam.blah> wrote:
>
> The push side of email is something you get very quickly get used to.
Amazingly, ``push'' is how email was originally setup. ``I have a
message, and now I'm going to give it to sendmail to send it over SMTP''.
``Push'', if you will.
The fundamental problem with ``push'' and mobile devices is that it's
a better idea to have them initiate the contact, so you're back to
polling. How expecting a (timed-from-elsewhere) push update every nine
minutes is somehow better than having the device poll every nine minutes
at its discretion somewhat eludes me. The information is not going to
get there faster, but it does create interesting.cn syncing problems.
Then again, I'm currently[1] at the receiving nuts'n'bolts end of an XML
interfacing project and the (hired from india) crackmonkeys that put the
``specification'' together layered leaky and ambigious custom XML on top
of SOAP (on top of XML, adding a base64 encoding step for good measure),
so I have a good view of how hype does not magically good solutions make.
> But the online/push calendar and address book is something that is
> really essential in today's business...
... because nobody deigns to afford a secretary, even when they can.
The key is to get the information where you want it, when you want it.
How you get it there is something marketeers like to focus on because it
lets them sell more technology ``product'' (often disservices, really).
Personally, I tote around a paper agenda (EUR 3,- for a full year of
service) as the act of writing appointments down helps me remember them.
Then again, I'm not in an environment where appointments can be (and
regularly are) wilfully yanked at any time for any reason. Nor do I
need to ``react fast'' as my decisions process is slow by choice and
necessity, so I allow for that. It saves a whole lot of bandwidth, too.
Not to say you have to copy my choices, of course.
[1] And have been for months: the project is dead in the water until
[details of weak project management elided]. This was supposed to
be a one weekend easy fix easy money project. It could've been
except for the backend people. *sigh*
Torfinn Ingolfsen
> 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
JYA
On 2008-07-26 19:40:41 +1000, Torfinn Ingolfsen <ti...@start.no> 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.
Steve Burton
>Hi
>On 2008-07-26 19:40:41 +1000, Torfinn Ingolfsen <ti...@start.no> 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.