[nos-bbs] JNOS and Winlink interfacing -- close but stuck

John Goerzen jgoerzen at complete.org
Fri Dec 24 21:41:09 EST 2010


OK, so I added some debugging code to fbbfwd.c and I now got this from 
the log:

20:38:18  KR0L-7 on port rms - MBOX (wl2k) validate_address on 
msglst[i].to Z at Y returned 0

So I had added this to fbbfwd.c:

           // If we're still OK, make sure the address resolves ok.
           if(msglst[i].accept == fbbYES) {
              if(msglst[i].rewrite_to == NULLCHAR) {
                 if(validate_address(msglst[i].to) == 0){
                   logmbox(m->user, m->name, "validate_address on 
msglst[i].to %s returned 0", msglst[i].to);
                    msglst[i].accept = fbbNO;
                 }

the logmbox line is the one I added.

Now, this makes sense with what Maiko said below about JNOS transforming 
the FC into the FA E X Y Z.  Perhaps I could fix this with a rewrite for 
Y at Z.  However, what I don't understand is how this is working for 
others.  The docs don't mention needing to do a rewrite on Y at Z so I'm 
confused about how this works for anyone.

Thanks,

-- John

On 12/24/2010 08:30 PM, John Goerzen wrote:
> On 12/24/2010 12:47 AM, Bob Tenty wrote:
>> rewrite most likely as wl2k is not a user.
>>
>> wl2k@* wl2k
>>
>> In the rewrite file might help.
>
> Thanks for the suggestion, but no difference.
>
> -- John
>
>
>>
>> 73,
>>
>> Bob VE3TOK
>>
>> On 10-12-23 11:20 PM, Maiko Langelaar wrote:
>>> Hi John,
>>>
>>> I'm taking off for a few days - christmas at the outlaws :)
>>>
>>> But a quick response for the following :
>>>
>>>> So, in other words, the RMS server sent out the strings:
>>>>
>>>> FC EM 7G9QYPPFQIVH 142 140 0
>>>> F> 5D
>>>>
>>>> But JNOS logged FA E X Y Z 7G9QYPPFQIVH 142 140.
>>>
>>> I'm sorry for the confusion. That is normal. JNOS is taking it as a FC
>>> actually, I forgot to change the logging of that, since I map it to the
>>> FA proposal in the code to make my life easier. I need to correct that.
>>>
>>>> And JNOS responded back with FS -
>>>
>>> It will do this is the message id has been used already by your JNOS,
>>> or if you have a reject clause in your rewrite file, or if the address
>>> of the recipient is not resolvable. This could be a combo of domain.txt
>>> or DNS and/or rewrite file. Perhaps others can chime in on this.
>>>
>>> You could turn on the mbox trace during forwarding and see what the
>>> console/logs say (ie, mbox trace on).
>>>
>>>> If I may ask a tangentially-related question: why do I have to set up
>>>> a tun0 and kissattach tunnel for JNOS? The Linux kernel already
>>>> provides this stuff natively -- and binding to a specific IP address
>>>> and such is something commonly done by things like apache already ...
>>>
>>> JNOS has it's own IP stack, it manages it's own threads, it's a user
>>> space
>>> threads application. JNOS originally ran on DOS systems, giving the
>>> user a
>>> multiuser, multitasking, tcp/ip environment - the linux of it's day.
>>>
>>> Perhaps that will answer the question for you the best. The tun0
>>> allows JNOS to interact with your LAN, your WAN, the internet, etc.
>>>
>>> 73 Maiko
>>>
>>>
>>> _______________________________________________
>>> nos-bbs mailing list
>>> nos-bbs at tapr.org
>>> https://www.tapr.org/cgi-bin/mailman/listinfo/nos-bbs
>>
>>
>> _______________________________________________
>> nos-bbs mailing list
>> nos-bbs at tapr.org
>> https://www.tapr.org/cgi-bin/mailman/listinfo/nos-bbs
>>
>
>
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/nos-bbs
>





More information about the nos-bbs mailing list