Shouldn't they just be fragmented?

Ringding wrote on 2023-09-14, 19:12:

Shouldn't they just be fragmented?

Does PPP perform that itself? What protocol is used on that case (for the fragments)?

What about supported non-IPv4 protocols, like IPX? It doesn't seem to have any fragmentation support?

Or does it require PPP multilink (https://www.rfc-editor.org/rfc/rfc1990 ) to be supported?

Edit: So if PPP multilink is required for that:
- Reject Endpoint Descriminator option: not used for this.
- Accept Short Sequence number if specified.
- Accept MRRU on a closed link (to open only 1 simple bundle), Reject it on open links (to only keep 1 simple link for all packets to pass through sequentially, mentioned in section 8 ).

Then, once LCP is open:
- Reject multilink packets reveived if not negotiated to send (following the same rules as for other LCP settings for said direction).
- If enabled in the receiving direction and a too large (MRU or MRRU (only when 'multi'-link is enabled or both), split the packet using both (according to combined lowest of the two specified or defaulted) if MRRU is specified and send to the client split using multilink, otherwise discard the packet silently?
- If the packet is small enough (MRU setting only), send using the normal protocol number for said protocol.

Would that be correct behaviour?
Edit: Does Multilink PPP even work with single modems and single connections?

TBH, I never thought sending IPX over PPP was even possible. I am still not sure this is the case 😉

I would assume that fragmentation is part of IP forwarding, whoever does that. When forwarding a packet that is too large for the target network’s MTU, it gets split up and the fragments will be fed into the receiving network.

Ringding wrote on 2023-09-15, 08:18:

TBH, I never thought sending IPX over PPP was even possible. I am still not sure this is the case 😉

I would assume that fragmentation is part of IP forwarding, whoever does that. When forwarding a packet that is too large for the target network’s MTU, it gets split up and the fragments will be fed into the receiving network.

Well it must be possible:
- https://www.rfc-editor.org/rfc/rfc1552.html#section-3
- Windows 95 clealy mentions it in it's PPP dial-up settings checkboxes (and it does work! Even ran DOOM 95 using it). Although Windows 9x has encoding/decoding problems using it simultaneous with IPv4 on the PPP connection for some weird reason (messing up PPP headers or going undocumented somehow).

you could probably find some answers digging though the code for linux ppp:
https://github.com/ppp-project/ppp

GloriousCow wrote on 2023-09-15, 17:26:

you could probably find some answers digging though the code for linux ppp:
https://github.com/ppp-project/ppp

Only came so far with it:
https://github.com/ppp-project/ppp/blob/maste … ppd/lcp.c#L1877
Leads to:
https://github.com/ppp-project/ppp/blob/maste … pd/main.c#L1190 (ppp_send_config / ppp_recv_config).
Leads to some function at the_channel->send_config/recv_config?

That pointer call ends up at:
tty_(d0_)send_config: https://github.com/ppp-project/ppp/blob/maste … pppd/tty.c#L865
^ also: https://github.com/ppp-project/ppp/blob/maste … solaris.c#L1522 (setting link_mtu)
also: https://github.com/ppp-project/ppp/blob/maste … s-linux.c#L1591 (setting link_mtu)

So the global "static int link_mtu" variable stores it? I don't see it used anywhere?
The other side's mru is simply executing ioctl PPPIOCSMRU on ppp_fd's descriptor, pointing to the /dev/ppp device?