Messages

1

Yate users hangout place / Play wave on chan.disconnected

« on: February 26, 2018, 05:52:52 AM »

Hello.

I want to play different slin files on to inform the caller about the reason of disconnection the other side: wrong number, unavailable and so on.

I watch chan.disconnected message and use chan.masquerade to play the message with options:
{
  'message': 'call.execute',
  'id': params['id'],
  'callto': 'wave/play//share/yate/sounds/%s.slin' % sound
}

If the provider sent progress message before (ring tones), the rtp is up and busy message on disconnect is played. If there is no progress and earlymedia, no any sound is hear (but msgsniffer shows all good and message was played).

What I've forgottent to make this work?

2

Yate bugs / Re: [fix] Wrong killing of extmodule

« on: May 15, 2017, 04:17:35 AM »

Yes, I use extmodule command flow but it must (can) be improved.

If an external script wants to know when yate is going to stop it may install a handler for engine.stop message.

For channel scripts you may install message handlers to check termination (see chan.disconnected)

Why do you think 2 different methods better than 1 in my solution? In my view it looks like a crutch. First one (engine.stop message) doesn't cover script restarting from CLI. Second one (chan.disconnected message) doesn't work at all due to CallEndpoint destruction. I installed handler for it (extmodule.cpp from 5.5.0 version without changes), but it doesn't work:

Code: [Select]

2017-05-15_09:48:27.212239 <sip:INFO> 'udp:0.0.0.0:5060' received 418 bytes SIP message from 85.142.148.80:5060 [0x140add0]
------
BYE sip:200@37.140.188.160:5060 SIP/2.0
Via: SIP/2.0/UDP 85.142.148.80:5060;rport;branch=z9hG4bKPj11500195-5795-455d-8971-2d13f3b0faf1
From: "laptop" <sip:laptop@talk37.ru>;tag=97bbbc5f-41bb-4abe-a293-775d02e33440
To: <sip:200@37.140.188.160>;tag=1893302431
Call-ID: b98b4e73-cd84-4a69-b4dc-a1430ce5af6a
CSeq: 32719 BYE
Reason: Q.850;cause=16
Max-Forwards: 70
User-Agent: ruVoIP.net PBX
Content-Length:  0

------
2017-05-15_09:48:27.222087 <sip:INFO> 'udp:0.0.0.0:5060' sending code 100 0x7f3590012180 to 85.142.148.80:5060 [0x140add0]
------
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 85.142.148.80:5060;rport=5060;branch=z9hG4bKPj11500195-5795-455d-8971-2d13f3b0faf1;received=85.142.148.80
From: "laptop" <sip:laptop@talk37.ru>;tag=97bbbc5f-41bb-4abe-a293-775d02e33440
To: <sip:200@37.140.188.160>;tag=1893302431
Call-ID: b98b4e73-cd84-4a69-b4dc-a1430ce5af6a
CSeq: 32719 BYE
Server: YATE/5.5.0
Content-Length: 0

------
2017-05-15_09:48:27.222179 <yrtp:INFO> YRTPWrapper::terminate() [0x7f358c011fc0]
2017-05-15_09:48:27.222205 >>> DataTranslator::detachChain(0x7f358c012610,0x7f358c014190)
2017-05-15_09:48:27.222212   >>> DataTranslator::detachChain(0x7f358c012610,0x7f3590012820)
2017-05-15_09:48:27.222216   <<< DataTranslator::detachChain
2017-05-15_09:48:27.222225 <<< DataTranslator::detachChain
2017-05-15_09:48:27.222229 >>> DataTranslator::detachChain(0x7f358c011840,0x7f358c017340)
2017-05-15_09:48:27.222234   >>> DataTranslator::detachChain(0x7f358c011840,0x7f3590013950)
2017-05-15_09:48:27.222238   <<< DataTranslator::detachChain
2017-05-15_09:48:27.222242 <<< DataTranslator::detachChain
2017-05-15_09:48:27.222253 <ALL> Cleaning up RTP 0x7f358c012170 [0x7f358c011fc0]
2017-05-15_09:48:27.222333 <ALL> ExtModChan::disconnected() '(null)' [0x7f358c014040]
2017-05-15_09:48:27.222345 <ALL> ExtModConsumer::~ExtModConsumer() [0x7f358c014190] total=53120
2017-05-15_09:48:27.222358 >>> ExtModChan::~ExtModChan() [0x7f358c014040]
2017-05-15_09:48:27.222374   <ALL> ExtModReceiver::die() pid=9064 dead=no [0x7f358c013d80]
2017-05-15_09:48:27.222382   <ALL> ExtModReceiver::die() waiting for pid=9064 to die [0x7f358c013d80]
2017-05-15_09:48:27.228405   <INFO> ExtModReceiver::die() pid=9064 did not exit? [0x7f358c013d80]
2017-05-15_09:48:27.232148   <ExtModule:WARN> Read error 9 on 0x7f35840011f0 [0x7f358c013d80]
2017-05-15_09:48:27.232287   <WARN> Process 9064 has not exited on closing stdin - we'll kill it
2017-05-15_09:48:27.232379   <WARN> Process 9064 has still not exited yet?
2017-05-15_09:48:27.233520   <ALL> ExtModSource [0x7f358c011840] end of data total=16000
2017-05-15_09:48:27.233550   <ALL> ExtModSource::~ExtModSource() [0x7f358c011840] total=16000
2017-05-15_09:48:27.233581   <ALL> ExtModReceiver::~ExtModReceiver() pid=0 [0x7f358c013d80]
2017-05-15_09:48:27.233589   <ALL> ExtModReceiver::die() pid=0 dead=yes [0x7f358c013d80]
2017-05-15_09:48:27.233595 <<< ExtModChan::~ExtModChan()
2017-05-15_09:48:27.233654 <sip:INFO> 'udp:0.0.0.0:5060' sending code 200 0x7f3590013950 to 85.142.148.80:5060 [0x140add0]
------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 85.142.148.80:5060;rport=5060;branch=z9hG4bKPj11500195-5795-455d-8971-2d13f3b0faf1;received=85.142.148.80
From: "laptop" <sip:laptop@talk37.ru>;tag=97bbbc5f-41bb-4abe-a293-775d02e33440
To: <sip:200@37.140.188.160>;tag=1893302431
Call-ID: b98b4e73-cd84-4a69-b4dc-a1430ce5af6a
CSeq: 32719 BYE
P-RTP-Stat: PS=60,OS=7500,PR=166,OR=26560,PL=0
Server: YATE/5.5.0
Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, INFO
Content-Length: 0

------
And I believe Process 9064 has not exited on closing stdin - we'll kill it -- it's not what we want to see in log on the normal case.

My solution allows to write extmodules in a common case more likely to cpp modules: you can do some operations on module constructor and module destructor as well. Moreover I fixed catching chan.disconnected message as well.

3

Yate bugs / Re: [fix] Wrong killing of extmodule

« on: May 11, 2017, 09:43:25 AM »

Any suggestions?

4

Yate bugs / Re: [fix] Wrong killing of extmodule

« on: May 10, 2017, 06:45:44 AM »

It's 2 improvements: waiting of termination and notification about starting termination. External scripts can be large and complicated. Not only about Yate going to stop but about the external module going to stop it's important to know to close their resources and unregister their lines and accounts (notify SIP clients about loging out). Another case -- channel/playrec external modules started and terminated by Yate for every call and it is also important not only to get notification about quiting but to close their resources properly as well.

Killing by SIGTERM is present on exceptions and wrong behavior.

5

Yate bugs / [fix] Wrong killing of extmodule

« on: May 09, 2017, 06:40:04 PM »

Some time ago I said about the bug of terminating external module. I've fixed it and changed the logic of quiting from external module as follows.

If exit is initiated from external module it just close their stdout and finish running. Yate as soon as get EOF trying to check is pid terminated or not and waiting up to m_timeout. If EOF was get from socket nothing to wait.

If exit initiated from Yate the engine send to external module %%<quit message and waiting EOF/pid termination as described above.

%%>quit from external module to Yate I've make redundant. But it's possible to interpret it as a "kill me" signal without waiting and without %%<quit as a reply. Let me know how it must be.

The approach let external modules to handle quit messages. It is useful for example if external module registers external lines through user.login message: it's may be important to unregister lines on module quiting (operation=logout).

I'm new in Yate and would like how can I share described improvements? How can I commit it and to know is it a needed feature?

6

Yate bugs / TCP external modules and Engine::dispatch

« on: May 09, 2017, 07:37:37 AM »

I have the following function which returns CallEndpoint by channel id:

Code: [Select]

static CallEndpoint* locateChan(const String& id, bool peer = false)
{
    if (id.null())
return 0;
    Message m("chan.locate");
    m.addParam("id",id);
    if (!Engine::dispatch(m))
return 0;
    CallEndpoint* ce = static_cast<CallEndpoint*>(m.userObject(YATOM("CallEndpoint")));
    if (!ce)
return 0;
    return peer ? ce->getPeer() : ce;
}
This code is used from ExtModReceiver::processLine as follows. And this works if external module is a pipe script, but doesn't work if it a TCP socket. I tried to debug it without success: Engine::dispatch doesn't work.

The difference which I've found is TCP extmodule starts from an additional thread of ExtListener which is a server for processing incoming connections (it's true approach). Can this broke Engine::dispatch? Or may be other reasons?

7

Yate bugs / Re: Picking up an endpoind from peer of extmodule crashes Yate

« on: May 04, 2017, 07:42:58 AM »

Yes, there is no problems if I read and lose input audio data from external module, or use 'play' mode instead of 'playrec'. Thank you!

I suppose, I can make a circular buffer on an external module side; maybe it will be better.

And what about killing external module? How to catch termination in external module correctly or to fix extmodule to wait for a reasonable time for termination? I suppose the following is not a good solution:

Code: [Select]

Unloading external module 'monitor.py' ''
2017-05-04_13:41:08.492771 <INFO> ExtModReceiver::die() pid=15024 did not exit? [0x7fc580001070]
2017-05-04_13:41:08.496951 <ExtModule:WARN> Read error 9 on 0x7fc590003d10 [0x7fc580001070]
2017-05-04_13:41:08.497051 <WARN> Process 15024 has not exited on closing stdin - we'll kill it
2017-05-04_13:41:08.497540 <WARN> Process 15024 has still not exited yet?

8

Yate bugs / Re: Picking up an endpoind from peer of extmodule crashes Yate

« on: May 03, 2017, 09:37:26 AM »

I made the following changes:

Code: [Select]

unsigned long ExtModConsumer::Consume(const DataBlock& data, unsigned long timestamp, unsigned long flags)
{
    if ((m_str) && !data.null()) {
Debug(DebugTest,"ExtModConsumer::Consume ENTER");
m_str->writeData(data);
m_total += data.length();
Debug(DebugTest,"ExtModConsumer::Consume EXIT");
return invalidStamp();
    }
    return 0;
}
The log is:

Code: [Select]

2017-05-03_15:31:13.431325 <TEST> ExtModConsumer::Consume ENTER
2017-05-03_15:31:13.431346 <TEST> ExtModConsumer::Consume EXIT
2017-05-03_15:31:13.466999 <TEST> ExtModConsumer::Consume ENTER
2017-05-03_15:31:13.467037 <TEST> ExtModConsumer::Consume EXIT
2017-05-03_15:31:13.467045 <TEST> ExtModConsumer::Consume ENTER
2017-05-03_15:31:16.057263 <sip:INFO> 'udp:0.0.0.0:5060' received 1351 bytes SIP message from 85.142.148.80:5060 [0x9b2dd0]
------
INVITE sip:200@37.140.188.160:5060 SIP/2.0
Via: SIP/2.0/UDP 85.142.148.80:5060;rport;branch=z9hG4bKPjb7b30d52-e99d-4776-9c6b-9c29aadb0b35
...
...
2017-05-03_15:31:16.063444 <INFO> Could not route call to '200' in context 'default', wasted 169 usec
!!! call_route: {'sip_user-agent': 'ruVoIP.net PBX', 'ip_host': '85.142.148.80', 'billid': '1493825410-3', 'ip_port': '5060', 'transport': 'RTP/AVP', 'antiloop': '19', 'media_video': 'yes', 'sip_content-type': 'application/sdp', 'sip_x-cid': 'KcffpUKcxxDt37oI2L77-hrHzsb7Moa-', 'sdp_maxptime': '20', 'sip_callid': '42c9652c-980e-4a17-bb77-8dbb8f5dcb5f', 'sip_from': 'sip:laptop@talk37.ru', 'callername': 'laptop', 'sip_allow': 'OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER', 'rtp_addr': '85.142.148.80', 'sdp_sendrecv': '', 'rtp_port_video': '25680', 'direction': 'incoming', 'transport_video': 'RTP/AVP', 'module': 'sip', 'handlers': 'regexroute:100,sip:100,regexroute:100', 'answered': 'false', 'device': 'ruVoIP.net PBX', 'sip_min-se': '90', 'sip_session-expires': '1800', 'formats_video': '', 'sip_contact': '<sip:asterisk@85.142.148.80:5060>', 'sip_supported': '100rel, timer, replaces, norefersub', 'rtp_forward': 'possible', 'formats': 'alaw', 'ip_transport': 'UDP', 'id': 'sip/4', 'rtp_rfc2833': '101', 'caller': 'laptop', 'address': '85.142.148.80:5060', 'media': 'yes', 'sip_uri': 'sip:200@37.140.188.160:5060', 'called': '200', 'sip_to': '<sip:200@37.140.188.160>', 'callid': 'sip/42c9652c-980e-4a17-bb77-8dbb8f5dcb5f/cd69bf93-880a-4da6-9a74-754ae71f7408/', 'status': 'incoming', 'rtp_port': '25486', 'sdp_video_sendrecv': ''} | {('200', 'laptop'): 'sip/2'} | {'sip/2': ('200', 'laptop')}
2017-05-03_15:31:16.067878 <INFO> Choosing offered 'audio' format 'alaw' [0x7fc588012b10]
2017-05-03_15:31:16.067888 <sip/4:NOTE> Formats for 'audio' changed to 'alaw' [0x7fc588012090]
2017-05-03_15:31:16.067924 >>> DataTranslator::detachChain(0x7fc584006e00,0x7fc59400fae0)
2017-05-03_15:31:19.000091   <engine:MILD> Creating new message dispatching thread (1 running)
2017-05-03_15:31:21.000020   <engine:MILD> Creating new message dispatching thread (2 running)
2017-05-03_15:31:23.000059   <engine:MILD> Creating new message dispatching thread (3 running)
2017-05-03_15:31:25.000087   <engine:WARN> Creating new message dispatching thread (4 running)
2017-05-03_15:31:27.000143   <engine:WARN> Creating new message dispatching thread (5 running)
2017-05-03_15:31:29.000109   <engine:WARN> Creating new message dispatching thread (6 running)
Supervisor: killing unresponsive child 12900
Yate (12935) is starting Wed May  3 15:31:30 2017

As you can see no EXIT before Yate hangs up. And if the problem is not happened the log is:

Code: [Select]

2017-05-03_15:31:04.590200 <TEST> ExtModConsumer::Consume ENTER
2017-05-03_15:31:04.590227 <TEST> ExtModConsumer::Consume EXIT
2017-05-03_15:31:04.590236 <TEST> ExtModConsumer::Consume ENTER
2017-05-03_15:31:04.590245 <TEST> ExtModConsumer::Consume EXIT
2017-05-03_15:31:04.601540 <sip:INFO> 'udp:0.0.0.0:5060' received 1349 bytes SIP message from 85.142.148.80:5060 [0x9b2dd0]
------
INVITE sip:200@37.140.188.160:5060 SIP/2.0
Via: SIP/2.0/UDP 85.142.148.80:5060;rport;branch=z9hG4bKPjab09198c-6c90-4b01-821d-5dfd05972ad3
I.e. EXIT is appeared. Sure, I really don't know why it wasn't EXITed for 2.6 seconds when Yate hangs up...

9

Yate bugs / Re: Picking up an endpoind from peer of extmodule crashes Yate

« on: May 03, 2017, 08:01:12 AM »

Yes, it happened! Since the 2nd recall (in log you can see what it was in the normal case).

See attachments.

10

Yate bugs / Re: Picking up an endpoind from peer of extmodule crashes Yate

« on: May 03, 2017, 05:48:40 AM »

Let's try again from scratch.

1. Use release version Yate 5.5.0.
2. Apply only the patch extmodule.cpp.diff .
3. Recompile, run with yate -vvvvvvvvvv -C -l yate.log -c /home/yate/conf .
4. Reproduce the problem (not from 1st time; it occurs in ≈60% of cases) and wait for 30 seconds.
5. Kill yate with -6 (SIGABORT) signal to make core dump.
6. Generate backtrace: echo -e 'thread apply all bt\nquit' | gdb yate core &> yate.bt

That's it. All files is attached.

And last words about restarting the global external module. I believe it's not the right way not to wait reasonable time for terminating:

Code: [Select]

2017-05-03_11:43:30.561179 <ALL> ExtModReceiver::die() pid=11961 dead=no [0xd21c90]
Unloading external module 'monitor.py' ''
2017-05-03_11:43:30.561241 <ALL> ExtModReceiver::die() waiting for pid=11961 to die [0xd21c90]
2017-05-03_11:43:30.568744 <INFO> ExtModReceiver::die() pid=11961 did not exit? [0xd21c90]
2017-05-03_11:43:30.573032 <ExtModule:WARN> Read error 9 on 0x7fad94000940 [0xd21c90]
2017-05-03_11:43:30.573137 <WARN> Process 11961 has not exited on closing stdin - we'll kill it
2017-05-03_11:43:30.573238 <WARN> Process 11961 has still not exited yet?
2017-05-03_11:43:30.573868 <ALL> ExtModReceiver::~ExtModReceiver() pid=0 [0xd21c90]
2017-05-03_11:43:30.573880 <ALL> ExtModReceiver::die() pid=0 dead=yes [0xd21c90]
2017-05-03_11:43:30.573899 <ALL> ExtModReceiver::ExtModReceiver("monitor.py","(null)") [0x7fad7c001070]

11

Yate bugs / Re: Picking up an endpoind from peer of extmodule crashes Yate

« on: May 02, 2017, 04:01:19 PM »

Yes, I've make some changes.

First, I use release version. When I haven't reach a success I replaced extmodule.cpp from trunk. Then I add ability to use CallEndpoint by extmodules which are started by the global one: it's only one line of new code ExtModReceiver::processLine:

Code: [Select]

    if (m_setdata) {
CallEndpoint* c_chan = locateChan(m->getValue("channelid"),m->getBoolValue("channelid_peer"));
m->userData(c_chan ? c_chan : m_chan);
            }After that I started to solve the described bug and tried to add to ExtModSource methods cleanup and attached (from wavefile.cpp) - it also doesn't help.

My latest version of extmodule.cpp is attached.

12

Yate bugs / Re: Picking up an endpoind from peer of extmodule crashes Yate

« on: May 02, 2017, 02:59:04 AM »

See attachments (suppose it doesn't contain a private data; if no notify me please). It's not a crash in true understanding but it produces extra threads without success and after that (if run Yate as a service) it restarted by supervisor process. Without a supervisor process it hangs up.

Log contains some extra test outputs (from extmodule.cpp and external modules as well).

The scenario was:
1. Call from 'home' to 'mobile'.
2. Hangup 'home' leg => 'mobile' leg connects to 'noise.py' (it's a channel module).
3. Call from 'home' to 'mobile' again => not happy to picking up 'mobile' leg from 'noise.py'.
4. Since not happy hangup 'home' and 'mobile'.

To manage the call logic I use 'monitor.py' (it's a global module). I believe the external modules ('monitor.py' and 'noise.py') is correct because if 'monitor.py' runs 'call.execute' with 'callto'='tone/milliwatt' (instead of 'external/playrec/noise.py') no any bugs are happend.

Also it seems external modules don't killed in a proper way. For example on restarting external module I see the following:

Code: [Select]

2017-05-02_08:36:57.353068 <TEST> !!! ExtModReceiver::die
2017-05-02_08:36:57.353114 <ALL> ExtModReceiver::die() pid=10175 dead=no [0x191e4f0]
Unloading external module 'monitor.py' ''
2017-05-02_08:36:57.353130 <ALL> ExtModReceiver::die() waiting for pid=10175 to die [0x191e4f0]
2017-05-02_08:36:57.360740 <INFO> ExtModReceiver::die() pid=10175 did not exit? [0x191e4f0]
2017-05-02_08:36:57.360768 <TEST> !!! ExtModReceiver::flush
2017-05-02_08:36:57.361942 <TEST> !!! ExtModReceiver::cleanup
2017-05-02_08:36:57.361999 <WARN> Process 10175 has not exited on closing stdin - we'll kill it
2017-05-02_08:36:57.362118 <WARN> Process 10175 has still not exited yet?
2017-05-02_08:36:57.365940 <ALL> ExtModReceiver::destruct() pid=0 [0x191e4f0]
2017-05-02_08:36:57.365961 <TEST> !!! ExtModReceiver::die
2017-05-02_08:36:57.365966 <ALL> ExtModReceiver::die() pid=0 dead=yes [0x191e4f0]
2017-05-02_08:36:57.366000 <ALL> ExtModReceiver::ExtModReceiver("monitor.py","(null)") [0x7f36840010f0]
Loading external module 'monitor.py' ''
'monitor.py' handles stdin and sigint in a proper way. I don't understand in the code why we killing external (call closeOut) in 2 places: in ExtModReceiver::die and ExtModReceiver::cleanup . And in both cases we don't wait for a reasonable time (because an external module can be complicated and requires a time for proper terminating). Another question is why we don't kill by sigint signal (sigterm only in a last chance)? Since we terminate in 2 different places I don't know for sure how to fix it in a proper way as well.

13

Yate bugs / Picking up an endpoind from peer of extmodule crashes Yate

« on: May 01, 2017, 05:35:51 PM »

I'm trying to fix the bug during last days, but without success.

If I have a sip endpoint which is connected to an external plugin (in playrec mode) a try to picking it up (disconnect extmodule and connect sip endpoints each other) crashes Yate at all in 90% of cases.

The log which I see:

Code: [Select]

2017-05-01_23:17:24.413847 <INFO> Choosing offered 'audio' format 'alaw' [0x7fb840011bc0]
2017-05-01_23:17:24.413857 <sip/3:NOTE> Formats for 'audio' changed to 'alaw' [0x7fb840010990]
2017-05-01_23:17:24.413902 >>> DataTranslator::detachChain(0x7fb83c006dd0,0x7fb84c00fac0)
2017-05-01_23:17:27.000093   <engine:MILD> Creating new message dispatching thread (1 running)
2017-05-01_23:17:29.000097   <engine:MILD> Creating new message dispatching thread (2 running)
...
The normal state (if I disconnecting tone endpoint):

Code: [Select]

2017-05-01_22:36:17.464148 <yrtp:INFO> RTP starting format 'alaw' payload 8 [0x7fb840016b40]
2017-05-01_22:36:17.464172 >>> DataTranslator::detachChain(0x7fb840017190,0x7fb8300040a0)
2017-05-01_22:36:17.464177 <<< DataTranslator::detachChain
2017-05-01_22:36:17.464185 <ALL> DataTranslator::attachChain [0x7fb840017190] 'alaw' -> [0x7fb8300040a0] 'alaw' succeeded
2017-05-01_22:36:17.464190 >>> DataTranslator::detachChain(0x7fb830003ec0,0x7fb840017320)
2017-05-01_22:36:17.464193 <<< DataTranslator::detachChain
2017-05-01_22:36:17.464198 <ALL> DataTranslator::attachChain [0x7fb830003ec0] 'alaw' -> [0x7fb840017320] 'alaw' succeeded
2017-05-01_22:36:17.464270 <yrtp:INFO> Wrapper opened a hole in firewall/NAT [0x7fb840016b40]

14

Other Yate server issues / Re: Yate as a client behind a firewall

« on: September 26, 2016, 03:33:59 AM »

Super! drillhole is really work!

I saw around it, but as I use Yate in client mode I think it's enabled by default:

drillhole: bool: Attempt to drill a hole through a firewall or NAT
drillhole=disable in server mode, enable in client mode

Thank you!

15

Other Yate server issues / Re: Yate as a client behind a firewall

« on: September 23, 2016, 03:20:07 PM »

Sure.

Yes, Yate registers as a client on other server to receive calls -- it works. I use UDP (as a default option), but as I remember TCP gives the same result.

The issue is that Yate doesn't receive any audio before it sends any audio chunk to the server.

I collected Yate logs in 2 scenario, see it. First one (silent) with echo.py as is, another one (noise) with uncommented line

Code: [Select]

os.write(4, os.urandom(1024)) in echo.py .