mactelnetd won't start with all interface don't have an IP address

when the box doesn't have an IP address, mactelnetd won't start, I see #17 and tested removing/adding -n was not help

in my case mactelnetd starts up but without assigned IP is not discoverable. I`m running debian stretch

maybe take a look in the modifications i made for dd-wrt. i fixed some interface related bugs in there https://github.com/mirror/dd-wrt/tree/master/src/router/mactelnet

@BrainSlayer I tested it, this version has the same problem, thanks

thats curious. for me this version works without ips on interfaces

which system are you run dd-wrt or ubuntu? i am run it on ubuntu 14 kvm,
i use command : multicall mactelnetd -f，when having ip, running on foreground, without ip mactelnetd quit

Have you tried starting it with -nf ?

the multicall binary doesnt work that way. you need to rename multicall to mactelnetd or simply do symbolic link to it. its not like busybox. i run this version on opensuse, ubuntu and its also included in dd-wrt

@haakonnessjoen yes i tried, -nf won't work
@BrainSlayer I created mactelnetd symbolic link to multicall won't work too
Any suggestions for me to find the problem?

Why is mactelnetd looking for AF_INET on the NIC when starting up? And why is it not working when there is no IP address on the NIC? I thought mactelnetd's purpose is to be able to connect to the server without having IP networking?

@metalgrid use option -n to avoid this. but this requires root privileges thats why its not default since it might be more insecure

Hi @BrainSlayer, thanks for answering. It still doesn't work though.
Whenever I run mactelnetd, with or without -n I get two messages in the logs:

mactelnetd [1139]: Bound to 0.0.0.0:20561
mactelnetd [1140]: Unable to find any valid network interfaces

So backtracing the logic through the code led me to

MAC-Telnet/src/interfaces.c

Line 148 in db80dc7

if (ifaddrsp->ifa_addr->sa_family == AF_INET) {

which to my understanding requires the NIC to have an IP address (address family AF_INET) ? Whatever the case, it enumerates only interface lo and skips eth0.

@metalgrid i made a patch to fix this and to listen on interfaces without ip. let me just finish my tests and then i send you a link to my own svn repo. but you need to merge to patch manually since i have some other modifications in my repository

@metalgrid
here is it. i already tested it on my system
https://svn.dd-wrt.com//changeset/41889

@haakonnessjoen you may also take a look on this patch above. it allows to use mactelnetd on interfaces without configured ip

The proposed changes was added in 46df165, please test :)

for me it works. :-) (but i tested only with -n) but i assume it working anyway

@haakonnessjoen i found out one limitation. if you have multiple interfaces with identical mac addresses, raw sockets wont work yet (it seems that the data packets are sended out on the wrong interface). i will try to find a workaround for this. i will work on this tomorrow. this might not be a issue for most computers, but on routers its not uncommon to have such situations

Great. But I do not agree with you that it is common to use the same mac address on multiple interfaces. Even routers. So this is not really a problem. You must have some really weird setups imho :p

@haakonnessjoen i do not. the problem are the vendors. they want to save payments for oid registrations so on some routers on the market you will find the situation that eth0, eth1 and wifi interface shares the same mac. anyway. i found a solution for this. just need to clean up the mess i created and i will send you a link for this patch when its done. i needed to rewrite the find_socket etc. functions to handle multiple replies

@haakonnessjoen unfortunatly i reformated the code using my own indent script. but here is the solution for the problem. https://svn.dd-wrt.com//changeset/41891
if you dont like it, no problem. but i have to deal with it in some way on these crazy devices :-)

Too bad with the formatting. Makes it a much bigger job moving back here.
Hm, why are you generating a new salt each time you get a new packet, regardless of what kind? :P

the problem is i need the same salt for multiple outgoing connection. the only way to handle this is uppon creation of the interface. so i do generate the salt array, but just set it to the connection object one time. so the regeeration everytime the handler is called is bogus and not required, but its the only location. but i can make a check if the connection object already contains a salt, to ignore it

btw. for easier comparing.
this is my ident script
indent -npro -kr -i8 -ts8 -sob -l220 -ss -ncs \ -T s8 -T s16 -T s32 -T s64 \ -T __s8 -T __s16 -T __s32 -T __s64 \ -T u8 -T u16 -T u32 -T u64 \ -T __u8 -T __u16 -T __u32 -T __u64 \ -T __be16 -T __be32 -T __be64 \ -T __le16 -T __le32 -T __le64 \ -T size_t -T u_int8_t -T u_int16_t -T u_int32_t -T u_int64_t -T int -T char -T unsigned -T long -T float -T double -T webs_t -T void \ -T HAL_BEACON_STATE -T HAL_BEACON_TIMERS -T HAL_BOOL -T HAL_CHANNEL \ -T HAL_TXQ_INFO -T HAL_INT -T HAL_KEYVAL -T HAL_MIB_STATS \ -T HAL_NODE_STATS -T HAL_RATE_TABLE -T HAL_STATUS \ "$@"

The old code did have that salt-check. Not sure why you would need to change it. :P

@haakonnessjoen because the old code was creating a individual salt for each connection with a salt check for each individual connection. but in case we have identical mac addresses on multiple interfaces i have to send out the reply to all of these interfaces. so the same salt has to be used for multiple replies based on the same initial connection request. otherwise authentication will fail. i already added a new salt check in my current code. mactelnetd identifies the connection request by the destination mac, but this mac fits to multiple interfaces. so i need multiple replies on each of these matching interfaces since i basicly dont know where the connection was coming from

and to explain it in more detail. i implemented this new salt creation way because i was running into trouble with authentication fail because of a wrong salt. so it was try and error in developing this solution

The original issue is fixed, also in the latest version, it listens for interface changes, and will adapt to new interfaces automatically on mac and linux.