-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tunctl with gen_udp #4
Comments
I think the {error,ehostunreach} is happening because of the way routing is handled when both interfaces are local. The kernel is generating an ICMP host unreachable because it doesn't know of a path to get from 192.168.100.100 to 192.168.100.101 using tap0. I don't have an OS X system to test on, so this is just a guess. I tried your code on Ubuntu and FreeBSD and didn't get the host unreachable error. Creating the interfaces in the repl: 1> {ok,D0} = tuncer:create(<<"tap0">>, [tap,no_pi,{active,true}]).
{ok,<0.42.0>}
2> {ok,D1} = tuncer:create(<<"tap1">>, [tap,no_pi,{active,true}]).
{ok,<0.47.0>}
3> tuncer:up(D0, {192,168,100,100}).
ok
4> tuncer:up(D1, {192,168,100,101}).
ok
5> flush().
% a bunch of ARP and ICMPv6 neighbour discovery packets Then in another shell:
Back in the erlang repl: 6> flush().
ok
% no packets So since both tap interfaces are local, the routing is short circuited and goes directly rather than via the tap devices despite the socket being bound to the ip address. |
Oh that's a shame. It kind of ruins my plans of using tunctl for running erlang clusters locally and simulating network conditions (delays,packetloss,splits). Thanks for the help. |
I realised the same when fiddling around with github/anond and did go /Joakim On 2015-01-25 18:11, Sergej Jurečko wrote:
|
@SergejJurecko Basically the 192.168.100.100 interface is the gateway to the 192.168.100.0/24 network. If a packet is sent to, e.g., 192.168.100.33, the packet will be sent via the tunnel. Since this is a tap interface, the erlang code will have to handle arp, etc. lansim seems to work this way: The other way is to use a tun device which will create a point to point device but you'll still need to handle the IP headers. Both of these are probably going too far down the rabbit hole if you want to simulate network failures on the loopback. I think it would be better if there were a higher level library, something like Joakim's anond, that let you programmatically set up the network. @joagre now that is cool! Too bad it didn't work out but that is what experiments are for. So did each node end up running inside a VM or does each node's interface live in a network namespace like mininet? |
I'm trying to create two interfaces, have an erlang process for each and use gen_udp to communicate between them. But on OSX it always crashes. One process is able to send over gen_udp, the other one not. Do you have any insight why the attached code does not work?
Exception:
** Generic server <0.37.0> terminating
** Last message in was {'EXIT',<0.35.0>,
{{badmatch,{error,ehostunreach}},
[{tt,route2,1,
[{file,"src/tt.erl"},{line,50}]}]}}
Code:
The text was updated successfully, but these errors were encountered: