Econet issues

[ZXGuesser]

I've been digging around trying to fix some papercuts in the econet emulation using AUN, and have identified one issue where BeebEm sends empty packets which was crashing the Pi Econet Bridge (it now catches this issue and emits warnings). The cause of these empty packets is that the SendMe flag is not being checked before sending the assembled tx packet to the SendSocket, so a packet is being generated for Scouts etc.

I've also been experimenting with supporting econet broadcast packets when not using StrictAUNMode, i.e. with port based addressing which doesn't see the udp broadcast packets. Currently all my tweaks and experimentation are mixed together and intertwined with my proposed configuration file change in #148. I don't know if you would prefer separate pull requests for each feature opposed to "here's a huge load of changes to everything at once"

[chrisn]

Thanks! If the changes are separable, I think I'd prefer separate pull requests if it doesn't create too much additional work.

I'd like to get a 4.20 release out very soon (it's now over 2 years since 4.19 and there are lots of improvements people could be using). Should we include your Econet (and Teletext adapter) changes, or do you mind if these go into a future 4.21 release (which could follow soon after, if ready)?

[ZXGuesser]

The latest teletext changes don't really affect anything users will actually notice unless they're poking around low level coding, but I think they're ready to go.

It would be good to get the empty econet packets fix into 4.20 at a minimum as that seems like a genuine bug and makes Pi bridges fall over if not running the very latest code there.

The wildcard proposal and my hacking around broadcast packets I'm less sure of because I'm very much an econet 'noob' and while it seems logical to me someone else might see issues I can't. That said I've been discussing the wildcard idea on the *. Discord and there seemed to be general agreement that it makes sense and makes connecting to stuff via the TNMoC econet cloud bridge a more pleasant experience.
The broadcast stuff is more experimental and currently only prods at machines BeebEm knows about which I think limits its usefulness somewhat. I think it needs thrashing out with people who understand both econet and the BeebEm code, which has so far meant "pester MarkUsher on Discord". I won't be at the LAN party which seems like being the place to figure these sort of things out unfortunately!

[ZXGuesser]

The empty packets fix seems as simple as putting an if (SendMe){ ... } around https://github.com/stardot/beebem-windows/blob/e5038df5e4547e6d4a17169982d39eb963ad9847/Src/Econet.cpp#L1605C1-L1611C9

[chrisn]

The latest teletext changes don't really affect anything users will actually notice unless they're poking around low level coding, but I think they're ready to go.

Thanks, I'll have a look at the PR and merge it.

The empty packets fix seems as simple as putting an if (SendMe){ ... } around https://github.com/stardot/beebem-windows/blob/e5038df5e4547e6d4a17169982d39eb963ad9847/Src/Econet.cpp#L1605C1-L1611C9

That could be a bug I introduced since 4.19... I'll check.

The wildcard proposal and my hacking around broadcast packets I'm less sure of

Ok, so maybe we could include this after the 4.20 release.

[chrisn]

The empty packets fix seems as simple as putting an if (SendMe){ ... } around https://github.com/stardot/beebem-windows/blob/e5038df5e4547e6d4a17169982d39eb963ad9847/Src/Econet.cpp#L1605C1-L1611C9

That could be a bug I introduced since 4.19... I'll check.

Looks to be related to this commit from @mark-usher: 36bc684

[ZXGuesser]

One of the issues I've been having with my attempts to get broadcast messages working is that I can get packets going off to all the instances, and see that they're arriving in BeebEm, but not being read by the emulated OS routines. I find that I can cure this by changing this line to BeebRx.eh.destnet = 255;.
i.e. the destination is 255.255 not 0.255

[mark-usher]

yes, @chrisn and I discussed testing the Econnet things out at the TNMoC event before pulling the trigger on the next release. Great that you've found some of these errors before the event. Great job. These should definitely be part of 4.20.

[ZXGuesser]

tracked down another pesky edge case which was preventing connecting to a host on another network when BeebEm knows about a host with the same station number on net 0.
I believe the solution is for this code to check that the network being checked is not zero (no aunnet in use):

if ((network[i].network == BeebTx.eh.destnet ||
	 (network[i].network == aunnet[myaunnet].network && network[i].network != 0)) &&
	 network[i].station == BeebTx.eh.deststn)
{

(I assume the AUNMap side of things still works, but I have no convenient way to test it)

[chrisn]

I can't be at TNMoC in person but I'll be available to test things remotely.

[chrisn]

The empty packets fix seems as simple as putting an if (SendMe){ ... } around https://github.com/stardot/beebem-windows/blob/e5038df5e4547e6d4a17169982d39eb963ad9847/Src/Econet.cpp#L1605C1-L1611C9

That could be a bug I introduced since 4.19... I'll check.

Looks to be related to this commit from @mark-usher: 36bc684

Adding if (SendMe) looks right. I can make that change, but it'll mean your PR #148 would need rebasing, if that's OK?

[ZXGuesser]

Yes, I wouldn't worry about that PR for now, I should probably close it as I've gone off down a bit of a rabbit hole in that branch now with fathoming out AUN broadcasts

[chrisn]

Thanks. I'll make the SendMe change then.

[ZXGuesser]

I've rebased the wildcard networks onto that, and separated out the other bits and bobs that had got pushed on the same branch, so #148 should not be contaminated with unrelated code now.

Small fixes:

• fix for empty AUNmap causing clashes in host lookups when the same station number is known on net 0 https://github.com/ZXGuesser/beebem-windows/tree/aun-network-0
• Broadcast packets having the wrong destination network https://github.com/ZXGuesser/beebem-windows/tree/broadcast-destination-fix

More unfinished/experimental code to discuss:

• send fake broadcast packets to other hosts when not doing proper AUN with separate IPs https://github.com/ZXGuesser/beebem-windows/tree/fake-broadcasts. This code currently limits itself to hosts on network 0.

[ZXGuesser]

I'm discussing the issues around BeebEm communicating with the Pi Econet Bridge here, and it seems like a better solution may be creating a special interface for gateway traffic on a single port rather than trying to bludgeon the existing AUN methods into behaving. It means adding a new incompatible extended AUN format, but that still seems tidier than opening thousands of ports for all potential remote stations to me!