Feature request and/or bug fix about mac-telnet HOT 20 CLOSED

Hi,

Thanks :)

1. In regards to the feature request. I am afraid that it is not possible to use PAM to authenticate users, since the authentication method used by the Mac-telnet protocol, requires the server to know the plain-text password.

2. Would you be able to take a wireshark/tcpdump dump while this happens, and email me the pcap file? Seems like there is some mismatch with the packet retransmission.

About them not being happy; I have not gotten any negative response from Mikrotik. So I do not think they have anything against this project. They are pretty much dependant of open source. So I wouldn't think they would have anything against any open source projects. This tool only helps them getting a bigger user-base.

Regards,
Håkon

from mac-telnet.

Hi,

I have done a tcpdump but only for mactelnet data i.e. I specified the protocol as UDP and both source and destination ports of 20561 - I hope that will help, otherwise I can do a full dump of all traffic during the testing.

https://www.dropbox.com/s/6liwtrbsz86z1rn/mactelnetd_latest.cap

Regards,
Karl

from mac-telnet.

Hi,

Sorry for the late response. Could you try to change the following line in mactelnetd.c?

if (time(0) - curconn->lastdata > 9) {

From 9 to 5, and recompile and test again. It should be on line 751.

from mac-telnet.

Hi,

Thanks, I tried it and it still disconnects although it may last a little longer before disconnecting...

Regards,
Karl

from mac-telnet.

Could you do another tcpdump with the test-fix in place? :)

from mac-telnet.

Hi,

Many thanks for your help, I have done a quick test, there may be 1 failed login in the capture due to butter fingers :)

https://www.dropbox.com/s/6liwtrbsz86z1rn/mactelnetd_latest.cap (don't think this changed since last time - but this is a new capture).

Edit: Here is a "clean" capture with no Login failure, again, this is from a Mikrotik client to the linux server that has an issue, from Linux to Mikrotik it works 100%

https://www.dropbox.com/s/xny1jqhx3gtwh9s/mactelnetd_201406301358.cap

Regards,
Karl

from mac-telnet.

Hi,

Thanks a lot for your help with tracking this bug down. I think I have found the problem, and have commited a new fix. Could you try to pull the latest changes from the master branch, and see if your problem disappears?

Regards,
Håkon

from mac-telnet.

:( not working, I nuked the whole local repo then did a git clone again to get all your changes but I still disconnect after a few 10 or so seconds. It's odd that the connection in the reverse direction is 100% stable. I haven't tested logging in from a Linux box to another Linux box to see if that is stable. If that works I would need to MAC telnet from the Mikrotik. Many thanks for your input / time on working on this.

from mac-telnet.

That sucks. I really hoped that would fix it.

In danger of sounding like a parrot, could you do a new capture? :)

from mac-telnet.

Hi,

Cap from this morning, tested with your latest code as per above :)

https://www.dropbox.com/s/15os99uancm635r/mactelnetd_201407030921.cap

Regards,
Karl

from mac-telnet.

Hi,

It regrettably doesn't get me enough info. Could you apply this patch?
https://gist.github.com/haakonnessjoen/7709c5f648ed3818f986

And then recompile, and do a new tcpdump capture. And also give me the mactelnet relevant info from /var/log/syslog ? I have added some debugging in the patch, to give me more insight in why it thinks the connection times out.

from mac-telnet.

OK, this is the cap and syslog for the session, I am going to try with another machine to see if I get the same behaviour.

https://www.dropbox.com/s/lruhl906u8so2w1/mactelnetd_201407031107.cap

Jul 3 11:06:53 matrix mactelnetd[15073]: Bound to 0.0.0.0:20561
Jul 3 11:06:53 matrix mactelnetd[15073]: Listening on eth0 for 0:1c:c0:18:88:af
Jul 3 11:06:53 matrix mactelnetd[15073]: Listening on vlan20 for 0:1c:c0:18:88:af
Jul 3 11:07:40 matrix mactelnetd[15074]: (6565) New connection from 0:c:42:d2:57:92.
Jul 3 11:07:40 matrix mactelnetd[15074]: (6565) New connection from 0:c:42:d2:57:92.
Jul 3 11:07:40 matrix mactelnetd[15074]: (6565) DEBUG: Data ack ts=1404378460, now=1404378460 lastack=25 pkcntr=25
Jul 3 11:07:40 matrix mactelnetd[15074]: (6565) DEBUG: Data ack ts=1404378460, now=1404378460 lastack=34 pkcntr=34
Jul 3 11:07:40 matrix mactelnetd[15100]: (6565) User root logged in.
Jul 3 11:07:40 matrix mactelnetd[15074]: (6565) DEBUG: Data ack ts=1404378460, now=1404378460 lastack=107 pkcntr=107
Jul 3 11:07:40 matrix mactelnetd[15074]: (6565) DEBUG: Data ack ts=1404378460, now=1404378460 lastack=175 pkcntr=175
Jul 3 11:07:50 matrix mactelnetd[15074]: (6565) DEBUG: Data ack ts=1404378460, now=1404378470 lastack=175 pkcntr=175
Jul 3 11:07:55 matrix mactelnetd[15074]: (6565) Session timed out
Jul 3 11:07:55 matrix mactelnetd[15074]: (6565) DEBUG: Timeout ts=1404378460, now=1404378475 lastack=0
Jul 3 11:07:55 matrix mactelnetd[15074]: (6565) DEBUG: Data ack ts=1404378470, now=1404378475 lastack=175 pkcntr=175
Jul 3 11:07:55 matrix mactelnetd[15074]: (6565) Connection closed.

from mac-telnet.

It seems like the problem is because you are on both VLAN 1(untagged) and VLAN 20, and the Mikrotik is also that. So the first packet is sent to both interfaces, and then it continues on only the one.

But I think the problem lies in the double "start session" on different interfaces, but with the same mac addresses. I will investigate further, how I can handle this.

from mac-telnet.

Could you try to ad the following under case MT_PTYPE_SESSIONSTART: ?

curconn = list_find_connection(pkthdr.seskey, (unsigned char *)&(pkthdr.srcaddr));
if (curconn != NULL) {
        /* Ignore multiple session starts from the same sender, this can be same mac but different interface */
        break;
}

I feel extra confident that this will fix your problem 👍

from mac-telnet.

Whereabouts do I place the code? Do I replace all the code under that case block? Thanks again for your assistance 👍

from mac-telnet.

Hi, go to line 709 in mactelnetd.c, where it should say:

case MT_PTYPE_SESSIONSTART:

Add the lines i mentioned in my last post right under that line. But do not remove anything from the existing code :)

The result should end up something like this:

                case MT_PTYPE_SESSIONSTART:
                        curconn = list_find_connection(pkthdr.seskey, (unsigned char *)&(pkthdr.srcaddr));
                        if (curconn != NULL) {
                                /* Ignore multiple session starts from the same sender, this can be same mac but different interface */
                                break;
                        }
                        syslog(LOG_DEBUG, _("(%d) New connection from %s."), pkthdr.seskey, ether_ntoa((struct ether_addr*)&(pkthdr.srcaddr)));

from mac-telnet.

Sweet it works 100% now.

from mac-telnet.

Super, I will commit the changes then :)

Thanks for your help with debugging this problem! 👍

from mac-telnet.

Fixed in 7683ebf

from mac-telnet.

Thanks

from mac-telnet.