 |
| cazador |
Posted: Mon Nov 17, 2008 3:20 am
Aardwolf telnet 102 triggers |
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
 Posted: Wed Nov 19, 2008 7:30 pm
|
Make sure the Newline option is OFF and the Prompt option is ON for the trigger. I cannot reproduce any problem with this.
On my system, the Telnet trigger with Newline OFF and Prompt ON is only executed when the MUD sends a WILL or DO. The telnet trigger with Newline ON and Prompt OFF is executed by the IAC SB 102 commands.
If you put %char(251) in the pattern field of the Prompt ON trigger, it will *never* fire since no data is passed to the trigger to match the pattern against. |
|
|
|
|
Nick Gammon
Adept
Joined: 08 Jan 2001
Posts: 255
Location: Australia
|
Posted: Sun Nov 30, 2008 7:06 am
|
| Quote: |
I will contact Lasher about this. Aardwolf should NOT be sending both IAC DO 102 and IAC WILL 102. It needs to pick one or the other. Otherwise they are just going to have more problems with other telnet and MUD clients.
|
My understanding of the DO/WILL issue is as follows.
First the server checks if the client will send message 102:
| Code: |
Server: IAC DO 102 --> will you send protocol 102 ?
Client: IAC WILL 102 --> I will send it
-- or : IAC WONT 102 --> I won't do that, they have earlier client version
|
This means that if the server wants to send messages to the client, we have to reverse it.
| Code: |
Server: IAC WILL 102 --> Can I send protocol 102 to you?
Client: IAC DO 102 --> Yes, do that.
-- or : IAC DONT 102 --> Don't send it, they have earlier client version
|
Thus it is valid for the server to send both DO and WILL. However it might be wise to check for multiple items to avoid a loop.
If someone wants to contradict me, and I may be wrong here ;) , please post the RFC number that supports such a claim. |
|
|
|
|
intoK
Apprentice
Joined: 18 Feb 2007
Posts: 190
|
Posted: Sun Nov 30, 2008 8:45 am
|
http://www.faqs.org/rfcs/rfc855.html
| Quote: |
The first step, agreeing to discuss the parameters, takes place in
the normal manner; one party proposes use of the option by sending a
DO (or WILL) followed by the option code, and the other party accepts
by returning a WILL (or DO) followed by the option code. Once both
parties have agreed to use the option, subnegotiation takes place by
using the command SB, followed by the option code, followed by the
parameter(s), followed by the command SE. Each party is presumed to
be able to parse the parameter(s), since each has indicated that the
option is supported (via the initial exchange of WILL and DO).
|
or clearly stated here
http://www.faqs.org/rfcs/rfc1143.html
| Quote: |
It MUST NOT initiate a
DO/WILL negotiation for an already enabled option or a DONT/WONT
negotiation for a disabled option.
|
|
|
|
|
|
Nick Gammon
Adept
Joined: 08 Jan 2001
Posts: 255
Location: Australia
|
Posted: Sun Nov 30, 2008 8:32 pm
|
OK thanks.
However my problem with that page is its vagueness.
For example it says one party should use DO (or WILL). Well, which is it? DO? or WILL?
My interpretation follows a lengthy search of more detail, months ago. One I found was here:
http://binaryhole.blogspot.com/2006/12/bh-1-telnet-protocol-explained.html
| Quote: |
The first set of commands normally sent are DO's, DONT's, WILL's, and WONT's. The following are the rules for these command sequences.
Sender Receiver Implication
WILL DO The sender would like to use a certain option if the receiver can handle it. The receiver says it can support the option. Option is now in effect
WILL DONT The sender would like to use a certain option if the receiver can handle it. The receiver says it cannot support the option. Option is not in effect.
DO WILL The sender requests that the receiver use a certain option. The receiver says it can support the option. Option is now in effect.
DO WONT The sender requests that the receiver use a certain option. The receiver says it cannot support the option. Option is not in effect.
WONT DONT The sender will not use a certain option. Option disabled. DONT is only valid response.
DONT WONT The sender requests that the receiver does not use a certain option. Option disabled. WONT is only valid response.
|
Note the more explicit clarification that WILL is used if the sender is querying if the receiver can handle an option. (eg. IAC WILL 102 : can I send 102 TO you?).
Then the further specification that DO is used if the sender is prepared to receive that option. (eg. IAC DO 102 : I can receive 102, will you send it?).
I proposed to Lasher late last year that we adopt the system of doing both, as described in my earlier post, as I could see four possible scenarios, not just two:
- Neither client nor server would handle the protocol
- The server could handle it, but not the client (eg. unsupported client, earlier version)
- The client could handle it, but not the server (eg. test port, different MUD)
- Both could handle it
The two-way specification handles all those cases.
RFC 855 goes on to say:
| Quote: |
Designers of options requiring "subnegotiation" must take great care
to avoid unending loops in the subnegotiation process. For example,
if each party can accept any value of a parameter, and both parties
suggest parameters with different values, then one is likely to have
an infinite oscillation of "acknowledgments" (where each receiver
believes it is only acknowledging the new proposals of the other).
|
This seems to me to be an acknowledgement that both sides might send both DO and WILL, and thus care needs to be taken that you do not get into such a loop. In MUSHclient, for example, there is a specific test that you do not keep replying DO repeatedly to a WILL query for a particular option.
Another page ( http://en.kioskea.net/contents/internet/telnet.php3 ) says something similar in different words:
| Quote: |
The Telnet protocol specifications make it possible to take into account the fact that certain terminals can offer additional services, not defined in the basic specifications (but in accordance with the specifications), so as to be able to use advanced functions. This functionality is reflected in terms of options. The Telnet protocol therefore offers a system of option negotiations enabling the use of advanced functions in the form of options on either side by initiating requests for its authorisation from the remote system.
The Telnet options separately affect each direction of the data channel. So, each end is able to negotiate the options, i.e. to define the options that it:
- wants to use (DO)
- refuses to use (DON'T)
- wants the other end to use (WILL)
- refuses that the other end use (WON'T)
In this way, each party can issue a request for an option to be used. The other party must then respond as to whether or not it accepts the use of the option. Where the request relates to the deactivation of an option, the recipient of the request must not refuse so as to be completely compatible with the NVT model.
|
Note again that "wants to use" and "wants the other end to use" are different things.
I thought it was entirely possible that the server might accept option 102, however because the player was using earlier versions of supported clients, or unsupported clients, that they could only send the code (eg. please turn on mapper tags) by using a raw packet, but not accept option 102 (eg. server says "player is AFK now"). |
|
|
|
|
Nick Gammon
Adept
Joined: 08 Jan 2001
Posts: 255
Location: Australia
|
|
|
|
|
intoK
Apprentice
Joined: 18 Feb 2007
Posts: 190
|
Posted: Sun Nov 30, 2008 11:04 pm
|
thy indeed are vague, rtfm era n all...
as far as i understand it, DO and WILL are there only to support master-client protocols
however, when you look into different protocols specifications trough rfc's actually both methods are used - but double negotiation only when it makes sense to do so, fe. binary over text
anyway,
| Quote: |
* Neither client nor server would handle the protocol
* The server could handle it, but not the client (eg. unsupported client, earlier version)
* The client could handle it, but not the server (eg. test port, different MUD)
* Both could handle it
The two-way specification handles all those cases. |
so can one way negotiation
| Quote: |
There is a link on that page to one of my release notes pages, which explicitly describes the DO/WILL protocol expected.
There was absolutely no intention by Lasher or me that any of this stuff should be secret or obscure, hence the extensive documentation.
|
problem is apparently other muds using telnet options already set up standard for that long ago |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Mon Dec 01, 2008 6:16 pm
|
Yes, the protocol documents can be vague and complicated. In zMUD and CMUD, I specifically ignore any second negotiation of the same option, because my understanding of the protocol is the same as what intoK has already posted, and there are also some MUDs out there who get this all wrong and you will get into an infinite loop if you respond to both. That is why I suggested that Lasher picks one and doesn't send both.
I have never seen any other actual telnet server implementation that sends both. So I think intoK and I are understanding the protocol correctly.
Unless you know of a MUD client that *requires* sending both, it really needs to be changed to just send WILL or DO and not both. Again, as intoK mentioned, there is no need to negotiate both unless there is really a reason to do so. There aren't that many MUD clients that even support telnet options, so unless MUSHclient has a need for both to be sent (which it shouldn't), then just stick with the simpler standard and don't try to make this more complicated.
All I know is that zMUD/CMUD used to allow for multiple negotiation of the same option. But then I ran into a MUD somewhere (and I don't remember who it was unfortunately) that created a negotiation infinite loop. So in zMUD/CMUD, if you have already done a successful DO/WILL then it ignores any further WILL message from the MUD, and if you have done a WILL/DO negotiation, then zMUD/CMUD ignores any additional DO from the MUD.
As intoK posted from RFC 1143:
| Quote: |
It MUST NOT initiate a
DO/WILL negotiation for an already enabled option or a DONT/WONT
negotiation for a disabled option. |
And I think that is pretty clear. Remember that the RFCs are the absolute authority on this, and that later numbered RFCs superceed earlier numbers. So the information in RFC 1143 takes precedence over RFC 855. I don't trust most blog sites on complicated stuff like this. Use the RFCs, and look at the reference implementations for telnet.
But I think the solution to this is pretty simple. Unless there is a good reason for sending both negotiations, why do it? It just makes it more likely that you will get into a negotiation loop with clients that do not handle telnet options properly. |
|
|
|
|
Nick Gammon
Adept
Joined: 08 Jan 2001
Posts: 255
Location: Australia
|
Posted: Mon Dec 01, 2008 8:32 pm
|
RFC 1143 states (emphasis added):
| Quote: |
Options are in almost all cases negotiated separately for each side of the connection. The option on one side is separate from the option on the other side. In this document, "the" option referred to by a DONT/WONT or DO/WILL is really two options, combined only for semantic convenience. Each sentence could be split into two, one with the words before the slash and one with the words after the slash.
|
It can't get much clearer than that. There are two sides to the connection. One may support something, one may not. In the case in point, I was trying to allow for the situation where, when we implemented the option 102, that older clients may be able to send a subnegotiation for 102 (with a raw packet send which some clients support), but not receive one - as that would probably require low-level changes to how the client interpreted out-of-band telnet negotiation.
Thus the double negotiation:
- I don't understand protocol 102
- I can send it but not receive it
- I can receive it but not send it
- I can do both
As for this sentence in RFC 1143:
| Quote: |
It MUST NOT initiate a DO/WILL negotiation for an already enabled option or a DONT/WONT negotiation for a disabled option. It MUST NOT respond to receipt of such a negotiation.
|
I have a different interpretation to what you are putting on it.
If the server says to the client IAC DO 102 (will you send me protocol 102) that is a different question to IAC WILL 102 (can you process it if I send 102 to you?).
Thus we are not negotiating an already enabled option, we are negotiating a different option (ie. a different direction). Remember the sentence from the same RFC: "The option on one side is separate from the option on the other side.".
| Zugg wrote: |
Remember that the RFCs are the absolute authority on this, and that later numbered RFCs superceed earlier numbers.
|
The status of RFC 855 is "standard", the status of RFC 1143 is "experimental" so I don't know if I would absolutely accept this. |
|
|
|
|
intoK
Apprentice
Joined: 18 Feb 2007
Posts: 190
|
Posted: Mon Dec 01, 2008 10:20 pm
|
| Quote: |
| I was trying to allow for the situation where, when we implemented the option 102, that older clients may be able to send a subnegotiation for 102 (with a raw packet send which some clients support), but not receive one - as that would probably require low-level changes to how the client interpreted out-of-band telnet negotiation. |
if the client and server was telnet compliant and you manually send say DO, server responds WILL, client interprets as request and responds WONT... see where its going?
thankfully aardwolf is not telnet compliant and it processes data sent over telnet options without enabling the channel, oh, what was the justification again?
sorry mate, i fail to see why youre so hell bent on two way negotiation |
|
|
|
|
cazador
Apprentice
Joined: 08 Dec 2005
Posts: 108
|
Posted: Mon Dec 01, 2008 10:44 pm
|
I can understand both interpretations of the protocol. For the short term, maybe we can get Aardwolf to put a few lines in there help section on enabling 102 protocol negotiation with cmud, until a we come to a common understanding of the protocol. Before this discussion gets to heated and feelings get hurt. I want to thank both the Aardwolf staff and zugg for working with each other on figure this out. I believe this protocol idea can have some very cool uses, and can help reduce the bandwith needed to mud. Thank you Lasher/aardwolf, for the innovative idea.
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Mon Dec 01, 2008 11:13 pm
|
I agree with intoK that I really don't see why we are stuck on this.
Nick: You say:
| Quote: |
| I was trying to allow for the situation where, when we implemented the option 102, that older clients may be able to send a subnegotiation for 102 |
What "older clients" are you talking about? Do you have a specific case where this is needed with a specific client? How about the case of existing and popular clients such as zMUD and CMUD who might break because they are trying to prevent negotiation loops? So let me get this straight...you added this just in case someone might need to use it in some other client, but ignored how it actually DOES work in an existing and popular client?
I think we can all agree that the protocol is un-clear on this whole thing and there are two different interpretations. However, the interpretation that Nick is using makes it MUCH MUCH easier to get into an infinite telnet negotiation loop. As I said, I've already run across MUDs in the past that cause such a loop. So why are we arguing about this?
RFC 855 is a "standard" because it gives the actual protocol specification. RFC 1143 is "experimental" because it simply proposes an implementation to the option negotiation in the original spec. But I'm not going to get into semantics on this.
But I have to continue to agree with intoK on this:
| Quote: |
| sorry mate, i fail to see why youre so hell bent on two way negotiation |
You still have not given me one good reason WHY Aardwolf needs to send out both negotiations. I'll say it again: why possibly break an existing and very popular client just for some obscure possibility that someone else *might* want to do with some unknown older client?
I have never seen *any* double option negotiation like you are doing here. Not with any other telnet option. We don't do it for MXP, or MSP, and I don't see any telnet server doing it for telnet emulations, naws, or any other common option that I can find. |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Dec 02, 2008 1:39 am
|
Or, even if everyone wants to be stubborn and retain the current two-way negotiation, then PLEASE just change the order in which Aardwolf sends out the option requests. If Aardwolf sent IAC WILL 102 and then IAC DO 102, then CMUD would respond to the first negotiation correctly with DO instead of responding with WILL like it does now.
With that SIMPLE CHANGE, Aardwolf could have both the two-way negotiation that you seem to be hooked on without impacting CMUD users. |
|
|
|
|
Nick Gammon
Adept
Joined: 08 Jan 2001
Posts: 255
Location: Australia
|
Posted: Tue Dec 02, 2008 4:47 am
|
| Zugg wrote: |
What "older clients" are you talking about?
|
Any earlier version of MUSHclient, zMUD, cMUD that didn't support incoming telnet negotiation for protocol 102. In other words, almost the entire installed user base of those clients.
| Zugg wrote: |
So let me get this straight...you added this just in case someone might need to use it in some other client, but ignored how it actually DOES work in an existing and popular client?
|
No, I didn't ignore anything. I didn't know exactly how it worked in zMUD/cMUD - how could I?
I apologize for any confusion I may have caused.
| Zugg wrote: |
Yes, the protocol documents can be vague and complicated.
|
At least we are agreed on that point. |
|
|
|
|
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5182
|
Posted: Tue Dec 02, 2008 12:31 pm
|
I haven't read the full RFC yet, but from the excerpts I gather a few simple things.
1. The negotiation protocol does not actually support a negotiation that allows each side to behave differently in regards to an option. This is because clear meanings are never assigned to the 4 different values. It is not clear which of the DO or WILL indicates a willingness to receive.
2. Linguistically DO should be replied to with either DO or DONT, and WILL should be replied to with WILL or WONT. The protocol does not require that little piece of language. Without that simple thing there is no possible way to even have a negotiation that concludes with 1 side sending on an option and the other side not sending on that option.
3. You want to do this
| Code: |
Ask about option 102:
Reply from other side can be 1 of 4 possibilities:
I don't understand protocol 102
I can send it but not receive it
I can receive it but not send it
I can do both |
Examining that we find that in order to do it 1 negotiation item is a request, and 4 different responses are required. The specification obviously does not have this. Furthermore each side of the communication would need to have a specific period to make requests, by this I mean the negotiation protocol would have to have a sequence that says "I am done asking about stuff. Do you have anything to ask for?" Again that is not in the protocol.
My thoughts on the correct way to do it if you want those responses are first negotiate the suboption. With the thought in mind that all negotiations are a "should we talk with this channel", and the sum result of that is either yes or no. Then use an IAC SE ... SB group to further negotiate how the channel is used. |
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
 |
|
|
Rorso
Wizard
Joined: 14 Oct 2000
Posts: 1368
|
Posted: Tue Dec 02, 2008 12:50 pm
|
I would suggest take a look at the MCP or MXP for this instead. Preferably MXP as the "102 triggers" seem essentially to be pretty much the same idea as MXP. I am very curious where everyone get those telnet option numbers from. How do you guarantee that it is somewhat unique at all? While MCP/MXP certainly does not remove that problem, at the very least they are established protocols. MXP is more standard and work on more clients than just zMUD/cMUD and MUSHClient.
What if I make my own telnet protocol implementation that get used by a few MUDs and it happen to have a different usage of telnet option 102?
Aardwolf has created an entire MUD engine from scratch and already has support for MCCP. I do not see why MXP should not be used. They certainly have the developer skill needed to do it. Right now the community is going on a very dangerous path. Everyone is creating their own extension protocols and it will become a nightmare for clients to focus on supporting any protocol properly.
To summarize:
1. This "102 triggers" is not a standard protocol.
2. Each client must implement it if it wants to make use of it properly.
3. Had Aardwolf supported MXP then all MXP compatible clients would automatically be able to use many of the features.
4. Upon connecting to Aardwolf right now I notice 91% of the players have Mud Client Compression active. To me this suggest most people use reasonable modern clients. Very likely clients capable of handling MXP.
5. Use MXP and let's cooperate to create standards that everyone can benefit from. |
|
|
|
|
Tarn
GURU
Joined: 10 Oct 2000
Posts: 867
Location: USA
|
Posted: Tue Dec 02, 2008 4:43 pm
|
| Zugg wrote: |
I have never seen any other actual telnet server implementation that sends both. So I think intoK and I are understanding the protocol correctly.
|
As an example, RFC 858, suppression of Go Ahead, specifically says that even though it's likely that when one end wants to suppress GA, it's likely that both will, the behavior at each end must still be negotiated independently.
| Quote: |
Therefore, it is desirable to have a TELNET option with which parties
involved can agree that one or the other or both should suppress
transmission of GO AHEADS.
...
It seems probable that the parties to the TELNET connection will
suppress GO AHEAD in both directions of the TELNET connection if GO
AHEAD is suppressed at all; but, nonetheless, it must be suppressed
in both directions independently.
|
Pragmatically, I think that an experimental (fully implemented by one server and one client) telnet option should probably use suboption negotiation to handle details. It's finer-grained and allows the use of the option to evolve without using up another telnet option number if it turns out that version 2 isn't backwards compatible with version 1 (or just supporting an older server/client gracefully). That approach is also more friendly for anyone implementing partial support.
-Tarn |
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Dec 02, 2008 6:11 pm
|
OK, I got really distracted by this and decided to spend the time to go back and actually read all of the relevant RFCs in detail (it's been years since I read them in detail). As we have agreed, the original RFC 854 (telnet) and 855 (telnet options) are pretty unclear. However, on re-reading RFC 1143 which discusses an actual implementation of option negotiation, I can see where it clarifies that each side of the connection can have it's own value for an option. It specifically says:
| Quote: |
There are two sides, we (us) and he (him). We keep four
variables:
us: state of option on our side (NO/WANTNO/WANTYES/YES)
usq: a queue bit (EMPTY/OPPOSITE) if us is WANTNO or WANTYES
him: state of option on his side
himq: a queue bit if him is WANTNO or WANTYES |
This makes it very clear that for each telnet option, each side of the connection has it's own "state" for this option. So yes, I can agree that it is possible for option 102 to have it enabled on one end, but disabled on the other end. In my previous thinking, I had imagined that each telnet option only had a *single* value and that each side was trying to agree on what that value should be. But now I see that each side of the connection can have it's own value.
In the zMUD/CMUD implementation, I only keep track of a single "value" for an option. That is why zMUD/CMUD ignores the DO 102 that is sent after the WILL 102 because zMUD/CMUD thinks that this option is already enabled, so it ignore the additional DO request. So I agree that I should be keeping track of the separate state of the server and not just keeping a single value for the option. It's possible that I will fix this in a future version of CMUD.
However, right now I'm in the middle of the mapper rewrite for CMUD. And this Telnet Option stuff can be very tricky to implement properly and I don't want to break anything. I will need to go back and find the non-compliant MUD codebase that caused the option negotiation loops in the past when I worked on this system years ago with zMUD. I don't want to do anything that might cause CMUD to stop working on certain MUDs.
I go back to my request from above to Aardwolf: Please just change the order in which you send the option negotiation. Instead of sending DO 102 and then WILL 102, PLEASE change this to send WILL 102 followed by DO 102. This SIMPLE CHANGE will allow existing versions of CMUD to work with Aardwolf.
So let's be done with this discussion. It has been very distracting to me. I feel like we have been talking about "theoretical physics" rather than "practical engineering". From a practical point of view, the current telnet option implementation in CMUD/zMUD works fine. It just doesn't handle any telnet option where each side might have a different value of an option...it assumes a single value for the option that the client/server agree upon. This difference in implementation normally has no problem since no telnet options used by MUDs require having different client/server values for an option.
I agree that from the "theorectical" point of view, the implementation in CMUD needs to be updated in the future. But the intent of the MUD server (Aardwolf) should be to make their new features as accessible as possible, so I'll recommend that Aardwolf does not depend upon having a different telnet option value on the client/server and just implements option 102 like any other MUD telnet option (MXP, MCCP, etc). This will make it more compatible with existing MUD clients, as well as making it easier on other MUD clients in the future. The more complicated you make your protocol option, the fewer people who will implement it. |
|
|
|
|
Tarn
GURU
Joined: 10 Oct 2000
Posts: 867
Location: USA
|
Posted: Tue Dec 02, 2008 6:43 pm
|
| Zugg wrote: |
I will need to go back and find the non-compliant MUD codebase that caused the option negotiation loops in the past when I worked on this system years ago with zMUD.
|
Some years ago (5+), depending on preference settings, the Iron Realms servers could get into a really nasty loop with zMud. I forget which option it was that got pinged back and forth during the entire period the connection was active. The problem wasn't visible as an end user; I found it because I was running through a proxy and the consumed bandwidth numbers looked out of whack. I think the problem went away a few months later. Back then I was on dialup, so I don't know if the extra latency was a factor in causing the problem.
-Tarn |
|
|
|
|
OCedHrt
Newbie
Joined: 05 Dec 2008
Posts: 3
|
Posted: Fri Dec 05, 2008 4:23 pm
|
So I can't even get the trigger to trigger:
| Code: |
<trigger name="Enable" type="Telnet" param="102" priority="610" newline="false" prompt="true" id="62">
<value>#sendraw %char(255)%char(253)%char(102)</value>
</trigger>
|
|
|
|
|
|
cazador
Apprentice
Joined: 08 Dec 2005
Posts: 108
|
Posted: Fri Dec 05, 2008 6:28 pm
|
I modified my password trigger to be the following and it works for me
| Code: |
<trigger priority="50" case="true" verbatim="true" newline="false" prompt="true" id="5">
<pattern>Password: </pattern>
<value>#PW;
#sendraw %char(255)%char(253)%char(102)
#T- autolog</value>
</trigger>
|
|
|
|
|
|
OCedHrt
Newbie
Joined: 05 Dec 2008
Posts: 3
|
Posted: Mon Dec 08, 2008 3:26 am
|
| cazador wrote: |
I modified my password trigger to be the following and it works for me
| Code: |
<trigger priority="50" case="true" verbatim="true" newline="false" prompt="true" id="5">
<pattern>Password: </pattern>
<value>#PW;
#sendraw %char(255)%char(253)%char(102)
#T- autolog</value>
</trigger>
|
|
Thanks. But Aardwolf sends back a slew of garbage characters in response. |
|
|
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
