It's been ages... so I looked it up.

Looks like ipxping (echo packet) is packet id 2 in the packet type field.

In order to send a packet, the destination must be specified. The source network and node data are also specified in the data packet's header.

https://www.novell.com/documentation/nw6p/?pa … a/hc1w6pvi.html

Since all pertinent info is right there in the header, a recieving system could respond to an echo packet, with info collected from the header.

I've looked for details about the data portion of an ipx echo packet, but can't seem to find paydirt.

wierd_w wrote on 2023-09-25, 04:16:

It's been ages... so I looked it up. […]
Show full quote

It's been ages... so I looked it up.

Looks like ipxping (echo packet) is packet id 2 in the packet type field.

In order to send a packet, the destination must be specified. The source network and node data are also specified in the data packet's header.

https://www.novell.com/documentation/nw6p/?pa … a/hc1w6pvi.html

Since all pertinent info is right there in the header, a recieving system could respond to an echo packet, with info collected from the header.

I've looked for details about the data portion of an ipx echo packet, but can't seem to find paydirt.

Then what about the response packet? How does it prevent sending a ping storm because of pings responding with 'pings' (protocol 2) to pings?

It if such a ping response would be received back and recognised as a ping request, it would infinitely ping itself?

Dosbox clears the protocol field when sending it's ping?

The IPX packet for echo does contain a TTL value analog, so packetstorm should be prevented, as long as the responding program does not modify the TTL and timestamp fields in a stupid manner.

There is no broadcast address with IPX either, so traditional packetstorm attack (Ping on the global broadcast, everyone responds, with compounding responses to responses, because of dumb TTL handling) should not even be possible-- All echos are unicast; The most you might be able to do is get an echo to bounce a few times between two hosts using a man in the middle to start the pingpong match-- the TTL will quickly expire though, and the bounce would stop.

Again, I tried to look for details about the actual data inside an IPX echo packet in the data portion, but could not find info. It's possible that additional Q0S measures use data in the data portion of the packet for sanity checking.

wierd_w wrote on 2023-09-25, 07:22:

The IPX packet for echo does contain a TTL value analog, so packetstorm should be prevented, as long as the responding program does not modify the TTL and timestamp fields in a stupid manner.

There is no broadcast address with IPX either, so traditional packetstorm attack (Ping on the global broadcast, everyone responds, with compounding responses to responses, because of dumb TTL handling) should not even be possible-- All echos are unicast; The most you might be able to do is get an echo to bounce a few times between two hosts using a man in the middle to start the pingpong match-- the TTL will quickly expire though, and the bounce would stop.

Again, I tried to look for details about the actual data inside an IPX echo packet in the data portion, but could not find info. It's possible that additional Q0S measures use data in the data portion of the packet for sanity checking.

IPX does have a broadcast address though. When all bits in the destination node number are set, the packet is a broadcast on the selected network. When all bits in the destination network number are set, the packet is broadcast to all selected networks (that are matching the node number, which can be a broadcast itself as well, so selecting network ffffffffh node ffffffffffffh will send it to all nodes on all connected networks).
https://en.wikipedia.org/wiki/Internetwork_Packet_Exchange

Are packets from itself blocked during broadcast? So will it receive packets from itself (or broadcasted itself)?

But source field does not permit broadcast as a valid value, per Novell documentation:

Source Network ---Number of the network to which the source node is attached. If a sending node sets this field to zero, the local network to which the source is connected is unknown. For routers, the rules that apply to the Destination Network field also apply to the Source Network field, except that routers can propagate packets that were received with this field set to zero.

Source Node ---Physical address of the source node.

Broadcast addresses are not allowed.

This means that the echo packet cannot specify the broadcast node ID as the source, it has to specify the its actual and correct node ID.

A properly implemented version of the echo packet handler, just needs to check "Is sender broadcast?" and simply go "no, I wont respond, dumbass" if somebody forged the packet with that return address.

wierd_w wrote on 2023-09-25, 08:43:

But source field does not permit broadcast as a valid value, per Novell documentation: […]
Show full quote

But source field does not permit broadcast as a valid value, per Novell documentation:

Source Network ---Number of the network to which the source node is attached. If a sending node sets this field to zero, the local network to which the source is connected is unknown. For routers, the rules that apply to the Destination Network field also apply to the Source Network field, except that routers can propagate packets that were received with this field set to zero.

Source Node ---Physical address of the source node.

Broadcast addresses are not allowed.

This means that the echo packet cannot specify the broadcast node ID as the source, it has to specify the its actual and correct node ID.

A properly implemented version of the echo packet handler, just needs to check "Is sender broadcast?" and simply go "no, I wont respond, dumbass" if somebody forged the packet with that return address.

OK. So sender broadcast will be ignored by the receiving side/router.

What if the sender is the receiver (same network and node number)?
IPXCP documentation (from PPP) seems to imply that a packet sent to itself won't arrive? It won't receive packets from itself and refuses to receive them apparently?