Fragmentation

Fragmentation

[Gérard Parat / F6FGZ]

Hello,

I am wondering how to tweak mss/mtu/window/packet lenght etc ... to avoid
TCP/IP fragmentation for a 1200 bds link. I am trying to send 256 byte size
AX25 packet, here an example:

vhf: fm F6FGZ-4 to F6KBS-1 ctl I37^ pid=8(segment) len 255 22:05:44 First seg;
remain 1
IP: len 328 44.151.78.19->44.151.91.49 ihl 20 ttl 64 DF prot TCP
TCP: 46755->http Seq x74f3e657 Ack x86439001 ACK PSH Wnd 472 Data 213
0000  GET / HTTP/1.0M.Connection: Keep-AliveM.User-Agent: Mozilla/4.78
0040   [fr] (X11; U; Linux 2.4.18 i686)M.Host: f6bgr.ampr.orgM.Accept:
0080   image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png,
00C0   */*M.Accept-Encoding
vhf: fm F6FGZ-4 to F6KBS-1 ctl I30^ pid=8(segment) len 76 22:05:45 remain 0
0000  : gzipM.Accept-Language: fr, en, zhM.Accept-Charset: iso-8859-1,
0040  *,utf-8M.M.

Data are splitted ...

--
73 Gérard F6FGZ



-
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fragmentation

[Tomi Manninen]

On Fri, 10 Jan 2003, Gérard Parat / F6FGZ wrote:

> I am wondering how to tweak mss/mtu/window/packet lenght etc ... to avoid
> TCP/IP fragmentation for a 1200 bds link. I am trying to send 256 byte size
> AX25 packet, here an example:

I think having the interface MTU equal to the value in 
/proc/sys/net/ax25/<ifname>/maximum_packet_length should be enough to 
prevent AX.25 fragmentation.

-- 
Tomi Manninen           Internet:  oh2bns@sral.fi
OH2BNS                  AX.25:     oh2bns@oh2rbi.fin.eu
KP20ME04                Amprnet:   oh2bns@oh2rbi.ampr.org

-
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

fragmentation

[devnetfs]

Hello,

I have a skb whose data I want to fragment into fixed size
chunks with each fragment having its own (fixed size) header.

What is the fastest way to do this, with minimal copying of data
around? The easiest approach looks to be:

1. allocated a *new* skb of size=header_size+fragement_size
2. *copy* part of data from my original skb into this new pkt
3. setup the header in the fragmented-packet
4. xmit this sk_buff (dev_queue_xmit)

What I dont like is the *new* and (extra) *copy* part. As my original
skb in in the kernel itself an additional copy (of fragment-size)
before xmit seems wasteful to me.

Is it possible to allocate buffer-space for just the header and then
have pointers into the original skb for the fragement data, avoiding
the extra *copy* of the fragment-data.

So the question(s) are:

[1] can I submit a packet (a sk_buff)to low level device (using
    dev_queue_xmit()) that has its buffer/data in discontinuous 
    blocks in the kernel -- some kind of iovec. 
    And if the network device supports DMA gather -- this would 
    make the xmit path very fast. right?
OR
[2] can I submit a chain of sk_buff's that need to be xmited as ONE
    ether frame to dev_queue_xmit()?
OR
[2] such a chaining is not very useful and the above approach 
    (steps 1-4) is ok.

[btw this data is being generated in the kernel and sent over ether]

Any insights or possible solutions would be helpful.

Thanks,
A.

ps: I've just subscribed to netdev, so not sure if I will get the reply
to this mail. So please Cc: me the reply -- thanks.

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Fragmentation

[Charles Gordon]

Hi,

I'm working on a driver which will use mac80211.  My hardware cannot
transmit a frame larger than 1792 bytes, or receive frames larger than
2048 bytes.  Right now I am relying on the fragmentation routines
built into mac80211.  Is there a way for my driver to tell mac80211
what the maximum transmit and receive frame sizes are?  Do I need to
implement my own fragmentation code to handle this?

Thanks for you help.

Re: Fragmentation

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]

Charles,

> I'm working on a driver which will use mac80211.  My hardware cannot
> transmit a frame larger than 1792 bytes, or receive frames larger than
> 2048 bytes.  Right now I am relying on the fragmentation routines
> built into mac80211.  Is there a way for my driver to tell mac80211
> what the maximum transmit and receive frame sizes are?  Do I need to
> implement my own fragmentation code to handle this?

Using fragmentation for this is not a good plan -- better adjust the
maximum MTU. We currently cannot do that because mac80211 assumes that
all devices actually conform to the 802.11 standard wrt. this... Clearly
your device does not -- 2048 bytes is much too small, and you cannot
force the remote peer to send smaller frames than that (though in
practise it they will be smaller most of the time).

I would suggest that for now you don't worry about it at all -- the
default MTU is 1500 matching ethernet, so the largest frame that
mac80211 will give you by default is much smaller than 1792 bytes. Then,
once you release your driver under GPL and post it for inclusion into
our tree we can think about adding a new hardware capability to mac80211
that restricts users from increasing the MTU above 1792-30-2-8-4 (or
something like that).

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Fragmentation

[Nigel Magnay]

[-- Attachment #1.1: Type: text/plain, Size: 1513 bytes --]

Hi!

I have successfully set up a wireguard connection, to a server hosted
inside Microsoft Azure. Thankyou for this software, it's so much easier to
configure than the alternatives.


I have a small problem though, which I think I understand (but seems
strange), but I'm not sure of the correct solution.

I have routed all internet traffic over this connection; it works, I can
successfully ping sites, and view some. I'm using IP masquerading at both
ends to connect entire networks (I thus use the client as a gateway).

However - some hosts do not respond - or, rather, there's a packet
fragmentation issue.

I can see with tcpdump on the server entries like this:

17:55:04.461804 IP 85.118.26.200.https > vpn1.60630: Flags [.], seq 1:1441,
ack 518, win 30, length 1440
17:55:04.461849 IP vpn1 > 85.118.26.200: ICMP vpn1 unreachable - need to
frag (mtu 1420), length 556

Which I take to mean "we got a response, it's length is too big to fit in
the vpn payload, please shorten".

What happens though is nothing - it just keeps receiving over-long
responses, so it doesn't work - which is hardly wireguard's fault.

Now, I guess either the end server is simply ignoring me, or the ICMP stuff
is being blocked somewhere. I'm not knowledgeable enough to know if either
of these are likely, as I'm a bit puzzle as to how anything could work
properly if either of those were true.

So - am I doing something wrong? What's the right knobs for me to be
twiddling here?

I have wireguard 0.0.20190601 at each end.

[-- Attachment #1.2: Type: text/html, Size: 1713 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Fragmentation

[ѽ҉ᶬḳ℠]

Any SQM measures deployed? That what it caused it on my nodes until
disabled.

On 18/06/2019 17:32, Nigel Magnay wrote:
> Hi!
>
> I have successfully set up a wireguard connection, to a server hosted
> inside Microsoft Azure. Thankyou for this software, it's so much
> easier to configure than the alternatives.
>
>
> I have a small problem though, which I think I understand (but seems
> strange), but I'm not sure of the correct solution.
>
> I have routed all internet traffic over this connection; it works, I
> can successfully ping sites, and view some. I'm using IP masquerading
> at both ends to connect entire networks (I thus use the client as a
> gateway).
>
> However - some hosts do not respond - or, rather, there's a packet
> fragmentation issue.
>
> I can see with tcpdump on the server entries like this:
>
> 17:55:04.461804 IP 85.118.26.200.https > vpn1.60630: Flags [.], seq
> 1:1441, ack 518, win 30, length 1440
> 17:55:04.461849 IP vpn1 > 85.118.26.200 <http://85.118.26.200>: ICMP
> vpn1 unreachable - need to frag (mtu 1420), length 556
>
> Which I take to mean "we got a response, it's length is too big to fit
> in the vpn payload, please shorten".
>
> What happens though is nothing - it just keeps receiving over-long
> responses, so it doesn't work - which is hardly wireguard's fault.
>
> Now, I guess either the end server is simply ignoring me, or the ICMP
> stuff is being blocked somewhere. I'm not knowledgeable enough to know
> if either of these are likely, as I'm a bit puzzle as to how anything
> could work properly if either of those were true.
>
> So - am I doing something wrong? What's the right knobs for me to be
> twiddling here?
>
> I have wireguard 0.0.20190601 at each end.
>
>
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard


_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Fragmentation

[Vincent Wiemann]

Hi Nigel,

I can't tell for sure what your problem is,
but I guess you don't use MSS clamping for the masquerading.

Regards,

Vincent Wiemann
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard