Andre Oppermann wrote:
>
> Richard,
>
> I've attached a patch that fixes the problem with FIN/ACK and one more
> case which got it wrong. I also fixed the host byte order problem in
> ip_output.c for the normal ip_id incrementor.
>
> Some comments and questions:
>
> 1. Do you think it is necc
> Richard Wendland wrote:
> Haven't read all of that yet.
>> It's important to remember that if fragmentation takes place, and a
>> fragment is lost, the other fragment(s) will wait for quite some time
>> in a re-assembly buffer (maybe up to 63 seconds). While they are
>> waiting they are at qui
Richard Wendland wrote:
> > 5. Random ip_id is already a kernel option but it is *not* enabled by
> >default in 5.2RC2 GENERIC or -current.
>
> I don't think random ip_id should be enabled by default. The reduction
> in ip_id cycle from 64k is a real re-assembly risk on modern high-speed
> ne
Richard Wendland wrote:
>
> > I've attached a patch that fixes the problem with FIN/ACK and one more
> > case which got it wrong.
>
> Well done! I couldn't track that down.
>
> > 1. Do you think it is necessary to do a htons() on the randomized
> > ip_id too? I'd say yes if there is a cas
> 4. After reading the pf.conf man page from OpenBSD (where it talks about
>scrubbing IP packets) I don't think it's a good idea to set the ip_id
>to zero in the DF case. It seems to cause various kinds of problems
>when for some reason DF is removed along the path (which it shouldn't
> I've attached a patch that fixes the problem with FIN/ACK and one more
> case which got it wrong.
Well done! I couldn't track that down.
> 1. Do you think it is necessary to do a htons() on the randomized
> ip_id too? I'd say yes if there is a case where it has to
> monotonically inc
< said:
> 1. Do you think it is neccessary to do a htons() on the randomized
> ip_id too? I'd say yes if there is a case where it has to
> monotonically increase afterwards. Does it?
IP IDs are nonces. The only requirement is that they not be reused
for a packet to the same destinatio
Richard,
I've attached a patch that fixes the problem with FIN/ACK and one more
case which got it wrong. I also fixed the host byte order problem in
ip_output.c for the normal ip_id incrementor.
Some comments and questions:
1. Do you think it is neccessary to do a htons() on the randomized
Good analysis, I don't believe that any of us had heard of these issues.
Rolling it back for 5.2-release makes sense to me, but I think we should
leave it alone in -current and work through the problems.
I'm out of town without a way to commit, so it'd be best if some other
developer can talk to
I've been asked (for freebsd-bugs) to open a discussion about PR
kern/60889 on freebsd-net, to decide if a recent change to IP should be
reversed before 5.2-RELEASE (scheduled this month) to give more time
for some serious issues and risks my PR has raised to be considered
and tested. My proposal
10 matches
Mail list logo
