[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Was: No buffer space available
As far as previous state/dead routes go, it depends on the situation.
nothing is actually being sent out (and it shouldn't be, until pppoe
renegotiates and starts encapsulating traffic again), then it is
in-line with typical network behavior. If you have a static default
to a typical ethernet interface, and the cable is unplugged, nothing
happens to that route. The packets just don't go anywhere until you
the cable back in.
Good you mention this. To me the problem is not with static /
semi-permanent addresses (like in your example), but with those
changing continuously; depending on the ISP.
To keep this on topic, what exactly are you seeing pf do in this case?
Is it working correctly after re-negotiation? How are you checking
This issue has a quite a history in here as well as in
comp.unix.bsd.openbsd.misc. At a certain time, a previous installation
refused to re-negotiate / change the route completely, even after
hours. Then those bad pings came in and all ... Contrary to another
poster there, I don't blame PF, because it simply is hooked to the
Then I started the investigation.
PF behaves properly, so to say, since it sits on the receiving end:
following the address of tun0 meticulously.
How did I check the status? Since pfctl -sn only displays (tun0),
simply observing a ping from an inside client to www.yahoo.com was used
for pf. For the rest I had the state of tun ('ifconfig tun0') and
'route -n show' observed continuously; throughout the period of
disconnection and reconnection.
NAT-ing and routing to an IP that by then might belong to someone else
nothing I'd expect to see in OpenBSD.
I wouldn't expect that either. But unless it's actually doing that,
not just dropping the packets, it's not an issue.
Makes me wonder. I'm not paranoid, but to me this is a potential issue.
Even if I will never be good enough to exploit this.
My personal, preferred solution is clear: If only I managed to get pppd
connect me to ADSL. This has been great before, without any hitch,
without any reboot; and most importantly with giving me a good sleep,
because it did precisely do what was expected. It would never use
shortcuts, but always bring up ip-down.local to disable forwarding,
remove the filter, flush routes.
pppd seems much better in detecting the loss of connectivity; without
waiting for a new address to show up. And in any case would always go
through the full circle.
I haven't managed yet, though, because the Roaring Penguin won't run on
I was also told, that the OpenBSD-developers don't like pppd, but
prefer ppp. Not my piece of cake to argue here; this is why pppd would
be my best preference. Rather than call ppp 'broken' (which I did); and
I am not the only one with similar experiences.
Your call ...
pf itself should be working as expected based on the feedback it gets
from the rest of the system.
As I said, it does as far as I can see. I posted the message not to
imply it wouldn't, b.t.w.
Rather as a follow-up to that earlier thread when ppp.linkup /
ppp.linkdown was discussed. In principle, I much prefer the way PF
handles the whole affair of changing connectivity; but it relies
heavily on the correct (and desired ?) functions of ppp. Anyone with a
PF production firewall should investigate if ppp actually does what the
individual administrator expects it to do; also in the case of link
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).