my setup would look like this:
ubunutu linux pc running Asterisk Server
analog phone connected to the VOIP ATA adapter
VOIP ATA adapter connected to Asterisk Server via Ethernet
I have only found information about setting up an extension within the Asterisk Server for the ATA. Here the SIP account for the phone is configured within Asterisk, it becomes clear to me that the Asterisk Server needs to be powered on at all times, otherwise the ATA won't be able to send/receive any phone calls.
My Question
Is it possible to let the ATA adapter store and manage the SIP accounts while the Asterisk Server monitors incoming calls (I need the called id) and also can send a desired phone number to the ATA to initiate an outgoing call. With this even if the Asterisk Server is powered down the user still is able to make/receive calls via the ATA adapter using the analog phone. If this is possible, could you please give me a reference or hint how to setup the Asterisk extension for this situation?
If you have linksys adapters, you can create dialplan on adapters to callout directly other adapter(with static ip) in case if server is down.
On most adapters you can use backup proxy if primary proxy failed
Thats all.
In most case if your server is down, you have no phone service
Related
I want to setup a register / discover type of service connection between 2 devices on the same wireless LAN. Idea is to find, connect and send wireless router password to a new device for easy installation. This needs communication between 2 devices on the same wireless network before connecting to router with SSID, password.
I'm aware of zeroconf, bonjour and mDNS libraries. All implementations I see start with connecting to wifi in station mode to get a local IP with hardcoded SSID and password, which is not known at this stage.
In other words, how can connect to wireless and get a link local IP without SSID and password?
-- Edit for better explanation --
The flow i'm looking for is like this:
1- Mobile phone (iphone or android) is connected to secure home wireless network as usual
2- A new device with wireless interface is powered on first time.
3- Device gets (or sets) a local IP and local dns name (multicast ip and name) for itself
4- Device broadcasts its available services to the network
5- Phone discovers the service, along with devices' local name and even local ip already assigned.
6- Phone initiates a direct connection with the device to send wireless configuration information (ssid and password for the access point)
7 - Device saves this information, resets into normal operation mode
8 - Device connects to internet
9 - Device services are still available in the local network
-- edit --
Code will run on esp32 or esp8266, so compatible c or arduino libraries are ok.
I'm aware of smartconfig implementation of ESPTouch application, but it is a horrible design! Discovery program tries to create sockets to every possible IP address to find the peer IP.
Read this sentence in your question again and think about it:
In other words, how can connect to wireless and get a link local IP
without SSID and password?
The protocols you mentioned are only possible AFTER you're part of the network. As you know, wifi networks are protected to prevent unauthorized access.
Try wifi protected setup (WPS) in Google.
Can software respond to a Wake-on-Lan packet, or does it get filtered out by the NIC and/or OS?
My PC receives a Wake-on-Lan packet when one of my devices can't connect to the service it's expecting. If the PC is off, the packet will cause the machine to boot up, as expected. Unfortunately, it's possible (and common) for a PC user to quit the service manually. This leaves the system in a bad state where the machine is on but the service isn't running.
This particular service (Steam Big Picture Mode) doesn't have a 'run as service' option, and doesn't provide any other hooks to start it remotely. I'd like to write some bootstrap code that listens for the WoL packet and launches the service.
I want to honor the user's request to close the service on the host, up until the point that the WoL request is received. Thus, I'd prefer not to write a process that just monitors the service health and re-starts it when it's closed.
I am able to access to my IOT device if I assign it a static IP with a service like dydns. But I would like to be able to reach it without relying on something.
I was thinking that my IOT device could ,on every start, write in a database its IP adress so my script on the server knows its ip.
The problem is that the IP will correspond to my hotspot IP. I am missing the connection part "hotspot -->IOT device".
For example I would like to be able to connect my IOT device to my mobile phone in hotspot mode.
One way to do this would be to re-design your system: if when it comes online the IoT device always connects (and stays connected) to a server component (which has a well-known/unchanging hostname/IP address), then the server can always send the IoT device a command over that TCP connection without knowing the hostname/IP address of the IoT device, and without it having to be contactable from the internet, i.e. this approach is firewall-friendly at the device end.
This is how the IoT is architected when using e.g. MQTT: devices connect inwards to the MQTT broker (i.e. server). MQTT also removes the need for the server application itself to need to connect to the clients. MQTT uses a concept called publish/subscribe with pre-agreed 'topics' - the client will subscribe to a 'command' topic, the server app publishes commands to that topic and the broker handles forwarding the command to the device. Incoming data from the device is published to another topic and the server application subscribes to that topic, the broker forwards the published data. You can try pub/sub example (using a browser, but real devices can also connect to the same server) using e.g. http://m2m.demos.ibm.com/utilities.html
I am currently working on a hobby project where I am using a PIC controller and a sim900 modem for remote monitoring, over a GPRS connection.
I can upload data from my remote device on to the server in regular intervals.
Now I would like to send some control signals to the device from the server, but how do I find which device to send data to? I need to know the IP address of the device which is assigned dynamically.
Is there a static IP on GSM modem, or can anyone please suggest a solution for this?
You need to contact your service provider(SIM card providers) to assign a static IP for your SIM card.
Other option is you have to develop a simple application layer protocol for data transfer over TCP/UDP in which once the connection is established your modem should send its identity(Name/ID etc.)
On the server side you need to write the code in which you have to maintain a dynamic table of modem details and socket number. When the modem is connected you can send data over the same socket for control commands.
I am new to network programming and try to understand managing traffic via TUN/TAP interface.
Since I have almost nonexistent system programming skills, and feel confident on Java; I use OpenVPN tun/tap driver and ready made Java binding for it. It works on TAP mode.
As an example application I am trying to imitiate no encryption, no authentication client server VPN application.
I can catch Ethernet Frame packets, but for the routing part, I failed miserably. (I can modify route/arp tables.)
Do anybody know how OpenVPN send packets from client to server, and from server to target. Opening sockets from Java looks like an alternative; but I was hoping that modifying packets(change IPs and/or MAC addresses) and writing back to the virtual tap interface would be enough. Is it so?
Can I inject packets to send other locations, or by default received packet moves towards application layer?
-- Edit:
Scneario
Client Tap0 _____ Server Tap0 ______ Target
Eth0 Eth0
Target: Ping from client, move through tap interfaces, target see only server ip (anonymization)
What I achived so far.
Catch traffic at client tap0 interface.
I coulnt forward traffic at server Tap so to fasten things I used Java socket programming between client-server.
Now I read packets from socket at server, and try to OpenVPN Tap driver's write method to move forward but I am not sure where do I fail. I see packets with tcpdump at server tap0, but they do not pass to server eth0.
My most important question is if I modify packet(ip, mac address) and call write method, is it possible that packet moves forward. (Or does it move to application layer whatever you change??)
Any help would be appreciated.
1. Routing is a Layer 3 (IP) problem and handled by the OS. As for the Ethernet frames on Layer 2, you have multiple options. In any case, you'll have to parse the incoming packets' headers and extract the MAC address, and decide based on the MAC where to pass the packet: To a specific client, all clients (broadcasts) or the local tap interface.
Option 1: On each client, use a tun device, and let the server use a tap device. Assign pseudo MAC addresses to each client, respond accordingly to ARP requests from the server's OS and let the OS on the server take care of the rest. Applicationwise, you'll only have to forward all incoming packets to the tap device and all outgoing packets to the client to which you assigned this MAC.
Option 2: Let the clients choose their own MAC address and forward ARP-requests through the network. The server application has to decide for incoming packets from a client whether to forward the packet to a client, or send it to the local tap device if the address matches the local device's MAC.
In both cases, clients pass all packets from their local tun/tap device to the server and vice versa.
2. You can do almost anything. A packet is only "received" when you decide to write it to the tap device, and you can of course temper with any packets, or inject new ones, ...
As a final comment, I've found that toying with tun devices is conceptually simpler, because they work on Layer 3. You'll have to open a tun device on the server for each client, but within your application you'll have to do nothing but to forward anything coming from the device to the single client, and vice versa.