VOGONS


First post, by superfury

User metadata
Rank l33t++
Rank
l33t++

How should an ISP handle packets that are received for the connected client (which has an IP and/or IPX address) that exceed the MTU of the client's PPP connection? If the client identifies a maximum of, say, 1500 bytes in the information fields and the ISP receives a larger IP/IPX packet in a open IPv4 or IPX connection, what should it do with the incoming packet for the client? Drop it and do nothing? Send some IMCP(IPv4 packets only) or IPX equivalent packet back to the sender of the received packet? Truncate the packet and send it to the client with the destination IP address or IPX node number?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 1 of 6, by Ringding

User metadata
Rank Member
Rank
Member

Shouldn't they just be fragmented?

Reply 2 of 6, by superfury

User metadata
Rank l33t++
Rank
l33t++
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?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 3 of 6, by Ringding

User metadata
Rank Member
Rank
Member

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.

Reply 4 of 6, by superfury

User metadata
Rank l33t++
Rank
l33t++
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).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 6 of 6, by superfury

User metadata
Rank l33t++
Rank
l33t++
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?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io