16.06.2020 17:37, hiral s shah wrote:
> I am currently pursuing MTECH and doing research on IP fragmentation.
> I came across a vulnerability that I am facing in my project.
>
> Can you please provide me some insight on "How freeBSD is handling ip
> fragmentation" ?
Hi Team,
I am currently pursuing MTECH and doing research on IP fragmentation.
I came across a vulnerability that I am facing in my project.
Can you please provide me some insight on "How freeBSD is handling ip
fragmentation" ?
Your help is much appreciated.
Than
On Sun, 23 Nov 2008, Eitan Shefi wrote:
Hi,
The IP fragmentation is not like in Linux, and is not clear to me.
I'm using 2 FreeBSD-6.3 hosts, connected directly.
If I change the MTU of both hosts to 5000, and send "ping" with message
size 4972 bytes ( 4972 = 5000 - 8(which is I
Hi,
The IP fragmentation is not like in Linux, and is not clear to me.
I'm using 2 FreeBSD-6.3 hosts, connected directly.
If I change the MTU of both hosts to 5000, and send "ping" with message
size 4972 bytes ( 4972 = 5000 - 8(which is ICMP Header size) - 20 (which
is IP Head
I successfully reproduced this on few different 4.8 routers.
Does anybody knows what is this? How to fix or workaround this problem?
Alexander Motin wrote:
I have one strange problem with dummynet & IP fragmentation.
I have FreeBSD 4.8-RELEASE router with few interfaces:
em0: flags=8843 mtu
Hello.
I have one strange problem with dummynet & IP fragmentation.
I have FreeBSD 4.8-RELEASE router with few interfaces:
em0: flags=8843 mtu 1500
options=3
inet 195.248.191.172 netmask 0xffc0 broadcast 195.248.191.191
ether 00:30:48:20:8e:7e
media: Ethe
*/
#define CSUM_FRAGMENT 0x0010 /* will do IP fragmentation */
Just use the first 3, have a look at the if_bge.c driver for
an example.
--
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why
Hi,
I am writing a gigabit ethernet driver for one of the
NICs.My hardware is capable of computing the checksum
and hence I am enabling per-packet handling of
TCP/IP/UDP checksum offload in transmit side.I would
like to know if there is a way by which I can tell the
upperguy that I will not be abl
Terry Lambert wrote:
> I thought about this for a while, after Bruce said he was
> looking into it.
>
> There are some implicit problems that I don't know if it's
> really possible to resolve satisfactorily.
>
> If you drop fragments for whatever reason, in order to prevent
> overflow, just random
Bill Fenner wrote:
> >Just for the heck of it, I started reading through ip_input.c to see how
> >hard this would be to do. Haven't got there yet, I saw something odd:
> >the variables ip_nfragpackets and nipq look *awfully* similar.
>
> So do the commit logs for the revisions in which each was
If memory serves me right, Bill Fenner wrote:
> The problem with the ip_nfragments code is that if space becomes
> available in the middle of reception of an entire packet, a queue
> will be created to reassemble a packet that will never completely
> arrive (since we dropped some of the beginning
>The only difference I can see is that in ip_input(), if nipq > maxnipq,
>all of the fragments for some other packet in the current hash bucket
>get dropped (with the wonderfully descriptive comment "gak").
The best thing to do is to drop the oldest frag queue; that's obviously
non-trivial with
>Just for the heck of it, I started reading through ip_input.c to see how
>hard this would be to do. Haven't got there yet, I saw something odd:
>the variables ip_nfragpackets and nipq look *awfully* similar.
So do the commit logs for the revisions in which each was introduced.
Revision 1.65 -
[Moving to -net]
If memory serves me right, Andrew Gallatin wrote:
> > Alternately, it would be a good idea to have a "ip_maxpacketfrags"
> > instead of an "ip_maxfragpackets", to put a hard limit on the
> > number of mbufs that can be consumed by the fragment reassembly
> > process.
>
> I
14 matches
Mail list logo
