This is invaluable for dial-on-demand connections...
In ppp.linkup:
set log -dns -tcp/ip
and in ppp.linkdown
set log +dns +tcp/ip
giving a much better account of why the link came up.
value.
This has minimal impact here, but if ppp ever needs to frequently
remove timers before they've timed out, it can badly skew the next
item in the timer list without this change.
The correct fix would be to store usecs in `rest' rather than
TICKUNITs, but the math is easier if we just round...
that we adjust that timers `rest' value (with the current getitimer()
values) before using that to adjust the next items `rest' value.
After adjusting that value, restart the timer service so that we've
now got the correct setitimer() values.
I don't claim to own the code and certainly don't want to discourage
people from fixing or updating it.
[I know it's the 29th, but the FREEZE hasn't yet been posted to committers]
passed to libalias. If there's not enough space, things like ftp
PORT commands start failing....
Reported by: Gianmarco Giovannelli <gmarco@giovannelli.it>
4096 - sizeof struct mbuf, and set MAX_MRU and MAX_MTU
back to 2048.
2048 is big enough as an MTU/MRU, but we need to be able
to allocate larger mbufs after reassembling IP fragments.
twice (once for the arg parsing and once to make it a normal character).
Make the man page example consistent.
Reminded by: Bryan Liesner <bleez@netaxs.com>
a running timer. This fixes a problem where a dial is manually
aborted, the hangup script kicks in and the chat timer ends up
on the timer queue twice (tick tick tick tick *boom*)
method avoided all race conditions, but suffered from
sometimes running out of buffer space if enough clients
were piled up at the same time.
Now, the client pushes the link descriptor, one end of a
socketpair() and the ppp version via sendmsg() at the
server. The server replies with a pid. The client then
transfers any link lock with uu_lock_txfr() and writev()s
the actual link contents. The socketpair is now the only
place we need to have large socket buffers and the bind()ed
socket can keep the default 4k buffer while still handling
around 90 racing clients.
length field rather than the one byte message length field embedded
in the packet. This steps slightly outside of the protocol boundaries,
but should not cause any problems.
Limitation noted by: Simon Winwood <simon@winwood.org>
Previously, ppp attempted to bind() to a local domain tcp socket
based on the peer authname & enddisc. If it succeeded, it listen()ed
and became MP server. If it failed, it connect()ed and became MP
client. The server then select()ed on the descriptor, accept()ed
it and wrote its pid to it then read the link data & link file descriptor,
and finally sent an ack (``!''). The client would read() the server
pid, transfer the link lock to that pid, send the link data & descriptor
and read the ack. It would then close the descriptor and clean up.
There was a race between the bind() and listen() where someone could
attempt to connect() and fail.
This change removes the race. Now ppp makes the RCVBUF big enough on a
socket descriptor and attempts to bind() to a local domain *udp* socket
(same name as before). If it succeeds, it becomes MP server. If it
fails, it sets the SNDBUF and connect()s, becoming MP client. The server
select()s on the descriptor and recvmsg()s the message, insisting on at
least two descriptors (plus the link data). It uses the second descriptor
to write() its pid then read()s an ack (``!''). The client creates a
socketpair() and sendmsg()s the link data, link descriptor and one of
the socketpair descriptors. It then read()s the server pid from the
other socketpair descriptor, transfers any locks and write()s an ack.
Now, there can be no race, and a connect() failure indicates a stale
socket file.
This also fixes MP ppp over ethernet, where the struct msghdr was being
misconstructed when transferring the control socket descriptor.
Also, if we fail to send the link, don't hang around in a ``session
owner'' state, just do the setsid() and fork() if it's required to
disown a tty.
UDP idea suggested by: Chris Bennet from Mindspring at FreeBSDCon
inserting a new item. Without this, it's possible to
mis-insert quite badly... but only by as much as the load of
the first item, which is almost always 1 second.
Initialise the timerservice with `restart' set if we're inserting
at the start of the list.
doing a HangupDone(). The HangupDone() may fuel
bundle_CleanDatalinks(), and if so, the bogus
UpdateSet() ends up select()ing on a closed
descriptor.....
Change the main `do/while' loop to a `for' loop so
that any `continue's do the bundle_CleanDatalinks()
& bundle_IsDead() bit.
PPPoUDP connection.
(*) This is as correct as ftp and uucp wtmp entries are - that is,
multiple concurrent connections will not record enough information
in wtmp to tell last(1) who was logged in for how long.
re-open a device. The fact that we're in NETWORK phase indicates
that there are other links in DATALINK_OPEN and that we don't want
to stop using them.
Warn about -alias being depricated (but still allow it).
Don't moan twice about failing to open any tun device.
Fix a diagnostic and add the -quiet switch to the usage message.
that the first timer ends up doing a timer_Stop() on the second.
When this happens, remove the timer from the pending list so that
we still call any subsequent timers.
This bug has been here for several years, but has only been tickled
recently with my device layering changes.
With enormous thanks for the perseverance of: Ruslan Ermilov <ru@ucb.crimea.ua>
in struct cstate rather than copying the stored header slot into a
potentially mis-aligned buffer then trying to update the ip_sum
without causing an exception on non-i386 hardware.
I've never been able to reproduce this problem, but it has been
reported by many people... besides, the code is now a bit cleaner.
Testing & patience by: Anthony Solovjoff <asolovjoff@hotmail.com>
carrier instead so that we can set up our carrier detect
timer and eventually notice when we lose carrier.
Honour the script.run value when coming out of carrier state.
PR: 14145
