I downloaded a routine from github about interconnection about traditional network with sdn. The program establishes ibpg peers. When I run the program, there is a problem occurred shown as follows. How can I deal with this trouble?
Since the peer closed the connection, you should check the logs and/or debug on the other side of the connection. The log file will probably explain why it didn't like your connection attempt / why it refused you.
You tagged quagga, so I assume that at least one of the side is quagga. It should be simple enough to enable some debug on the quagga cli to see what's going on.
Additionally, BGP can send notifications, notifying the peer of an error. So the connecting side should be aware of the error. This implies that the connection (TCP) was established and that the first BGP exchanges (BGP OPEN MSG) happened.
Maybe start with a tcpdump -vvv -i -s0 'host 10.10.10.1 and port 179'
Related
I think there is a simple answer to this question, but everything I find online is about preventing SSH client connections from timing out.
In this case, the client has established a connection to the server, and remains connected. Then the connection is disrupted, say the ethernet cable is unplugged, or the router is powered off.
When this happens, the client connection is not dropped.
The ssh client connection is part of a script and the line that performs the ssh login looks like this:
ssh -Nn script#example.com
The .ssh/config contains the following parameters:
Host *
ServerAliveInterval 60
ServerAliveCountMax 2
When these disconnects occur, I'd like the client ssh connection to timeout, and allow the script to attempt reconnect...
Thanks!
I guess I was wrong about this being a simple question, since no one was able to provide an answer.
My further reading and asking led to one reply on the openssh IRC channel, around 2022-06-06. I was advised that the options:
ServerAliveInterval 60
ServerAliveCountMax 2
Often don't disconnect the client as one might expect.
The ssh_config man page:
ServerAliveCountMax
Sets the number of server alive messages (see below) which
may be sent without ssh(1) receiving any messages back from
the server. If this threshold is reached while server alive
messages are being sent, ssh will disconnect from the server,
terminating the session...
The default value is 3. If, for example, ServerAliveInterval
(see below) is set to 15 and ServerAliveCountMax is left at
the default, if the server becomes unresponsive, ssh will
disconnect after approximately 45 seconds.
Seems to pretty conclusively state that disconnecting on lack of server response is the intention of these parameters. However, in practice this doesn't happen in all cases. Maybe the caveat here is: "while server alive messages are being sent"?
If the application calls for a reliable client disconnect when the server becomes unresponsive, the advice was to implement an external method, separate from the ssh client login script, that monitors server responsiveness, and kills the ssh client process on timeout.
I am using this example https://github.com/libp2p/js-libp2p/tree/master/examples/libp2p-in-the-browser and try to connect to a nodejs peer through the given hosted rendezserver ‘/dns4/wrtc-star2.sjc.dwebops.pub/tcp/443/wss/p2p-webrtc-star’ . The peer get found but the connection is not established. If i run the nodejs peer in the same machine as the browser peer they get connected but if the nodejs peer is on a different machine/network the peers find each other but they don’t get connected. Is this normal ?
Yes that's totally normal. WebRTC will only work if you can get through the NAT. IPv6 really helps with NAT traversal too, but it can be trickier with IPv4. So it will work over more than locally, but each peer must be able to directly reach each-other.
https://docs.ipfs.io/how-to/create-simple-chat-app/
We can use WebRTC-Star nodes to help discover other peers we can connect with directly browser-to-browser. If you're familiar with the concept of STUN, it might be helpful to think of them as conceptually similar. Effectively, each connecting node will be given a WebRTC-Star multiaddress that other nodes can use to discover and connect to your browser directly. This means that if you peer with someone using the star node, and the star node goes offline, you remain connected!
[...]
Tip
This is a very clean and effective method of P2P communications; however, sometimes NATs get in the way. We use p2p-circuit to get around that.
I normally use MOBAXterm to SSH into my work pc, but when I use my gf's internet connection, it works for only a little while before giving me the above error message.
It also happens when I ssh into other external machines and it also happens when I use putty. I already implemented all the in-build steps MOBAXterm offers that could potentially fix this problem.
My suspicion is that it's related to the internet connection cutting out temporarily, but I don't see why that should be such an issue.
Any advice would be appreciated.
Two possibilities here, the nefarious and the irritating. If you know how to sniff traffic, a pcap dump of the session dying would be extremely useful. Grab it using the stable version of Wireshark.
The nefarious possibility
Traffic shaping. SSH can be used to tunnel VPN traffic. If the ISP is difficult about it (more likely if they're a big ISP) they could happily send RSTs to long-lived sessions.
The irritating possibility
Sketchy home router. If the NAT table is too full, the router's memory is overloaded, or there's a bug in the firmware, the NAT table could drop sessions which would cause what you describe.
Solutions
Try mosh. It uses SSH for session setup, then its own protocol over UDP for the actual session. It's UDP-based so there's no TCP connection to RST, and mosh is designed to survive a nuclear strike. It doesn't even care if your IP address changes mid session.
The problem is likely to be solved using mosh - even if it's the home router, mosh's session continuity will mask the NAT table resetting.
If you want to replace the home router (for example if the same thing is happening to other protocols), and you can get the authentication details for the Internet connection, try swapping it out for another one - preferably a recent high-end SOHO model.
If the connection presents as Ethernet (for example a cable modem, like Virgin) then my standard known-good is the TP-Link Archer C7.
If the connection is DSL-based (copper phone line, or BT fibre), you'll also want a 1-port VDSL (for fibre) or ADSL/ADSL2+ (for copper) modem capable of bridge mode. You'll need this in addition to the Ethernet router.
For VDSL, I'd probably recommend the ZyXEL VMG1312-B. For ADSL/ADSL2+ I'd suggest the ZyXEL P660-R.
I discovered today that if I ssh-forward the local port X to ssh server port Y, and no process is listening on port Y, I can still connect to local port X (I don't get the usual "connection refused" error).
I did my test with 2 different SSH clients on a windows host connecting to a linux server.
After a bit of reflexion, I came to the conclusion that from a pure network point of view, this is the behaviour I should expect: the SSH client is actually listening on localhost:X, so the connection is possible.
Nevertheless, this leads to a problematic situation in which I have an apparently connected socket that talks to nobody. Even sending data on the socket is a successful operation.
So my question: does the SSH protocol manage this situation in some ways, i.e. do I have strategies for detecting this situation? And if yes, may I hope support for this feature on some SSH clients and APIs (today I'm using ssh.net, that does not seem to offer this feature).
If not, how would you proceed for detecting the situation? Timeout on answer?
Thanks for your help,
Alberto.
The only logical behavior would be to close client connection if the server can't connect to the remote side, but that would not be much better than just a hanging connection.
Also there can happen situation when the SSH server is waiting for the remote connection for a minute or two before giving up, so the client's connection will be opened for this period of time anyway.
So there's actually no logical alternative rather than a hanging client connection.
I am using the google's TURN servers which is given in the demo, Sometimes the connection is established and remote video is streamed sometimes I just get a black screen instead of remote stream. Are these servers not reliable or is there any other issue because I can see the IP of the other machine on the peer which means the peer connection has been established. So what could be the possible problem is?
google doesn't provide any TURN server, only a STUN one.
There's a lot of situation where you need a TURN server, but as far as I know, there's no open TURN server. Even when the ip is detected, you can have problems with a proxy destroying the UDP stream or some of the ports needed.