25 May 16 09:35, you wrote to me:

 ml>> to handle pkts from points, add the following above your thunderbirds
 ml>> comment...

 ac> pkthdr.origpoint & destpoint should work fine?

those do but it is pkthdr.orignet that has to change based on if it is
65535... in that case, pkthdr.auxnet should be used...

 ml>> ===== anip =====
 ml>>   # if orignet is 65535, use auxnet

 ml>>   if pkthdr.orignet == 65535:
 ml>>     pkthdr.orignet = pkthdr.auxnet
 ml>> ===== snip =====

 ac> Hmm, ok. I'm not sure what software uses this.

BBBS for one... most any that do type 2+ PKTs from point systems should do
this as well... i will have to set up a special test system to see what
fastecho does... if the fmail maintainer is here, perhaps he can tell us
what fmail does when it creates type 2+ PKTs from point systems...

 ac> Delving into the HPT source, it has:

 ac>   if (header->origAddr.net == 65535) {
 ac>           if (header->origAddr.point) header->origAddr.net =
 ac> header->auxNet;
 ac>           else header->origAddr.net = header->destAddr.net;
/*  not in FSC
 ac> ! */ }

i think that is OK... i haven't traced it fully, though... it looks like it
jumps directly to the auxnet address if there is a point number at all...
that's not really right, though... auxnet should be used only if orignet is
65535... not if there is a point address... the logic is similar but the
distinction is between the two formulas is ummm... distinct...

 ac> which in my Python code would translate to:

 ac>   if pkthdr.orignet == 65535:
 ac>     if pkthdr.origpoint != 0:
 ac>       pkthdr.orignet = pkthdr.auxnet
 ac>     else:
 ac>       pkthdr.orignet = pkthdr.destnet

 ac> I trust HPT is doing the correct thing here but it's pretty weird-looking.

yes, it is kinda... the only key that i'm aware of is if orignet == 65535
then auxnet should be used as it will/should contain the proper origin net
number... the result would not work if the address is 1:153/123.2 and a
pointnet of 1:12345/2 was used... this conversation is taking place over at
least two echos... maybe three... i think FIDO_UTIL is the other one where
i explained this earlier today...

 ac> HPT never sets the auxnet field to non-zero anywhere, though. Maybe
 ac> some older software does.

if HPT is creating type 2+ PKTs from a point address, it should be setting
orignet to 65535... i'll have to take a look at some of the PKTs from this
system to my main host system...

 ml>> i might mess around with it and see what can be done to add the other
 ml>> two type 2 formats... no sure, though... am kinda interested in python
 ml>> for several projects that have python engines in them... i think,
 ml>> though, that they're doing python3...

 ac> Well Python 2 & 3 aren't hugely different.

that's what i thought, too...

 ac> The 2to3 program included with Python will convert my code to 3.x
 ac> syntax.

cool that they added a conversion tool...

does python have a way to load a buffer with data and then overlay other
formats right on top of that buffer so as to be able to view certain data
in different ways? this is like TP's

  header1 : pkthdr1 absolute bulkhdr;
  header2 : pkthdr2 absolute bulkhdr;
  header3 : phthdr3 absolute bulkhdr;

and then we can use header1, header2 and header3 to look for sane values in
certain specific fields to determine which PKT type we are looking at...

)\/(ark

Always Mount a Scratch Monkey

... It's not nice to *fool* with Mother Nature, is it?
---