Hi Alex, sorry for the late response. I was sort of consumed with loads of PLC4X tasks that didn't involve coding, but more talking and convincing __
Thanks for that suggestion. It definitely sounds like a good option ... I think we should keep that in mind, or you try your luck in implementing this ... PRs are more than welcome ;-) Right now I really have to concentrate on the S7 Fragmentation issues as we're currently starting to use PLC4X in the first industrial project and we will need this sooner than later. After that I have finishing the Netty modules for the RawIpSocket and the RawEthernetSockets ... I sort of am really pushing this task away in front of me as it is almost more challenging than reverse engineering part of the S7 protocol ;-) Right now the option with providing two mac addresses should work and we can optimize things on a need to use basis. Right now we don't even have a single driver implementation that would require that (Except perhaps Beckhoff ADS over EtherCat). Chris Am 12.03.18, 16:22 schrieb "Alexander Wellbrock" <[email protected]>: Well, the following is really ugly so beware: if you know about the network infrastructure (ask 'ip a' on unix) you could also run nmap with 'nmap -sn 192.168.1.0/24' to fill your arp cache with all devices connected to the network. Then you can use 'arp -a' to list all devices, even the ones that are not so communicative. The response will be full of 'empty' arp entries, so beware of that. I know, it's really ugly, but it could work :D Alex > Christofer Dutz <[email protected]> hat am 12. März 2018 um 15:22 geschrieben: > > > Hi Alexander, > > yeah ... I already thought about that ... the "arp -a" does work, after I sort of had some form of communication prior to that lookup. My S7 is very uncommunicative if I just turn it on. Having fixed IP not much chatter leaving the grey box which my client could catch and remember. Some people say: Ping the box, then it's in the arp cache, but I would ping it, if it had an IP address ... if there was any "Hey guys I'm new to the network, please introduce yourselves" type of package, that would be awesome (HGINTTNPIY Protocol ;-) ) > > I had to do a cli-parsing option for my RawIpSocket as I needed to find the default gateway if I'm connecting to a device not on the same physical network and I need to go through a router or gateway. It worked but I had to implement parsers for all sorts of OSes and it doesn't really feel good to rely on that. So that's sort of a measure of last resort for me. > > Chris > > > Am 12.03.18, 15:13 schrieb "Alexander Wellbrock" <[email protected]>: > > Hey Christofer, > > with your MAC-Address problem a hackish way could be to implement a small adapter for a native query of the arp-table and a little parser to parse the information which contains mac-addresses and corresponding network interfaces. On unix systems that would be 'arp -a' and splitting the result by whitespace. You retrieve hostname, ipaddress, mac-address and interface. > > Alex > > > Christofer Dutz <[email protected]> hat am 12. März 2018 um 14:12 geschrieben: > > > > > > Hi all, > > > > after realizing that Beckhoff seems to use ADS inside of EtherCat frames sent directly inside Ethernet frames (which seems to take only a fraction of the protocol overhead a normal TCP packet requires. I renamed the RawSocket to RawIpSocket and added a new type RawEthernetSocket, which allows to send and receive raw Ethernet frames and would allow implementing protocols like EtherCat and Profinet IO. > > > > The one problem I’m having with this, is that right now you need to pass in the MAC addresses of the target as well as that of the source. The problem without this I can’t seem to be able to find out which network device is able to communicate with the given MAC address. I tried several things, but none of them seemed to work without knowing the IP address of the target. Having a Ethernet level connection sounded bad to require an IP. It anyone here has an Idea how I could check which local network device can be used to send data to a remote mac address, I would be super happy. > > > > Next thing I definitely need to do, is to implement the “Raw socket” -> Netty integration … sort of a little hesitant to do that as this API is really quite a mess :-( > > > > Chris > >
