This is strange. I'm wondering why it captures an incorrect IP address. No, you definitely should not have to add the network address to the interface. Well, it's not even the network address of your network. It's the whole 192.168/16 as per RFC1918. What is the kernel version, OS / distribution and what NIC drivers are you using? Are you using regular Linux or some other OS - are you using the standard networks stack or something like LWIP? uCLinux?
I know this may sound funny, but can you try a different mask for a test - configure yourself with something with a /24?
The interface address comes from getifaddrs(). If you look at getInterfaceAddress() in net.c, there is a for loop going through all the addresses. Can you put some debug code to print all the addresses it finds, and don't exit the loop until you have looped through all addresses? I wonder if both the 192.168.0.0 and your address will come up, or only one. Judging by the symptoms, the only thing that comes to my mind is some issue with getifaddrs - unless something has been configured on this NIC that causes it to behave this way.
Thanks,
Wojciech
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've inserted more debug lines to net.c code.
I've run ptpd-2.3.1-rc3 and ptpd-2.3.1 on older SoC module
uname: Linux mki4 2.6.35.3 #86 PREEMPT Tue Jan 27 12:14:03 CET 2015 armv5tejl GNU/Linux
I'm not confirm information from my previus post that on old kernel ptpd starts OK.
For me more importent are lines:
net.c: (function netInit)
DBG_OUT_IFADDR((netPath->interfaceInfo.afAddress), "DBG 10");
/* save interface address for IGMP refresh */
{
struct sockaddr_in* sin = (struct sockaddr_in*)&(netPath->interfaceInfo.afAddress);
netPath->interfaceAddr = sin->sin_addr;
}
DBG_OUT_IFADDR((netPath->interfaceInfo.afAddress), "DBG 11");
DBG("Local IP address used : %s \n", inet_ntoa(netPath->interfaceAddr));
full file results are in attachment:
ptpd-2.3.1-rc3-log.log --- oryginal code
ptpd-2.3.1-log.log --- oryginal code
ptpd-2.3.1-log_dodatkowy_debug.log ---net.c with additional debug
net.c with additional debug
I 've made more tests.
1. test with network mask /24 the same - bad
2. I'm not confirm my previuos information that ptpd is running well on older version of our SoC uname: Linux mki4 2.6.35.3 #86 PREEMPT Tue Jan 27 12:14:03 CET 2015 armv5tejl GNU/Linux
I've add more debug to net.c code. Lines interestin for me starts at 1158
net.c (function netInit)
DBG_OUT_IFADDR((netPath->interfaceInfo.afAddress), "DBG 10");
/* save interface address for IGMP refresh */
{
struct sockaddr_in* sin = (struct sockaddr_in*)&(netPath->interfaceInfo.afAddress);
netPath->interfaceAddr = sin->sin_addr;
}
DBG_OUT_IFADDR((netPath->interfaceInfo.afAddress), "DBG 11");
DBG("Local IP address used : %s \n", inet_ntoa(netPath->interfaceAddr));
ptpd was started with:
./ptpd2 -C -V -D 9 -c ptpd2.conf.default-full
All results are in attachment.
ptpd-2.3.1-log-rc3.log -- original code rc3
ptpd-2.3.1-log.log -- original code
ptpd-2.3.1 -- dodatkowy-debug.log
net.c -- with debug lines
Hi, thank you for fast answer. I'll try to do this test tommorow.
This is regular linux. Just build new kernel.
uname:
Linux mki4 3.14.4-tq-arm-bsp-0109-rt4 #10 PREEMPT RT Wed Feb 17 14:09:48 CET 2016 armv5tejl GNU/Linux
system is running on ARM SoM module TQMa28 - i.MX28
To compare I've just started ptpd2_2.3.1-rc3 on old module with kernel 2.6.35 and ptpd2 is starting OK.
Than I need to verify kernel or network settings on our new modul.
Mirek
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I 've made more tests.
1. test with network mask /24 the same - bad
2. I'm not confirm my previuos information that ptpd is running well on older version of our SoC uname: Linux mki4 2.6.35.3 #86 PREEMPT Tue Jan 27 12:14:03 CET 2015 armv5tejl GNU/Linux
I've add more debug to net.c code. Lines interestin for me starts at 1158
net.c (function netInit)
DBG_OUT_IFADDR((netPath->interfaceInfo.afAddress), "DBG 10");
/* save interface address for IGMP refresh */
{
struct sockaddr_in* sin = (struct sockaddr_in*)&(netPath->interfaceInfo.afAddress);
netPath->interfaceAddr = sin->sin_addr;
}
DBG_OUT_IFADDR((netPath->interfaceInfo.afAddress), "DBG 11");
DBG("Local IP address used : %s \n", inet_ntoa(netPath->interfaceAddr));
ptpd was started with:
./ptpd2 -C -V -D 9 -c ptpd2.conf.default-full
All results are in attachment.
ptpd-2.3.1-log-rc3.log -- original code rc3
ptpd-2.3.1-log.log -- original code
ptpd-2.3.1 -- dodatkowy-debug.log
net.c -- with debug lines
ptpd2.conf.default-full
My previous post wait for moderation but my suspicious was correct.
casting : struct sockaddr_in sin = (struct sockaddr_in)&(netPath->interfaceInfo.afAddress);
is probably not correct, because of pointer aligment. Pointers are align to 32bit I thing on arm.
Safe is to explicite copy struct. Code below works for me.
DBG_OUT_IFADDR((netPath->interfaceInfo.afAddress), "DBG 10");
/* save interface address for IGMP refresh */
{
struct sockaddr_in* sin = (struct sockaddr_in*)&(netPath->interfaceInfo.afAddress);
struct sockaddr_in sin1;
unsigned u;
memcpy(&sin1, &netPath->interfaceInfo.afAddress, sizeof(sin1));
netPath->interfaceAddr = sin1.sin_addr;
}
DBG_OUT_IFADDR((netPath->interfaceInfo.afAddress), "DBG 11");
DBG("Local IP address used : %s \n", inet_ntoa(netPath->interfaceAddr));
Mirek
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But I think that in several cases this can slow down running process and this isn't very efficient.
In ptpd this is only during init procedure. In two places. One is that we discussed above, the second one I can't find.
Mirek
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I thought armv4 and armv5 explicitly did not allow unaligned access, and armv6 had the toggle option.
Anyway, we should not be relying on unaligned access or cpu fixup, the structures should be correctly aligned. From ARM I only currently have Raspberry Pi which is armv7 so can't test this properly, but I'll have a look at the structure layout, worst case I'll put some padding in.
Thanks,
Wojciech
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, thanks. Any of these casts will be misaligned. I can get rid of the casts - and anyway, the transport API that's coming, decouples socket code from PTP code and provides an addressToString() method.
Regards,
Wojciech
Last edit: Wojciech Owczarek 2016-02-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
ptpd2 failed when setsockopt in
netInitMulticastIPv4function (net.c;line 522 PERROR is printed put)2016-02-17 14:02:20.618873 ptpd2[1254].eth0 (error) (init) error while setting outgoig multicast interface (IP_MULTICAST_IF) (strerror: Cannot assign requested address)I've printed out :
netPath->interfaceAddrfromnetInitMulticastIPv4call and this is network address: 192.168.0.0What specific should be in multicast in network setting to get this function work?
When I add 192.168.0.0 to eth0
ip addr add 192.168.0.0 dev eth0than
netInitMulticastIPv4is called without error.I'm not sure that adding network address to eth0 is right or?
Any help appreciated.
Kind regards
Mirek
my current network configuration
at my system:
/etc/network/interfaces:
auto eth0 eth1 lo iface lo inet static address 127.0.0.1 netmask 255.0.0.0 iface eth0 inet static address 192.168.3.173 netmask 255.255.224.0 pre-up ifconfig eth0 hw ether 00:04:5a:00:00:00 up iface eth1 inet static address 192.168.33.1 netmask 255.255.224.0 pre-up ifconfig eth1 hw ether 00:04:5a:00:00:01 upip addr ->:
ip route ->:
Hi Mirek,
This is strange. I'm wondering why it captures an incorrect IP address. No, you definitely should not have to add the network address to the interface. Well, it's not even the network address of your network. It's the whole 192.168/16 as per RFC1918. What is the kernel version, OS / distribution and what NIC drivers are you using? Are you using regular Linux or some other OS - are you using the standard networks stack or something like LWIP? uCLinux?
I know this may sound funny, but can you try a different mask for a test - configure yourself with something with a /24?
The interface address comes from getifaddrs(). If you look at getInterfaceAddress() in net.c, there is a for loop going through all the addresses. Can you put some debug code to print all the addresses it finds, and don't exit the loop until you have looped through all addresses? I wonder if both the 192.168.0.0 and your address will come up, or only one. Judging by the symptoms, the only thing that comes to my mind is some issue with getifaddrs - unless something has been configured on this NIC that causes it to behave this way.
Thanks,
Wojciech
Hello Wojciech,
I've inserted more debug lines to net.c code.
I've run ptpd-2.3.1-rc3 and ptpd-2.3.1 on older SoC module
uname: Linux mki4 2.6.35.3 #86 PREEMPT Tue Jan 27 12:14:03 CET 2015 armv5tejl GNU/Linux
I'm not confirm information from my previus post that on old kernel ptpd starts OK.
For me more importent are lines:
net.c: (function netInit)
DBG_OUT_IFADDR((netPath->interfaceInfo.afAddress), "DBG 10"); /* save interface address for IGMP refresh */ { struct sockaddr_in* sin = (struct sockaddr_in*)&(netPath->interfaceInfo.afAddress); netPath->interfaceAddr = sin->sin_addr; } DBG_OUT_IFADDR((netPath->interfaceInfo.afAddress), "DBG 11"); DBG("Local IP address used : %s \n", inet_ntoa(netPath->interfaceAddr));Debug printout
full file results are in attachment:
ptpd-2.3.1-rc3-log.log --- oryginal code
ptpd-2.3.1-log.log --- oryginal code
ptpd-2.3.1-log_dodatkowy_debug.log ---net.c with additional debug
net.c with additional debug
Mirek
Hello Wojciech,
I 've made more tests.
1. test with network mask /24 the same - bad
2. I'm not confirm my previuos information that ptpd is running well on older version of our SoC uname: Linux mki4 2.6.35.3 #86 PREEMPT Tue Jan 27 12:14:03 CET 2015 armv5tejl GNU/Linux
net.c (function netInit)
DBG_OUT_IFADDR((netPath->interfaceInfo.afAddress), "DBG 10"); /* save interface address for IGMP refresh */ { struct sockaddr_in* sin = (struct sockaddr_in*)&(netPath->interfaceInfo.afAddress); netPath->interfaceAddr = sin->sin_addr; } DBG_OUT_IFADDR((netPath->interfaceInfo.afAddress), "DBG 11"); DBG("Local IP address used : %s \n", inet_ntoa(netPath->interfaceAddr));log:
ptpd was started with:
./ptpd2 -C -V -D 9 -c ptpd2.conf.default-full
All results are in attachment.
ptpd-2.3.1-log-rc3.log -- original code rc3
ptpd-2.3.1-log.log -- original code
ptpd-2.3.1 -- dodatkowy-debug.log
net.c -- with debug lines
Hi, thank you for fast answer. I'll try to do this test tommorow.
This is regular linux. Just build new kernel.
uname:
Linux mki4 3.14.4-tq-arm-bsp-0109-rt4 #10 PREEMPT RT Wed Feb 17 14:09:48 CET 2016 armv5tejl GNU/Linux
system is running on ARM SoM module TQMa28 - i.MX28
To compare I've just started ptpd2_2.3.1-rc3 on old module with kernel 2.6.35 and ptpd2 is starting OK.
Than I need to verify kernel or network settings on our new modul.
Mirek
Hello Wojciech,
I 've made more tests.
1. test with network mask /24 the same - bad
2. I'm not confirm my previuos information that ptpd is running well on older version of our SoC uname: Linux mki4 2.6.35.3 #86 PREEMPT Tue Jan 27 12:14:03 CET 2015 armv5tejl GNU/Linux
net.c (function netInit)
DBG_OUT_IFADDR((netPath->interfaceInfo.afAddress), "DBG 10"); /* save interface address for IGMP refresh */ { struct sockaddr_in* sin = (struct sockaddr_in*)&(netPath->interfaceInfo.afAddress); netPath->interfaceAddr = sin->sin_addr; } DBG_OUT_IFADDR((netPath->interfaceInfo.afAddress), "DBG 11"); DBG("Local IP address used : %s \n", inet_ntoa(netPath->interfaceAddr));log:
ptpd was started with:
./ptpd2 -C -V -D 9 -c ptpd2.conf.default-full
All results are in attachment.
ptpd-2.3.1-log-rc3.log -- original code rc3
ptpd-2.3.1-log.log -- original code
ptpd-2.3.1 -- dodatkowy-debug.log
net.c -- with debug lines
ptpd2.conf.default-full
Mirek
Hello Wojciech
My previous post wait for moderation but my suspicious was correct.
casting : struct sockaddr_in sin = (struct sockaddr_in)&(netPath->interfaceInfo.afAddress);
is probably not correct, because of pointer aligment. Pointers are align to 32bit I thing on arm.
Safe is to explicite copy struct. Code below works for me.
DBG_OUT_IFADDR((netPath->interfaceInfo.afAddress), "DBG 10"); /* save interface address for IGMP refresh */ { struct sockaddr_in* sin = (struct sockaddr_in*)&(netPath->interfaceInfo.afAddress); struct sockaddr_in sin1; unsigned u; memcpy(&sin1, &netPath->interfaceInfo.afAddress, sizeof(sin1)); netPath->interfaceAddr = sin1.sin_addr; } DBG_OUT_IFADDR((netPath->interfaceInfo.afAddress), "DBG 11"); DBG("Local IP address used : %s \n", inet_ntoa(netPath->interfaceAddr));Mirek
Hi Mirek,
OK, thanks - this is clearly a problem with memory alignment. Armv4 and v5 do not allow unalingned access.
We can either do a memcpy, or change the field order to ensure everything is sitting on 32-bit.
I'll have a look.
Thanks,
Wojciech
Hi Wojciech,
Linux kernel allow to fixup alignments error by:
echo 3 > /proc/cpu/alignment
then:
But I think that in several cases this can slow down running process and this isn't very efficient.
In ptpd this is only during init procedure. In two places. One is that we discussed above, the second one I can't find.
Mirek
I thought armv4 and armv5 explicitly did not allow unaligned access, and armv6 had the toggle option.
Anyway, we should not be relying on unaligned access or cpu fixup, the structures should be correctly aligned. From ARM I only currently have Raspberry Pi which is armv7 so can't test this properly, but I'll have a look at the structure layout, worst case I'll put some padding in.
Thanks,
Wojciech
Can you try this as an alternative and check if it fixes this for you:
edit src/datatypes.h, find PTPClock definition, and move netPath to be the first field in the structure.
Thanks,
Wojciech
Hi Wojciech,
I've changed PTPClock definition like you wrote but this isn't fixup bug.
I've found second place of bug. This is DBG message, line 1008:
DBG("Listening on IP: %s\n",inet_ntoa( ((struct sockaddr_in*)&(netPath->interfaceInfo.afAddress))->sin_addr));Mirek
OK, thanks. Any of these casts will be misaligned. I can get rid of the casts - and anyway, the transport API that's coming, decouples socket code from PTP code and provides an addressToString() method.
Regards,
Wojciech
Last edit: Wojciech Owczarek 2016-02-26