Posts for Technology Raymond Flach http://community.qnx.com/sf/go/post98532 2013-01-12T21:32:39Z 2013-01-12T21:32:39Z

Has anyone ever figured this out? I am having the same issues. How do I set/get form values with SSI and qnxvar?

Raymond Flach 2013-01-12T21:32:39Z Boangoat Jarupan http://community.qnx.com/sf/go/post97004 2012-11-08T17:26:50Z 2012-11-08T17:26:50Z

Please find the dump in the attachment. I filter out only DHCP packets due to the size of the original dump file. Also, please note that we use f8:7b:7a:40:89:c4 as the mac address for testing. The first DISCOVER packet starts at packet #11 and it is from our board. In this dump, there is no response from the server. We have tried many times; unfortunately, we can not get any response from the server. I am also wondering whether this problem is related to relay agent for DHCP server. What do we need to do to check that possibility? Thank you.

Boangoat Jarupan 2012-11-08T17:26:50Z Hugh Brown http://community.qnx.com/sf/go/post97003 2012-11-08T16:47:31Z 2012-11-08T16:47:31Z

Yes, Wireshark traces will be fine. On 2012-11-08 11:09 AM, "Boangoat Jarupan" <community-noreply@qnx.com> wrote: >We use io-pkt-v4-hc on TI WL1283 chip. Below is the command we use to >load the driver > ># io-pkt-v4-hc -dti1283-sdc4430 >sdio=2,dmatx=47,dmarx=48,irq=1003,gpio=90,irq_gpio=3 > >The dhcp.client does have a back-off timer and I see that the DHCP >DISCOVER packet get rebroadcast. We have been running dhcp.client for >multiple times. Unfortunately we are not be able to get the IP address. >Most of the time, DISCOVER packets got ignore. We rarely received the >OFFER packets back. On the other hand, other devices such as cell phone >and laptop are able to obtain the IP addresses easily from our server. > >Unfortunately, we have trouble getting the trace result from tcpdump. >This happens after we upgrade to CAR 2.0 alpha 5 platform. I posted the >questions on CAR 2.0, but I received no response yet. >http://community.qnx.com/sf/discussion/do/listPosts/projects.qnx_car_2/dis >cussion.garmin_qnx_car_2.topc22641 > >We currently capture packets from Wireshark. Would you be able to help us >to get tcpdump to work? Or should I send you packet traces results from >Wireshark? Thank you. > > > >_______________________________________________ > >Technology >http://community.qnx.com/sf/go/post96998 >To cancel your subscription to this discussion, please e-mail >technology-networking-unsubscribe@community.qnx.com

Hugh Brown 2012-11-08T16:47:31Z Boangoat Jarupan http://community.qnx.com/sf/go/post96998 2012-11-08T16:09:48Z 2012-11-08T16:09:48Z

We use io-pkt-v4-hc on TI WL1283 chip. Below is the command we use to load the driver # io-pkt-v4-hc -dti1283-sdc4430 sdio=2,dmatx=47,dmarx=48,irq=1003,gpio=90,irq_gpio=3 The dhcp.client does have a back-off timer and I see that the DHCP DISCOVER packet get rebroadcast. We have been running dhcp.client for multiple times. Unfortunately we are not be able to get the IP address. Most of the time, DISCOVER packets got ignore. We rarely received the OFFER packets back. On the other hand, other devices such as cell phone and laptop are able to obtain the IP addresses easily from our server. Unfortunately, we have trouble getting the trace result from tcpdump. This happens after we upgrade to CAR 2.0 alpha 5 platform. I posted the questions on CAR 2.0, but I received no response yet. http://community.qnx.com/sf/discussion/do/listPosts/projects.qnx_car_2/discussion.garmin_qnx_car_2.topc22641 We currently capture packets from Wireshark. Would you be able to help us to get tcpdump to work? Or should I send you packet traces results from Wireshark? Thank you.

Boangoat Jarupan 2012-11-08T16:09:48Z Hugh Brown http://community.qnx.com/sf/go/post96994 2012-11-08T15:24:04Z 2012-11-08T15:24:04Z

Further to my last e-mail, we need to know what version of io-pkt you are running as the old io-pkt sets the TTL to 1 but the 6.5.0 SP1 io-pkt sets the TTL to 64. On 2012-11-07 4:47 PM, "Boangoat Jarupan" <community-noreply@qnx.com> wrote: >It seems like the server does not response to the DHCP DISCOVER packet >from the client in "far" case. I have tried to capture the packets and >found that the TTL in IP header is set to 1. Should we set this to higher >value so that the DISCOVER packet could forward by relay agent? Are there >anyway we can change this value using command line? Something like >sysctl. Unfortunately, I tried net.inet.ip.ttl, but it returns 64. > ># sysctl net.inet.ip.ttl >net.inet.ip.ttl = 64 > > > > > > >_______________________________________________ > >Technology >http://community.qnx.com/sf/go/post96970 >To cancel your subscription to this discussion, please e-mail >technology-networking-unsubscribe@community.qnx.com

Hugh Brown 2012-11-08T15:24:04Z Hugh Brown http://community.qnx.com/sf/go/post96992 2012-11-08T15:21:22Z 2012-11-08T15:21:22Z

Apparently we do set the TTL to 1 as it is a broadcast packet. The fact that you get a response to the first packet indicates that you are communicating. Are you in a noisy WiFi environment? The dhcp.client does have a back-off timer, so if you leave it running for a while, do you eventually get an IP address? On 2012-11-07 4:47 PM, "Boangoat Jarupan" <community-noreply@qnx.com> wrote: >It seems like the server does not response to the DHCP DISCOVER packet >from the client in "far" case. I have tried to capture the packets and >found that the TTL in IP header is set to 1. Should we set this to higher >value so that the DISCOVER packet could forward by relay agent? Are there >anyway we can change this value using command line? Something like >sysctl. Unfortunately, I tried net.inet.ip.ttl, but it returns 64. > ># sysctl net.inet.ip.ttl >net.inet.ip.ttl = 64 > > > > > > >_______________________________________________ > >Technology >http://community.qnx.com/sf/go/post96970 >To cancel your subscription to this discussion, please e-mail >technology-networking-unsubscribe@community.qnx.com

Hugh Brown 2012-11-08T15:21:22Z Hugh Brown http://community.qnx.com/sf/go/post96990 2012-11-08T14:59:13Z 2012-11-08T14:59:13Z

We would have to check versions, it should be going out as 64. That said, if we are still dealing with a range issue, The TTL should be treated the same in either case, unless we are talking about two different network setups that are being connected to. It would still be good to see complete packet traces as well, as it seemed like the DHCP discover was not being ignored, it was just the 4 way handshake did not complete. The complete packet trace would confirm this. On 2012-11-07 4:47 PM, "Boangoat Jarupan" <community-noreply@qnx.com> wrote: >It seems like the server does not response to the DHCP DISCOVER packet >from the client in "far" case. I have tried to capture the packets and >found that the TTL in IP header is set to 1. Should we set this to higher >value so that the DISCOVER packet could forward by relay agent? Are there >anyway we can change this value using command line? Something like >sysctl. Unfortunately, I tried net.inet.ip.ttl, but it returns 64. > ># sysctl net.inet.ip.ttl >net.inet.ip.ttl = 64 > > > > > > >_______________________________________________ > >Technology >http://community.qnx.com/sf/go/post96970 >To cancel your subscription to this discussion, please e-mail >technology-networking-unsubscribe@community.qnx.com

Hugh Brown 2012-11-08T14:59:13Z Boangoat Jarupan http://community.qnx.com/sf/go/post96970 2012-11-07T21:47:04Z 2012-11-07T21:47:04Z

It seems like the server does not response to the DHCP DISCOVER packet from the client in "far" case. I have tried to capture the packets and found that the TTL in IP header is set to 1. Should we set this to higher value so that the DISCOVER packet could forward by relay agent? Are there anyway we can change this value using command line? Something like sysctl. Unfortunately, I tried net.inet.ip.ttl, but it returns 64. # sysctl net.inet.ip.ttl net.inet.ip.ttl = 64

Boangoat Jarupan 2012-11-07T21:47:04Z Hugh Brown http://community.qnx.com/sf/go/post96518 2012-10-22T15:51:22Z 2012-10-22T15:51:22Z

Please can you do the following: It would be better if they dumped the entire frame so that we can see the contents of the DHCP packets, but for the 'far' example, it is incomplete as there is no DHCP ACK from the server if we got that far, as I can't see what the client sent. Client -> discover Server -> offer Client -> request Server -> ACK There is only one reply from the server, so it appears the ACK is missing, so the protocol exchange was never completed. Whether the client is sending the REQUEST after the server OFFER is unclear as not enough of the frame length is captured. The ARP exchange is a final sanity done by dhcp.client to verify the address is not already in use. This happens after the server ACK, but before the IP address is assigned to the interface. At this point it looks like traffic is dropped in the far case. A packet sniff on both the client and AP should give an idea of what each host is able to see. On 2012-10-04 5:51 PM, "Boangoat Jarupan" <community-noreply@qnx.com> wrote: >wireless chip: TI WL1281Q > >We have problem getting IP address from AP using dhcp.client. Our board >can successfully connect to the server using wpa_supplicant. After the >connection, we run "dhcp.client" to obtain the IP address from the >server. When the AP is far away (this is a main server with internet >access), the station could not get the IP address to assign to the node. >On the other hand, dpch.client works fine when the AP is closed to the >node within a single hop and does not have the internet access. > >We include log info in the attachment (dhcp_dump.txt) with four different >logs. > >1. TCPDUMP: connecting to AP_far >2. Sloginfo: connecting to AP_far >3. TCPDUMP: connecting to AP_near >4. Sloginfo: connecting to AP_near > >The first two logs show the connection to far away from AP, and IP >requests are fail. The first log shows that the station receives the IP >address. However, when we run ifconfig command, the IP does not get >assigned to the node. Sloginfo (2nd log) shows problem with cmdQueue_SM >which we are not sure what is the implication of this error. Last two >logs show successful IP request to local AP. In log 3, the arp is called >after the IP is assigned. We are not sure why the arp command is not >called when AP is far and have internet access. In log 4, the new >connection information is shown in sloginfo. > > > > > > >_______________________________________________ > >Technology >http://community.qnx.com/sf/go/post96045 >To cancel your subscription to this discussion, please e-mail >technology-networking-unsubscribe@community.qnx.com

Hugh Brown 2012-10-22T15:51:22Z Hugh Brown http://community.qnx.com/sf/go/post96470 2012-10-19T15:49:14Z 2012-10-19T15:49:14Z

Just to let you know that I'm still waiting for a response from TI. On 2012-10-04 5:51 PM, "Boangoat Jarupan" <community-noreply@qnx.com> wrote: >wireless chip: TI WL1281Q > >We have problem getting IP address from AP using dhcp.client. Our board >can successfully connect to the server using wpa_supplicant. After the >connection, we run "dhcp.client" to obtain the IP address from the >server. When the AP is far away (this is a main server with internet >access), the station could not get the IP address to assign to the node. >On the other hand, dpch.client works fine when the AP is closed to the >node within a single hop and does not have the internet access. > >We include log info in the attachment (dhcp_dump.txt) with four different >logs. > >1. TCPDUMP: connecting to AP_far >2. Sloginfo: connecting to AP_far >3. TCPDUMP: connecting to AP_near >4. Sloginfo: connecting to AP_near > >The first two logs show the connection to far away from AP, and IP >requests are fail. The first log shows that the station receives the IP >address. However, when we run ifconfig command, the IP does not get >assigned to the node. Sloginfo (2nd log) shows problem with cmdQueue_SM >which we are not sure what is the implication of this error. Last two >logs show successful IP request to local AP. In log 3, the arp is called >after the IP is assigned. We are not sure why the arp command is not >called when AP is far and have internet access. In log 4, the new >connection information is shown in sloginfo. > > > > > > >_______________________________________________ > >Technology >http://community.qnx.com/sf/go/post96045 >To cancel your subscription to this discussion, please e-mail >technology-networking-unsubscribe@community.qnx.com

Hugh Brown 2012-10-19T15:49:14Z Hugh Brown http://community.qnx.com/sf/go/post96059 2012-10-05T14:49:07Z 2012-10-05T14:49:07Z

I have forwarded your query to TI. On 2012-10-04 5:51 PM, "Boangoat Jarupan" <community-noreply@qnx.com> wrote: >wireless chip: TI WL1281Q > >We have problem getting IP address from AP using dhcp.client. Our board >can successfully connect to the server using wpa_supplicant. After the >connection, we run "dhcp.client" to obtain the IP address from the >server. When the AP is far away (this is a main server with internet >access), the station could not get the IP address to assign to the node. >On the other hand, dpch.client works fine when the AP is closed to the >node within a single hop and does not have the internet access. > >We include log info in the attachment (dhcp_dump.txt) with four different >logs. > >1. TCPDUMP: connecting to AP_far >2. Sloginfo: connecting to AP_far >3. TCPDUMP: connecting to AP_near >4. Sloginfo: connecting to AP_near > >The first two logs show the connection to far away from AP, and IP >requests are fail. The first log shows that the station receives the IP >address. However, when we run ifconfig command, the IP does not get >assigned to the node. Sloginfo (2nd log) shows problem with cmdQueue_SM >which we are not sure what is the implication of this error. Last two >logs show successful IP request to local AP. In log 3, the arp is called >after the IP is assigned. We are not sure why the arp command is not >called when AP is far and have internet access. In log 4, the new >connection information is shown in sloginfo. > > > > > > >_______________________________________________ > >Technology >http://community.qnx.com/sf/go/post96045 >To cancel your subscription to this discussion, please e-mail >technology-networking-unsubscribe@community.qnx.com

Hugh Brown 2012-10-05T14:49:07Z Boangoat Jarupan http://community.qnx.com/sf/go/post96045 2012-10-04T21:51:42Z 2012-10-04T21:51:42Z

wireless chip: TI WL1281Q We have problem getting IP address from AP using dhcp.client. Our board can successfully connect to the server using wpa_supplicant. After the connection, we run "dhcp.client" to obtain the IP address from the server. When the AP is far away (this is a main server with internet access), the station could not get the IP address to assign to the node. On the other hand, dpch.client works fine when the AP is closed to the node within a single hop and does not have the internet access. We include log info in the attachment (dhcp_dump.txt) with four different logs. 1. TCPDUMP: connecting to AP_far 2. Sloginfo: connecting to AP_far 3. TCPDUMP: connecting to AP_near 4. Sloginfo: connecting to AP_near The first two logs show the connection to far away from AP, and IP requests are fail. The first log shows that the station receives the IP address. However, when we run ifconfig command, the IP does not get assigned to the node. Sloginfo (2nd log) shows problem with cmdQueue_SM which we are not sure what is the implication of this error. Last two logs show successful IP request to local AP. In log 3, the arp is called after the IP is assigned. We are not sure why the arp command is not called when AP is far and have internet access. In log 4, the new connection information is shown in sloginfo.

Boangoat Jarupan 2012-10-04T21:51:42Z Mario Charest http://community.qnx.com/sf/go/post95755 2012-09-21T19:50:19Z 2012-09-21T19:50:19Z

> -----Message d'origine----- > De : Nick Reilly [mailto:community-noreply@qnx.com] > Envoyé : 21 septembre 2012 15:19 > À : technology-networking > Objet : Re: RE: Not real-time enough > > I think unfortunately splitting in to two io-pkt stacks may be the best. > > As you are jumbos you're not going to get that many more packets in without > hitting 27386. 27386??? > Adding a whole new API involving even more locking stuff on > the sockbuf would likely be counter productive, you could always switch to > TCP instead. Can't, the sender is not under our control. > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post95751 > To cancel your subscription to this discussion, please e-mail technology- > networking-unsubscribe@community.qnx.com

Mario Charest 2012-09-21T19:50:19Z Nick Reilly http://community.qnx.com/sf/go/post95756 2012-09-21T19:49:50Z 2012-09-21T19:49:50Z

> > As you are jumbos you're not going to get that many more packets in without > > hitting 27386. > > 27386??? The tracking number for the known issue with increasing net.inet.udp.recvspace that was mentioned in the other post you quoted.

Nick Reilly 2012-09-21T19:49:50Z Nick Reilly http://community.qnx.com/sf/go/post95751 2012-09-21T19:19:21Z 2012-09-21T19:19:21Z

I think unfortunately splitting in to two io-pkt stacks may be the best. As you are jumbos you're not going to get that many more packets in without hitting 27386. Adding a whole new API involving even more locking stuff on the sockbuf would likely be counter productive, you could always switch to TCP instead.

Nick Reilly 2012-09-21T19:19:21Z Mario Charest http://community.qnx.com/sf/go/post95750 2012-09-21T19:03:51Z 2012-09-21T19:03:51Z

UDP is on NIC2 and QNET is on NICE1 so I guess having two io-pkt would help in our case. I don`t like the idea though because it creates major headache for us, but if that is the only solution ;-( > -----Message d'origine----- > De : Nick Reilly [mailto:community-noreply@qnx.com] > Envoyé : 21 septembre 2012 13:48 > À : technology-networking > Objet : Re: Not real-time enough > > Hi Mario, > Whilst some areas in io-pkt are multi-threaded, there is a single "stack > context" used for some operations within io-pkt. I believe that the issue you > are running in to is that packet reception in to the socket buffer and draining > of the socket buffer out to the application both require the stack context. Also > the receiving of packets into socket buffers is prioritised over the draining of > the socket buffers out to the application. > > If you do send enough packets in then you can end up with the socket buffer > overflowing and the packet dropping. This will show with "netstat -p udp" > showing an incrementing "dropped due to full socket buffers" count. > > Unfortunately there isn't a quick fix that I can see for this issue. The > prioritisation of reception of packets over playout to the application is deeply > embedded in io-pkt and was chosen to improve the "fastforward" throughput. > > If this is just a small overflow then increasing the size of the socket buffer may > help. Also try and ensure that the minimum number of packets are seen by io- > pkt e.g. ensure the driver isn't in promiscuous mode and limit the broadcast > traffic that it sees. > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post95747 > To cancel your subscription to this discussion, please e-mail technology- > networking-unsubscribe@community.qnx.com

Mario Charest 2012-09-21T19:03:51Z Mario Charest http://community.qnx.com/sf/go/post95749 2012-09-21T18:56:51Z 2012-09-21T18:56:51Z

Was thinking, too bad there isn`t a simple API to get all the buffered UDP packets in one call instead of having to go through multiple read(), may not fix the issue but seems to me it could maybe reduce its likelyness. > -----Message d'origine----- > De : Nick Reilly [mailto:community-noreply@qnx.com] > Envoyé : 21 septembre 2012 13:48 > À : technology-networking > Objet : Re: Not real-time enough > > Hi Mario, > Whilst some areas in io-pkt are multi-threaded, there is a single "stack > context" used for some operations within io-pkt. I believe that the issue you > are running in to is that packet reception in to the socket buffer and draining > of the socket buffer out to the application both require the stack context. Also > the receiving of packets into socket buffers is prioritised over the draining of > the socket buffers out to the application. > > If you do send enough packets in then you can end up with the socket buffer > overflowing and the packet dropping. This will show with "netstat -p udp" > showing an incrementing "dropped due to full socket buffers" count. > > Unfortunately there isn't a quick fix that I can see for this issue. The > prioritisation of reception of packets over playout to the application is deeply > embedded in io-pkt and was chosen to improve the "fastforward" throughput. > > If this is just a small overflow then increasing the size of the socket buffer may > help. Also try and ensure that the minimum number of packets are seen by io- > pkt e.g. ensure the driver isn't in promiscuous mode and limit the broadcast > traffic that it sees. > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post95747 > To cancel your subscription to this discussion, please e-mail technology- > networking-unsubscribe@community.qnx.com

Mario Charest 2012-09-21T18:56:51Z Mario Charest http://community.qnx.com/sf/go/post95748 2012-09-21T18:49:43Z 2012-09-21T18:49:43Z

Thanks for the explanation. The receive udp buffer is already set at 160k which I think is close to the maximum (not sure where this number comes from ), but given that we use jumbo frame its only about 17 packets. Any way I could use a buffer bigger then 160k. The increase potential latency wouldn`t be an issue for use. I saw a post about using net.inetd.udp.recvspace but apparently is causing problem (http://community.qnx.com/sf/discussion/do/listPosts/projects.bsp/discussion.bsp.topc21336), that post got no response. Cheers, > -----Message d'origine----- > De : Nick Reilly [mailto:community-noreply@qnx.com] > Envoyé : 21 septembre 2012 13:48 > À : technology-networking > Objet : Re: Not real-time enough > > Hi Mario, > Whilst some areas in io-pkt are multi-threaded, there is a single "stack > context" used for some operations within io-pkt. I believe that the issue you > are running in to is that packet reception in to the socket buffer and draining > of the socket buffer out to the application both require the stack context. Also > the receiving of packets into socket buffers is prioritised over the draining of > the socket buffers out to the application. > > If you do send enough packets in then you can end up with the socket buffer > overflowing and the packet dropping. This will show with "netstat -p udp" > showing an incrementing "dropped due to full socket buffers" count. > > Unfortunately there isn't a quick fix that I can see for this issue. The > prioritisation of reception of packets over playout to the application is deeply > embedded in io-pkt and was chosen to improve the "fastforward" throughput. > > If this is just a small overflow then increasing the size of the socket buffer may > help. Also try and ensure that the minimum number of packets are seen by io- > pkt e.g. ensure the driver isn't in promiscuous mode and limit the broadcast > traffic that it sees. > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post95747 > To cancel your subscription to this discussion, please e-mail technology- > networking-unsubscribe@community.qnx.com

Mario Charest 2012-09-21T18:49:43Z Nick Reilly http://community.qnx.com/sf/go/post95747 2012-09-21T17:47:45Z 2012-09-21T17:47:45Z

Hi Mario, Whilst some areas in io-pkt are multi-threaded, there is a single "stack context" used for some operations within io-pkt. I believe that the issue you are running in to is that packet reception in to the socket buffer and draining of the socket buffer out to the application both require the stack context. Also the receiving of packets into socket buffers is prioritised over the draining of the socket buffers out to the application. If you do send enough packets in then you can end up with the socket buffer overflowing and the packet dropping. This will show with "netstat -p udp" showing an incrementing "dropped due to full socket buffers" count. Unfortunately there isn't a quick fix that I can see for this issue. The prioritisation of reception of packets over playout to the application is deeply embedded in io-pkt and was chosen to improve the "fastforward" throughput. If this is just a small overflow then increasing the size of the socket buffer may help. Also try and ensure that the minimum number of packets are seen by io-pkt e.g. ensure the driver isn't in promiscuous mode and limit the broadcast traffic that it sees.

Nick Reilly 2012-09-21T17:47:45Z Mario Charest http://community.qnx.com/sf/go/post95742 2012-09-21T16:07:53Z 2012-09-21T16:07:53Z

Oups sorry: 00116551. Thanks

Mario Charest 2012-09-21T16:07:53Z Armin Steinhoff http://community.qnx.com/sf/go/post95740 2012-09-21T15:39:16Z 2012-09-21T15:39:16Z

Hi Mario, if you need a true real-time network based on Ethernet ... we will release in October the support of the fieldbus Varan: http://www.varan-bus.net/index_en.htm Cheers --Armin http://www.steinhoff-automation.com Mario Charest wrote: > Any of the network guru want to take a look at my support caser CaseID0011655. In a nutshell I have demonstrated a case where UDP packets will get drop be the stack eventhough we have a very high priority thread reading the packets. The packets are dropped because the stack is apparently busy doing something else. > > That seems very conter-intuitive and I would expect io-pkt-v4 NOT to dropped packet for that reason. > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post95739 > To cancel your subscription to this discussion, please e-mail technology-networking-unsubscribe@community.qnx.com >

Armin Steinhoff 2012-09-21T15:39:16Z Mario Charest http://community.qnx.com/sf/go/post95739 2012-09-21T15:24:26Z 2012-09-21T15:24:26Z

Any of the network guru want to take a look at my support caser CaseID0011655. In a nutshell I have demonstrated a case where UDP packets will get drop be the stack eventhough we have a very high priority thread reading the packets. The packets are dropped because the stack is apparently busy doing something else. That seems very conter-intuitive and I would expect io-pkt-v4 NOT to dropped packet for that reason.

Mario Charest 2012-09-21T15:24:26Z Boangoat Jarupan http://community.qnx.com/sf/go/post95658 2012-09-18T21:52:48Z 2012-09-18T21:52:48Z

It works now. Please also let us know once wpa_cli utility has p2p support. Thank you very much.

Boangoat Jarupan 2012-09-18T21:52:48Z Denes Pap http://community.qnx.com/sf/go/post95650 2012-09-18T18:55:16Z 2012-09-18T18:55:16Z

For a WiFi-Direct network node both interfaces tiw_p2pdev0 and tiw_p2pgrp0 need to be brought up in addition to the tiw_drv0. The IP address is assigned to the tiw_p2pgrp0 interface. The following commands can be used to configure the interfaces and start the supplicant: random -p & ifconfig tiw_drv0 up ifconfig tiw_p2pdev0 up ifconfig tiw_p2pgrp0 192.168.100.10/24 up P2P_supplicant_ti -Dwilink -itiw_p2pdev0 -c /etc/p2p.conf & The QNX stock 6.50 version of the wpa_cli utility does not support the p2p options. We are looking into adding an updated wpa_cli utility with p2p support into our wifi driver patch deliverable. As an interim solution, the wlan_cu utility can be used to establish P2P connections as follows: wlan_cu / m 2 p 1 / m 2 p 2 / m 2 p 3 08:00:28:32:DD:01 pbc go_intent=0 or / m 2 p 3 08:00:28:32:DD:01 pbc go_intent=15 To kill a connection: wlan-cu / m 2 p 5 tiw_p2pgrp0 The go_intent value of 15 is used for the Group Owner and lower values for devices. The MAC address has to be unique in the network. If two target boards are used to establish network connections, the nvs_map.bin file can be edited with a Hex Editor to give unique MAC addresses. The compile time configuration file already has the p2p options enabled: file: config_p2p # Enable P2P CONFIG_P2P=y CONFIG_AP=y Regards, Denes Pap

Denes Pap 2012-09-18T18:55:16Z Boangoat Jarupan http://community.qnx.com/sf/go/post95591 2012-09-14T19:08:12Z 2012-09-14T19:08:12Z

Hi, I include README-P2P in wpa_supplicant source code here. Seems like we need to add the following in to the .config file. CONFIG_DRIVER_NL80211=y CONFIG_CTRL_IFACE=y CONFIG_P2P=y CONFIG_AP=y CONFIG_WPS=y Since NL80211 is for linux. Here I am not sure which driver we should use. In addition, we are not sure what are other hardware (QNX related) config's that we will need for our board. Is it possible that you could add these configurations in your build and send us the binary files? Thank you.

Boangoat Jarupan 2012-09-14T19:08:12Z Boangoat Jarupan http://community.qnx.com/sf/go/post95572 2012-09-13T20:04:30Z 2012-09-13T20:04:30Z

We are trying to run some tests on peer-to-peer connection using WiFi direct protocol on TI WL1281Q. Unfortunately we cannot get other devices to see our board. We have following questions. 1. After running io-pkt-v4-hc, we got the following interfaces: lo0, tiw_drv0, tiw_sta0, tiw_sap0, tiw_p2pdev0, tiw_p2pgrp0, tiw_ibss0. Is tiw_p2pdev0 for p2p device and tiw_p2pgrp0 for group owner? Can we run these interfaces simultaneously? If so, can we use same IP address? 2. We received wpa_supplicant, P2P_supplicant, and wpa_cli binaries from QNX. What is the different from P2P_supplicant and wpa_supplicant? We got an error when we tried to run wpa_supplicant with p2p.conf. P2P_supplicant with p2p.conf works better. However, we got an error when we tried to run with wpa_cli which requires wpa_supplicant process to be run . After rename P2P_supplicant to wpa_supplicant and rerun the process as wpa_supplicant, we do not get the error message. However, wpa_cli does not give any p2p options such as p2p_find. Do we need p2p_cli binaries? Or do we need enable P2P_CONFIG in P2P_supplicant source code? Could you please check on this issue and let us know? Thank you.

Boangoat Jarupan 2012-09-13T20:04:30Z Hugh Brown http://community.qnx.com/sf/go/post95463 2012-09-10T12:07:27Z 2012-09-10T12:07:27Z

I seem to have lost the thread about the e1000 driver! Please will you try the attached driver and see if it works. On 2012-09-07 3:58 PM, "Mario Charest" <community-noreply@qnx.com> wrote: >The doc says that the qnet MTU must be the same on each machine. What's >not clear to me is does it mean havoc will ensue if not or just that >computer with different MTU will not be able to access each other? > > > > > >_______________________________________________ > >Technology >http://community.qnx.com/sf/go/post95457 >To cancel your subscription to this discussion, please e-mail >technology-networking-unsubscribe@community.qnx.com

Hugh Brown 2012-09-10T12:07:27Z Mario Charest http://community.qnx.com/sf/go/post95457 2012-09-07T19:58:48Z 2012-09-07T19:58:48Z

The doc says that the qnet MTU must be the same on each machine. What's not clear to me is does it mean havoc will ensue if not or just that computer with different MTU will not be able to access each other?

Mario Charest 2012-09-07T19:58:48Z Ole Jørgen Legård http://community.qnx.com/sf/go/post95192 2012-08-28T12:55:51Z 2012-08-28T12:55:51Z

We need to implement a custom network stack. Everything with a specific EtherType value should be routed to this network stack. How can we handled this in QNX (6.5.0)? How is e.g. IP and ARP handled (different EtherType value). What would be the proper way to do this in QNX?

Ole Jørgen Legård 2012-08-28T12:55:51Z Dennis Kellly http://community.qnx.com/sf/go/post93849 2012-06-23T20:05:11Z 2012-06-23T20:05:11Z

It's not slinger, but maybe this will meet your needs... http://dl.dropbox.com/u/13676760/howto_https.pdf

Dennis Kellly 2012-06-23T20:05:11Z Maximilian Haas http://community.qnx.com/sf/go/post93729 2012-06-18T14:48:14Z 2012-06-18T14:48:14Z

Hello, I am experencing a problem with pcap: pcap_sendpacket -1 = send failed! p(No buffer space available) the problem is - I do not know how to set/get the buffer size in QNX. So first I want to find out what buffer sizes I do have in general. Then how much I do have at the moment and - after that - increase them. Thank you for your advices :)

Maximilian Haas 2012-06-18T14:48:14Z Sophia Green http://community.qnx.com/sf/go/post93590 2012-06-08T02:58:08Z 2012-06-08T02:58:08Z

One of the best email marketing tips is to make it personalized. Email users are more likely to read an email that is addressed to them than a general one that they can tell is sent to hundreds of others, we all want to feel unique and special. In the beginning of the email place their name, the human eye catches familiar words and our names are the most familiar to us. By personalizing the email you make your client feel special and not just a number. Any client will tell you that they go back to the places that treat them like individuals rather than just a statistic. Email marketing is efficient to get traffic. I am doing email marketing for my business and website now. It brings me 500+traffic every day! I use the iKode newsletter server, it is a web based <a href="http://www.phpnewsletter.org/">email marketing software</a> for creating, maintaining and sending your mailing lists. Manage your email campaign using statistical tracking, time sensitive autoresponders, custom subscription forms, personalized mailings, advanced real time graphical reporting, and more. You can download the email marketing software!

Sophia Green 2012-06-08T02:58:08Z Karim Mouline http://community.qnx.com/sf/go/post93524 2012-06-05T17:20:55Z 2012-06-05T17:20:55Z

Hi, A customer is asking whether it is possible to create two vlan pseudo-interfaces that are associated with the same physical Ethernet interface and then use those pseudo-interfaces as parameters to the brconfig command? Or is there some other means to load balance between two pseudo-interfaces? I attached the network topology and other details below. Any suggestions are appreciated, Karim. --- START Quoting the customer Our physical network topology will look something like this (see attached .JPEG) In the diagram above, the two 10/100 links are for cabling redundancy purposes. My initial plan is to configure the switch chip with static port based VLAN ids. The VLAN ID assigned to the GE port would be either 1 or 2 depending on which 10/100 port I want to use. I plan on developing a health monitoring application that would change which VLAN the GE port is assigned to if custom heartbeat messages from other hosts are not received as expected (or if the 10/100 port link status changes). What I would really like to be able to do is to load-balance between the two 10/100 ports. I was looking at creating two VLAN pseudo-interfaces associated with the physical 1 GE interface. One of the pseudo-interfaces would be assigned to VLAN1 and the other VLAN2. (In this case, the GE switch port would be assigned to both VLAN 1 and 2). I am hoping that either the QNX network manager or the QNX Fleet product (or some other mechanism) would then be able to load balance outbound traffic between these two pseudo-interfaces. I think I would still need my custom health monitoring application to detect faults and dynamically disable the load-balancing (and try to restore load balancing). (I previously asked about bridging the pseudo-interfaces. I don't think that can be used to load-balance.) --- END Quoting the customer [Cross post from Tech Support]

Karim Mouline 2012-06-05T17:20:55Z Tony Mahieu http://community.qnx.com/sf/go/post93053 2012-05-14T15:58:26Z 2012-05-14T15:58:26Z

FYI - I posed this question to support and the answer is "no". They suggested Apache if I need SSL support.

Tony Mahieu 2012-05-14T15:58:26Z Tony Mahieu http://community.qnx.com/sf/go/post92988 2012-05-09T20:25:21Z 2012-05-09T20:25:21Z

I'm exploring the feature set of slinger, and was curious if anyone knows if you can configure slinger for https? I can't find any documentation on it, so I'm guessing the answer is no. Thanks in advance.

Tony Mahieu 2012-05-09T20:25:21Z Santhosh A http://community.qnx.com/sf/go/post92629 2012-04-19T06:44:57Z 2012-04-19T06:44:57Z

Hello, Thanks for the information. But I am new to networking, so would appreciate if you can explain this in detail. 1)))I tried to get the ether type from input_hook() as given in the article. But unable to fetch it, It looks like I am wrong and I will not get ether type information from the input_hook() as PFIL_TYPE_AF is used for getting the head of the list. Please confirm is it really possible to get the ether type information in the ethernet header using the application explained in filtering.html document. If possible, please let me know how? 2)))I was going through another discussion in this community "http://community.qnx.com/sf/discussion/do/listPosts/projects.networking/discussion.technology.topc2806?pageSize=-1#post_post8281" which says ethernet hook is possible as done in QNET. But I am not able to find any information anywhere. Please guide me on this. Thanks and warm regards, Santhosh. A

Santhosh A 2012-04-19T06:44:57Z Hugh Brown http://community.qnx.com/sf/go/post92600 2012-04-18T11:58:10Z 2012-04-18T11:58:10Z

You can either do this in the driver or use the packet filtering interface you described below. It's your decision. -- Hugh Brown QNX Software Systems Limited 1001 Farrar Rd., Ottawa. ON. K2K 0B3. Telephone: 613-591-0931 On 12-04-17 11:21 PM, "Santhosh A" <community-noreply@qnx.com> wrote: >Hello, > >Thanks for the reply. > >I am using P1020RDB and QNX6.5.0. > >In the build file the below command exists fro io-pkt, >io-pkt-v4-hc -d mpc85xx emu_phy=0 > >With your reply, did you mean that this need to be done in the mpc85xx >driver? > >I also saw a document in the QNX commmunicty help as given below. >http://community.qnx.com/sf/wiki/do/viewPage/projects.networking/wiki/Filt >ering_wiki_page > >In this, if all packets that move in and out of tsec0 ethernet interface, >then Is it possible for me do this ether type updation in the packet at >the below function? > >"static int output_hook(void *arg, struct mbuf **m, struct ifnet *ifp, >int dir)" > >Please clarify. > >Thanks and warm regards, >Santhosh. A > > > > >_______________________________________________ > >Technology >http://community.qnx.com/sf/go/post92594 >

Hugh Brown 2012-04-18T11:58:10Z Santhosh A http://community.qnx.com/sf/go/post92594 2012-04-18T03:21:19Z 2012-04-18T03:21:19Z

Hello, Thanks for the reply. I am using P1020RDB and QNX6.5.0. In the build file the below command exists fro io-pkt, io-pkt-v4-hc -d mpc85xx emu_phy=0 With your reply, did you mean that this need to be done in the mpc85xx driver? I also saw a document in the QNX commmunicty help as given below. http://community.qnx.com/sf/wiki/do/viewPage/projects.networking/wiki/Filtering_wiki_page In this, if all packets that move in and out of tsec0 ethernet interface, then Is it possible for me do this ether type updation in the packet at the below function? "static int output_hook(void *arg, struct mbuf **m, struct ifnet *ifp, int dir)" Please clarify. Thanks and warm regards, Santhosh. A

Santhosh A 2012-04-18T03:21:19Z Hugh Brown http://community.qnx.com/sf/go/post92586 2012-04-17T18:43:06Z 2012-04-17T18:43:06Z

These changes will need to be made at the driver level. -- Hugh Brown QNX Software Systems Limited 1001 Farrar Rd., Ottawa. ON. K2K 0B3. Telephone: 613-591-0931 On 12-04-17 5:54 AM, "Santhosh A" <community-noreply@qnx.com> wrote: >Hello, > >I want to change the ether type parameter of the ethernet header of >ethernet packet. This needs to be done for all the ethernet packets that >moves out of the ethernet interface. > >Similarly all the ethernet packets received at an interface need to be >verified with its ether type at its ethernet header and if it matches >with the custom ether type id, then only it need to be send to the stack. > Else that packet needs to be discarded. > >Can anyone please suggest me how to do these above two requirements? > >Warm regards, >Santhosh. A > > > >_______________________________________________ > >Technology >http://community.qnx.com/sf/go/post92576 >

Hugh Brown 2012-04-17T18:43:06Z Santhosh A http://community.qnx.com/sf/go/post92576 2012-04-17T09:54:25Z 2012-04-17T09:54:25Z

Hello, I want to change the ether type parameter of the ethernet header of ethernet packet. This needs to be done for all the ethernet packets that moves out of the ethernet interface. Similarly all the ethernet packets received at an interface need to be verified with its ether type at its ethernet header and if it matches with the custom ether type id, then only it need to be send to the stack. Else that packet needs to be discarded. Can anyone please suggest me how to do these above two requirements? Warm regards, Santhosh. A

Santhosh A 2012-04-17T09:54:25Z Andrew Sherk http://community.qnx.com/sf/go/post92458 2012-04-04T16:25:28Z 2012-04-04T16:25:28Z

Thanks all for the suggestions. The /etc/resolv.conf doc mentions dhcp.client, and 'use dhcp.client' describes the '-m' option: -m Write resolv.conf data as in-memory configuration strings (Neutrino only, default is off) Using dhcp.client -m seems to do the trick when /etc/resolv.conf isn't available. -asherk -----Original Message----- From: Hugh Brown [mailto:community-noreply@qnx.com] Sent: Wednesday, April 04, 2012 11:11 AM To: technology-networking Subject: Re: what binaries are required for domain name resolution I think that you need to have a writeable /etc/resolv.conf file. -- Hugh Brown QNX Software Systems Limited 1001 Farrar Rd., Ottawa. ON. K2K 0B3. Telephone: 613-591-0931 On 12-04-04 11:06 AM, "Andrew Sherk" <community-noreply@qnx.com> wrote: >Hi, > >With io-pkt-v4 and dhcp.client to get an IP address, what additional >binaries are needed so that domain name lookups succeed? > >e.g. > ># ping foo >ping: Cannot resolve "foo" (Host name lookup failure) > >When I mount the HDD with my SDP install the look up succeeds, so it >appears a binary is needed, but I'm not sure which one. > >-asherk > > > >_______________________________________________ > >Technology >http://community.qnx.com/sf/go/post92454 > _______________________________________________ Technology http://community.qnx.com/sf/go/post92456

Andrew Sherk 2012-04-04T16:25:28Z Jeevan Mathew(deleted) http://community.qnx.com/sf/go/post92457 2012-04-04T15:12:47Z 2012-04-04T15:12:47Z

Pidin mem from ok system and not ok system as starting point + /etc/hosts config file. Perhaps? J. From BB. ----- Originalnachricht ----- Von: Andrew Sherk [mailto:community-noreply@qnx.com] Gesendet: Wednesday, April 04, 2012 11:06 AM An: technology-networking <post92454@community.qnx.com> Betreff: what binaries are required for domain name resolution Hi, With io-pkt-v4 and dhcp.client to get an IP address, what additional binaries are needed so that domain name lookups succeed? e.g. # ping foo ping: Cannot resolve "foo" (Host name lookup failure) When I mount the HDD with my SDP install the look up succeeds, so it appears a binary is needed, but I'm not sure which one. -asherk _______________________________________________ Technology http://community.qnx.com/sf/go/post92454

Jeevan Mathew(deleted) 2012-04-04T15:12:47Z Hugh Brown http://community.qnx.com/sf/go/post92456 2012-04-04T15:10:35Z 2012-04-04T15:10:35Z

I think that you need to have a writeable /etc/resolv.conf file. -- Hugh Brown QNX Software Systems Limited 1001 Farrar Rd., Ottawa. ON. K2K 0B3. Telephone: 613-591-0931 On 12-04-04 11:06 AM, "Andrew Sherk" <community-noreply@qnx.com> wrote: >Hi, > >With io-pkt-v4 and dhcp.client to get an IP address, what additional >binaries are needed so that domain name lookups succeed? > >e.g. > ># ping foo >ping: Cannot resolve "foo" (Host name lookup failure) > >When I mount the HDD with my SDP install the look up succeeds, so it >appears a binary is needed, but I'm not sure which one. > >-asherk > > > >_______________________________________________ > >Technology >http://community.qnx.com/sf/go/post92454 >

Hugh Brown 2012-04-04T15:10:35Z Sean Boudreau http://community.qnx.com/sf/go/post92455 2012-04-04T15:10:12Z 2012-04-04T15:10:12Z

The resolver library is part of libsocket, so if ping runs at all you have it. Check out the docs for /etc/resolv.conf. Regards, -seanb On Wed, Apr 04, 2012 at 11:06:37AM -0400, Andrew Sherk wrote: > Hi, > > With io-pkt-v4 and dhcp.client to get an IP address, what additional binaries are needed so that domain name lookups succeed? > > e.g. > > # ping foo > ping: Cannot resolve "foo" (Host name lookup failure) > > When I mount the HDD with my SDP install the look up succeeds, so it appears a binary is needed, but I'm not sure which one. > > -asherk > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post92454 >

Sean Boudreau 2012-04-04T15:10:12Z Andrew Sherk http://community.qnx.com/sf/go/post92454 2012-04-04T15:06:35Z 2012-04-04T15:06:35Z

Hi, With io-pkt-v4 and dhcp.client to get an IP address, what additional binaries are needed so that domain name lookups succeed? e.g. # ping foo ping: Cannot resolve "foo" (Host name lookup failure) When I mount the HDD with my SDP install the look up succeeds, so it appears a binary is needed, but I'm not sure which one. -asherk

Andrew Sherk 2012-04-04T15:06:35Z sudhir katta http://community.qnx.com/sf/go/post91403 2012-02-08T03:11:15Z 2012-02-08T03:11:15Z

Thanks for the replies. It worked -- started Slinger after defining environment variables. Thanks Sudhir

sudhir katta 2012-02-08T03:11:15Z Steve Reid http://community.qnx.com/sf/go/post91396 2012-02-07T21:04:13Z 2012-02-07T21:04:13Z

I think you have to start Slinger after you define the environment variables. Steve Reid (stever@qnx.com) Technical Editor QNX Software Systems -----Original Message----- From: sudhir katta [mailto:community-noreply@qnx.com] Sent: Tuesday, February 07, 2012 3:40 PM To: technology-networking Subject: Slinger - Installation Hi, I have configured Slinger from the documentation but still cant access the html pages. 1. I can ssh and ping QNX system (192.168.1.100) that means TCP/IP stack is running 2. Slinger & -- I'm stating the slinger at bootup from /etc/rc.d/rc.local. ps -e shows slinger is running 3. export HTTPD_ROOT_DIR=/usr/local/httpd export HTTPD_ROOT_DOC=index.html My understanding is that running TCP/IP stack automatically enables sockets. I'm I missing something. Please help. Thanks Sudhir _______________________________________________ Technology http://community.qnx.com/sf/go/post91394

Steve Reid 2012-02-07T21:04:13Z Dennis Kellly http://community.qnx.com/sf/go/post91395 2012-02-07T21:00:42Z 2012-02-07T21:00:42Z

Are you exporting the HTTPD variables BEFORE your start slinger? You have the "export"s listed after...

Dennis Kellly 2012-02-07T21:00:42Z sudhir katta http://community.qnx.com/sf/go/post91394 2012-02-07T20:40:27Z 2012-02-07T20:40:27Z

Hi, I have configured Slinger from the documentation but still cant access the html pages. 1. I can ssh and ping QNX system (192.168.1.100) that means TCP/IP stack is running 2. Slinger & -- I'm stating the slinger at bootup from /etc/rc.d/rc.local. ps -e shows slinger is running 3. export HTTPD_ROOT_DIR=/usr/local/httpd export HTTPD_ROOT_DOC=index.html My understanding is that running TCP/IP stack automatically enables sockets. I'm I missing something. Please help. Thanks Sudhir

sudhir katta 2012-02-07T20:40:27Z David Terry http://community.qnx.com/sf/go/post91258 2012-01-31T20:01:24Z 2012-01-31T20:01:24Z

Is there any support now or in the works for IGMP v3 in io-pkt? Alternately, is there any workaround for the current protocol stack? I need a QNX6.5 host to receive multicast packets from a router running PIM-SSM. DT

David Terry 2012-01-31T20:01:24Z Wen Xu http://community.qnx.com/sf/go/post90903 2012-01-10T23:36:03Z 2012-01-10T23:36:03Z

Hi, The following is the code piece used to set the IP address of one physcial interface, say e0. It works well. struct ifreq niIfreq; long socketId; struct sockaddr_in addr_in; memset (&addr_in, 0, sizeof(struct sockaddr_in)); memset (&niIfreq, 0, sizeof(struct ifreq)); addr_in.sin_family = AF_INET; addr_in.sin_addr.s_addr = htonl (INADDR_ANY); addr_in.sin_port = htons (5000); socketId = socket(AF_INET, SOCK_DGRAM, 0); bind(socketId, (struct sockaddr *)&addr_in, sizeof(struct sockaddr_in)); strncpy(niIfreq.ifr_name, "en0", sizeof("en0")); niIfreq.ifr_ifru.ifru_addr.sa_len = 6; niIfreq.ifr_ifru.ifru_addr.sa_family = 0; niIfreq.ifr_ifru.ifru_addr.sa_data[0] = (uint8_t)0x00; niIfreq.ifr_ifru.ifru_addr.sa_data[1] = (uint8_t)0x00; niIfreq.ifr_ifru.ifru_addr.sa_data[2] = (uint8_t)0x0B; niIfreq.ifr_ifru.ifru_addr.sa_data[3] = (uint8_t)0x05; niIfreq.ifr_ifru.ifru_addr.sa_data[4] = (uint8_t)0x00; niIfreq.ifr_ifru.ifru_addr.sa_data[5] = (uint8_t)0x06; ioctl(socketId, SIOCSIFNETMASK, &niIfreq); ############### Question, is it possible to write to simple data struct of the same niIfreq to achive the result of the following commad? e.g the code to realize "ifconfig en0 alias xx.xx.xx.xx". if not, what should be the code? Thanks in advance.

Wen Xu 2012-01-10T23:36:03Z Wen Xu http://community.qnx.com/sf/go/post90734 2011-12-22T03:50:36Z 2011-12-22T03:50:36Z

Sean, in the other post, there seems to be the similar problem: http://community.qnx.com/sf/discussion/do/listPosts/projects.networking/discussion.technology.topc3860 The thing I don't understand is that Santosh said he used " revision 400 of trunk".. What is that? In my case, the two boxes are plugged into two ports of a same switch. I don't know whether the switch has dot1q vlan enabled. If both boxes can ping each other with IP addr associated with physical interfaces. However if they use VLAN interfaces (on the same vlan),they cannot ping each other. Thanks and happy holidays!

Wen Xu 2011-12-22T03:50:36Z Wen Xu http://community.qnx.com/sf/go/post90731 2011-12-21T22:43:20Z 2011-12-21T22:43:20Z

Sean, if I configure the same IPs on the physical itnerfaces, ping works well. e.g. one box: # ifconfig -a lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 en0: flags=80008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,SHIM> mtu 1500 address: 00:22:e5:1f:1a:4c media: Ethernet none full-duplex status: active inet 10.4.0.14 netmask 0xfffe0000 broadcast 10.5.255.255 # ping 10.4.0.10 PING 10.4.0.10 (10.4.0.10): 56 data bytes ----10.4.0.10 PING Statistics---- 8 packets transmitted, 8 packets received, 0% packet loss round-trip min/avg/max = 2/5/20 ms variance = 39 ms^2 ######## The other box: # ifconfig -a lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 en0: flags=80008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,SHIM> mtu 1500 address: 00:22:e5:1f:12:ea media: Ethernet 100baseTX full-duplex status: active inet 10.4.0.10 netmask 0xfffe0000 broadcast 10.5.255.255 # ping 10.4.0.14 PING 10.4.0.14 (10.4.0.14): 56 data bytes 64 bytes from 10.4.0.14: icmp_seq=0 ttl=128 time=1 ms 64 bytes from 10.4.0.14: icmp_seq=1 ttl=255 time=1 ms ----10.4.0.14 PING Statistics---- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 1/1/1 ms variance = 0 ms^2

Wen Xu 2011-12-21T22:43:20Z Wen Xu http://community.qnx.com/sf/go/post90730 2011-12-21T22:18:11Z 2011-12-21T22:18:11Z

Sean, I set up another box with similar configuration, both on vlan 2. But they still could not ping each other. The two boxes are connected to the same LAN. e.g. one box: # ifconfig -a lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 en0: flags=80008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,SHIM> mtu 1 address: 00:22:e5:1f:1a:4c media: Ethernet none full-duplex status: active vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1496 vlan: 2 parent: en0 address: 00:22:e5:1f:1a:4c inet 10.4.0.14 netmask 0xff000000 broadcast 10.255.255.255 # ping 10.4.0.10 PING 10.4.0.10 (10.4.0.10): 56 data bytes ----10.4.0.10 PING Statistics---- 76 packets transmitted, 0 packets received, 100% packet loss ######### the other box # ifconfig -a lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 en0: flags=80008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,SHIM> mtu 1500 address: 00:22:e5:1f:12:ea media: Ethernet 100baseTX full-duplex status: active vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1496 vlan: 2 parent: en0 address: 00:22:e5:1f:12:ea inet 10.4.0.10 netmask 0xff000000 broadcast 10.255.255.255 # ping 10.4.0.14 PING 10.4.0.14 (10.4.0.14): 56 data bytes ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ping: sendto: Host is down ... ----10.4.0.14 PING Statistics---- 30 packets transmitted, 0 packets received, 100% packet loss ########### Anything is wrong with the configuration? Thanks.

Wen Xu 2011-12-21T22:18:11Z Sean Boudreau http://community.qnx.com/sf/go/post90703 2011-12-20T23:40:45Z 2011-12-20T23:40:45Z

The host in question has to be on the same vlan. Regards, -seanb ----- Original Message ----- From: Wen Xu [mailto:community-noreply@qnx.com] Sent: Tuesday, December 20, 2011 05:35 PM To: technology-networking <post90702@community.qnx.com> Subject: Re: how to use psudo-interface instead of physcial interface to network Hi Sean. Thank you for your reply. I tried the "delete". The host could not ping outside any more. e.g. # ifconfig -a lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 en0: flags=80008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,SHIM> mtu 1500 address: 00:22:e5:1f:12:ea media: Ethernet 100baseTX full-duplex status: active inet 10.4.0.10 netmask 0xfffe0000 broadcast 10.5.255.255 vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1496 vlan: 2 parent: en0 address: 00:22:e5:1f:12:ea inet 10.4.0.20 netmask 0xff000000 broadcast 10.255.255.255 # ping 10.4.0.6 PING 10.4.0.6 (10.4.0.6): 56 data bytes 64 bytes from 10.4.0.6: icmp_seq=0 ttl=128 time=0 ms 64 bytes from 10.4.0.6: icmp_seq=1 ttl=128 time=0 ms 64 bytes from 10.4.0.6: icmp_seq=2 ttl=128 time=0 ms 64 bytes from 10.4.0.6: icmp_seq=3 ttl=128 time=0 ms ----10.4.0.6 PING Statistics---- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0/0/0 ms variance = 0 ms^2 # ifconfig en0 delete # ifconfig -a lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 en0: flags=80008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,SHIM> address: 00:22:e5:1f:12:ea media: Ethernet 100baseTX full-duplex status: active vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 14 vlan: 2 parent: en0 address: 00:22:e5:1f:12:ea inet 10.4.0.20 netmask 0xff000000 broadcast 10.255.255.2 # # # ping 10.4.0.6 PING 10.4.0.6 (10.4.0.6): 56 data bytes ping: sendto: Host is down ping: sendto: Host is down ----10.4.0.6 PING Statistics---- 6 packets transmitted, 0 packets received, 100% packet loss _______________________________________________ Technology http://community.qnx.com/sf/go/post90702

Sean Boudreau 2011-12-20T23:40:45Z Wen Xu http://community.qnx.com/sf/go/post90702 2011-12-20T22:35:19Z 2011-12-20T22:35:19Z

Hi Sean. Thank you for your reply. I tried the "delete". The host could not ping outside any more. e.g. # ifconfig -a lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 en0: flags=80008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,SHIM> mtu 1500 address: 00:22:e5:1f:12:ea media: Ethernet 100baseTX full-duplex status: active inet 10.4.0.10 netmask 0xfffe0000 broadcast 10.5.255.255 vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1496 vlan: 2 parent: en0 address: 00:22:e5:1f:12:ea inet 10.4.0.20 netmask 0xff000000 broadcast 10.255.255.255 # ping 10.4.0.6 PING 10.4.0.6 (10.4.0.6): 56 data bytes 64 bytes from 10.4.0.6: icmp_seq=0 ttl=128 time=0 ms 64 bytes from 10.4.0.6: icmp_seq=1 ttl=128 time=0 ms 64 bytes from 10.4.0.6: icmp_seq=2 ttl=128 time=0 ms 64 bytes from 10.4.0.6: icmp_seq=3 ttl=128 time=0 ms ----10.4.0.6 PING Statistics---- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0/0/0 ms variance = 0 ms^2 # ifconfig en0 delete # ifconfig -a lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 en0: flags=80008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,SHIM> address: 00:22:e5:1f:12:ea media: Ethernet 100baseTX full-duplex status: active vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 14 vlan: 2 parent: en0 address: 00:22:e5:1f:12:ea inet 10.4.0.20 netmask 0xff000000 broadcast 10.255.255.2 # # # ping 10.4.0.6 PING 10.4.0.6 (10.4.0.6): 56 data bytes ping: sendto: Host is down ping: sendto: Host is down ----10.4.0.6 PING Statistics---- 6 packets transmitted, 0 packets received, 100% packet loss

Wen Xu 2011-12-20T22:35:19Z Sean Boudreau http://community.qnx.com/sf/go/post90700 2011-12-20T21:14:56Z 2011-12-20T21:14:56Z

Never assign one to en0 to begin with or: # ifconfig en0 delete Or # ifconfig en0 -alias 10.4.0.10 -seanb ----- Original Message ----- From: Wen Xu [mailto:community-noreply@qnx.com] Sent: Tuesday, December 20, 2011 04:02 PM To: technology-networking <post90699@community.qnx.com> Subject: how to use psudo-interface instead of physcial interface to network Hi, the scenario is that the physical interface en0 is up and configured. The host can reach and be reachable though the IP address that configured on en0, e.g. 10.4.0.10 My intention is to remove the IP associate with the physical interface. Instead, I want to create some vlan interfaces over parent interface en0, say Vlan0. I configure it's IP address as 10.4.0.20, which is on the same 10.4.x.x lan segment. However this IP is not pingable from outside. This is the original ifconfig: # ifconfig -a lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 en0: flags=80008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,SHIM> mtu 1500 address: 00:22:e5:1f:12:ea media: Ethernet 100baseTX full-duplex status: active inet 10.4.0.10 netmask 0xfffe0000 broadcast 10.5.255.255 Then I create psudo interface vlan0 with vlan number 2 on parent interface en0. And then I give it the IP address 10.4.0.20 and netmask 255.254.0.0 #ifconfig vlan0 create #ifconfig vlan0 vlan2 vlanif en0 #ifconfig vlan0 10.4.0.20 #ifconfig vlan0 netmask 255.254.0.0 The current configuration is: # ifconfig -a lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 en0: flags=80008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,SHIM> mtu 1500 address: 00:22:e5:1f:12:ea media: Ethernet 100baseTX full-duplex status: active inet 10.4.0.10 netmask 0xfffe0000 broadcast 10.5.255.255 vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1496 vlan: 2 parent: en0 address: 00:22:e5:1f:12:ea inet 10.4.0.20 netmask 0xff000000 broadcast 10.255.255.255 My questions is how to remove the IP from the physical interface en0 and then make the host comunicate with outside with 10.4.0.20 (vlan0)? _______________________________________________ Technology http://community.qnx.com/sf/go/post90699

Sean Boudreau 2011-12-20T21:14:56Z Wen Xu http://community.qnx.com/sf/go/post90699 2011-12-20T21:02:55Z 2011-12-20T21:02:55Z

Hi, the scenario is that the physical interface en0 is up and configured. The host can reach and be reachable though the IP address that configured on en0, e.g. 10.4.0.10 My intention is to remove the IP associate with the physical interface. Instead, I want to create some vlan interfaces over parent interface en0, say Vlan0. I configure it's IP address as 10.4.0.20, which is on the same 10.4.x.x lan segment. However this IP is not pingable from outside. This is the original ifconfig: # ifconfig -a lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 en0: flags=80008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,SHIM> mtu 1500 address: 00:22:e5:1f:12:ea media: Ethernet 100baseTX full-duplex status: active inet 10.4.0.10 netmask 0xfffe0000 broadcast 10.5.255.255 Then I create psudo interface vlan0 with vlan number 2 on parent interface en0. And then I give it the IP address 10.4.0.20 and netmask 255.254.0.0 #ifconfig vlan0 create #ifconfig vlan0 vlan2 vlanif en0 #ifconfig vlan0 10.4.0.20 #ifconfig vlan0 netmask 255.254.0.0 The current configuration is: # ifconfig -a lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 en0: flags=80008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,SHIM> mtu 1500 address: 00:22:e5:1f:12:ea media: Ethernet 100baseTX full-duplex status: active inet 10.4.0.10 netmask 0xfffe0000 broadcast 10.5.255.255 vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1496 vlan: 2 parent: en0 address: 00:22:e5:1f:12:ea inet 10.4.0.20 netmask 0xff000000 broadcast 10.255.255.255 My questions is how to remove the IP from the physical interface en0 and then make the host comunicate with outside with 10.4.0.20 (vlan0)?

Wen Xu 2011-12-20T21:02:55Z Vasiliy Pupkin http://community.qnx.com/sf/go/post90689 2011-12-20T08:31:22Z 2011-12-20T08:31:22Z

So, what is the current status of agr(4) porting? Does it work? I'm interested in Ethernet link bonding too.

Vasiliy Pupkin 2011-12-20T08:31:22Z lei zhou http://community.qnx.com/sf/go/post89819 2011-11-02T07:26:57Z 2011-11-02T07:26:57Z

I checked manual for racoon and didn't understand how to do this. Racoon can support the following authentication_method : pre_shared_key rsasig gssapi_krb From the manual, seems rassig is for RSA signature, but not RSA-encrypted nonces. Anyone can help me with this question? That will be greate help if provide a example. THanks

lei zhou 2011-11-02T07:26:57Z Mohammad Adeel Mian http://community.qnx.com/sf/go/post89704 2011-10-27T21:52:05Z 2011-10-27T21:52:05Z

Hi, I'm trying to establish 2 simultaneous FTP sessions but I'm facing some probelms mapping the interface with the IP address and declaring the route. The first session connects and I'm able to download but the second session fails to connect with the FTP server. I'm using the following commands: For first session: ifconfig [interface1] [Gateway_IP_Address1] route add [FTP_Server1_IP_Address] -interface [Gateway_IP_Address1] setconf CS_RESOLVE nameserver_[DNS ADDRESS] ftp [FTP_Server1_IP_Address] For second session: ifconfig [interface2] [Gateway_IP_Address2] route add [FTP_Server2_IP_Address] -interface [Gateway_IP_Address2] setconf CS_RESOLVE nameserver_[DNS ADDRESS] ftp [FTP_Server2_IP_Address] I've seen that the if the two FTP servers (ex: 192.168.0.100 & 192.168.0.102) and Gateway_IP_Addresses (ex: 192.168.0.105 & 192.168.0.106) are on the same subnet, adding the first route results in the following entry in the routing table: (destination) 192.168.0.0/24 --> (gateway) 192.168.0.105 This I beleive might be the reason why the I am not able to connect to the second FTP server (correct?). Also since both the gateway IP address are of the same subnet, the network mask is also the same. How can this issue be resolved. Thanks!

Mohammad Adeel Mian 2011-10-27T21:52:05Z Poul Christiansen http://community.qnx.com/sf/go/post88893 2011-09-16T13:05:57Z 2011-09-16T13:05:57Z

Ahh, great, thanks. I'll be creating new devices because I still need 127.0.0.1 (and .3 and .4). I am trying to get some multicasting setup to work Thanks for the quick answer.

Poul Christiansen 2011-09-16T13:05:57Z Sean Boudreau http://community.qnx.com/sf/go/post88892 2011-09-16T12:18:46Z 2011-09-16T12:18:46Z

You're missing the address locally. No interface has been assigned that address: # ifconfig lo0 127.0.0.2 Or if you want both 127.0.0.[12] # ifconfig lo0 alias 127.0.0.2 (or) # ifconfig lo1 create # ifconfig lo1 127.0.0.2 A straight 'ifconfig' will show all the interfaces with their addresses. Regards, -seanb ----- Original Message ----- From: Poul Christiansen [mailto:community-noreply@qnx.com] Sent: Friday, September 16, 2011 04:59 AM To: technology-networking <post88885@community.qnx.com> Subject: bind() to "127.0.0.x" (x > 1) Hi I'm trying to bind a socket to "127.0.0.2" (port 10001), but failing with errno == EADDRNOTAVAIL, "Can't assign requested address"... It obviously works with the normal default localhost 127.0.0.1, but seems to fail for any other 127.0.0.x address. It's is my impression that it should work and it works on Windows. Am I missing a route? Best Regards Poul Christiansen _______________________________________________ Technology http://community.qnx.com/sf/go/post88885

Sean Boudreau 2011-09-16T12:18:46Z Poul Christiansen http://community.qnx.com/sf/go/post88885 2011-09-16T08:59:52Z 2011-09-16T08:59:52Z

Hi I'm trying to bind a socket to "127.0.0.2" (port 10001), but failing with errno == EADDRNOTAVAIL, "Can't assign requested address"... It obviously works with the normal default localhost 127.0.0.1, but seems to fail for any other 127.0.0.x address. It's is my impression that it should work and it works on Windows. Am I missing a route? Best Regards Poul Christiansen

Poul Christiansen 2011-09-16T08:59:52Z Sean Boudreau http://community.qnx.com/sf/go/post88555 2011-08-31T20:51:22Z 2011-08-31T20:51:22Z

Hi, Please read the whole thread. We have the ability to send raw packets in bpf. It's not fully supported in 6.3.2 and it's not the linux interface. The next version will also have tun / tap. Regards, -seanb On Wed, Aug 31, 2011 at 04:06:11PM -0400, Armin Steinhoff wrote: > Sean Boudreau wrote: > > It's true of io-pkt which wasn't released under 6.3.2. It's > theoretically possible > > It's not theoretical issue ... it's simply possible to implement a raw > > socket interface. > I see here customers asking for a raw socket interface since more than > 20 years .... how long will you ingnore your customers needs ? > > --Armin > > > to run it under that version but that's not a supported or tested > configuration. > > > > Regards, > > > > -seanb > > > > ----- Original Message ----- > > From: Phil Shiel [mailto:community-noreply@qnx.com] > > Sent: Wednesday, August 10, 2011 09:10 AM > > To: technology-networking<post87976@community.qnx.com> > > Subject: Re: Raw (Ethernet) Sockets over io-net net stack on QNX 6.3.2 > > > > Hi Sean, > > > > Is this true for all versions of QNX? Can I do the same with 6.3.2 as > I can do with 6.5? Or is an upgrade required? > > > > Phil > > > > > > > > > > > > > > _______________________________________________ > > > > Technology > > http://community.qnx.com/sf/go/post87976 > > > > > > > > > > _______________________________________________ > > > > Technology > > http://community.qnx.com/sf/go/post87978 > > > > > > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post88551 >

Sean Boudreau 2011-08-31T20:51:22Z Armin Steinhoff http://community.qnx.com/sf/go/post88551 2011-08-31T20:06:09Z 2011-08-31T20:06:09Z

Sean Boudreau wrote: > It's true of io-pkt which wasn't released under 6.3.2. It's theoretically possible It's not theoretical issue ... it's simply possible to implement a raw socket interface. I see here customers asking for a raw socket interface since more than 20 years .... how long will you ingnore your customers needs ? --Armin > to run it under that version but that's not a supported or tested configuration. > > Regards, > > -seanb > > ----- Original Message ----- > From: Phil Shiel [mailto:community-noreply@qnx.com] > Sent: Wednesday, August 10, 2011 09:10 AM > To: technology-networking<post87976@community.qnx.com> > Subject: Re: Raw (Ethernet) Sockets over io-net net stack on QNX 6.3.2 > > Hi Sean, > > Is this true for all versions of QNX? Can I do the same with 6.3.2 as I can do with 6.5? Or is an upgrade required? > > Phil > > > > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post87976 > > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post87978 > >

Armin Steinhoff 2011-08-31T20:06:09Z CRK CRK http://community.qnx.com/sf/go/post88349 2011-08-25T12:20:04Z 2011-08-25T12:20:04Z

We have MPC8548CDS eval board. How to configure all the 4 tsec port to be in same subnet so that that all the 4 tsec ports are pingable from externally connected devices. for example the assigned address may be: tsec0 172.195.51.2 tsec1 172.195.51.3 tsec2 172.195.51.4 tsec3 172.195.51.5 The question might be wrong from concept wise, but still I request to comment. Chandrashekhar Bangalore India

CRK CRK 2011-08-25T12:20:04Z CRK CRK http://community.qnx.com/sf/go/post88348 2011-08-25T12:13:47Z 2011-08-25T12:13:47Z

I was trying to use the example given in the packet filtering section: http://www.qnx.com/developers/docs/6.4.1/io-pkt_en/user_guide/filtering.html. I need to build and test the functionality of this example, after which I will be using it to implement customized functionality. The above link does not document as how to build the example to create Loadable Shared Modules (lsm) and use it. Kindly give the procedure to build the above example. If there are any sample examples to create lsm modules please share so that I can try use the above example. Thanks and Regards Chandrashekhrar Bangalore India.

CRK CRK 2011-08-25T12:13:47Z Vineet Garg http://community.qnx.com/sf/go/post88110 2011-08-16T03:21:32Z 2011-08-16T03:21:32Z

No Phil, I did not refer to BPF, I meant custom module written to be plugged in at runtime into qnx io-net framework. Look around for up-filter in qnx networking documentation....... On Mon, Aug 15, 2011 at 11:01 AM, Phil Shiel <community-noreply@qnx.com> wrote: > > By network filter I assume you don't mean BPF. > > If I understand things correctly BPF (Berkley Packet Filter) can only be used at 6.3.2 to read raw packets not send them, or has this changed? > > Phil > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post88105 > >

Vineet Garg 2011-08-16T03:21:32Z Phil Shiel http://community.qnx.com/sf/go/post88105 2011-08-15T15:01:40Z 2011-08-15T15:01:40Z

By network filter I assume you don't mean BPF. If I understand things correctly BPF (Berkley Packet Filter) can only be used at 6.3.2 to read raw packets not send them, or has this changed? Phil

Phil Shiel 2011-08-15T15:01:40Z Senthil Kumar http://community.qnx.com/sf/go/post88050 2011-08-12T08:33:39Z 2011-08-12T08:33:39Z

A Customer asked here.. Which version of the SSL (Secure Socket Layer) is used in QNX network protocol suite? Version 3.3 seems to be the latest one. Any idea which version we use?

Senthil Kumar 2011-08-12T08:33:39Z Dave Bott(deleted) http://community.qnx.com/sf/go/post87995 2011-08-10T22:05:36Z 2011-08-10T22:05:36Z

Hi 6.5.0 X86 A prospect is asking about what RFC1323 support, if any we have, and also whether we implement any DSCP capabilities. I see an option in sysctl for window scaling, which is (I'm told) part of 1323, but the field is undocumented - no choices, or meaning of what it does is documented. Prospect specifically asks: "Do you support any RFC1323 enhancements (SACK, advanced RTT, PAWS, etc.), " DSCP is a QoS method, as described here: http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a00800949f2.shtml [I think we did this for one of my customers once, but is it in our product ?] One last question - what SNMPv3 solution would we recommend today ? Thanks ! Dave

Dave Bott(deleted) 2011-08-10T22:05:36Z Vineet Garg http://community.qnx.com/sf/go/post87985 2011-08-10T16:05:26Z 2011-08-10T16:05:26Z

Hi Phil We achieved similar functionality on io-net using io-net filter module such that is has ethernet below it and IP above it. so, this way we can get access to all ethernet frames entering the system and can generate ethernet frames of our own. Other scenario is hacking the network driver code but that might not be a great design. HTH Vineet On Wed, Aug 10, 2011 at 8:39 AM, Phil Shiel <community-noreply@qnx.com> wrote: > > Hi, > > I am attempting to port an application to run under QNX version 6.3.2. > The application makes use of the socket(AF_PACKET,SOCK_RAW,0) function call to allow it to create its own ethernet based protocol packets. It also makes use of QOS and VLANs in the extended ethernet header. > > As far as I can see this functionality does not seem to exist in the io-net network stack include with 6.3.2 , so my question is what is the best approach I should take to migrate the application. > > Do later version of QNX support this functionality? I know there is a new network stack;- io-pkt. Does this give me what I need, and because we are stuck as 6.3.2 is it possible to migrate this stack to run under 6.3.2? > > Any ideas, suggestions would be greatly appreciated!! > > Thanks > > Phil > > > > > > > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post87971 > >

Vineet Garg 2011-08-10T16:05:26Z Sean Boudreau http://community.qnx.com/sf/go/post87978 2011-08-10T13:32:38Z 2011-08-10T13:32:38Z

It's true of io-pkt which wasn't released under 6.3.2. It's theoretically possible to run it under that version but that's not a supported or tested configuration. Regards, -seanb ----- Original Message ----- From: Phil Shiel [mailto:community-noreply@qnx.com] Sent: Wednesday, August 10, 2011 09:10 AM To: technology-networking <post87976@community.qnx.com> Subject: Re: Raw (Ethernet) Sockets over io-net net stack on QNX 6.3.2 Hi Sean, Is this true for all versions of QNX? Can I do the same with 6.3.2 as I can do with 6.5? Or is an upgrade required? Phil _______________________________________________ Technology http://community.qnx.com/sf/go/post87976

Sean Boudreau 2011-08-10T13:32:38Z Phil Shiel http://community.qnx.com/sf/go/post87976 2011-08-10T13:10:09Z 2011-08-10T13:10:09Z

Hi Sean, Is this true for all versions of QNX? Can I do the same with 6.3.2 as I can do with 6.5? Or is an upgrade required? Phil

Phil Shiel 2011-08-10T13:10:09Z Sean Boudreau http://community.qnx.com/sf/go/post87973 2011-08-10T12:48:20Z 2011-08-10T12:48:20Z

The closest we have is BPF under io-pkt. Regards, -seanb ----- Original Message ----- From: Phil Shiel [mailto:community-noreply@qnx.com] Sent: Wednesday, August 10, 2011 08:39 AM To: technology-networking <post87971@community.qnx.com> Subject: Raw (Ethernet) Sockets over io-net net stack on QNX 6.3.2 Hi, I am attempting to port an application to run under QNX version 6.3.2. The application makes use of the socket(AF_PACKET,SOCK_RAW,0) function call to allow it to create its own ethernet based protocol packets. It also makes use of QOS and VLANs in the extended ethernet header. As far as I can see this functionality does not seem to exist in the io-net network stack include with 6.3.2 , so my question is what is the best approach I should take to migrate the application. Do later version of QNX support this functionality? I know there is a new network stack;- io-pkt. Does this give me what I need, and because we are stuck as 6.3.2 is it possible to migrate this stack to run under 6.3.2? Any ideas, suggestions would be greatly appreciated!! Thanks Phil _______________________________________________ Technology http://community.qnx.com/sf/go/post87971

Sean Boudreau 2011-08-10T12:48:20Z Phil Shiel http://community.qnx.com/sf/go/post87971 2011-08-10T12:39:28Z 2011-08-10T12:39:28Z

Hi, I am attempting to port an application to run under QNX version 6.3.2. The application makes use of the socket(AF_PACKET,SOCK_RAW,0) function call to allow it to create its own ethernet based protocol packets. It also makes use of QOS and VLANs in the extended ethernet header. As far as I can see this functionality does not seem to exist in the io-net network stack include with 6.3.2 , so my question is what is the best approach I should take to migrate the application. Do later version of QNX support this functionality? I know there is a new network stack;- io-pkt. Does this give me what I need, and because we are stuck as 6.3.2 is it possible to migrate this stack to run under 6.3.2? Any ideas, suggestions would be greatly appreciated!! Thanks Phil

Phil Shiel 2011-08-10T12:39:28Z Patrik Lahti http://community.qnx.com/sf/go/post87776 2011-08-03T03:40:28Z 2011-08-03T03:40:28Z

I see, Please feel free to contact us or your FAE/Support. Cheers! /P On 07/28/2011 01:30 PM, Robert Murrell wrote: > > Our ultimate goal is to implement the zero configuration mechanism > described at http://www.zeroconf.org/ AutoIP is an important part of > this mechanism. > > > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post87660 >

Patrik Lahti 2011-08-03T03:40:28Z Michael Tasche http://community.qnx.com/sf/go/post87717 2011-07-31T08:46:00Z 2011-07-31T08:46:00Z

Just saw the latest Patch for qnx 6.5. (io-pkt) Well, 2 years later, but they have done it. Realtime is back, thanks very much. -Michael > Hi all, > > why do we need this interrupt-handler in the io-pkt process, which is fired by > the timer-tick? > > This causes an unnecessary overhead in the system. > We have a second tick-handler in a second process(io-pkt), which counts the > time to fire a PULSE all 8 msec. > > Why can't we use the very good timer capabilities of the kernel ? > > > Kind Regards > Michael > > > > > >

Michael Tasche 2011-07-31T08:46:00Z Robert Murrell http://community.qnx.com/sf/go/post87660 2011-07-28T17:30:20Z 2011-07-28T17:30:20Z

Our ultimate goal is to implement the zero configuration mechanism described at http://www.zeroconf.org/ AutoIP is an important part of this mechanism.

Robert Murrell 2011-07-28T17:30:20Z Patrik Lahti http://community.qnx.com/sf/go/post87659 2011-07-28T16:19:14Z 2011-07-28T16:19:14Z

Hi Robert, BPF fills this type of need. See the Networking project wiki http://community.qnx.com/sf/wiki/do/viewPage/projects.networking/wiki/Filtering_wiki_page and the product docs. We actually have something like this on the road map, an improved Auto IP which lives in "user land" and not inside io-pkt (like current lsm-autoip.so). If you're interested please contact your FAE. It would be great if you could share some of your requirements and thoughts on this.Hopefully it would be beneficial to you too. You can contact me at plahti[at]qnx.com. Cheers! /P On 07/27/2011 04:47 PM, Robert Murrell wrote: > > To work around an incompatibility between lsm-autoip.so and > dhcp.client, I have decided to roll my own autoip mechanism. This > should be simple, but I can not open a socket to the ARP layer. I'm > assuming I have to use the AF_ARP protocol family as defined in > socket.h, but I can't find the right combination of arguments to > socket to get it to open. I have to guess because there is no > documentation on how to do this. > > Does anyone have sample code to send and receive ARP packets? > > P.S. I am developing under QNX 6.5.0. And despite having the Standard > Support plan, I have been waiting months for access to the networking > source code. > > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post87637 >

Patrik Lahti 2011-07-28T16:19:14Z Robert Murrell http://community.qnx.com/sf/go/post87637 2011-07-27T20:47:05Z 2011-07-27T20:47:05Z

To work around an incompatibility between lsm-autoip.so and dhcp.client, I have decided to roll my own autoip mechanism. This should be simple, but I can not open a socket to the ARP layer. I'm assuming I have to use the AF_ARP protocol family as defined in socket.h, but I can't find the right combination of arguments to socket to get it to open. I have to guess because there is no documentation on how to do this. Does anyone have sample code to send and receive ARP packets? P.S. I am developing under QNX 6.5.0. And despite having the Standard Support plan, I have been waiting months for access to the networking source code.

Robert Murrell 2011-07-27T20:47:05Z Lewis Donzis http://community.qnx.com/sf/go/post87636 2011-07-27T20:33:59Z 2011-07-27T20:33:59Z

The original build that didn't correct it is documented under case 00109733. However, I posted details of our findings in case 00110356 and it was confirmed as a known problem that has already been fixed. So it sounds like it's all under control. Thanks! lew

Lewis Donzis 2011-07-27T20:33:59Z Mario Charest http://community.qnx.com/sf/go/post87632 2011-07-27T18:53:56Z 2011-07-27T18:53:56Z

The version we are using that is NOT crashing is a debug version: NAME=io-pkt-v4 DESCRIPTION=TCP/IP protocol module. DATE=2011/01/14-01:04:25-ang STATE=Experimental HOST=localhost USER=root VERSION=skhan.1 Then later on I tried this version, that is following some comments on the forum about a possible fix, but it crashed: NAME=io-pkt-v6 DESCRIPTION=TCP/IP protocol module. DATE=2011/06/03-13:10:11-ang STATE=Experimental HOST=vmware-650 USER=root VERSION=skhan.1 Then a few days later, you gave me this version to try which also end up crashing NAME=io-pkt-v4 DESCRIPTION=TCP/IP protocol module. DATE=2011/06/28-09:31:48-ang STATE=Experimental HOST=vmware-650 USER=root VERSION=skhan.1 I`m leaving at 15h30 today. > -----Message d'origine----- > De : Sabtain Khan [mailto:community-noreply@qnx.com] > Envoyé : 27 juillet 2011 14:04 > À : technology-networking > Objet : Re: RE: mbuf corruption > > Lewis, > can you please tell me who provided you latest patch and what date > was it at? > > Thanks, > Sabtain > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post87631 >

Mario Charest 2011-07-27T18:53:56Z Sabtain Khan http://community.qnx.com/sf/go/post87631 2011-07-27T18:03:34Z 2011-07-27T18:03:34Z

Lewis, can you please tell me who provided you latest patch and what date was it at? Thanks, Sabtain

Sabtain Khan 2011-07-27T18:03:34Z Mario Charest http://community.qnx.com/sf/go/post87535 2011-07-22T15:46:52Z 2011-07-22T15:46:52Z

> -----Message d'origine----- > De : Lewis Donzis [mailto:community-noreply@qnx.com] > Envoyé : 22 juillet 2011 11:42 > À : technology-networking > Objet : Re: RE: mbuf corruption > > Sean, > > We thought we had this fixed, but the prior (e1000 related) problem was > something entirely different -- the previous problem was corrupting mbufs > by DMAing into them at bad times. > > In any event, after almost a month of trying, we found a method of > reproducing a highly intermittent problem in a matter of minutes. > Unfortunately, the lab setup is so complex that it would not be easy to > replicate for you. But the problem is likely due to passing an mbuf to another > thread and having that thread free it, thus exercising the pool allocator > because each thread's local mbuf cache is either empty or full all the time. > > Long story short, there is a corruption occurring inside the pool allocator. > After several days of looking into it, there appear to be cases in the pool > allocator where the PR_PROTECT flag is not set and therefore mutex locking > is not occurring on certain pools. > > Empirically, we found that we can eliminate the problem by locking a mutex > on all pools, so now we're trying to find out exactly which one of the pools > was causing the problem. > > You mentioned that a mutexing problem had been found & fixed in the pool > allocator, and we were theoretically given a copy of io-pkt that contained the > fix, but we have no way to verify that the fix was contained within. > > So my question is, can you tell us EXACTLY what was changed? We'd like to > make sure that we're in sync, both with whatever you fixed previously, as > well as our findings in this particular case. > > This is a very serious problem for us, we've even held up a major release due > to a lurking known problem. We now have light at the end of the tunnel, but > would like to discuss further so we can make sure that our findings are > consistent with your much deeper knowledge of this code, and that the fix is > made appropriately so that it can be contributed back. > Same here! That being said we were given a debug version of io-pkt to help debug the crash, but this debug version isn't crashing. That's what we had to put in the field, otherwise we couldn't have deliver our product. > Thanks, > lew > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post87534 >

Mario Charest 2011-07-22T15:46:52Z Lewis Donzis http://community.qnx.com/sf/go/post87534 2011-07-22T15:41:34Z 2011-07-22T15:41:34Z

Sean, We thought we had this fixed, but the prior (e1000 related) problem was something entirely different -- the previous problem was corrupting mbufs by DMAing into them at bad times. In any event, after almost a month of trying, we found a method of reproducing a highly intermittent problem in a matter of minutes. Unfortunately, the lab setup is so complex that it would not be easy to replicate for you. But the problem is likely due to passing an mbuf to another thread and having that thread free it, thus exercising the pool allocator because each thread's local mbuf cache is either empty or full all the time. Long story short, there is a corruption occurring inside the pool allocator. After several days of looking into it, there appear to be cases in the pool allocator where the PR_PROTECT flag is not set and therefore mutex locking is not occurring on certain pools. Empirically, we found that we can eliminate the problem by locking a mutex on all pools, so now we're trying to find out exactly which one of the pools was causing the problem. You mentioned that a mutexing problem had been found & fixed in the pool allocator, and we were theoretically given a copy of io-pkt that contained the fix, but we have no way to verify that the fix was contained within. So my question is, can you tell us EXACTLY what was changed? We'd like to make sure that we're in sync, both with whatever you fixed previously, as well as our findings in this particular case. This is a very serious problem for us, we've even held up a major release due to a lurking known problem. We now have light at the end of the tunnel, but would like to discuss further so we can make sure that our findings are consistent with your much deeper knowledge of this code, and that the fix is made appropriately so that it can be contributed back. Thanks, lew

Lewis Donzis 2011-07-22T15:41:34Z Lewis Donzis http://community.qnx.com/sf/go/post86542 2011-06-09T23:30:53Z 2011-06-09T23:30:53Z

We found the problem. It's in the e1000 driver, where it doesn't clear the status of packets when initializing the ring. We had previously mentioned this to Hugh and had implemented a fix, but our fix wasn't in the right part of the code to get executed in this case. lew

Lewis Donzis 2011-06-09T23:30:53Z Lewis Donzis http://community.qnx.com/sf/go/post86473 2011-06-07T13:00:34Z 2011-06-07T13:00:34Z

> A mutexing issue in the pool allocator. Sean, We're trying to come up with a test case that would let you see this more easily, and that is proving difficult. One thing that helps a lot is changing the e1000 driver to do receive processing in its own separate thread, and using poke_stack_pkt_q() to get another thread to become the stack (more like the io-net model). At that point, we can make it fail reasonably often by directing a decent load (about 500,000 packets/sec) at the machine and then running "tcpdump -c1" in a loop, to cause the interface to go in/out of promiscuous mode. If we don't use poke_stack_pkt_q(), it fails so rarely as to be useless. I was thinking that this might be similar to how the shim drivers operate, so we'll try replicating it with a released shim driver. Note that the problem is a lot more serious for us than going into promiscuous mode -- we have occasional random failures, but they are very rare, so we're just searching for some way to cause it to happen more frequently. In any event, after tracing through the driver, the mbuf library, and the pool allocator, it appears that something in the pool gets corrupted while it's unallocated. 99% of the time, everything works fine. But every now and then, pcg_get() returns an object which points to 0x0f320700, which is not a valid pointer (which of course leads to a SEGV). Sometimes, the pointer is null, and rarely it's -1, but about 90% of the time, it's the above magic value. We can see that pcg_get() is returning a corrupted object, but we also instrumented pcg_put() and nothing ever intentionally frees a "bad" object. Does any of this sound familiar? Support sent us an io-pkt-v6 to try, and it made no difference, but I don't know how to verify whether it actually contains the fix you mentioned previously. Thanks, lew

Lewis Donzis 2011-06-07T13:00:34Z Lewis Donzis http://community.qnx.com/sf/go/post86427 2011-06-03T15:09:36Z 2011-06-03T15:09:36Z

> Talk to your FAE and ask how to get the fix. > > You may need a support plan and the FAE will be glad to enroll you in one. No problem. We already have an active support plan, so I just opened a case. Thanks, lew

Lewis Donzis 2011-06-03T15:09:36Z Mate Szarvas http://community.qnx.com/sf/go/post86426 2011-06-03T15:06:27Z 2011-06-03T15:06:27Z

Talk to your FAE and ask how to get the fix. You may need a support plan and the FAE will be glad to enroll you in one. On 11-06-03 9:22 AM, "Lewis Donzis" <community-noreply@qnx.com> wrote: >> > A mutexing issue in the pool allocator. > > That sounds promising and would explain a lot. > >>> > > and where we could get >>> > > the fixed code to give it a try? >> > >> > This I'm not sure of these days... > > Well, we've compiled io-pkt from the released source, so if we knew what to > change, we could modify the source and try it here. > > Or maybe I should ask our FAE for an update? > > What would be the best course of action? > > Thanks, > lew > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post86425 > >

Mate Szarvas 2011-06-03T15:06:27Z Lewis Donzis http://community.qnx.com/sf/go/post86425 2011-06-03T13:22:05Z 2011-06-03T13:22:05Z

> A mutexing issue in the pool allocator. That sounds promising and would explain a lot. > > and where we could get > > the fixed code to give it a try? > > This I'm not sure of these days... Well, we've compiled io-pkt from the released source, so if we knew what to change, we could modify the source and try it here. Or maybe I should ask our FAE for an update? What would be the best course of action? Thanks, lew

Lewis Donzis 2011-06-03T13:22:05Z Sean Boudreau http://community.qnx.com/sf/go/post86424 2011-06-03T13:12:35Z 2011-06-03T13:12:35Z

On Fri, Jun 03, 2011 at 08:52:33AM -0400, Lewis Donzis wrote: > > There was a fix recently that may explain this. > > Thanks, Sean. > > Can you shed any more light, i.e., what was fixed A mutexing issue in the pool allocator. > and where we could get > the fixed code to give it a try? This I'm not sure of these days... > > I'm pretty sure that we can reproduce it within a reasonably short > period of time. > > lew > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post86423 >

Sean Boudreau 2011-06-03T13:12:35Z Lewis Donzis http://community.qnx.com/sf/go/post86423 2011-06-03T12:52:32Z 2011-06-03T12:52:32Z

> There was a fix recently that may explain this. Thanks, Sean. Can you shed any more light, i.e., what was fixed and where we could get the fixed code to give it a try? I'm pretty sure that we can reproduce it within a reasonably short period of time. lew

Lewis Donzis 2011-06-03T12:52:32Z Sean Boudreau http://community.qnx.com/sf/go/post86422 2011-06-03T12:45:59Z 2011-06-03T12:45:59Z

On Thu, Jun 02, 2011 at 03:33:27PM -0400, Lewis Donzis wrote: > > We are also having issues with io-pkt-v4 crashing. In your case is it > related > > to tcpip or QNET? > > We've seen crashes from both, but the cause is a big mystery. > Generally, we see a crash in the mbuf allocator, where something in the > mbuf that it pulled from the pool was previously corrupted. > > So while we have seen qnet call something that allocates an mbuf and > then crashes, removing qnet has very little effect, it still crashes > elsewhere. > > We've seen crashes from tcp_input() calling tcp_output calling the mbuf > allocator. > > We also have our own modules that use the pfil hooks, and there are > crashes when those modules call the mbuf allocator. > > And, there are also crashes in the driver, where the receive code > allocates a replacement mbuf. > > The problem is that the crash occurs some time after the corruption > actually occurred, i.e., only when the mbuf gets recycled, so we don't > know when it was originally corrupted. > > Anyway, we'll continue to investigate, I just didn't want to spend a lot > more time on it if it's a "known" problem that's already been fixed. > > lew There was a fix recently that may explain this. Regards, -seanb

Sean Boudreau 2011-06-03T12:45:59Z Lewis Donzis http://community.qnx.com/sf/go/post86410 2011-06-02T19:33:26Z 2011-06-02T19:33:26Z

> We are also having issues with io-pkt-v4 crashing. In your case is it related > to tcpip or QNET? We've seen crashes from both, but the cause is a big mystery. Generally, we see a crash in the mbuf allocator, where something in the mbuf that it pulled from the pool was previously corrupted. So while we have seen qnet call something that allocates an mbuf and then crashes, removing qnet has very little effect, it still crashes elsewhere. We've seen crashes from tcp_input() calling tcp_output calling the mbuf allocator. We also have our own modules that use the pfil hooks, and there are crashes when those modules call the mbuf allocator. And, there are also crashes in the driver, where the receive code allocates a replacement mbuf. The problem is that the crash occurs some time after the corruption actually occurred, i.e., only when the mbuf gets recycled, so we don't know when it was originally corrupted. Anyway, we'll continue to investigate, I just didn't want to spend a lot more time on it if it's a "known" problem that's already been fixed. lew

Lewis Donzis 2011-06-02T19:33:26Z Mario Charest http://community.qnx.com/sf/go/post86396 2011-06-02T14:32:27Z 2011-06-02T14:32:27Z

> -----Message d'origine----- > De : Lewis Donzis [mailto:community-noreply@qnx.com] > Envoyé : 2 juin 2011 09:22 > À : technology-networking > Objet : mbuf corruption > > We're trying to track down a problem where an mbuf gets corrupted > somewhere along the line, which eventually causes a fault and io-pkt > crashes. > > It's not obvious what's going on, and we've already spent quite a bit of time > investigating. > > However, before we continue digging into it, I just wanted to ask if there > have been any changes since the 6.5.0 release that might cause one or more > fields of an mbuf to be invalid, particularly m_ext.ext_page. > > If there are no known issues, we'll continue with what we're doing, but I > didn't want to spend a whole lot of time on it if this is a known issue. > We are also having issues with io-pkt-v4 crashing. In your case is it related to tcpip or QNET? In our case the problem happened when we handle one extra tcpip stream in our application. Finaly got access to network source last week, so I`ll investigate this further in the following weeks. We have a Case open but since I`m not able to create a simple test case for QNX to reproduce the issue, they aren`t really able to assist. > Thanks, > lew > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post86386 >

Mario Charest 2011-06-02T14:32:27Z Hugh Brown http://community.qnx.com/sf/go/post86394 2011-06-02T14:06:18Z 2011-06-02T14:06:18Z

Not that I'm aware of. On 11-06-02 10:04 AM, "Lewis Donzis" <community-noreply@qnx.com> wrote: >> The e1000 driver doesn¹t change the ext_page variable. All that the driver >> does is to use this offset to get the physical address of the buffer > > I agree. I didn't say it was a problem in the hardware driver, I was just > answering the question :) > > That's why I asked whether there have been any other changes in the rest of > the stack that might involve possible mbuf corruption? > _______________________________________________ Technology http://communi > ty.qnx.com/sf/go/post86393 -- Hugh Brown (613) 591-0931 ext. 2209 (voice) QNX Software Systems Ltd. (613) 591-3579 (fax) 175 Terence Matthews Cres. email: hsbrown@qnx.com Kanata, Ontario, Canada. K2M 1W8

Hugh Brown 2011-06-02T14:06:18Z Lewis Donzis http://community.qnx.com/sf/go/post86393 2011-06-02T14:04:18Z 2011-06-02T14:04:18Z

> The e1000 driver doesn¹t change the ext_page variable. All that the driver > does is to use this offset to get the physical address of the buffer I agree. I didn't say it was a problem in the hardware driver, I was just answering the question :) That's why I asked whether there have been any other changes in the rest of the stack that might involve possible mbuf corruption?

Lewis Donzis 2011-06-02T14:04:18Z Hugh Brown http://community.qnx.com/sf/go/post86390 2011-06-02T13:38:03Z 2011-06-02T13:38:03Z

The e1000 driver doesn¹t change the ext_page variable. All that the driver does is to use this offset to get the physical address of the buffer On 11-06-02 9:34 AM, "Lewis Donzis" <community-noreply@qnx.com> wrote: > In this case, e1000. > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post86389 > > -- Hugh Brown (613) 591-0931 ext. 2209 (voice) QNX Software Systems Ltd. (613) 591-3579 (fax) 175 Terence Matthews Cres. email: hsbrown@qnx.com Kanata, Ontario, Canada. K2M 1W8

Hugh Brown 2011-06-02T13:38:03Z Lewis Donzis http://community.qnx.com/sf/go/post86389 2011-06-02T13:34:33Z 2011-06-02T13:34:33Z

In this case, e1000.

Lewis Donzis 2011-06-02T13:34:33Z Dennis Kellly http://community.qnx.com/sf/go/post86387 2011-06-02T13:24:58Z 2011-06-02T13:24:58Z

Which h/w driver?

Dennis Kellly 2011-06-02T13:24:58Z Lewis Donzis http://community.qnx.com/sf/go/post86386 2011-06-02T13:22:10Z 2011-06-02T13:22:10Z

We're trying to track down a problem where an mbuf gets corrupted somewhere along the line, which eventually causes a fault and io-pkt crashes. It's not obvious what's going on, and we've already spent quite a bit of time investigating. However, before we continue digging into it, I just wanted to ask if there have been any changes since the 6.5.0 release that might cause one or more fields of an mbuf to be invalid, particularly m_ext.ext_page. If there are no known issues, we'll continue with what we're doing, but I didn't want to spend a whole lot of time on it if this is a known issue. Thanks, lew

Lewis Donzis 2011-06-02T13:22:10Z saro sun http://community.qnx.com/sf/go/post86118 2011-05-25T11:23:04Z 2011-05-25T11:23:04Z

Hi Seanb, Thanks for your support. I have tried to implement the nw_pthread_create instead of pthread_create for sdio thread. Source code: pthread_attr_init(&pattr); pthread_attr_setschedpolicy(&pattr,SCHED_RR); param.sched_priority = priority; pthread_attr_setschedparam(&pattr,&param); pthread_attr_setinheritsched(&pattr, PTHREAD_EXPLICIT_SCHED); pthread_attr_setdetachstate(&pattr, PTHREAD_CREATE_DETACHED); pthread_attr_setstacksize(&pattr, SD_THREAD_STACK_SIZE); #if QNX_THREAD if((status = pthread_create(&pHandle->osThreadId,(const pthread_attr_t *)&pattr, (Qnx_Thread_Function)pFunction,pContext)) != SD_SUCCESS) { sd_Error("Could not create Thread - Tx err: %u\n",status); SD_FREE(pStackStart); return (SD_ERROR_INVALID); } #else if((status = nw_pthread_create(&pHandle->osThreadId,(const pthread_attr_t *)&pattr, (Qnx_Thread_Function)pFunction,pContext,0,NULL,NULL)) != SD_SUCCESS) { sd_Error("Could not create Thread - Tx err: %u\n",status); SD_FREE(pStackStart); return (SD_ERROR_INVALID); } #endif But It returns error No. 22 Please let me know if any example source code to implement the nw_pthread_create() function. Best Regards, Saravana On Tue, May 24, 2011 at 7:20 PM, Sean Boudreau <community-noreply@qnx.com>wrote: > > If you use nw_pthread_create() for the sdio thread, it > can use malloc(9). If you override the define with > parentheses (eg (malloc)) it can use malloc(3). > > Regards, > > -seanb > > On Tue, May 24, 2011 at 09:23:27AM -0400, saro sun wrote: > > Hi Seanb, > > > > Thanks for response. > > > > My network driver is a shared library, please let me know how to link > > with > > network driver shared library to my sdio shared or static library. I > > have > > tried with extra library and path option, but throwing a error. > > > > And if try to merge the network driver and sdio source as single shared > > library which, I can able to run using the io-pkt application. but in > > network driver dynamic allocation using malloc with three variables. > > Same > > malloc, if I used in sdio thread (using pthread_create) with three > > variable > > malloc its crashing. If try to use the normal malloc with single > > variable, > > its giving a compilation error, because of the _KERNEL macro variable. > > Please let me know your suggestion. > > > > Best Regards, > > Saravana. > > > > > > > > On Tue, May 24, 2011 at 5:26 PM, Sean Boudreau > > <community-noreply@qnx.com>wrote: > > > > > It sounds like you need to compile your sdio layer as a library; > > either as > > > a shared library (foo.so) or a static PIC variant (fooS.a) and link > > your > > > driver against that. > > > > > > Regards, > > > > > > -seanb > > > > > > ----- Original Message ----- > > > From: saro sun [mailto:community-noreply@qnx.com] > > > Sent: Tuesday, May 24, 2011 07:24 AM > > > To: technology-networking <post86068@community.qnx.com> > > > Subject: Regarding Exporting a symbol from executable to shared > > library > > > > > > > > > > > Hello, > > > > > > > > Queries to QNX: > > > > > > > > Reference board: AT91SAM9263 development board. > > > > > > > > BSP: bsp-nto640-ATMEL-AT91SAM9263- > > > > EK-trunk. > > > > > > > > IDE: QNX Momentics Integrated Development 4.7.0 > > > > > > > > OS: QNXSDP 6.5.0 > > > > > > > > > > > > > > > > We have designed our SDIO stack as QNX application (as a executable > > > > binary) and net work driver as a shared library format (.so file). > > We > > > can > > > > able run/debug our SDIO stack application using run/debug the > > > configuration > > > > utility. QNX SDIO stack able to do initialization of any network > > SDIO > > > card > > > > successfully. As per net work driver design some of the SDIO stack > > API's > > > are > > > > used bythe network driver. While running the network driver library > > using > > > > io-pkt application SDIO stack API's are showing unresolved symbols. > > We > > > have > > > > tried to export the symbol from QNX SDIO stack application and tried > > to > > > link > > > > the network driver against QNX SDIO stack application using extra > > library > > > > paths and extra library include options, but its throwing > > compilation > > > error > > > > when its not able to fined the library from the specified path > > given. At > > > > this moment we are unable to export the symbols of the QNX SDIO > > stack > > > > application to the network shared library. > > > > > > > > Our QNX SDIO stack is working properly with below mentioned > > methods. > > > > 1. Normal C/C++ projects as executable. > > > > 2. QNX C projects as a executable. > > > > 3. Include in the AT91SAM9263 QNX BSP device driver as a executable. > > > > > > > > Our network driver is include in the AT91SAM9263 QNX BSP devnp > > driver as > > > a > > > > shared library. It will executed by the io-pkt application > > > > > > > > Please suggest us to resolve the issues. > > > > > > > > Best Regards, > > > > Saravana > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Technology > > > http://community.qnx.com/sf/go/post86068 > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Technology > > > http://community.qnx.com/sf/go/post86069 > > > > > > > > > > > > > > > > _______________________________________________ > > > > Technology > > http://community.qnx.com/sf/go/post86071 > > > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post86073 > >

saro sun 2011-05-25T11:23:04Z Sean Boudreau http://community.qnx.com/sf/go/post86073 2011-05-24T13:49:56Z 2011-05-24T13:49:56Z

If you use nw_pthread_create() for the sdio thread, it can use malloc(9). If you override the define with parentheses (eg (malloc)) it can use malloc(3). Regards, -seanb On Tue, May 24, 2011 at 09:23:27AM -0400, saro sun wrote: > Hi Seanb, > > Thanks for response. > > My network driver is a shared library, please let me know how to link > with > network driver shared library to my sdio shared or static library. I > have > tried with extra library and path option, but throwing a error. > > And if try to merge the network driver and sdio source as single shared > library which, I can able to run using the io-pkt application. but in > network driver dynamic allocation using malloc with three variables. > Same > malloc, if I used in sdio thread (using pthread_create) with three > variable > malloc its crashing. If try to use the normal malloc with single > variable, > its giving a compilation error, because of the _KERNEL macro variable. > Please let me know your suggestion. > > Best Regards, > Saravana. > > > > On Tue, May 24, 2011 at 5:26 PM, Sean Boudreau > <community-noreply@qnx.com>wrote: > > > It sounds like you need to compile your sdio layer as a library; > either as > > a shared library (foo.so) or a static PIC variant (fooS.a) and link > your > > driver against that. > > > > Regards, > > > > -seanb > > > > ----- Original Message ----- > > From: saro sun [mailto:community-noreply@qnx.com] > > Sent: Tuesday, May 24, 2011 07:24 AM > > To: technology-networking <post86068@community.qnx.com> > > Subject: Regarding Exporting a symbol from executable to shared > library > > > > > > > > Hello, > > > > > > Queries to QNX: > > > > > > Reference board: AT91SAM9263 development board. > > > > > > BSP: bsp-nto640-ATMEL-AT91SAM9263- > > > EK-trunk. > > > > > > IDE: QNX Momentics Integrated Development 4.7.0 > > > > > > OS: QNXSDP 6.5.0 > > > > > > > > > > > > We have designed our SDIO stack as QNX application (as a executable > > > binary) and net work driver as a shared library format (.so file). > We > > can > > > able run/debug our SDIO stack application using run/debug the > > configuration > > > utility. QNX SDIO stack able to do initialization of any network > SDIO > > card > > > successfully. As per net work driver design some of the SDIO stack > API's > > are > > > used bythe network driver. While running the network driver library > using > > > io-pkt application SDIO stack API's are showing unresolved symbols. > We > > have > > > tried to export the symbol from QNX SDIO stack application and tried > to > > link > > > the network driver against QNX SDIO stack application using extra > library > > > paths and extra library include options, but its throwing > compilation > > error > > > when its not able to fined the library from the specified path > given. At > > > this moment we are unable to export the symbols of the QNX SDIO > stack > > > application to the network shared library. > > > > > > Our QNX SDIO stack is working properly with below mentioned > methods. > > > 1. Normal C/C++ projects as executable. > > > 2. QNX C projects as a executable. > > > 3. Include in the AT91SAM9263 QNX BSP device driver as a executable. > > > > > > Our network driver is include in the AT91SAM9263 QNX BSP devnp > driver as > > a > > > shared library. It will executed by the io-pkt application > > > > > > Please suggest us to resolve the issues. > > > > > > Best Regards, > > > Saravana > > > > > > > > > > > > > _______________________________________________ > > > > Technology > > http://community.qnx.com/sf/go/post86068 > > > > > > > > > > _______________________________________________ > > > > Technology > > http://community.qnx.com/sf/go/post86069 > > > > > > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post86071 >

Sean Boudreau 2011-05-24T13:49:56Z saro sun http://community.qnx.com/sf/go/post86071 2011-05-24T13:23:26Z 2011-05-24T13:23:26Z

Hi Seanb, Thanks for response. My network driver is a shared library, please let me know how to link with network driver shared library to my sdio shared or static library. I have tried with extra library and path option, but throwing a error. And if try to merge the network driver and sdio source as single shared library which, I can able to run using the io-pkt application. but in network driver dynamic allocation using malloc with three variables. Same malloc, if I used in sdio thread (using pthread_create) with three variable malloc its crashing. If try to use the normal malloc with single variable, its giving a compilation error, because of the _KERNEL macro variable. Please let me know your suggestion. Best Regards, Saravana. On Tue, May 24, 2011 at 5:26 PM, Sean Boudreau <community-noreply@qnx.com>wrote: > It sounds like you need to compile your sdio layer as a library; either as > a shared library (foo.so) or a static PIC variant (fooS.a) and link your > driver against that. > > Regards, > > -seanb > > ----- Original Message ----- > From: saro sun [mailto:community-noreply@qnx.com] > Sent: Tuesday, May 24, 2011 07:24 AM > To: technology-networking <post86068@community.qnx.com> > Subject: Regarding Exporting a symbol from executable to shared library > > > > > Hello, > > > > Queries to QNX: > > > > Reference board: AT91SAM9263 development board. > > > > BSP: bsp-nto640-ATMEL-AT91SAM9263- > > EK-trunk. > > > > IDE: QNX Momentics Integrated Development 4.7.0 > > > > OS: QNXSDP 6.5.0 > > > > > > > > We have designed our SDIO stack as QNX application (as a executable > > binary) and net work driver as a shared library format (.so file). We > can > > able run/debug our SDIO stack application using run/debug the > configuration > > utility. QNX SDIO stack able to do initialization of any network SDIO > card > > successfully. As per net work driver design some of the SDIO stack API's > are > > used bythe network driver. While running the network driver library using > > io-pkt application SDIO stack API's are showing unresolved symbols. We > have > > tried to export the symbol from QNX SDIO stack application and tried to > link > > the network driver against QNX SDIO stack application using extra library > > paths and extra library include options, but its throwing compilation > error > > when its not able to fined the library from the specified path given. At > > this moment we are unable to export the symbols of the QNX SDIO stack > > application to the network shared library. > > > > Our QNX SDIO stack is working properly with below mentioned methods. > > 1. Normal C/C++ projects as executable. > > 2. QNX C projects as a executable. > > 3. Include in the AT91SAM9263 QNX BSP device driver as a executable. > > > > Our network driver is include in the AT91SAM9263 QNX BSP devnp driver as > a > > shared library. It will executed by the io-pkt application > > > > Please suggest us to resolve the issues. > > > > Best Regards, > > Saravana > > > > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post86068 > > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post86069 > >

saro sun 2011-05-24T13:23:26Z Sean Boudreau http://community.qnx.com/sf/go/post86069 2011-05-24T11:56:27Z 2011-05-24T11:56:27Z

It sounds like you need to compile your sdio layer as a library; either as a shared library (foo.so) or a static PIC variant (fooS.a) and link your driver against that. Regards, -seanb ----- Original Message ----- From: saro sun [mailto:community-noreply@qnx.com] Sent: Tuesday, May 24, 2011 07:24 AM To: technology-networking <post86068@community.qnx.com> Subject: Regarding Exporting a symbol from executable to shared library > > Hello, > > Queries to QNX: > > Reference board: AT91SAM9263 development board. > > BSP: bsp-nto640-ATMEL-AT91SAM9263- > EK-trunk. > > IDE: QNX Momentics Integrated Development 4.7.0 > > OS: QNXSDP 6.5.0 > > > > We have designed our SDIO stack as QNX application (as a executable > binary) and net work driver as a shared library format (.so file). We can > able run/debug our SDIO stack application using run/debug the configuration > utility. QNX SDIO stack able to do initialization of any network SDIO card > successfully. As per net work driver design some of the SDIO stack API's are > used bythe network driver. While running the network driver library using > io-pkt application SDIO stack API's are showing unresolved symbols. We have > tried to export the symbol from QNX SDIO stack application and tried to link > the network driver against QNX SDIO stack application using extra library > paths and extra library include options, but its throwing compilation error > when its not able to fined the library from the specified path given. At > this moment we are unable to export the symbols of the QNX SDIO stack > application to the network shared library. > > Our QNX SDIO stack is working properly with below mentioned methods. > 1. Normal C/C++ projects as executable. > 2. QNX C projects as a executable. > 3. Include in the AT91SAM9263 QNX BSP device driver as a executable. > > Our network driver is include in the AT91SAM9263 QNX BSP devnp driver as a > shared library. It will executed by the io-pkt application > > Please suggest us to resolve the issues. > > Best Regards, > Saravana > _______________________________________________ Technology http://community.qnx.com/sf/go/post86068

Sean Boudreau 2011-05-24T11:56:27Z saro sun http://community.qnx.com/sf/go/post86068 2011-05-24T11:24:10Z 2011-05-24T11:24:10Z

> > Hello, > > Queries to QNX: > > Reference board: AT91SAM9263 development board. > > BSP: bsp-nto640-ATMEL-AT91SAM9263- > EK-trunk. > > IDE: QNX Momentics Integrated Development 4.7.0 > > OS: QNXSDP 6.5.0 > > > > We have designed our SDIO stack as QNX application (as a executable > binary) and net work driver as a shared library format (.so file). We can > able run/debug our SDIO stack application using run/debug the configuration > utility. QNX SDIO stack able to do initialization of any network SDIO card > successfully. As per net work driver design some of the SDIO stack API's are > used bythe network driver. While running the network driver library using > io-pkt application SDIO stack API's are showing unresolved symbols. We have > tried to export the symbol from QNX SDIO stack application and tried to link > the network driver against QNX SDIO stack application using extra library > paths and extra library include options, but its throwing compilation error > when its not able to fined the library from the specified path given. At > this moment we are unable to export the symbols of the QNX SDIO stack > application to the network shared library. > > Our QNX SDIO stack is working properly with below mentioned methods. > 1. Normal C/C++ projects as executable. > 2. QNX C projects as a executable. > 3. Include in the AT91SAM9263 QNX BSP device driver as a executable. > > Our network driver is include in the AT91SAM9263 QNX BSP devnp driver as a > shared library. It will executed by the io-pkt application > > Please suggest us to resolve the issues. > > Best Regards, > Saravana >

saro sun 2011-05-24T11:24:10Z Mark Dowdy http://community.qnx.com/sf/go/post86027 2011-05-20T23:07:44Z 2011-05-20T23:07:44Z

Could anyone add some clarity to the 'slightly lower performance' that one would encounter using Berkeley Packet Filter? I know io-pkt has been around for quite a while but we're finally forced, due to hardware obsolescence, to move away from our io-net filter an io-pkt equivalent. The filtering page recommends BPF as the interface of first choice, and it was fairly straightforward to move to BPF. Unfortunately, our new devnp-e1000/io-pkt/BPF combination has significant performance issues compared to our old devn-i82544/io-net/filter combination. We're using BPF to slurp and inject frames of a proprietary protocol. We open a BPF file handle, set the interface, set 'immediate' to 1, set 'header complete' to 1, and 'see sent' to 0. From there we just read and write the file descriptor. We're heading into the bowels of the system kernel trace but in the meantime we're curious to know if 'slightly lower performance' means a few µseconds or hundreds of µseconds. Thanks. Mark

Mark Dowdy 2011-05-20T23:07:44Z Derek Spadaro http://community.qnx.com/sf/go/post85562 2011-05-10T19:12:17Z 2011-05-10T19:12:17Z

My fault, I wasn't clear. That directory did contain all the libraries from my test. The test is just a one-liner that calls socket(). But now I think the issue is at least partially how we are looking for dependencies (by parsing the output of ntoppc-strings). objdump the test executable and I see ... Dynamic Section: NEEDED libsocket.so.3 NEEDED libc.so.3 INIT 0x480404d0 FINI 0x48040888 HASH 0x48040128 STRTAB 0x480402f0 SYMTAB 0x480401c0 STRSZ 0x000000e5 SYMENT 0x00000010 DEBUG 0x00000000 PLTGOT 0x480419d8 PLTRELSZ 0x00000078 PLTREL 0x00000007 JMPREL 0x48040458 RELA 0x4804041c RELASZ 0x000000b4 RELAENT 0x0000000c VERNEED 0x480403fc VERNEEDNUM 0x00000001 VERSYM 0x480403d6 Version References: required from libsocket.so.3: 0x040fdf22 0x00 02 libsocket.so.2 ... So libsocket.so.3 somehow still points back to .2. objdump libsocket.so.3 and I see ... Dynamic Section: NEEDED libc.so.3 SONAME libsocket.so.3 INIT 0x00006fb8 FINI 0x00029618 HASH 0x000000f4 STRTAB 0x000027c8 SYMTAB 0x00000c08 STRSZ 0x00000f76 SYMENT 0x00000010 PLTGOT 0x0002e780 PLTRELSZ 0x00000984 PLTREL 0x00000007 JMPREL 0x00006634 RELA 0x00003af0 RELASZ 0x000034c8 RELAENT 0x0000000c VERDEF 0x00003ab8 VERDEFNUM 0x00000002 VERSYM 0x0000373e RELACOUNT 0x0000038d Version definitions: 1 0x01 0x040fdf23 libsocket.so.3 2 0x00 0x040fdf22 libsocket.so.2 ... I don't have enough ELF knowledge to know if this is a problem, how to fix it, etc. But from the previous post it sounds like the libsocket.so.2 pointer here can be safely ignored.

Derek Spadaro 2011-05-10T19:12:17Z Sean Boudreau http://community.qnx.com/sf/go/post85560 2011-05-10T18:56:54Z 2011-05-10T18:56:54Z

I mean all the libs in your test. ----- Original Message ----- From: Derek Spadaro [mailto:community-noreply@qnx.com] Sent: Tuesday, May 10, 2011 02:52 PM To: technology-networking <post85559@community.qnx.com> Subject: Re: libsocket in QNX 6.5.0 OK. 13:46:42-dspadaro@EXV2:/opt/qnx650/target/qnx6/ppcbe/lib> ls *.so *.so.* | xargs objdump -x | grep NEEDED NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.2 NEEDED libc.so.3 NEEDED libc.so.2 NEEDED libc.so.2 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.2 NEEDED libc.so.3 NEEDED libc.so.2 NEEDED libc.so.2 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libm.so.2 NEEDED libc.so.3 NEEDED libm.so.2 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libsocket.so.3 NEEDED libc.so.3 NEEDED libsocket.so.3 NEEDED libc.so.3 Nothing obvious there, but I was looking as much to confirm that .2 is not required as anything. We have 6.4.1 and 6.5.0 toolchains co-existing on the same machines, so I will assume somebody is pointing where they needn't be and try to track it down. Thanks. _______________________________________________ Technology http://community.qnx.com/sf/go/post85559

Sean Boudreau 2011-05-10T18:56:54Z Derek Spadaro http://community.qnx.com/sf/go/post85559 2011-05-10T18:51:59Z 2011-05-10T18:51:59Z

OK. 13:46:42-dspadaro@EXV2:/opt/qnx650/target/qnx6/ppcbe/lib> ls *.so *.so.* | xargs objdump -x | grep NEEDED NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.2 NEEDED libc.so.3 NEEDED libc.so.2 NEEDED libc.so.2 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.2 NEEDED libc.so.3 NEEDED libc.so.2 NEEDED libc.so.2 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libm.so.2 NEEDED libc.so.3 NEEDED libm.so.2 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libc.so.3 NEEDED libsocket.so.3 NEEDED libc.so.3 NEEDED libsocket.so.3 NEEDED libc.so.3 Nothing obvious there, but I was looking as much to confirm that .2 is not required as anything. We have 6.4.1 and 6.5.0 toolchains co-existing on the same machines, so I will assume somebody is pointing where they needn't be and try to track it down. Thanks.

Derek Spadaro 2011-05-10T18:51:59Z Sean Boudreau http://community.qnx.com/sf/go/post85558 2011-05-10T18:29:35Z 2011-05-10T18:29:35Z

Do an 'objdump -x | grep NEEDED' on the various libs. Something must not have been re-linked. In general only the .3 should be needed. Regards, -seanb ----- Original Message ----- From: Derek Spadaro [mailto:community-noreply@qnx.com] Sent: Tuesday, May 10, 2011 02:25 PM To: technology-networking <post85557@community.qnx.com> Subject: libsocket in QNX 6.5.0 Using QNX Neutrino 6.5.0, I notice that there is a new libsocket version, libsocket.so.3, in addition to libsocket.so.2 However, a simple test shows that linking against "-lsocket" will include both libsocket.so.2 _and_ libsocket.so.3: 13:22:22-dspadaro@EXV2:~/builds/tot/source/configurations/QNX-PPC/test/ppc/be> ntoppc-strings test | grep lib.*\.so /usr/lib/ldqnx.so.2 libsocket.so.3 libc.so.3 libsocket.so.2 I guess I was assuming that when the version number incremented the functionality would be a superset. It would be nice if we did not have to carry forward 2 versions of this library. Does anyone know of a trick (or a reason not) to do this? _______________________________________________ Technology http://community.qnx.com/sf/go/post85557

Sean Boudreau 2011-05-10T18:29:35Z Derek Spadaro http://community.qnx.com/sf/go/post85557 2011-05-10T18:25:18Z 2011-05-10T18:25:18Z

Using QNX Neutrino 6.5.0, I notice that there is a new libsocket version, libsocket.so.3, in addition to libsocket.so.2 However, a simple test shows that linking against "-lsocket" will include both libsocket.so.2 _and_ libsocket.so.3: 13:22:22-dspadaro@EXV2:~/builds/tot/source/configurations/QNX-PPC/test/ppc/be> ntoppc-strings test | grep lib.*\.so /usr/lib/ldqnx.so.2 libsocket.so.3 libc.so.3 libsocket.so.2 I guess I was assuming that when the version number incremented the functionality would be a superset. It would be nice if we did not have to carry forward 2 versions of this library. Does anyone know of a trick (or a reason not) to do this?

Derek Spadaro 2011-05-10T18:25:18Z Dirk Zumwalt http://community.qnx.com/sf/go/post85099 2011-04-18T17:57:23Z 2011-04-18T17:57:23Z

Thanks for the info Mario, this will help me to eleminate thinking it was a hardware issue.

Dirk Zumwalt 2011-04-18T17:57:23Z Mario Charest http://community.qnx.com/sf/go/post85097 2011-04-18T17:38:25Z 2011-04-18T17:38:25Z

> Ok, I am at my witts end and getting frustrated with this communication issue. > I have tried three different NICs and still having communication issues with > the QNX server. The connection will stay up for about 5 min and then drop. I > was looking at the ifconfig and saw that the interface said it was a simplex > connection and would it have anything to do with that? I know most connections > are full duplex. > > Thanks for any help that comes my way! > Dirk The physical NIC that you use is not really important. What ever model brand you use the virtual machine will always present the same model to the guest OS. That is QNX never gets direct access to the hardware and always see the same type of NIC. I realized this is of little help. But more information is better then nothing.

Mario Charest 2011-04-18T17:38:25Z Dirk Zumwalt http://community.qnx.com/sf/go/post85096 2011-04-18T16:58:16Z 2011-04-18T16:58:16Z

Ok, I am at my witts end and getting frustrated with this communication issue. I have tried three different NICs and still having communication issues with the QNX server. The connection will stay up for about 5 min and then drop. I was looking at the ifconfig and saw that the interface said it was a simplex connection and would it have anything to do with that? I know most connections are full duplex. Thanks for any help that comes my way! Dirk

Dirk Zumwalt 2011-04-18T16:58:16Z Dirk Zumwalt http://community.qnx.com/sf/go/post85044 2011-04-15T15:07:44Z 2011-04-15T15:07:44Z

I also did some looking on the QNX site and found that my onboard NIC is not listed in the supported hardware (Intel 82567LM-3 Gigabit Network Connection). I will see if I can get another nic from the hardware guy to see if this works and will report back. Thanks, Dirk

Dirk Zumwalt 2011-04-15T15:07:44Z Dirk Zumwalt http://community.qnx.com/sf/go/post85041 2011-04-15T14:48:15Z 2011-04-15T14:48:15Z

That was our first thought and we got with our internal comms guy and did a trace on the network and came up with nothing. We had also got a static IP from him in the begining so we would not be using duplicate IPs. Thanks Walt! Dirk

Dirk Zumwalt 2011-04-15T14:48:15Z Walt Wimer http://community.qnx.com/sf/go/post85040 2011-04-15T14:44:23Z 2011-04-15T14:44:23Z

Do you possibly have some other completely-unrelated machine (virtual or physical) on your network with the same IP address? I recently saw this problem in one of my customers' networks, and the cause turned out to be a printer configured with the same IP address as a Cisco router that we were using! Took us forever to find the problem, and then we felt stupid that it turned out to be the darn printer! Good Luck! Walt -----Original Message----- From: Dirk Zumwalt [mailto:community-noreply@qnx.com] Sent: Friday, April 15, 2011 10:31 AM To: technology-networking Subject: QNX 6.3 in MS Virtual PC on XP - Communication Issues Hi, We have several guys here at our company that run the described senerio in the subject line and two of us have set up new boxes to simulate the QNX virtual machine for testing customer ATMs with a paragon simulator. We are having communication issues with the QNX box but no one else is, everything seems to be the same as the working machines. The MS virtual pc is the 2007 version. We can ping the virtual machine and than it drops and no responce after a few minutes we can communicate again, it does this back and forth up and down up and down. Any Ideas would be appreciated? Thanks, Dirk _______________________________________________ Technology http://community.qnx.com/sf/go/post85038

Walt Wimer 2011-04-15T14:44:23Z Dirk Zumwalt http://community.qnx.com/sf/go/post85038 2011-04-15T14:31:06Z 2011-04-15T14:31:06Z

Hi, We have several guys here at our company that run the described senerio in the subject line and two of us have set up new boxes to simulate the QNX virtual machine for testing customer ATMs with a paragon simulator. We are having communication issues with the QNX box but no one else is, everything seems to be the same as the working machines. The MS virtual pc is the 2007 version. We can ping the virtual machine and than it drops and no responce after a few minutes we can communicate again, it does this back and forth up and down up and down. Any Ideas would be appreciated? Thanks, Dirk

Dirk Zumwalt 2011-04-15T14:31:06Z Mario Charest http://community.qnx.com/sf/go/post84760 2011-04-07T15:29:23Z 2011-04-07T15:29:23Z

Here is the other file

Mario Charest 2011-04-07T15:29:23Z Mario Charest http://community.qnx.com/sf/go/post84758 2011-04-07T15:28:50Z 2011-04-07T15:28:50Z

Picture server.jpg shows a screen shot of WireShark taken from a windows server machine. Picture qnx.jpg shows a screen of WireShark taken of the traffic on the port of a cisco switch connecte to a QNX box. This is done using port mirrorint. Traffic on the port is copied to another board where a laptop is running the wireshark session. In server.jp line 24289 shows the penultimate packet a data transfer. The last packet which should be Seq ( 1654677 ) arrives at 25572, but that's 1 second after that previous packet. By looking at the qnx.jpg image, line 14361 shows the packet 1654677 was send but it seems to have been lost because 1 second latter (14997) QNX resent that same packet. We are looking at why the packet got lost in the first place, but I'm surprise QNX took 1 second to resent the packet. Is that "normal", anything we can do to shorten that time? Both screen shot only shows the data related to the stream.

Mario Charest 2011-04-07T15:28:50Z Fernando Gonzalez http://community.qnx.com/sf/go/post84638 2011-04-05T17:52:48Z 2011-04-05T17:52:48Z

Thank you Lasse for your experience report and vote of support. Have a great week! -Fernando.

Fernando Gonzalez 2011-04-05T17:52:48Z Dennis Kellly http://community.qnx.com/sf/go/post84631 2011-04-05T16:44:13Z 2011-04-05T16:44:13Z

>>>is there a limitation as to how many partitions can be created? Docs say the limit is eight. Of course there is overhead associated with scheduling a partition so you don't want to create more than necessary. >>>>>>do the user apps have to bundled together to form the "user partition"? Not sure what you mean by "bundle" ... but there is no change to the binaries. You either start the binary in the correct partition or "move" the instance to the correct partition after it starts. Use "aps" command to create the partitions. Use "on" command (-X) to start an instance in a particular partition. Dennis

Dennis Kellly 2011-04-05T16:44:13Z Frederic Defever http://community.qnx.com/sf/go/post84628 2011-04-05T16:20:14Z 2011-04-05T16:20:14Z

hi guys, I'm wondering the level of granularity provided by the adaptive partitioning module in QNX? On the adaptive partitioning page on qnx, they gave the example of partitioning the system like this, into 3 partitions: 1) QNX filesystem 2) User apps 3) downloadable partition do the user apps have to bundled together to form the "user partition"? is there a limitation as to how many partitions can be created? trying to figure out a way to prevent applications from hogging the cpu and blocking other applications to start/function properly. rgs, Fred

Frederic Defever 2011-04-05T16:20:14Z Sean Boudreau http://community.qnx.com/sf/go/post84609 2011-04-05T12:22:23Z 2011-04-05T12:22:23Z

Yes. Regards, -seanb ----- Original Message ----- From: Frederic Defever [mailto:community-noreply@qnx.com] Sent: Tuesday, April 05, 2011 05:26 AM To: technology-networking <post84607@community.qnx.com> Subject: Re: GDB on target ppc ?? Sean, are you saying there's no gdb version available to run on ppc with qnx? and the only way to debug binaries on ppc is to use gdb from host? rgs, Fred _______________________________________________ Technology http://community.qnx.com/sf/go/post84607

Sean Boudreau 2011-04-05T12:22:23Z Jeevan Mathew http://community.qnx.com/sf/go/post84608 2011-04-05T09:28:18Z 2011-04-05T09:28:18Z

Exactly, that is what he was saying. -Jeevan

Jeevan Mathew 2011-04-05T09:28:18Z Frederic Defever http://community.qnx.com/sf/go/post84607 2011-04-05T09:26:20Z 2011-04-05T09:26:20Z

Sean, are you saying there's no gdb version available to run on ppc with qnx? and the only way to debug binaries on ppc is to use gdb from host? rgs, Fred

Frederic Defever 2011-04-05T09:26:20Z Lasse Skov http://community.qnx.com/sf/go/post84598 2011-04-05T06:00:02Z 2011-04-05T06:00:02Z

Hi Yes i had tried a design without phy. It's no problem. My design was with MII interface but should not give problem. My PPC was not 8536 but a 83xx but this serie also using driver mpc85xx and this working without problem. /Lasse

Lasse Skov 2011-04-05T06:00:02Z Mike Srdanovic http://community.qnx.com/sf/go/post84594 2011-04-04T23:53:30Z 2011-04-04T23:53:30Z

thanks to everyone for your response and suggestions. Glad to hear that the standard tools are available for QNX and I look into putting together a custom test as a first step. Mike

Mike Srdanovic 2011-04-04T23:53:30Z Sean Boudreau http://community.qnx.com/sf/go/post84581 2011-04-04T18:31:26Z 2011-04-04T18:31:26Z

On Mon, Apr 04, 2011 at 12:38:28PM -0400, Frederic Defever wrote: > hi, > > we're using QNX6.4.1 with dev platforms on windows and linux (host), but > our target is PPC. > > as part of the QNX install we have several versions of GDB installed > under the QNX641/host like: ntoppc-gdb.exe, ntomips-gdb.exe, ... > > which is ok to run GDB from windows on binaries built for PPC target. > > But now if we want to use GDB directly on our target PPC, how do we > proceed?? > thanks. > Fred > ntoppc-gdb on windows (all hosts). We don't ship a self hosted gdb for ppc targets AFAIK. Regards, -seanb

Sean Boudreau 2011-04-04T18:31:26Z Frederic Defever http://community.qnx.com/sf/go/post84577 2011-04-04T16:38:27Z 2011-04-04T16:38:27Z

hi, we're using QNX6.4.1 with dev platforms on windows and linux (host), but our target is PPC. as part of the QNX install we have several versions of GDB installed under the QNX641/host like: ntoppc-gdb.exe, ntomips-gdb.exe, ... which is ok to run GDB from windows on binaries built for PPC target. But now if we want to use GDB directly on our target PPC, how do we proceed?? thanks. Fred

Frederic Defever 2011-04-04T16:38:27Z Patrik Lahti http://community.qnx.com/sf/go/post84558 2011-04-04T12:22:37Z 2011-04-04T12:22:37Z

There are, e.g. iperf/netperf/etc, and we use them all them all the time, but they measure the entire path between two hosts. And from your original description, that's not what you want to measure. You could make a custom driver just for measuring exactly what you want, or maybe use loopback, or custom kernel event trace... On 04/04/2011 07:58 AM, Mike Srdanovic wrote: > > Yes, thanks for the suggetion and I've thought of that approach as > well. Is there a standard network test tool set available for qnx? > > Mike > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post84553 >

Patrik Lahti 2011-04-04T12:22:37Z Mike Srdanovic http://community.qnx.com/sf/go/post84553 2011-04-04T11:58:41Z 2011-04-04T11:58:41Z

Yes, thanks for the suggetion and I've thought of that approach as well. Is there a standard network test tool set available for qnx? Mike

Mike Srdanovic 2011-04-04T11:58:41Z Patrik Lahti http://community.qnx.com/sf/go/post84541 2011-04-03T16:29:03Z 2011-04-03T16:29:03Z

Sounds like you should not do this measurement using your "app" but rather using a (known good) latency test software. Good luck! /P On 11-04-02 10:11 AM, Mike Srdanovic wrote: > Jeevan, > > This is essentially what I have, a single dedicated app on the host with > nothing more than the network stack being utilized once the app is > running. The app currently runs on a different OS and I'm trying to > determine the expected improvement porting to QNX (i certianly expect > some). The app has "chat" functionality i.e. it's sole purpose is to > receive network packets via UDP and communicate to other servers via > tcp/ip. The communication latency (both UDP and via TCP) is of utmost > importance and am trying to minimize this value. > > Thank, > Mike > > > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post84538 >

Patrik Lahti 2011-04-03T16:29:03Z Mike Srdanovic http://community.qnx.com/sf/go/post84538 2011-04-02T14:11:01Z 2011-04-02T14:11:01Z

Jeevan, This is essentially what I have, a single dedicated app on the host with nothing more than the network stack being utilized once the app is running. The app currently runs on a different OS and I'm trying to determine the expected improvement porting to QNX (i certianly expect some). The app has "chat" functionality i.e. it's sole purpose is to receive network packets via UDP and communicate to other servers via tcp/ip. The communication latency (both UDP and via TCP) is of utmost importance and am trying to minimize this value. Thank, Mike

Mike Srdanovic 2011-04-02T14:11:01Z Jeevan Mathew(deleted) http://community.qnx.com/sf/go/post84536 2011-04-02T10:28:10Z 2011-04-02T10:28:10Z

I do not think that this kind of stats are available. Also the transport of the information can be preempted along all the way up to your application by any higher prior event. You would have to cut down your system just having your app and the stack and do the measurement yourself to be able to compare it with whatever. My 2 cents. -Jeevan ----- Originalnachricht ----- Von: Mike Srdanovic [mailto:community-noreply@qnx.com] Gesendet: Friday, April 01, 2011 05:56 PM An: technology-networking <post84532@community.qnx.com> Betreff: tcp/ip packet to application latency General qustion to all: Are there any stats or reviews available that would give me some figures around the general tcp/ip packet latency I could expect within my QNX application? I realize that this is a large topic and a loaded question, but what I'm trying to get the sense of is the general expected data latency on QNX from arival on the NIC to my application via recv(), given a "fast" machine. Thanks in advance Mike _______________________________________________ Technology http://community.qnx.com/sf/go/post84532

Jeevan Mathew(deleted) 2011-04-02T10:28:10Z Mike Srdanovic http://community.qnx.com/sf/go/post84532 2011-04-01T21:56:05Z 2011-04-01T21:56:05Z

General qustion to all: Are there any stats or reviews available that would give me some figures around the general tcp/ip packet latency I could expect within my QNX application? I realize that this is a large topic and a loaded question, but what I'm trying to get the sense of is the general expected data latency on QNX from arival on the NIC to my application via recv(), given a "fast" machine. Thanks in advance Mike

Mike Srdanovic 2011-04-01T21:56:05Z Fernando Gonzalez http://community.qnx.com/sf/go/post84428 2011-03-30T19:08:30Z 2011-03-30T19:08:30Z

We would like to consider a PHY-less design with MAC-to-MAC communication, with an MPC 8536e CPU processor. Has anybody tried this? Or do you know if this a feature that the mpc85xx network driver may support in the future? Thanks, -Fernando Gonzalez.

Fernando Gonzalez 2011-03-30T19:08:30Z nizam mohamed http://community.qnx.com/sf/go/post84119 2011-03-21T10:28:51Z 2011-03-21T10:28:51Z

I have found the issue. The problem is not to do with QnX configuration. The router doesn't know where to forward the packet (192.168.20.X). So, In the router, i need to make routing 192.168.20.X packets to 192.168.1.102 which is my QnX WiFi's AP Ethernet Port. I am using Cisco Linksys Router (WRT310N). In that under "Setup" -> "Advanced Routing" -> "Static Routing", i did as follows. Route Entries (1) Enter Router Name: test Destination LAN IP: 192.168.20.0 Subnet Mask: 255.255.255.0 Gatewat: 192.168.1.102 Interface: Lan & Wireless Now, i am able to access WiFi Clients (Internal) from Wired (External) Network. Thanks.

nizam mohamed 2011-03-21T10:28:51Z Dave Brown http://community.qnx.com/sf/go/post84050 2011-03-16T18:59:37Z 2011-03-16T18:59:37Z

ALTQ is functioning and should be available in the next major release. If you require access before this, please contact your QNX representative. Thanks Dave > -----Original Message----- > From: Max Timchenko [mailto:community-noreply@qnx.com] > Sent: March 14, 2011 9:41 AM > To: technology-networking > Subject: ALTQ support in io-pkt-v6-hc and pf > > Dear forum, > > In this thread > http://community.qnx.com/sf/discussion/do/listPosts/projects.networking > /discussion.general.topc1999 it was mentioned that ALTQ is not > necessarily working. That was about 2 years ago. > > What's the current state of ALTQ support, given pfctl -e returns > > No ALTQ support in kernel > ALTQ related functions disabled > > ? > > Thanks, Max > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post83969

Dave Brown 2011-03-16T18:59:37Z Walt Wimer http://community.qnx.com/sf/go/post83981 2011-03-14T16:24:59Z 2011-03-14T16:24:59Z

After some more searching, it looks like the answer to my question is likely to be "yes, this is (at least mostly) possible." This appears to be a good documentation resource: http://www.netbsd.org/docs/internals/en/chap-networking-services.html Walt

Walt Wimer 2011-03-14T16:24:59Z Walt Wimer http://community.qnx.com/sf/go/post83979 2011-03-14T15:57:21Z 2011-03-14T15:57:21Z

Hi All, My searches for answers to this question have come up a bit short, so I'm now posing the question directly. Can QNX Neutrino support the following scenario: - Two (or more?) physical ethernet interfaces, all connected to the same Layer 2 network (e.g. two or more interconnected physical ethernet switches). This Layer 2 network also represents a single IP subnet, say 192.168.1.0/24. - One ("virtual"?) IP interface under QNX, with a single IP address (say 192.168.1.100/24). - A software Layer 2 bridge function that bridges the one IP interface to the outside world. Ideally, it would NOT forward packets from one physical ethernet interface to another, only between the many physical interfaces and the one virtual IP interface. It would look something like this: +-------- ethernet 1 | IP interface ---- bridge | +-------- ethernet 2 The bridge would NOT forward packets _between_ ethernets 1 and 2. When the IP interface sends outgoing packets, the bridge would flood broadcasts, multicasts, and unknown unicasts out both ethernet interfaces. The bridge would listen to and learn source MAC addresses (of external nodes) that it hears on ethernets 1 and 2. For example, the bridge might learn that the MAC address of some external host A lives on ethernet 1, and the MAC address of another external host B lives on ethernet 2. In the normal way, the internal IP interface learns (via ARP) the mapping between A's IP address and A's MAC address, and between B's IP address and B's MAC address. When the internal IP interface sends an outgoing IP datagram destined to A, the bridge knows to send the packet out ethernet 1. Similarly, when the internal IP interface sends an outgoing IP datagram destined to B, the bridge knows to send the packet out ethernet 2. If changes occur in the external network (links go down, the spanning tree topology changes, etc.), the bridge re-learns the various MAC address locations, so that connectivity is maintained. Does Neutrino support this kind of arrangement? (As far as I know, QNX4 does not. We are likely transitioning from QNX4 to Neutrino for other reasons, and I'm hoping that Neutrino can help us with the above problem as well.) Thanks!!! Walt

Walt Wimer 2011-03-14T15:57:21Z nizam mohamed http://community.qnx.com/sf/go/post83975 2011-03-14T15:16:59Z 2011-03-14T15:16:59Z

Yes, both way it is working. Do i need to set any "route" command for doing this?. How other guys are setting up QnX WiFi AP?. Do i need to add any extra commands like "rdr on" in the pf.conf file?. Thanks.

nizam mohamed 2011-03-14T15:16:59Z Patrik Lahti http://community.qnx.com/sf/go/post83970 2011-03-14T13:49:12Z 2011-03-14T13:49:12Z

And with that config on Linux, can you ping both ways? On 11-03-14 02:20 AM, nizam mohamed wrote: > Thanks Patrik, > > Then how to make my WiFi QnX AP work without using NAT?. Since the WiFi > network is internal (192.168.X.X), any way we need NAT to access > external network. My problem is accessing internal network from External > network. In linux, the following commands achieve this > > ---------------------------------------------------------------------------------------------- > iptables -t nat -A POSTROUTING -o en0 -j MASQUERADE > iptables -A FORWARD -i en0 -o wl0 -m state --state RELATED,ESTABLISHED > -j ACCEPT > iptables -A FORWARD -i wl0 -o en0 -j ACCEPT > ----------------------------------------------------------------------------------------------- > > What is the correct way doing this in QnX?. > > > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post83959 >

Patrik Lahti 2011-03-14T13:49:12Z Max Timchenko http://community.qnx.com/sf/go/post83969 2011-03-14T13:41:18Z 2011-03-14T13:41:18Z

Dear forum, In this thread http://community.qnx.com/sf/discussion/do/listPosts/projects.networking/discussion.general.topc1999 it was mentioned that ALTQ is not necessarily working. That was about 2 years ago. What's the current state of ALTQ support, given pfctl -e returns No ALTQ support in kernel ALTQ related functions disabled ? Thanks, Max

Max Timchenko 2011-03-14T13:41:18Z nizam mohamed http://community.qnx.com/sf/go/post83959 2011-03-14T06:20:21Z 2011-03-14T06:20:21Z

Thanks Patrik, Then how to make my WiFi QnX AP work without using NAT?. Since the WiFi network is internal (192.168.X.X), any way we need NAT to access external network. My problem is accessing internal network from External network. In linux, the following commands achieve this ---------------------------------------------------------------------------------------------- iptables -t nat -A POSTROUTING -o en0 -j MASQUERADE iptables -A FORWARD -i en0 -o wl0 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i wl0 -o en0 -j ACCEPT ----------------------------------------------------------------------------------------------- What is the correct way doing this in QnX?.

nizam mohamed 2011-03-14T06:20:21Z Patrik Lahti http://community.qnx.com/sf/go/post83955 2011-03-13T17:58:35Z 2011-03-13T17:58:35Z

Hi, I suspect the ping won't work because you have the NAT in between. It can only translate outgoing connections. Cheers! /P On 11-03-11 08:27 AM, nizam mohamed wrote: > I have setup my QnX target as WiFi AP. The setup is as follows. > > en0 - 192.168.1.102 (dhcp.client) connected to backbone. > wl0 - 192.168.20.1 (dhcpd) > > Other WiFi clients are able to associate with WiFi AP and getting IP > addresses from dhcpd running in my taget. For example: 192.168.20.254 or > 192.168.20.253 > > I have issued following commands for NAT: > > sysctl -w net.inet.ip.forwarding=1 > mount -Ttcpip lsm-pf-v4.so > pfctl -e -f /etc/pf.conf > > From WiFi client, i am able to ping the host (192.168.1.101) that is > connected on the backbone and i am able to browse the internet. But i am > not able to ping 192.168.20.X (neither 192.168.20.1 nor 192.168.20.254) > region from the wired host (192.168.1.102). > > My /etc/pf.conf is as follows > > "nat on en0 from wl0/24 to any -> en0" > > Please let me know how to make the ping from External network > (192.168.1.X) to internal network (192.168.20.X) to work. > > Thanks & Regards, > Nizam. > > ---------------------------------------- > Ethernet Client (192.168.1.101) > ----------------------------------------- > | > | > --------------------------------------- > Router (192.168.1.1) --------------------------------------> LAN > ---------------------------------------- > | > | > --------------------------------------- > QnX Target en0 (192.168.1.102) > QnX Target wl0 (192.168.20.1) > ---------------------------------------- > : > : > ------------------------------------ > Wifi Client (192.168.20.254) > -------------------------------------- > > ping from 192.168.20.254 to 192.168.1.X is working > ping from 192.168.1.101 to 192.168.20.X is NOT working > > > > > > > > > > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post83927 >

Patrik Lahti 2011-03-13T17:58:35Z nizam mohamed http://community.qnx.com/sf/go/post83927 2011-03-11T13:27:27Z 2011-03-11T13:27:27Z

I have setup my QnX target as WiFi AP. The setup is as follows. en0 - 192.168.1.102 (dhcp.client) connected to backbone. wl0 - 192.168.20.1 (dhcpd) Other WiFi clients are able to associate with WiFi AP and getting IP addresses from dhcpd running in my taget. For example: 192.168.20.254 or 192.168.20.253 I have issued following commands for NAT: sysctl -w net.inet.ip.forwarding=1 mount -Ttcpip lsm-pf-v4.so pfctl -e -f /etc/pf.conf From WiFi client, i am able to ping the host (192.168.1.101) that is connected on the backbone and i am able to browse the internet. But i am not able to ping 192.168.20.X (neither 192.168.20.1 nor 192.168.20.254) region from the wired host (192.168.1.102). My /etc/pf.conf is as follows "nat on en0 from wl0/24 to any -> en0" Please let me know how to make the ping from External network (192.168.1.X) to internal network (192.168.20.X) to work. Thanks & Regards, Nizam. ---------------------------------------- Ethernet Client (192.168.1.101) ----------------------------------------- | | --------------------------------------- Router (192.168.1.1) --------------------------------------> LAN ---------------------------------------- | | --------------------------------------- QnX Target en0 (192.168.1.102) QnX Target wl0 (192.168.20.1) ---------------------------------------- : : ------------------------------------ Wifi Client (192.168.20.254) -------------------------------------- ping from 192.168.20.254 to 192.168.1.X is working ping from 192.168.1.101 to 192.168.20.X is NOT working

nizam mohamed 2011-03-11T13:27:27Z Dave Bott(deleted) http://community.qnx.com/sf/go/post83625 2011-03-01T15:46:36Z 2011-03-01T15:46:36Z

Hi Sean, You're right, '-C' is mentioned, in the depths of reams of docs, but how would a new person know to look for it ? If there was a section marked 'how to set up a bridge', that would be a lot more obvious. I'll grant you it could help to provide a clue, but we're supposed to be helping prospects and customers to get things done easily, not make them work really hard to do stuff we can document. So, I run 'ifconfig -C' and it lists 'bridge' amongst other things. How does this help me ? How do I know what to do with 'bridge' ? How do I know to use brconfig (it is not mentioned in ifconfig) ? The customer tells me he's tried to use brconfig, but is not managing to get it working. Is there a (tested) example that a customer can use as a starting point, even if it is a non-QNX document ? I'll file a PR requesting improved docs, assuming that this does all work at some point. I'm not trying to be awkward, I'm asking that the documentation cover this, so that a customer can help themselves and be happier, while also relieving us of the support burden. Happier customer and less work for us sounds like the way to go... Any suggestions for the exact steps that this customer should take would be most welcome. Regards Dave ________________________________ From: Sean Boudreau [mailto:community-noreply@qnx.com] Sent: Tue 3/1/2011 12:06 AM To: technology-networking Subject: RE: How to behave like a switch ? 'ifconfig -C' is mentioned. Regards, -seanb -----Original Message----- From: Dave Bott [mailto:community-noreply@qnx.com] Sent: Mon 2/28/2011 9:39 PM To: technology-networking Subject: RE: How to behave like a switch ? Thanks Guys. Small point : ifconfig bridge0 create does not appear to be documented.... 'create' is mentioned, but nothing specific. brconfig is, which is lovely ! So, is ifconfig bridge0 create all that is required to be done, prior to using brconfig to set the real magic up ? Thanks ! Dave ________________________________ From: Sean Boudreau [mailto:community-noreply@qnx.com] Sent: Mon 2/28/2011 6:14 PM To: technology-networking Subject: Re: How to behave like a switch ? Look at 'ifconfig bridge0 create' and the 'brconfig' utility. This is all at layer 2. Regards, -seanb ----- Original Message ----- From: Dave Bott [mailto:community-noreply@qnx.com] Sent: Monday, February 28, 2011 08:55 PM To: technology-networking <post83605@community.qnx.com> Subject: How to behave like a switch ? 6.5.0 X86 A customer wonders how to use their 3-NIC X86 board to forward packets like a switch does i.e. configure all 3 NICs to be on the same logical subnet, yet be physically connected to different cables/other NICs on each port, allowing those external devices to communicate with each other and QNX via the QNX box that will forward packets as required between the ports. Normally, we do not allow this, and I understand that. Is there a mode we can se tthat will achieve this, or do we strictly require each NIC to be on a different subnet ? Thanks ! Dave _______________________________________________ Technology http://community.qnx.com/sf/go/post83605 _______________________________________________ Technology http://community.qnx.com/sf/go/post83606 _______________________________________________ Technology http://community.qnx.com/sf/go/post83608 _______________________________________________ Technology http://community.qnx.com/sf/go/post83610

Dave Bott(deleted) 2011-03-01T15:46:36Z Sean Boudreau http://community.qnx.com/sf/go/post83610 2011-03-01T08:06:18Z 2011-03-01T08:06:18Z

'ifconfig -C' is mentioned. Regards, -seanb -----Original Message----- From: Dave Bott [mailto:community-noreply@qnx.com] Sent: Mon 2/28/2011 9:39 PM To: technology-networking Subject: RE: How to behave like a switch ? Thanks Guys. Small point : ifconfig bridge0 create does not appear to be documented.... 'create' is mentioned, but nothing specific. brconfig is, which is lovely ! So, is ifconfig bridge0 create all that is required to be done, prior to using brconfig to set the real magic up ? Thanks ! Dave ________________________________ From: Sean Boudreau [mailto:community-noreply@qnx.com] Sent: Mon 2/28/2011 6:14 PM To: technology-networking Subject: Re: How to behave like a switch ? Look at 'ifconfig bridge0 create' and the 'brconfig' utility. This is all at layer 2. Regards, -seanb ----- Original Message ----- From: Dave Bott [mailto:community-noreply@qnx.com] Sent: Monday, February 28, 2011 08:55 PM To: technology-networking <post83605@community.qnx.com> Subject: How to behave like a switch ? 6.5.0 X86 A customer wonders how to use their 3-NIC X86 board to forward packets like a switch does i.e. configure all 3 NICs to be on the same logical subnet, yet be physically connected to different cables/other NICs on each port, allowing those external devices to communicate with each other and QNX via the QNX box that will forward packets as required between the ports. Normally, we do not allow this, and I understand that. Is there a mode we can se tthat will achieve this, or do we strictly require each NIC to be on a different subnet ? Thanks ! Dave _______________________________________________ Technology http://community.qnx.com/sf/go/post83605 _______________________________________________ Technology http://community.qnx.com/sf/go/post83606 _______________________________________________ Technology http://community.qnx.com/sf/go/post83608

Sean Boudreau 2011-03-01T08:06:18Z Dave Bott(deleted) http://community.qnx.com/sf/go/post83608 2011-03-01T02:39:01Z 2011-03-01T02:39:01Z

Thanks Guys. Small point : ifconfig bridge0 create does not appear to be documented.... 'create' is mentioned, but nothing specific. brconfig is, which is lovely ! So, is ifconfig bridge0 create all that is required to be done, prior to using brconfig to set the real magic up ? Thanks ! Dave ________________________________ From: Sean Boudreau [mailto:community-noreply@qnx.com] Sent: Mon 2/28/2011 6:14 PM To: technology-networking Subject: Re: How to behave like a switch ? Look at 'ifconfig bridge0 create' and the 'brconfig' utility. This is all at layer 2. Regards, -seanb ----- Original Message ----- From: Dave Bott [mailto:community-noreply@qnx.com] Sent: Monday, February 28, 2011 08:55 PM To: technology-networking <post83605@community.qnx.com> Subject: How to behave like a switch ? 6.5.0 X86 A customer wonders how to use their 3-NIC X86 board to forward packets like a switch does i.e. configure all 3 NICs to be on the same logical subnet, yet be physically connected to different cables/other NICs on each port, allowing those external devices to communicate with each other and QNX via the QNX box that will forward packets as required between the ports. Normally, we do not allow this, and I understand that. Is there a mode we can se tthat will achieve this, or do we strictly require each NIC to be on a different subnet ? Thanks ! Dave _______________________________________________ Technology http://community.qnx.com/sf/go/post83605 _______________________________________________ Technology http://community.qnx.com/sf/go/post83606

Dave Bott(deleted) 2011-03-01T02:39:01Z Sean Boudreau http://community.qnx.com/sf/go/post83606 2011-03-01T02:14:46Z 2011-03-01T02:14:46Z

Look at 'ifconfig bridge0 create' and the 'brconfig' utility. This is all at layer 2. Regards, -seanb ----- Original Message ----- From: Dave Bott [mailto:community-noreply@qnx.com] Sent: Monday, February 28, 2011 08:55 PM To: technology-networking <post83605@community.qnx.com> Subject: How to behave like a switch ? 6.5.0 X86 A customer wonders how to use their 3-NIC X86 board to forward packets like a switch does i.e. configure all 3 NICs to be on the same logical subnet, yet be physically connected to different cables/other NICs on each port, allowing those external devices to communicate with each other and QNX via the QNX box that will forward packets as required between the ports. Normally, we do not allow this, and I understand that. Is there a mode we can se tthat will achieve this, or do we strictly require each NIC to be on a different subnet ? Thanks ! Dave _______________________________________________ Technology http://community.qnx.com/sf/go/post83605

Sean Boudreau 2011-03-01T02:14:46Z Dave Bott(deleted) http://community.qnx.com/sf/go/post83605 2011-03-01T01:55:17Z 2011-03-01T01:55:17Z

6.5.0 X86 A customer wonders how to use their 3-NIC X86 board to forward packets like a switch does i.e. configure all 3 NICs to be on the same logical subnet, yet be physically connected to different cables/other NICs on each port, allowing those external devices to communicate with each other and QNX via the QNX box that will forward packets as required between the ports. Normally, we do not allow this, and I understand that. Is there a mode we can se tthat will achieve this, or do we strictly require each NIC to be on a different subnet ? Thanks ! Dave

Dave Bott(deleted) 2011-03-01T01:55:17Z Max Timchenko http://community.qnx.com/sf/go/post83560 2011-02-27T14:49:39Z 2011-02-27T14:49:39Z

Dear forum, Does QNX 6.5 support the mbuf_tags API as described in http://portal.acm.org/citation.cfm?id=1250985? It is not mentioned in the documentation, but matching prototypes can be found in sys\mbuf.h. If yes, any restrictions on type of networking stack (v4, v4-hc, v6-hc) this API may be used with? Does the QNX packet filter (PF) propagate packet tags done by its rules on egress packets to the mbuf_tags information in packet mbufs? Thanks! Max

Max Timchenko 2011-02-27T14:49:39Z Davide Ancri http://community.qnx.com/sf/go/post83174 2011-02-15T14:05:30Z 2011-02-15T14:05:30Z

Sorry for press forward on this post, but it is becoming a blocking problem for us. Can anyone give me any useful information? Thanks a lot, Davide

Davide Ancri 2011-02-15T14:05:30Z Davide Ancri http://community.qnx.com/sf/go/post83109 2011-02-11T11:06:07Z 2011-02-11T11:06:07Z

Hi all the text in the post subject appears into "sloginfo" output, on a qnx 6.4.1 node with no local filesystem, reachable and handled through qnet and IP. I noticed this strange sloginfo message since the qnx node seems to stop working properly from an IP point of view right 5 seconds before this message gets slogged. A number of custom applications run on the node and try to perform standard IP networking: 5 second before the NetSignalKill message in sloginfo, all these applications warn about socket queues full on tx. Node keeps up and is reachable through qnet. What is the reason for that sloginfo message... and can it point me to a cause of the IP problem? Or is it a simple effect of something I'm doing wrong? Thanks Davide

Davide Ancri 2011-02-11T11:06:07Z Vineet Garg http://community.qnx.com/sf/go/post83062 2011-02-10T03:08:04Z 2011-02-10T03:08:04Z

hi apurva assuming io-net as ip stack, i dont think you can change the mac address of vlan interface as it is just a pseudo-interface providing vlan capablity over parent interface. however, if you have access to you have access to your network driver, you can change it is register multiple logical interfaces (with different mac addresses) to io-net while it can actually transmit on the same physical port. hope this helps. regards vineet On Tue, Feb 8, 2011 at 12:48 PM, Apurva P <community-noreply@qnx.com> wrote: > Hi, > > First of all please let me explain what is my requirement. Using single > physical interface I want to create three network interfaces having > different IP and MAC addresses. > > For that I created three VLAN interfaces (vlan0, vlan1 and vlan2) on > physical interface (en0) using ifconfig. > > e.g. > ifconfig vlan0 create > ifconfig vlan0 vlan 2 vlanif en0 > > Now, I can assign different IP address for all three VLAN interface using > ifconfig but MAC address of all these interfaces is same as its > parent's(en0) MAC address . > > To change MAC address I tried... > # ifconfig vlan0 down > # ifconfig vlan0 link new_mac_addr active > # ifconfig vlan0 link old_mac_addr delete > ... > > This works for en0 but it did not work for vlan interfaces. > > So please can anyone tell whether is it possible to change MAC address of > VLAN interface? If yes please let me know how it can be done? > > Thank you very much > Apurva > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post82966 > >

Vineet Garg 2011-02-10T03:08:04Z Apurva P http://community.qnx.com/sf/go/post82966 2011-02-08T07:18:27Z 2011-02-08T07:18:27Z

Hi, First of all please let me explain what is my requirement. Using single physical interface I want to create three network interfaces having different IP and MAC addresses. For that I created three VLAN interfaces (vlan0, vlan1 and vlan2) on physical interface (en0) using ifconfig. e.g. ifconfig vlan0 create ifconfig vlan0 vlan 2 vlanif en0 Now, I can assign different IP address for all three VLAN interface using ifconfig but MAC address of all these interfaces is same as its parent's(en0) MAC address . To change MAC address I tried... # ifconfig vlan0 down # ifconfig vlan0 link new_mac_addr active # ifconfig vlan0 link old_mac_addr delete ... This works for en0 but it did not work for vlan interfaces. So please can anyone tell whether is it possible to change MAC address of VLAN interface? If yes please let me know how it can be done? Thank you very much Apurva

Apurva P 2011-02-08T07:18:27Z Sean Boudreau http://community.qnx.com/sf/go/post82942 2011-02-07T17:58:52Z 2011-02-07T17:58:52Z

If you use pkg_add it will install all dependencies. Regards, -seanb ----- Original Message ----- From: Michael Stinaff [mailto:community-noreply@qnx.com] Sent: Monday, February 07, 2011 12:46 PM To: technology-networking <post82941@community.qnx.com> Subject: Re: RE: OpenLDAP for user authentication Thank you for the prompt reply. I've actually already installed the OpenLDAP package, just not sure how to get QNX to use it for user authentication. Do I need to install the OpenPAM package as well? Or is everything I need to use the OpenLDAP package already there? Again thank you very much, Mike _______________________________________________ Technology http://community.qnx.com/sf/go/post82941

Sean Boudreau 2011-02-07T17:58:52Z Michael Stinaff http://community.qnx.com/sf/go/post82941 2011-02-07T17:46:49Z 2011-02-07T17:46:49Z

Thank you for the prompt reply. I've actually already installed the OpenLDAP package, just not sure how to get QNX to use it for user authentication. Do I need to install the OpenPAM package as well? Or is everything I need to use the OpenLDAP package already there? Again thank you very much, Mike

Michael Stinaff 2011-02-07T17:46:49Z Sean Boudreau http://community.qnx.com/sf/go/post82939 2011-02-07T16:08:11Z 2011-02-07T16:08:11Z

http://ftp.netbsd.org/pub/pkgsrc/packages/QNX/i386/6.5.0_head_20100424/databases/openldap-2.4.21.tgz http://community.qnx.com/sf/projects/pkgsrc Regards, -seanb -----Original Message----- From: Michael Stinaff [mailto:community-noreply@qnx.com] Sent: Mon 2/7/2011 11:05 AM To: technology-networking Subject: OpenLDAP for user authentication I'm running QNX 6.5 and am wondering if it is possible for users to log into QNX using the OpenLDAP package for authentication against an LDAP server. I searched the forums and only found this old post: http://community.qnx.com/sf/go/topc3006 and the internet and found this: http://www.openqnx.com/PNphpBB2-viewtopic-t85-.html I'm hoping things have changed since then. Thank you, Mike _______________________________________________ Technology http://community.qnx.com/sf/go/post82938

Sean Boudreau 2011-02-07T16:08:11Z Michael Stinaff http://community.qnx.com/sf/go/post82938 2011-02-07T16:05:01Z 2011-02-07T16:05:01Z

I'm running QNX 6.5 and am wondering if it is possible for users to log into QNX using the OpenLDAP package for authentication against an LDAP server. I searched the forums and only found this old post: http://community.qnx.com/sf/go/topc3006 and the internet and found this: http://www.openqnx.com/PNphpBB2-viewtopic-t85-.html I'm hoping things have changed since then. Thank you, Mike

Michael Stinaff 2011-02-07T16:05:01Z Patrick Shelly(deleted) http://community.qnx.com/sf/go/post82835 2011-02-01T17:45:06Z 2011-02-01T17:45:06Z

Thanks Dave. I was confusing the protocol option enmap=0 with the driver option name=en... Cheers, Pat

Patrick Shelly(deleted) 2011-02-01T17:45:06Z Dave Bott(deleted) http://community.qnx.com/sf/go/post82833 2011-02-01T16:56:03Z 2011-02-01T16:56:03Z

Hi Pat, I think you misunderstand. 'fec0' is the published name for that driver. You'll always get the name(s) that the driver publishes. The enmap option, as I understand it, enables/disables the use of 'en<X>' as a generic way to interact with NIC device instances. So, the question is - does 'ifconfig en0' work in both cases, or only without 'enmap=0'? I could be wrong, but that's how I understood it... Cheers Dave ________________________________ From: Patrick Shelly [mailto:community-noreply@qnx.com] Sent: Tue 2/1/2011 8:31 AM To: technology-networking Subject: Re: interface naming convention Using QNX 6.5.0 with the i.MX51, it seems the enmap=0 option has no effect. #io-pkt-v4-hc -d mx51 mac=00049F00EA2C -p tcpip enmap=0 #ifconfig lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 fec0: flags=802<BROADCAST,SIMPLEX> mtu 1500 address: 00:04:9f:00:ea:2c media: Ethernet none #slay o-pkt-v4-hc #io-pkt-v4-hc -d mx51 mac=00049F00EA2C #ifconfig lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 fec0: flags=802<BROADCAST,SIMPLEX> mtu 1500 address: 00:04:9f:00:ea:2c media: Ethernet none Seems to enumerate as fec0 regardless of enmap. Is this expected? _______________________________________________ Technology http://community.qnx.com/sf/go/post82829

Dave Bott(deleted) 2011-02-01T16:56:03Z Patrick Shelly(deleted) http://community.qnx.com/sf/go/post82829 2011-02-01T16:31:34Z 2011-02-01T16:31:34Z

Using QNX 6.5.0 with the i.MX51, it seems the enmap=0 option has no effect. #io-pkt-v4-hc -d mx51 mac=00049F00EA2C -p tcpip enmap=0 #ifconfig lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 fec0: flags=802<BROADCAST,SIMPLEX> mtu 1500 address: 00:04:9f:00:ea:2c media: Ethernet none #slay o-pkt-v4-hc #io-pkt-v4-hc -d mx51 mac=00049F00EA2C #ifconfig lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 fec0: flags=802<BROADCAST,SIMPLEX> mtu 1500 address: 00:04:9f:00:ea:2c media: Ethernet none Seems to enumerate as fec0 regardless of enmap. Is this expected?

Patrick Shelly(deleted) 2011-02-01T16:31:34Z Abhishek Ashtekar http://community.qnx.com/sf/go/post82610 2011-01-25T09:27:04Z 2011-01-25T09:27:04Z

Hello, Using the slinger, I would like to write data to data server (ds) that is entered into the HTML form field and submitted. However I cannot understand, how can one manipulate the string value " data" so that it takes the value entered in the form and sent to the dataserver (<!--#qnxvar write="var_name "data"" -->) Normal qnxvar write works well and the variable change in the webserver is reflected on the html page. However problem is with sending in value entered in the form. Thanks, Abhi ----------------------------------------------------------------------------------------------------- Here is my HTML form code : <META HTTP-EQUIV="" CONTENT="2;URL=index.shtml"> <html> <head> <title>AT91SAM9G20</title> </head> <body> <tr><td valign="top"></td> <td valign="top"><h2><i><B>Status</B></i></h2></td></tr> <!-- Start magic --> <P> <!-- Show the Current Value Set --> <!--#qnxvar format="<P>Variable Value Set = %s" --> <!--#qnxvar read="ABHI 128" --> <P> <!-- End magic --> <form name="input" action="index.shtml" method="get"> Set Variable: <input type="text" name="ABHI" <!--#qnxvar format="value="%s"" --> <!--#qnxvar write="ABHI "%s"" --> <input type="submit" value="Submit" /> </form> </body> </html> ------------------------------------------------------------------------------------------------------

Abhishek Ashtekar 2011-01-25T09:27:04Z Robert Murrell http://community.qnx.com/sf/go/post82500 2011-01-20T14:20:49Z 2011-01-20T14:20:49Z

I would like to know about information in the RTM_NETMASK field returned by calls to sysctl. Since I do not have access to the source code I can't determine this myself. I would appreciate insight from anyone who has access to it. When I retrieve the routing table (NET_RT_DUMP), the net mask field of each entry that provides one has a sa_family type of 255. If I treat this field like an AF_INET family (2) I get the correct network mask. What is the significance of the 255 value? When I retrieve the interface list (NET_RT_IFLIST), some of the net mask entries have a sa_family type of AF_UNSPEC (0). The sysctl call returns a list of 'struct if_msghdr' fields, each followed by one or more 'struct ifa_msghdr' fields. The if_msghdr field describes the interface giving the name and MAC address in the RTA_IFP field. Following this entry is an ifa_msghdr field. The RTA_IFA field repeats the interface description. The ifm_flags field is zero. The RTA_NETMASK field is the AF_UNSPEC family. In my tests, this field has an sa_len of 11 bytes. Is there any significance to these data? Following this mystery ifa_msghdr field are more ifa_msghdr fields describing the IP addresses assigned to the interface. The first field describes the default IP address. Its RTA_NETMASK family type is AF_UNSPEC, but if I treat it as AF_INET, I get the correct net mask. Any remaining ifa_msghdr fields are IP aliases and the RTA_NETMASK fields are AF_INET. Why is this field AF_UNSPEC and can I use it to distinguish it as the default IP address?

Robert Murrell 2011-01-20T14:20:49Z Robert Murrell http://community.qnx.com/sf/go/post82499 2011-01-20T13:44:10Z 2011-01-20T13:44:10Z

For the benefit of those struggling to figure out how to do the seemingly simple task of setting network parameters, I have found out through much Google searching and experimentation that getting the information involves the super-secret poorly documented 'syctl' function and setting them involves the equally poorly documented AF_ROUTE socket interface. Avoid 'ioctl' because it doesn't handle IP aliases and is not threadsafe. If my employer is feeling magnanimous I will post code snippets on what I have learned on company time when I get it all working

Robert Murrell 2011-01-20T13:44:10Z Robert Murrell http://community.qnx.com/sf/go/post82459 2011-01-18T20:49:50Z 2011-01-18T20:49:50Z

I am adding an IP alias to en0 using ioctl SIOCAIFADDR function in my application. This works OK. Next, I try to set the subnet mask using ioctl SIOCSIFNETMASK, but this changes the network mask of the primary IP address. I tried to 'bind' the alias address to the socket before calling ioctl but this didn't work. How do I set the subnet mask (and broadcast address) for an IP alias?

Robert Murrell 2011-01-18T20:49:50Z Yuh-Fwu Guu http://community.qnx.com/sf/go/post82426 2011-01-17T19:13:45Z 2011-01-17T19:13:45Z

The transmit and receive nodes are connected directly to each other via a crossover cable for testing, there is nothing in between. Tcpdump shows the dual vlan tags.

Yuh-Fwu Guu 2011-01-17T19:13:45Z Vineet Garg http://community.qnx.com/sf/go/post82425 2011-01-17T18:05:05Z 2011-01-17T18:05:05Z

at least with io-net I am sure that VLAN tag is added by io-net itself and network driver gets the entire frame including the VLAN tag. Not sure if this is any different in io-pkt stack. are you sure there is no other network switch between your transmitter and receiver who could be adding this double tag..? Regards VG On Mon, Jan 17, 2011 at 8:47 PM, Yuh-Fwu Guu <community-noreply@qnx.com>wrote: > When sending a packet of data using sendto() through a vlan, the received > packet has vlan tag attached at the end of the MAC header and before the IP > header. Where does the tag get added to the transmitted packet? Is it in the > socket library? io-pkt? network driver? or somewhere else? > > I am getting dual vlan tag at the receive node (please see the packet data > below), and I am trying to figure out why I am getting double vlan tags. > > 0x0000: 0100 5E28 1114 0018 4405 050A 8100 0000 > 0x0010: 8100 044A 0800 4500 0050 BC4F 0000 0100 > > Thanks for any help... > (I am using e1000 driver with 82576) > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post82416 > >

Vineet Garg 2011-01-17T18:05:05Z Max Timchenko http://community.qnx.com/sf/go/post82420 2011-01-17T16:47:20Z 2011-01-17T16:47:20Z

> My question is more specific. A driver needs to react to a QNX pulse, which is > a MsgReceive blocking call. Can I register it with the io-pkt stack in some > way (similar to an interrupt) so that my function will get called to handle > the pulse, or do I need to create my own thread for this? > > (the scenario is almost the same as the one described in http://community.qnx. > com/sf/discussion/do/listPosts/projects.networking/discussion.technology. > topc14720 - a driver has to communicate with a RM in a different process, > instead of the actual hardware, to perform I/O). Bump... any help? Thanks, Max

Max Timchenko 2011-01-17T16:47:20Z Yuh-Fwu Guu http://community.qnx.com/sf/go/post82416 2011-01-17T15:17:00Z 2011-01-17T15:17:00Z

When sending a packet of data using sendto() through a vlan, the received packet has vlan tag attached at the end of the MAC header and before the IP header. Where does the tag get added to the transmitted packet? Is it in the socket library? io-pkt? network driver? or somewhere else? I am getting dual vlan tag at the receive node (please see the packet data below), and I am trying to figure out why I am getting double vlan tags. 0x0000: 0100 5E28 1114 0018 4405 050A 8100 0000 0x0010: 8100 044A 0800 4500 0050 BC4F 0000 0100 Thanks for any help... (I am using e1000 driver with 82576)

Yuh-Fwu Guu 2011-01-17T15:17:00Z Chris Conlon http://community.qnx.com/sf/go/post82016 2011-01-12T18:46:22Z 2011-01-12T18:46:22Z

Hi, I wanted to present CyaSSL as an alternative to the QNX OpenSSL port for developers with size or resource constraints. Over the years OpenSSL has grown in size as the code base has increased. CyaSSL has been targeted at embedded environments while still remaining fully-functional for non-embedded systems. It is dual licensed under the GPLv2 and standard commercial licensing. CyaSSL supports the industry standards including TLS 1.2 and offers some unique features such as stream ciphers for securing streaming media. CyaSSL 1.8.0 was recently released which added x509 v3 Signed Certificate Generation support, a new C Standard Library Abstraction Layer, configurable input/output buffer sizes, less dynamic memory use, and a complete user manual. More information about CyaSSL can be viewed on the product page (http://yassl.com/yaSSL/Products_cyassl.html). Questions or comments can be posted to the support forum (http://www.yassl.com/forums) or sent to info@yassl.com. Regards, Chris Conlon www.yassl.com chris@yassl.com

Chris Conlon 2011-01-12T18:46:22Z Durwin De La Rue http://community.qnx.com/sf/go/post81898 2011-01-11T18:47:09Z 2011-01-11T18:47:09Z

> Are you using devb-ram or another file system driver. It may be that the > driver does not support all file system operations. The not enough > memory responses are odd though. > > Dave > What ever driver is running the shared memory (/tmp) and what ever driver runs the nand flash (/mnt/etfs) fails. I do not know the drivers. But when we mount the SD card and use it, DHCPD works. So for now, we will do just that. Thank you for your time. Durwin > > -----Original Message----- > > From: Durwin De La Rue [mailto:community-noreply@qnx.com] > > Sent: January 7, 2011 5:02 PM > > To: technology-networking > > Subject: Re: dhcpd not quite working > > > > > Does the leases file exist? touch /tmp/dhcpd.leases > > > > Yes it does. I make sure after each reboot. > > > > > > > > On 11-01-07 04:47 PM, Durwin De La Rue wrote: > > > > > Is /tmp a RAM disk? How big is it? > > > > > > > > Yes, 19M > > > > > > > > Even if I run following command I get similar results. > > > > > > > > # dhcpd -d -cf /mnt/etfs/etc/dhcpd.conf -lf > > /mnt/etfs/etc/dhcpd.leases > > > > -pf /mnt/etfs/etc/dhcpd.pid > > > > > > > > # Internet Software Consortium DHCP Server V3.0pl2 > > > > # Copyright 1995-2003 Internet Software Consortium. > > > > # All rights reserved. > > > > # Wrote 0 leases to leases file. > > > > # Can't backup lease database /mnt/etfs/etc/dhcpd.leases to > > > > /mnt/etfs/etc/dhcpd.le > > > > # ases~: Improper link > > > > # Listening on Socket/en0/192.168.1.0/24 > > > > # Sending on Socket/en0/192.168.1.0/24 > > > > # DHCPDISCOVER from 00:26:6c:87:5f:d1 via en0 > > > > # DHCPOFFER on 192.168.1.250 to 00:26:6c:87:5f:d1 (ursa) via en0 > > > > # Can't create new lease file: Not enough memory > > > > # DHCPREQUEST for 192.168.1.250 (192.168.1.2) from > > 00:26:6c:87:5f:d1 > > > > (ursa) via en > > > > # 0: database update failed > > > > # Can't create new lease file: Not enough memory > > > > # DHCPREQUEST for 192.168.1.250 (192.168.1.2) from > > 00:26:6c:87:5f:d1 > > > > (ursa) via en > > > > # 0: database update failed > > > > # > > > > > > > > > > > > > > > > > > On 11-01-07 03:09 PM, Durwin De La Rue wrote: > > > > > > I have a issue as you can see below. Can anyone tell me where > > to start. > > > > > > > > > If this is not enough information to understand the problem, > > let me > > > > > > know. From one line it says function not implemented. If it > > can't > > > > commit > > > > > > a lease, then it is completely useless is it not? > > > > > > > > > > > > # dhcpd -d -cf /mnt/etfs/etc/dhcpd.conf -lf /tmp/dhcpd.leases > > -pf > > > > > > /mnt/etfs/etc/dhcpd.pid > > > > > > > > > > > > > > > > > > Internet Software Consortium DHCP Server V3.0pl2 > > > > > > Copyright 1995-2003 Internet Software Consortium. > > > > > > All rights reserved. > > > > > > Wrote 0 leases to leases file. > > > > > > commit_leases: unable to commit: Function not implemented > > > > > > Listening on Socket/en0/192.168.1.0/24 > > > > > > Sending on Socket/en0/192.168.1.0/24 > > > > > > DHCPDISCOVER from 00:26:6c:87:5f:d1 via en0 > > > > > > DHCPOFFER on 192.168.1.250 to 00:26:6c:87:5f:d1 (ursa) via > en0 > > > > > > Can't create new lease file: Not enough memory > > > > > > DHCPREQUEST for 192.168.1.250 (192.168.1.2) from > > 00:26:6c:87:5f:d1 > > > > > > (ursa) via en > > > > > > 0: database update failed > > > > > > Can't create new lease file: Not enough memory > > > > > > DHCPREQUEST for 192.168.1.250 (192.168.1.2) from > > 00:26:6c:87:5f:d1 > > > > > > (ursa) via en > > > > > > 0: database update failed > > > > > > Can't create new lease file: Not enough memory > > > > > > DHCPREQUEST for 192.168.1.250 (192.168.1.2) from > > 00:26:6c:87:5f:d1 > > > > > > (ursa) via en > > > > > > 0: database update failed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > Technology > > > > > > http://community.qnx.com/sf/go/post81558 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Technology > > > > http://community.qnx.com/sf/go/post81575 > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Technology > > http://community.qnx.com/sf/go/post81578

Durwin De La Rue 2011-01-11T18:47:09Z Dave Brown http://community.qnx.com/sf/go/post81712 2011-01-10T16:32:52Z 2011-01-10T16:32:52Z

Are you using devb-ram or another file system driver. It may be that the driver does not support all file system operations. The not enough memory responses are odd though. Dave > -----Original Message----- > From: Durwin De La Rue [mailto:community-noreply@qnx.com] > Sent: January 7, 2011 5:02 PM > To: technology-networking > Subject: Re: dhcpd not quite working > > > Does the leases file exist? touch /tmp/dhcpd.leases > > Yes it does. I make sure after each reboot. > > > > > On 11-01-07 04:47 PM, Durwin De La Rue wrote: > > > > Is /tmp a RAM disk? How big is it? > > > > > > Yes, 19M > > > > > > Even if I run following command I get similar results. > > > > > > # dhcpd -d -cf /mnt/etfs/etc/dhcpd.conf -lf > /mnt/etfs/etc/dhcpd.leases > > > -pf /mnt/etfs/etc/dhcpd.pid > > > > > > # Internet Software Consortium DHCP Server V3.0pl2 > > > # Copyright 1995-2003 Internet Software Consortium. > > > # All rights reserved. > > > # Wrote 0 leases to leases file. > > > # Can't backup lease database /mnt/etfs/etc/dhcpd.leases to > > > /mnt/etfs/etc/dhcpd.le > > > # ases~: Improper link > > > # Listening on Socket/en0/192.168.1.0/24 > > > # Sending on Socket/en0/192.168.1.0/24 > > > # DHCPDISCOVER from 00:26:6c:87:5f:d1 via en0 > > > # DHCPOFFER on 192.168.1.250 to 00:26:6c:87:5f:d1 (ursa) via en0 > > > # Can't create new lease file: Not enough memory > > > # DHCPREQUEST for 192.168.1.250 (192.168.1.2) from > 00:26:6c:87:5f:d1 > > > (ursa) via en > > > # 0: database update failed > > > # Can't create new lease file: Not enough memory > > > # DHCPREQUEST for 192.168.1.250 (192.168.1.2) from > 00:26:6c:87:5f:d1 > > > (ursa) via en > > > # 0: database update failed > > > # > > > > > > > > > > > > > > On 11-01-07 03:09 PM, Durwin De La Rue wrote: > > > > > I have a issue as you can see below. Can anyone tell me where > to start. > > > > > > > If this is not enough information to understand the problem, > let me > > > > > know. From one line it says function not implemented. If it > can't > > > commit > > > > > a lease, then it is completely useless is it not? > > > > > > > > > > # dhcpd -d -cf /mnt/etfs/etc/dhcpd.conf -lf /tmp/dhcpd.leases > -pf > > > > > /mnt/etfs/etc/dhcpd.pid > > > > > > > > > > > > > > > Internet Software Consortium DHCP Server V3.0pl2 > > > > > Copyright 1995-2003 Internet Software Consortium. > > > > > All rights reserved. > > > > > Wrote 0 leases to leases file. > > > > > commit_leases: unable to commit: Function not implemented > > > > > Listening on Socket/en0/192.168.1.0/24 > > > > > Sending on Socket/en0/192.168.1.0/24 > > > > > DHCPDISCOVER from 00:26:6c:87:5f:d1 via en0 > > > > > DHCPOFFER on 192.168.1.250 to 00:26:6c:87:5f:d1 (ursa) via en0 > > > > > Can't create new lease file: Not enough memory > > > > > DHCPREQUEST for 192.168.1.250 (192.168.1.2) from > 00:26:6c:87:5f:d1 > > > > > (ursa) via en > > > > > 0: database update failed > > > > > Can't create new lease file: Not enough memory > > > > > DHCPREQUEST for 192.168.1.250 (192.168.1.2) from > 00:26:6c:87:5f:d1 > > > > > (ursa) via en > > > > > 0: database update failed > > > > > Can't create new lease file: Not enough memory > > > > > DHCPREQUEST for 192.168.1.250 (192.168.1.2) from > 00:26:6c:87:5f:d1 > > > > > (ursa) via en > > > > > 0: database update failed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Technology > > > > > http://community.qnx.com/sf/go/post81558 > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Technology > > > http://community.qnx.com/sf/go/post81575 > > > > > > > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post81578

Dave Brown 2011-01-10T16:32:52Z Durwin De La Rue http://community.qnx.com/sf/go/post81578 2011-01-07T22:02:02Z 2011-01-07T22:02:02Z

> Does the leases file exist? touch /tmp/dhcpd.leases Yes it does. I make sure after each reboot. > > On 11-01-07 04:47 PM, Durwin De La Rue wrote: > > > Is /tmp a RAM disk? How big is it? > > > > Yes, 19M > > > > Even if I run following command I get similar results. > > > > # dhcpd -d -cf /mnt/etfs/etc/dhcpd.conf -lf /mnt/etfs/etc/dhcpd.leases > > -pf /mnt/etfs/etc/dhcpd.pid > > > > # Internet Software Consortium DHCP Server V3.0pl2 > > # Copyright 1995-2003 Internet Software Consortium. > > # All rights reserved. > > # Wrote 0 leases to leases file. > > # Can't backup lease database /mnt/etfs/etc/dhcpd.leases to > > /mnt/etfs/etc/dhcpd.le > > # ases~: Improper link > > # Listening on Socket/en0/192.168.1.0/24 > > # Sending on Socket/en0/192.168.1.0/24 > > # DHCPDISCOVER from 00:26:6c:87:5f:d1 via en0 > > # DHCPOFFER on 192.168.1.250 to 00:26:6c:87:5f:d1 (ursa) via en0 > > # Can't create new lease file: Not enough memory > > # DHCPREQUEST for 192.168.1.250 (192.168.1.2) from 00:26:6c:87:5f:d1 > > (ursa) via en > > # 0: database update failed > > # Can't create new lease file: Not enough memory > > # DHCPREQUEST for 192.168.1.250 (192.168.1.2) from 00:26:6c:87:5f:d1 > > (ursa) via en > > # 0: database update failed > > # > > > > > > > > > > On 11-01-07 03:09 PM, Durwin De La Rue wrote: > > > > I have a issue as you can see below. Can anyone tell me where to start. > > > > > If this is not enough information to understand the problem, let me > > > > know. From one line it says function not implemented. If it can't > > commit > > > > a lease, then it is completely useless is it not? > > > > > > > > # dhcpd -d -cf /mnt/etfs/etc/dhcpd.conf -lf /tmp/dhcpd.leases -pf > > > > /mnt/etfs/etc/dhcpd.pid > > > > > > > > > > > > Internet Software Consortium DHCP Server V3.0pl2 > > > > Copyright 1995-2003 Internet Software Consortium. > > > > All rights reserved. > > > > Wrote 0 leases to leases file. > > > > commit_leases: unable to commit: Function not implemented > > > > Listening on Socket/en0/192.168.1.0/24 > > > > Sending on Socket/en0/192.168.1.0/24 > > > > DHCPDISCOVER from 00:26:6c:87:5f:d1 via en0 > > > > DHCPOFFER on 192.168.1.250 to 00:26:6c:87:5f:d1 (ursa) via en0 > > > > Can't create new lease file: Not enough memory > > > > DHCPREQUEST for 192.168.1.250 (192.168.1.2) from 00:26:6c:87:5f:d1 > > > > (ursa) via en > > > > 0: database update failed > > > > Can't create new lease file: Not enough memory > > > > DHCPREQUEST for 192.168.1.250 (192.168.1.2) from 00:26:6c:87:5f:d1 > > > > (ursa) via en > > > > 0: database update failed > > > > Can't create new lease file: Not enough memory > > > > DHCPREQUEST for 192.168.1.250 (192.168.1.2) from 00:26:6c:87:5f:d1 > > > > (ursa) via en > > > > 0: database update failed > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Technology > > > > http://community.qnx.com/sf/go/post81558 > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Technology > > http://community.qnx.com/sf/go/post81575 > >

Durwin De La Rue 2011-01-07T22:02:02Z Patrik Lahti http://community.qnx.com/sf/go/post81576 2011-01-07T21:49:22Z 2011-01-07T21:49:22Z

Does the leases file exist? touch /tmp/dhcpd.leases On 11-01-07 04:47 PM, Durwin De La Rue wrote: > > Is /tmp a RAM disk? How big is it? > > Yes, 19M > > Even if I run following command I get similar results. > > # dhcpd -d -cf /mnt/etfs/etc/dhcpd.conf -lf /mnt/etfs/etc/dhcpd.leases > -pf /mnt/etfs/etc/dhcpd.pid > > # Internet Software Consortium DHCP Server V3.0pl2 > # Copyright 1995-2003 Internet Software Consortium. > # All rights reserved. > # Wrote 0 leases to leases file. > # Can't backup lease database /mnt/etfs/etc/dhcpd.leases to > /mnt/etfs/etc/dhcpd.le > # ases~: Improper link > # Listening on Socket/en0/192.168.1.0/24 > # Sending on Socket/en0/192.168.1.0/24 > # DHCPDISCOVER from 00:26:6c:87:5f:d1 via en0 > # DHCPOFFER on 192.168.1.250 to 00:26:6c:87:5f:d1 (ursa) via en0 > # Can't create new lease file: Not enough memory > # DHCPREQUEST for 192.168.1.250 (192.168.1.2) from 00:26:6c:87:5f:d1 > (ursa) via en > # 0: database update failed > # Can't create new lease file: Not enough memory > # DHCPREQUEST for 192.168.1.250 (192.168.1.2) from 00:26:6c:87:5f:d1 > (ursa) via en > # 0: database update failed > # > > > > > > On 11-01-07 03:09 PM, Durwin De La Rue wrote: > > > I have a issue as you can see below. Can anyone tell me where to start. > > > If this is not enough information to understand the problem, let me > > > know. From one line it says function not implemented. If it can't > commit > > > a lease, then it is completely useless is it not? > > > > > > # dhcpd -d -cf /mnt/etfs/etc/dhcpd.conf -lf /tmp/dhcpd.leases -pf > > > /mnt/etfs/etc/dhcpd.pid > > > > > > > > > Internet Software Consortium DHCP Server V3.0pl2 > > > Copyright 1995-2003 Internet Software Consortium. > > > All rights reserved. > > > Wrote 0 leases to leases file. > > > commit_leases: unable to commit: Function not implemented > > > Listening on Socket/en0/192.168.1.0/24 > > > Sending on Socket/en0/192.168.1.0/24 > > > DHCPDISCOVER from 00:26:6c:87:5f:d1 via en0 > > > DHCPOFFER on 192.168.1.250 to 00:26:6c:87:5f:d1 (ursa) via en0 > > > Can't create new lease file: Not enough memory > > > DHCPREQUEST for 192.168.1.250 (192.168.1.2) from 00:26:6c:87:5f:d1 > > > (ursa) via en > > > 0: database update failed > > > Can't create new lease file: Not enough memory > > > DHCPREQUEST for 192.168.1.250 (192.168.1.2) from 00:26:6c:87:5f:d1 > > > (ursa) via en > > > 0: database update failed > > > Can't create new lease file: Not enough memory > > > DHCPREQUEST for 192.168.1.250 (192.168.1.2) from 00:26:6c:87:5f:d1 > > > (ursa) via en > > > 0: database update failed > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Technology > > > http://community.qnx.com/sf/go/post81558 > > > > > > > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post81575 >

Patrik Lahti 2011-01-07T21:49:22Z Durwin De La Rue http://community.qnx.com/sf/go/post81575 2011-01-07T21:47:32Z 2011-01-07T21:47:32Z

> Is /tmp a RAM disk? How big is it? Yes, 19M Even if I run following command I get similar results. # dhcpd -d -cf /mnt/etfs/etc/dhcpd.conf -lf /mnt/etfs/etc/dhcpd.leases -pf /mnt/etfs/etc/dhcpd.pid # Internet Software Consortium DHCP Server V3.0pl2 # Copyright 1995-2003 Internet Software Consortium. # All rights reserved. # Wrote 0 leases to leases file. # Can't backup lease database /mnt/etfs/etc/dhcpd.leases to /mnt/etfs/etc/dhcpd.le # ases~: Improper link # Listening on Socket/en0/192.168.1.0/24 # Sending on Socket/en0/192.168.1.0/24 # DHCPDISCOVER from 00:26:6c:87:5f:d1 via en0 # DHCPOFFER on 192.168.1.250 to 00:26:6c:87:5f:d1 (ursa) via en0 # Can't create new lease file: Not enough memory # DHCPREQUEST for 192.168.1.250 (192.168.1.2) from 00:26:6c:87:5f:d1 (ursa) via en # 0: database update failed # Can't create new lease file: Not enough memory # DHCPREQUEST for 192.168.1.250 (192.168.1.2) from 00:26:6c:87:5f:d1 (ursa) via en # 0: database update failed # > > On 11-01-07 03:09 PM, Durwin De La Rue wrote: > > I have a issue as you can see below. Can anyone tell me where to start. > > If this is not enough information to understand the problem, let me > > know. From one line it says function not implemented. If it can't commit > > a lease, then it is completely useless is it not? > > > > # dhcpd -d -cf /mnt/etfs/etc/dhcpd.conf -lf /tmp/dhcpd.leases -pf > > /mnt/etfs/etc/dhcpd.pid > > > > > > Internet Software Consortium DHCP Server V3.0pl2 > > Copyright 1995-2003 Internet Software Consortium. > > All rights reserved. > > Wrote 0 leases to leases file. > > commit_leases: unable to commit: Function not implemented > > Listening on Socket/en0/192.168.1.0/24 > > Sending on Socket/en0/192.168.1.0/24 > > DHCPDISCOVER from 00:26:6c:87:5f:d1 via en0 > > DHCPOFFER on 192.168.1.250 to 00:26:6c:87:5f:d1 (ursa) via en0 > > Can't create new lease file: Not enough memory > > DHCPREQUEST for 192.168.1.250 (192.168.1.2) from 00:26:6c:87:5f:d1 > > (ursa) via en > > 0: database update failed > > Can't create new lease file: Not enough memory > > DHCPREQUEST for 192.168.1.250 (192.168.1.2) from 00:26:6c:87:5f:d1 > > (ursa) via en > > 0: database update failed > > Can't create new lease file: Not enough memory > > DHCPREQUEST for 192.168.1.250 (192.168.1.2) from 00:26:6c:87:5f:d1 > > (ursa) via en > > 0: database update failed > > > > > > > > > > > > _______________________________________________ > > > > Technology > > http://community.qnx.com/sf/go/post81558 > >

Durwin De La Rue 2011-01-07T21:47:32Z Patrik Lahti http://community.qnx.com/sf/go/post81561 2011-01-07T20:20:51Z 2011-01-07T20:20:51Z

Is /tmp a RAM disk? How big is it? On 11-01-07 03:09 PM, Durwin De La Rue wrote: > I have a issue as you can see below. Can anyone tell me where to start. > If this is not enough information to understand the problem, let me > know. From one line it says function not implemented. If it can't commit > a lease, then it is completely useless is it not? > > # dhcpd -d -cf /mnt/etfs/etc/dhcpd.conf -lf /tmp/dhcpd.leases -pf > /mnt/etfs/etc/dhcpd.pid > > > Internet Software Consortium DHCP Server V3.0pl2 > Copyright 1995-2003 Internet Software Consortium. > All rights reserved. > Wrote 0 leases to leases file. > commit_leases: unable to commit: Function not implemented > Listening on Socket/en0/192.168.1.0/24 > Sending on Socket/en0/192.168.1.0/24 > DHCPDISCOVER from 00:26:6c:87:5f:d1 via en0 > DHCPOFFER on 192.168.1.250 to 00:26:6c:87:5f:d1 (ursa) via en0 > Can't create new lease file: Not enough memory > DHCPREQUEST for 192.168.1.250 (192.168.1.2) from 00:26:6c:87:5f:d1 > (ursa) via en > 0: database update failed > Can't create new lease file: Not enough memory > DHCPREQUEST for 192.168.1.250 (192.168.1.2) from 00:26:6c:87:5f:d1 > (ursa) via en > 0: database update failed > Can't create new lease file: Not enough memory > DHCPREQUEST for 192.168.1.250 (192.168.1.2) from 00:26:6c:87:5f:d1 > (ursa) via en > 0: database update failed > > > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post81558 >

Patrik Lahti 2011-01-07T20:20:51Z Durwin De La Rue http://community.qnx.com/sf/go/post81558 2011-01-07T20:09:14Z 2011-01-07T20:09:14Z

I have a issue as you can see below. Can anyone tell me where to start. If this is not enough information to understand the problem, let me know. From one line it says function not implemented. If it can't commit a lease, then it is completely useless is it not? # dhcpd -d -cf /mnt/etfs/etc/dhcpd.conf -lf /tmp/dhcpd.leases -pf /mnt/etfs/etc/dhcpd.pid Internet Software Consortium DHCP Server V3.0pl2 Copyright 1995-2003 Internet Software Consortium. All rights reserved. Wrote 0 leases to leases file. commit_leases: unable to commit: Function not implemented Listening on Socket/en0/192.168.1.0/24 Sending on Socket/en0/192.168.1.0/24 DHCPDISCOVER from 00:26:6c:87:5f:d1 via en0 DHCPOFFER on 192.168.1.250 to 00:26:6c:87:5f:d1 (ursa) via en0 Can't create new lease file: Not enough memory DHCPREQUEST for 192.168.1.250 (192.168.1.2) from 00:26:6c:87:5f:d1 (ursa) via en 0: database update failed Can't create new lease file: Not enough memory DHCPREQUEST for 192.168.1.250 (192.168.1.2) from 00:26:6c:87:5f:d1 (ursa) via en 0: database update failed Can't create new lease file: Not enough memory DHCPREQUEST for 192.168.1.250 (192.168.1.2) from 00:26:6c:87:5f:d1 (ursa) via en 0: database update failed

Durwin De La Rue 2011-01-07T20:09:14Z Max Timchenko http://community.qnx.com/sf/go/post81293 2011-01-06T07:26:19Z 2011-01-06T07:26:19Z

Thanks Andrew. You're confirming my understanding of the Networking architecture so far. My question is more specific. A driver needs to react to a QNX pulse, which is a MsgReceive blocking call. Can I register it with the io-pkt stack in some way (similar to an interrupt) so that my function will get called to handle the pulse, or do I need to create my own thread for this? (the scenario is almost the same as the one described in http://community.qnx.com/sf/discussion/do/listPosts/projects.networking/discussion.technology.topc14720 - a driver has to communicate with a RM in a different process, instead of the actual hardware, to perform I/O).

Max Timchenko 2011-01-06T07:26:19Z Andrew Boyd http://community.qnx.com/sf/go/post81265 2011-01-05T21:05:55Z 2011-01-05T21:05:55Z

In the io-net world, drivers created their own (usually priority 21) threads to service their interrupts. You're not supposed to do that in io-pkt. The stack is supposed to be in charge of threading and execution. Ideally, an io-pkt driver should be just a collection of callback functions, which the stack executes. In an io-pkt driver's _attach function, you will see it stuffing various function callbacks in the driver ifp structure, such as _ioctl, _start (tx), _init, and _stop. Additionally, io-pkt drivers also attach to hardware interrupts but the driver handlers actually kick io-pkt, which in turn call the driver. The other common way that a driver can do stuff (eg start execution) is via the callback_msec() function, where it asks the stack to make a callback function into the driver after a certain amount of time has elapsed. This is often used by a driver for link monitoring, tx packet harvesting, etc. However. You may encounter a situation where you really really need your own driver thread. This occasionally happens, but is discouraged unless really necessary. It can be done if you code carefull, because there are things you simply cannot do if you are not "the stack thread". Seanb or Patrik can explain further if need be.

Andrew Boyd 2011-01-05T21:05:55Z Andrew Boyd http://community.qnx.com/sf/go/post81163 2011-01-05T13:26:41Z 2011-01-05T13:26:41Z

> what happens when a network driver doesn't have any empty > buffers and doesn't call IFQ-DEQUEUE()? That's how most of the io-pkt drivers are coded. The packet is left queued with the stack by the driver and the next time the stack calls the driver if_start function, hopefully some resources are available.

Andrew Boyd 2011-01-05T13:26:41Z Vineet Garg http://community.qnx.com/sf/go/post81080 2011-01-04T19:24:50Z 2011-01-04T19:24:50Z

Hi In our setup running io-net on qnx 6.3.0, we have created a static arp entry for a particular IP address X. However, if the mac address changes for host with IP address X and it sends a ARP request for our machine's IP address, then QNX stack chooses to ignore that request. Basically QNX replies to an ARP request only if: 1. there is no arp entry for source IP in arp request 2. there is an arp entry with same IP-MAC mapping as present in source IP-source MAC fields of ARP request. Any idea if this is a known issue with io-net and is there a workaround possible?? Example: QNX local IP: 10.10.10.1 arp -s 10.10.10.10 0a:0b:0c:0d:0e:0f QNX receives an ARP request for 10.10.10.1 with source Ip 10.10.10.10 and source mac: 0a:0b:0c:0d:0e:01 <--- different from entry in arp table QNX does not send ARP reply. <-- PROBLEM However, if QNX recieves ARP request with source IP 10.10.10.10 and source mac: 0a:0b:0c:0d:0e:0f <--- same as that in arp table QNX sends back the ARP reply. Regards Vineet

Vineet Garg 2011-01-04T19:24:50Z Max Timchenko http://community.qnx.com/sf/go/post81011 2011-01-04T11:57:06Z 2011-01-04T11:57:06Z

Looking at the "Porting an io-net driver to io-pkt" document's description of Write process, what happens when a network driver doesn't have any empty buffers and doesn't call IFQ-DEQUEUE()? Will the io-pkt framework retry the write (and when), or will it drop the packet? Thanks, Max

Max Timchenko 2011-01-04T11:57:06Z Andrew Boyd http://community.qnx.com/sf/go/post80965 2011-01-03T20:11:08Z 2011-01-03T20:11:08Z

When a CRC error is detected, qnet will log an error in sloginfo which looks like this: bad rxd packet - crc and if you do this at the command line: # cat /proc/qnetstats you will see the L4 counter for "rxd bad L4" increase from zero. The packet will be dropped and the remote end will time out and retransmit the packet. Note that qnet also has the facility to hex dump the packet with the bad crc to sloginfo. See the "dump_crc=X" qnet command line option. This can help you figure out what's going on with the driver.

Andrew Boyd 2011-01-03T20:11:08Z Max Timchenko http://community.qnx.com/sf/go/post80657 2010-12-30T07:05:50Z 2010-12-30T07:05:50Z

Thanks VG. Sorry, I should have specified I'm interested in how this works in the new io-pkt framework.

Max Timchenko 2010-12-30T07:05:50Z Vineet Garg http://community.qnx.com/sf/go/post80644 2010-12-30T02:35:24Z 2010-12-30T02:35:24Z

If I get the question right, the other events could be among the callbacks registered to io-net by different driver/filter/protocol modules. please refer io_net_registrant_funcs_t in qnx documentation Regards VG On Wed, Dec 29, 2010 at 7:56 PM, Max Timchenko <community-noreply@qnx.com>wrote: > The documentation says "The stack uses a thread pool to service events that > are generated from other parts of the system. These events may be time outs, > ISR events or other things generated by the stack or protocol modules." > > An example for a driver registering for interrupt handling is provided - > it's interrupt_entry_init(). But where can I find an example for a driver > registering to handle "other things", such as pulses? > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post80616 > >

Vineet Garg 2010-12-30T02:35:24Z Max Timchenko http://community.qnx.com/sf/go/post80616 2010-12-29T14:26:35Z 2010-12-29T14:26:35Z

The documentation says "The stack uses a thread pool to service events that are generated from other parts of the system. These events may be time outs, ISR events or other things generated by the stack or protocol modules." An example for a driver registering for interrupt handling is provided - it's interrupt_entry_init(). But where can I find an example for a driver registering to handle "other things", such as pulses?

Max Timchenko 2010-12-29T14:26:35Z Hayder Mouhammed http://community.qnx.com/sf/go/post79488 2010-12-20T20:00:42Z 2010-12-20T20:00:42Z

Greetings, Has anyone attempted to use QNET over HDLC? I have a hardware setup that has multiple devices on an I2C bus that is shared between two different units. I'm trying to find a way to prevent collisions on the bus and thought the shared semaphore would be ideal. I can't use QNET over ethernet because of security practices. If you have other ideas on how to synchronize the bus between both units, feel free to throw them out! Thanks in advance!

Hayder Mouhammed 2010-12-20T20:00:42Z Robert Murrell http://community.qnx.com/sf/go/post79407 2010-12-20T16:38:30Z 2010-12-20T16:38:30Z

In my application, I need to display some connection information in a thread-safe manner. I have figured out how to get my IP address and net mask, but how do I look up my MAC address, Gateway, and DNS servers?

Robert Murrell 2010-12-20T16:38:30Z Mark Anderson http://community.qnx.com/sf/go/post77963 2010-12-08T22:06:44Z 2010-12-08T22:06:44Z

I have implemented a QNet client and server application where data is passes between the two using an mqueue. I want the data to be checked for corruption using a CRC so I specified the do_crc=1 and enforce_crc=1 options. How will I be notified, if at all, when a crc failure happens? Will the packet be retried? I have read all the documentation I can find on crc checking over Qnet and all that it says is that the packet is dropped. Thanks for your insight.

Mark Anderson 2010-12-08T22:06:44Z David van Geest http://community.qnx.com/sf/go/post77192 2010-12-03T21:01:07Z 2010-12-03T21:01:07Z

I might just have to make that request. The DHCP servers will vary and we don't have access to them. My current workaround is in the same vein as your dhcp-up solution, but a cleaner solution would be nice. Thanks for the reply Dave! > The easiest option might be requesting this for 6.4.1. Other options > include configuring the server if you have access to not provide this > information. Also, the dhcp.client dhcp-up script will contain all the > parameters supplied by the DHCP server, so you could reverse what was > set by the client. > > Dave > > > -----Original Message----- > > From: David van Geest [mailto:community-noreply@qnx.com] > > Sent: December 2, 2010 4:59 PM > > To: technology-networking > > Subject: Re: prevent dhcp.cllient from modifying routing table > > > > Thanks for the replies, guys. That -R option is exactly the thing I'm > > looking for, however we are using 6.4.1. > > > > Any other ideas? > > > > > > > > _______________________________________________ > > > > Technology > > http://community.qnx.com/sf/go/post76989

David van Geest 2010-12-03T21:01:07Z Dave Brown http://community.qnx.com/sf/go/post77083 2010-12-03T15:52:10Z 2010-12-03T15:52:10Z

The easiest option might be requesting this for 6.4.1. Other options include configuring the server if you have access to not provide this information. Also, the dhcp.client dhcp-up script will contain all the parameters supplied by the DHCP server, so you could reverse what was set by the client. Dave > -----Original Message----- > From: David van Geest [mailto:community-noreply@qnx.com] > Sent: December 2, 2010 4:59 PM > To: technology-networking > Subject: Re: prevent dhcp.cllient from modifying routing table > > Thanks for the replies, guys. That -R option is exactly the thing I'm > looking for, however we are using 6.4.1. > > Any other ideas? > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post76989

Dave Brown 2010-12-03T15:52:10Z David van Geest http://community.qnx.com/sf/go/post76989 2010-12-02T21:59:27Z 2010-12-02T21:59:27Z

Thanks for the replies, guys. That -R option is exactly the thing I'm looking for, however we are using 6.4.1. Any other ideas?

David van Geest 2010-12-02T21:59:27Z Sean Boudreau http://community.qnx.com/sf/go/post76987 2010-12-02T21:52:39Z 2010-12-02T21:52:39Z

The 6.5 dhcp.client has a -R option which prevents it from applying the default route. -seanb ----- Original Message ----- From: David van Geest [mailto:community-noreply@qnx.com] Sent: Thursday, December 02, 2010 04:31 PM To: technology-networking <post76976@community.qnx.com> Subject: prevent dhcp.cllient from modifying routing table Hi, We're using dhcp.client as documented here: http://www.qnx.com/developers/docs/6.4.1/neutrino/utilities/d/dhcp.client.html. For various reasons, it would be preferable for dhcp.client to not change the routing table when it gets IP info or when it shuts down. However, I don't see a way to disable this functionality in the documentation. Am I missing something, or is this not possible? -David _______________________________________________ Technology http://community.qnx.com/sf/go/post76976

Sean Boudreau 2010-12-02T21:52:39Z Patrik Lahti http://community.qnx.com/sf/go/post76985 2010-12-02T21:51:58Z 2010-12-02T21:51:58Z

Hi David, Are you running 6.4.1? In 6.5.0 there's a command line option (-R) which avoids installing a default route. Is that what you're looking for? Cheers! /P On 10-12-02 04:31 PM, David van Geest wrote: > Hi, > > We're using dhcp.client as documented here: > http://www.qnx.com/developers/docs/6.4.1/neutrino/utilities/d/dhcp.client.html. > > For various reasons, it would be preferable for dhcp.client to not > change the routing table when it gets IP info or when it shuts down. > However, I don't see a way to disable this functionality in the > documentation. Am I missing something, or is this not possible? > > -David > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post76976 >

Patrik Lahti 2010-12-02T21:51:58Z David van Geest http://community.qnx.com/sf/go/post76976 2010-12-02T21:31:06Z 2010-12-02T21:31:06Z

Hi, We're using dhcp.client as documented here: http://www.qnx.com/developers/docs/6.4.1/neutrino/utilities/d/dhcp.client.html. For various reasons, it would be preferable for dhcp.client to not change the routing table when it gets IP info or when it shuts down. However, I don't see a way to disable this functionality in the documentation. Am I missing something, or is this not possible? -David

David van Geest 2010-12-02T21:31:06Z Kjell Raghildrod http://community.qnx.com/sf/go/post75654 2010-11-23T15:51:47Z 2010-11-23T15:51:47Z

During stress testing of ftp server we found the following limitation in the syslog: Nov 10 03:12:03 nto inetd[8204331-1]: ftp/tcp max spawn rate (40 in 60 seconds) exceeded; service not started How do we configure this limit (change the default). In NetBSD the configuration of this is a command line option (not via inetd.conf, ref. http://www.freebsd.org/doc/handbook/network-inetd.html, which says: However, QNX on-line manual (help in the IDE, inetd, /etc/inetd.conf) does not mention this option. In QNX 6.3 it is in /etc/inetd.conf, ref. http://www.qnx.com/developers/docs/6.3.0SP3/neutrino/utilities/i/inetd.conf.html .... Can't find where it is in 6.5.0 - Can you spread more light over this?

Kjell Raghildrod 2010-11-23T15:51:47Z Hugh Brown http://community.qnx.com/sf/go/post75362 2010-11-19T19:08:23Z 2010-11-19T19:08:23Z

Unfortunately we don¹t support different MRU/MTU sizes in io-net. If you change one, they both change. On 10-11-17 1:13 AM, "Vineet Garg" <community-noreply@qnx.com> wrote: > Hi > > In our system running io-net with qnx 6.3.0, setting mtu value using ifconfig > sets mru also to the same value. Thus, stack rejects any incoming traffic > which is larger than mtu value even though driver supports reception of such > frames. > > Is there any workaround possible to set mru greater than mtu at ip stack? > > > Regards > VG > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post74902 > > -- Hugh Brown (613) 591-0931 ext. 2209 (voice) QNX Software Systems Ltd. (613) 591-3579 (fax) 175 Terence Matthews Cres. email: hsbrown@qnx.com Kanata, Ontario, Canada. K2M 1W8

Hugh Brown 2010-11-19T19:08:23Z Vineet Garg http://community.qnx.com/sf/go/post74902 2010-11-17T06:13:21Z 2010-11-17T06:13:21Z

Hi In our system running io-net with qnx 6.3.0, setting mtu value using ifconfig sets mru also to the same value. Thus, stack rejects any incoming traffic which is larger than mtu value even though driver supports reception of such frames. Is there any workaround possible to set mru greater than mtu at ip stack? Regards VG

Vineet Garg 2010-11-17T06:13:21Z Ravish Kumar http://community.qnx.com/sf/go/post74607 2010-11-15T14:08:55Z 2010-11-15T14:08:55Z

I need ed to implement SNMP traps.Traps is to be send from MPC 8548cds board to NMS running on some other PC . I have with me my custom MIB module. How to load/integrate this MIB module in QNX 6. 4 os running on the MPC 8548CDS board?? Till now I have done following things:- 1)running a trap reciver on some PC. 2) I used snmptrap command fom QNX 6.4 to send a trap. . I am able to receive the trap on the other side. MIB module used to send this trap is in perhaps /etc/mib.txt. Problem I am facing is ,custom MIB module is not getting loaded with the QNX os. Plz let me know the procedure to do this.Also how I can start QNX agent?? Regards, Ravish Kumar

Ravish Kumar 2010-11-15T14:08:55Z Matt Blackburn http://community.qnx.com/sf/go/post73925 2010-11-08T18:35:35Z 2010-11-08T18:35:35Z

No I think we are on the same page. I had a dhcp server running against rum0 but I also tried it w/o a server too. My solution is to "Not" have a bridge, so I agree that -apbridge is correct, but just not working.

Matt Blackburn 2010-11-08T18:35:35Z Patrik Lahti http://community.qnx.com/sf/go/post73923 2010-11-08T18:30:32Z 2010-11-08T18:30:32Z

Maybe I misunderstood but I thought you had a DHCP server running directly on the rum0? (I'm saying, if it is in bridge mode but isn't bridged to anything then there are no other interfaces which would come into play) On 10-11-08 12:32 PM, Matt Blackburn wrote: > Please correct me if I am wrong here but if I was struck in "Bridge" > mode then wouldn't I be getting addresses assigned to me from the "Far" > end? Basically look like I was on the Far end network rather than the > local network to my board? > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post73902 >

Patrik Lahti 2010-11-08T18:30:32Z Matt Blackburn http://community.qnx.com/sf/go/post73902 2010-11-08T17:32:51Z 2010-11-08T17:32:51Z

Please correct me if I am wrong here but if I was struck in "Bridge" mode then wouldn't I be getting addresses assigned to me from the "Far" end? Basically look like I was on the Far end network rather than the local network to my board?

Matt Blackburn 2010-11-08T17:32:51Z Patrik Lahti http://community.qnx.com/sf/go/post73878 2010-11-08T16:38:29Z 2010-11-08T16:38:29Z

You can use pf to make routing work out of apbridge, but the fundamental problem seems to be the driver stuck in apbridge. /P On 10-11-08 11:20 AM, Matt Blackburn wrote: > Ok I have tried with "Packet Filtering" (pf) to sort of "Reverse" the > situation. > en0->rum0 with rum0 associated to an WiFi AP in the area. Packets are > routed just fine. > en0->ppp0 with ppp0 connected to a 3G network. Packets are routed just fine. > > The only issue I seem to have is rum0->ppp0 with the rum being a AP. > > At this point I'm beginning to question the stability of: devnp-rum.so. > > Any thoughts. > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post73868 >

Patrik Lahti 2010-11-08T16:38:29Z Matt Blackburn http://community.qnx.com/sf/go/post73868 2010-11-08T16:20:02Z 2010-11-08T16:20:02Z

Ok I have tried with "Packet Filtering" (pf) to sort of "Reverse" the situation. en0->rum0 with rum0 associated to an WiFi AP in the area. Packets are routed just fine. en0->ppp0 with ppp0 connected to a 3G network. Packets are routed just fine. The only issue I seem to have is rum0->ppp0 with the rum being a AP. At this point I'm beginning to question the stability of: devnp-rum.so. Any thoughts.

Matt Blackburn 2010-11-08T16:20:02Z Matt Blackburn http://community.qnx.com/sf/go/post73837 2010-11-08T14:17:17Z 2010-11-08T14:17:17Z

Based on my reading if I do the -apbridge then I need to use pf or something like that. I have tried packet filtering (NAT) as well to no success. I"m beginning to wonder if there is a problem with the "rum" driver.

Matt Blackburn 2010-11-08T14:17:17Z Matt Blackburn http://community.qnx.com/sf/go/post73816 2010-11-08T13:10:42Z 2010-11-08T13:10:42Z

Got pretty busy at the end of the week so wasn't able to try this until just now. ifconfig rum0 -apbridge Did not produce the desired defaults.

Matt Blackburn 2010-11-08T13:10:42Z Patrik Lahti http://community.qnx.com/sf/go/post73590 2010-11-04T16:30:58Z 2010-11-04T16:30:58Z

Maybe try 'ifconfig rum0 -apbridge' and see if that clears it? (shot in the dark)

Patrik Lahti 2010-11-04T16:30:58Z Matt Blackburn http://community.qnx.com/sf/go/post73582 2010-11-04T16:11:03Z 2010-11-04T16:11:03Z

I wondered the same thing, but I configure the interface as follows: ifconfig rum0 mediaopt hostap ssid "MYSSID" 192.168.253.1 netmask 255.255.255.0 So I'm not 100% sure why it says "Bridge"..

Matt Blackburn 2010-11-04T16:11:03Z Patrik Lahti http://community.qnx.com/sf/go/post73572 2010-11-04T15:55:37Z 2010-11-04T15:55:37Z

Thanks for sending the info, This looks suspicious: rum0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ssid MYAP apbridge I don't have a setup to try on at the moment, but IIRC that shouldn't say apbridge when you're trying to run router... /P On 10-11-04 10:15 AM, Matt Blackburn wrote: > Here is the information you requested. I ran the command as you > indicated in your last response, but I was to busy to clean it up, > trying to run between meetings and all. > I can not ping the external side of the PPP connection, 10.0.0.1 from > any of my clients. Right now the clients are a DROID X and a MAC, the > information was gathered from the MAC client and the QNX 641 target. > > Sure hope this helps. > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post73534 >

Patrik Lahti 2010-11-04T15:55:37Z Matt Blackburn http://community.qnx.com/sf/go/post73534 2010-11-04T14:15:58Z 2010-11-04T14:15:58Z

Here is the information you requested. I ran the command as you indicated in your last response, but I was to busy to clean it up, trying to run between meetings and all. I can not ping the external side of the PPP connection, 10.0.0.1 from any of my clients. Right now the clients are a DROID X and a MAC, the information was gathered from the MAC client and the QNX 641 target. Sure hope this helps.

Matt Blackburn 2010-11-04T14:15:58Z Patrik Lahti http://community.qnx.com/sf/go/post73487 2010-11-03T20:33:45Z 2010-11-03T20:33:45Z

Hi again, What's the error message from the ping command? Can the clients ping the router 192.168.253.1? Can the clients ping the router's IP address on the "Internet" side (router's PPP interface)? Can you post output of the following commands taken on the router: sysctl net.inet.ip.forwarding netstat -rn ifconfig arp -na And from client: cat /etc/resolv.conf netstat -rn ifconfig arp -na I think you should keep the name server line in dhcp.conf, the question is maybe what name server you should have in there. Are you running an name server inside the router? If not, then the name server line should change to point to the name server you're getting from the 3G network. Cheers! /P

Patrik Lahti 2010-11-03T20:33:45Z Matt Blackburn http://community.qnx.com/sf/go/post73475 2010-11-03T18:49:02Z 2010-11-03T18:49:02Z

Nope doesn't work by IP address either. I tried removing the name-server entry from my dhcp.conf file and still noJoy. I have tried the connection from 3 different clients as well. With the same results.

Matt Blackburn 2010-11-03T18:49:02Z Patrik Lahti http://community.qnx.com/sf/go/post73471 2010-11-03T18:15:42Z 2010-11-03T18:15:42Z

Hi Matt, If you ping from the wireless client using an IP address (instead of a name), does that work? From the dhcpd.conf it looks like you may have to setup a nameserver on your router. Cheers! /P

Patrik Lahti 2010-11-03T18:15:42Z Matt Blackburn http://community.qnx.com/sf/go/post73461 2010-11-03T17:36:59Z 2010-11-03T17:36:59Z

I'm following the direction from here: http://community.qnx.com/sf/wiki/do/viewPage/projects.networking/wiki/Wifi_tcpip_config_wiki_page But I can not get the "routing" to work. I am bringing up a 3G data connection and the nameservers are being added to /etc/resolv.conf I then follow the directions above to start my wireless adapter as a hostap and I am able to attach to the the AP that I created. But my data packets are not routed between the wireless client and the 3G network. I am able to ping off of the router via the 3G network so I'm pretty sure that everything to the "Internet" side is working just fine and I believe I have my dhcp.conf file setup correctly based on the examples. Here is my pppd line: pppd /dev/serusb1 defaultroute resconf require-ns noipdefault logstatus Here is my "Network" portion of the dhcp.conf file: subnet 192.168.253.0 netmask 255.255.255.0{ range 192.168.253.100 192.168.253.110; option routers 192.168.253.1; option domain-name "my.net"; option broadcast-address 192.168.253.255; option domain-name-servers 192.168.253.1; default-lease-time 600; max-lease-time 7200; } I have configured my wireless adapter with 192.168.253.1 as the IP address. Thoughts?

Matt Blackburn 2010-11-03T17:36:59Z Matt Blackburn http://community.qnx.com/sf/go/post73192 2010-11-01T19:38:37Z 2010-11-01T19:38:37Z

Thank you much, and presto it works.

Matt Blackburn 2010-11-01T19:38:37Z Sean Boudreau http://community.qnx.com/sf/go/post73122 2010-11-01T13:20:10Z 2010-11-01T13:20:10Z

On Mon, Nov 01, 2010 at 09:14:34AM -0400, Matt Blackburn wrote: > I have an access point that is configured to be "hidden", that is not > broadcasting an SSID, and has WPA2 encryption. > > While I have wpa_supplicant running, if I reconfigure the AP to > broadcast the SSID my system then connects as expected. > > Has anybody else had any luck accessing "Hidden" APs with or without > encryption. Yes. Add 'scan_ssid=1' to the network block in question in your wpa_supplicant.conf. Regards, -seanb

Sean Boudreau 2010-11-01T13:20:10Z Matt Blackburn http://community.qnx.com/sf/go/post73120 2010-11-01T13:14:33Z 2010-11-01T13:14:33Z

I have an access point that is configured to be "hidden", that is not broadcasting an SSID, and has WPA2 encryption. While I have wpa_supplicant running, if I reconfigure the AP to broadcast the SSID my system then connects as expected. Has anybody else had any luck accessing "Hidden" APs with or without encryption. -Matt

Matt Blackburn 2010-11-01T13:14:33Z Nick Horsley http://community.qnx.com/sf/go/post70393 2010-10-13T10:55:59Z 2010-10-13T10:55:59Z

We start several instances of io-net, however, the one that starts tcpip-v4 occurs several seconds in. So presumably cannot be explained by this known problem?

Nick Horsley 2010-10-13T10:55:59Z Sean Boudreau http://community.qnx.com/sf/go/post70281 2010-10-12T15:22:56Z 2010-10-12T15:22:56Z

IIRC there was a one second window where this could happen if the stack gets started before the time's set (ie a time() of 0). -seanb -----Original Message----- From: Nick Horsley [mailto:community-noreply@qnx.com] Sent: Tue 10/12/2010 11:18 AM To: technology-networking Subject: ARP Requests Ignored We have occasional instances where our stack doesn't operate properly after power-up. All ARP responses to our ARP requests seem to get ignored. Is there a known problem with io-net in QNX6.3.2 which may cause this ? _______________________________________________ Technology http://community.qnx.com/sf/go/post70277

Sean Boudreau 2010-10-12T15:22:56Z Nick Horsley http://community.qnx.com/sf/go/post70277 2010-10-12T15:18:07Z 2010-10-12T15:18:07Z

We have occasional instances where our stack doesn’t operate properly after power-up. All ARP responses to our ARP requests seem to get ignored. Is there a known problem with io-net in QNX6.3.2 which may cause this ?

Nick Horsley 2010-10-12T15:18:07Z Vineet Garg http://community.qnx.com/sf/go/post70209 2010-10-11T19:07:56Z 2010-10-11T19:07:56Z

Hi All I am using a resource manager to feed packets to my network driver. However, in transmit side I am having to perform a full extra copy of the frame due to problem mentioned below. Please help me in understanding this situation better. QNX documentation mentions following about handling io_write message while writing a resource manager: buf = (char *) malloc(msg->i.nbytes + 1); if (buf == NULL) return(ENOMEM); /* * Reread the data from the sender's message buffer. * We're not assuming that all of the data fit into the * resource manager library's receive buffer. */ resmgr_msgread(ctp, buf, msg->i.nbytes, sizeof(msg->i)); buf [msg->i.nbytes] = '\0'; /* just in case the text is not NULL terminated */ printf ("Received %d bytes = '%s'\n", msg -> i.nbytes, buf); free(buf); I want to understant the importance of resmgr_msgread API here and the comment above it. I need to write the packet to the SRAM of a device which is memory mapped into my process (resource manager). However, If I pass the pointer to mapped memory directly into resmgr_msgread, it fails with errno ESRVRFAULT. This now requires me to pass a local buffer to get the data from client and then copy it again into memory mapped space in device SRAM causing performance issues under load. Please help me optimize performance of my system by removing this additional copy. Regards VG

Vineet Garg 2010-10-11T19:07:56Z Vineet Garg http://community.qnx.com/sf/go/post69135 2010-09-30T11:07:52Z 2010-09-30T11:07:52Z

So, i have found out the reason for the upper limit on MTU at parent interface. Driver sends maximum MTU and minimum MTU in interface advertisements it sends to stack during startup. Changing the max MTU in advertisement allowed to set MTU of en0 to 1504 bytes using ifconfig.. thanks patrik for your help here... Regards VG

Vineet Garg 2010-09-30T11:07:52Z Patrik Lahti http://community.qnx.com/sf/go/post69047 2010-09-29T17:47:26Z 2010-09-29T17:47:26Z

Check for ioctl() of SIOCSIFMTU? It might need to be Jumbo capable to go beyond 1500... In order to interop you've got to have the same MTU... On 10-09-29 01:34 PM, Vineet Garg wrote: > Hi Patrik > > I have the source for network driver (devn-ixp2351) and know it reasonably > well. I checked today and it does not receive any devctl checking for the > MTU size...hmm..maybe I should check again. > > However, leaving that aside, do you think it is correct for maximum MTU to > be 1496 if 802.1Q is enabled and this is valid for most systems? > > In that case we need to consider updating requirements for our system. > > VG > > On Wed, Sep 29, 2010 at 6:56 PM, Patrik Lahti > <community-noreply@qnx.com>wrote: > > > Then the driver or the medium itself don't allow frames larger than 1514 > > bytes. With the regular Ethernet header there's only 1500 bytes of > > payload left, with the and Q-header there is simply not more than 1496 > > bytes left... > > > > I've never seen the devn-ixp2351 driver. It might be hard coded to 1500 > > bytes MTU. You'd have to ask whoever wrote it, maybe in the driver forum? > > > > PS. The article isn't QNX product documentation, it's on a website which > > isn't controlled nor endorsed by QNX. > > > > /P > > > > On 10-09-28 11:46 PM, Vineet Garg wrote: > > > hi patrik > > > > > > in my case system is not allowing to set mtu of parent interface to > more > > > than 1500 bytes thus leading to problems as even in article pointed > to by > > > you. > > > > > > To be compatible with other IEEE 802.1Q devices, the *vlan* interface > > sup- > > > ports a 1500 byte MTU, which means that the parent interface will > have to > > > handle packets that are 4 bytes larger than the original Ethernet stan- > > > dard > > > > > > > > > Is this behavior dependent on underlying network driver or is a > > > property of operating system? I have devn-ixp2351 as network driver in > > > my case. > > > > > > Since article provides a list of network drivers that support > > > increased mtu size, does it mean that ifconfig sends a devctl to > > > network driver to check if given mtu value is supported or not? In > > > that case I can modify my network driver to accept even higher mtu. > > > > > > > > > > > > > > > On Wed, Sep 29, 2010 at 1:18 AM, Patrik Lahti > > > <community-noreply@qnx.com>wrote: > > > > > > > This is expected and not unique to QNX. > > > > > > > > The 802.1Q encapsulation requires four more bytes which are then not > > > > available for payload (IP or whatever). > > > > > > > > To change the MTU of the VLAN interface I believe you'll have to set > > the > > > > parent interface's MTU to be bigger. > > > > > > > > See e.g. http://netbsd.gw.com/cgi-bin/man-cgi?vlan+4 > > > > > > > > /P > > > > > > > > On 10-09-28 02:17 PM, Vineet Garg wrote: > > > > > Hi > > > > > > > > > > I noticed that VLAN interface derives its mtu attribute from the > > parent > > > > > interface (say en0) but uses a value that is 4 less than that of > > parent > > > > > interface. > > > > > So, if mtu for en0 is 1500 > > > > > vlanX on en0 will have mtu 1496. > > > > > > > > > > Also, stack does not allow user to set the mtu value at vlanX to be > > > more > > > > > than 1496 so that difference of 4 byte always stays. Neither does > > stack > > > > > allow mtu of en0 to be more than 1500. > > > > > > > > > > This causes issues when an IP peer with MTU set to 1500 sends > > > fragmented > > > > > packets to this interface vlanX. > > > > > > > > > > Theoratically, I do not understand the reasoning for having this > > > > > difference of 4 bytes. MTU at IP layer (1500 for ethernet) is IP > > header > > > > > + IP payload. It should make no difference to stack if the size of > > > > > Ethernet header is 14 bytes or 18 bytes as that should not be part > > of > > > > > MTU anyways. > > > > > > > > > > Please help in understanding this behavior of QNX stack and > also any > > > > > workaround that is possible to use MTU size of 1500 on a VLAN > > > interface. > > > > > > > > > > Regards > > > > > VG > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Technology > > > > > http://community.qnx.com/sf/go/post68865 > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Technology > > > > http://community.qnx.com/sf/go/post68893 > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Technology > > > http://community.qnx.com/sf/go/post68936 > > > > > > > > > > > _______________________________________________ > > > > Technology > > http://community.qnx.com/sf/go/post68974 > > > > > > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post69044 >

Patrik Lahti 2010-09-29T17:47:26Z Vineet Garg http://community.qnx.com/sf/go/post69044 2010-09-29T17:34:19Z 2010-09-29T17:34:19Z

Hi Patrik I have the source for network driver (devn-ixp2351) and know it reasonably well. I checked today and it does not receive any devctl checking for the MTU size...hmm..maybe I should check again. However, leaving that aside, do you think it is correct for maximum MTU to be 1496 if 802.1Q is enabled and this is valid for most systems? In that case we need to consider updating requirements for our system. VG On Wed, Sep 29, 2010 at 6:56 PM, Patrik Lahti <community-noreply@qnx.com>wrote: > Then the driver or the medium itself don't allow frames larger than 1514 > bytes. With the regular Ethernet header there's only 1500 bytes of > payload left, with the and Q-header there is simply not more than 1496 > bytes left... > > I've never seen the devn-ixp2351 driver. It might be hard coded to 1500 > bytes MTU. You'd have to ask whoever wrote it, maybe in the driver forum? > > PS. The article isn't QNX product documentation, it's on a website which > isn't controlled nor endorsed by QNX. > > /P > > On 10-09-28 11:46 PM, Vineet Garg wrote: > > hi patrik > > > > in my case system is not allowing to set mtu of parent interface to more > > than 1500 bytes thus leading to problems as even in article pointed to by > > you. > > > > To be compatible with other IEEE 802.1Q devices, the *vlan* interface > sup- > > ports a 1500 byte MTU, which means that the parent interface will have to > > handle packets that are 4 bytes larger than the original Ethernet stan- > > dard > > > > > > Is this behavior dependent on underlying network driver or is a > > property of operating system? I have devn-ixp2351 as network driver in > > my case. > > > > Since article provides a list of network drivers that support > > increased mtu size, does it mean that ifconfig sends a devctl to > > network driver to check if given mtu value is supported or not? In > > that case I can modify my network driver to accept even higher mtu. > > > > > > > > > > On Wed, Sep 29, 2010 at 1:18 AM, Patrik Lahti > > <community-noreply@qnx.com>wrote: > > > > > This is expected and not unique to QNX. > > > > > > The 802.1Q encapsulation requires four more bytes which are then not > > > available for payload (IP or whatever). > > > > > > To change the MTU of the VLAN interface I believe you'll have to set > the > > > parent interface's MTU to be bigger. > > > > > > See e.g. http://netbsd.gw.com/cgi-bin/man-cgi?vlan+4 > > > > > > /P > > > > > > On 10-09-28 02:17 PM, Vineet Garg wrote: > > > > Hi > > > > > > > > I noticed that VLAN interface derives its mtu attribute from the > parent > > > > interface (say en0) but uses a value that is 4 less than that of > parent > > > > interface. > > > > So, if mtu for en0 is 1500 > > > > vlanX on en0 will have mtu 1496. > > > > > > > > Also, stack does not allow user to set the mtu value at vlanX to be > > more > > > > than 1496 so that difference of 4 byte always stays. Neither does > stack > > > > allow mtu of en0 to be more than 1500. > > > > > > > > This causes issues when an IP peer with MTU set to 1500 sends > > fragmented > > > > packets to this interface vlanX. > > > > > > > > Theoratically, I do not understand the reasoning for having this > > > > difference of 4 bytes. MTU at IP layer (1500 for ethernet) is IP > header > > > > + IP payload. It should make no difference to stack if the size of > > > > Ethernet header is 14 bytes or 18 bytes as that should not be part > of > > > > MTU anyways. > > > > > > > > Please help in understanding this behavior of QNX stack and also any > > > > workaround that is possible to use MTU size of 1500 on a VLAN > > interface. > > > > > > > > Regards > > > > VG > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Technology > > > > http://community.qnx.com/sf/go/post68865 > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Technology > > > http://community.qnx.com/sf/go/post68893 > > > > > > > > > > > > > > > > _______________________________________________ > > > > Technology > > http://community.qnx.com/sf/go/post68936 > > > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post68974 > >

Vineet Garg 2010-09-29T17:34:19Z Patrik Lahti http://community.qnx.com/sf/go/post68974 2010-09-29T13:26:01Z 2010-09-29T13:26:01Z

Then the driver or the medium itself don't allow frames larger than 1514 bytes. With the regular Ethernet header there's only 1500 bytes of payload left, with the and Q-header there is simply not more than 1496 bytes left... I've never seen the devn-ixp2351 driver. It might be hard coded to 1500 bytes MTU. You'd have to ask whoever wrote it, maybe in the driver forum? PS. The article isn't QNX product documentation, it's on a website which isn't controlled nor endorsed by QNX. /P On 10-09-28 11:46 PM, Vineet Garg wrote: > hi patrik > > in my case system is not allowing to set mtu of parent interface to more > than 1500 bytes thus leading to problems as even in article pointed to by > you. > > To be compatible with other IEEE 802.1Q devices, the *vlan* interface sup- > ports a 1500 byte MTU, which means that the parent interface will have to > handle packets that are 4 bytes larger than the original Ethernet stan- > dard > > > Is this behavior dependent on underlying network driver or is a > property of operating system? I have devn-ixp2351 as network driver in > my case. > > Since article provides a list of network drivers that support > increased mtu size, does it mean that ifconfig sends a devctl to > network driver to check if given mtu value is supported or not? In > that case I can modify my network driver to accept even higher mtu. > > > > > On Wed, Sep 29, 2010 at 1:18 AM, Patrik Lahti > <community-noreply@qnx.com>wrote: > > > This is expected and not unique to QNX. > > > > The 802.1Q encapsulation requires four more bytes which are then not > > available for payload (IP or whatever). > > > > To change the MTU of the VLAN interface I believe you'll have to set the > > parent interface's MTU to be bigger. > > > > See e.g. http://netbsd.gw.com/cgi-bin/man-cgi?vlan+4 > > > > /P > > > > On 10-09-28 02:17 PM, Vineet Garg wrote: > > > Hi > > > > > > I noticed that VLAN interface derives its mtu attribute from the parent > > > interface (say en0) but uses a value that is 4 less than that of parent > > > interface. > > > So, if mtu for en0 is 1500 > > > vlanX on en0 will have mtu 1496. > > > > > > Also, stack does not allow user to set the mtu value at vlanX to be > more > > > than 1496 so that difference of 4 byte always stays. Neither does stack > > > allow mtu of en0 to be more than 1500. > > > > > > This causes issues when an IP peer with MTU set to 1500 sends > fragmented > > > packets to this interface vlanX. > > > > > > Theoratically, I do not understand the reasoning for having this > > > difference of 4 bytes. MTU at IP layer (1500 for ethernet) is IP header > > > + IP payload. It should make no difference to stack if the size of > > > Ethernet header is 14 bytes or 18 bytes as that should not be part of > > > MTU anyways. > > > > > > Please help in understanding this behavior of QNX stack and also any > > > workaround that is possible to use MTU size of 1500 on a VLAN > interface. > > > > > > Regards > > > VG > > > > > > > > > > > > _______________________________________________ > > > > > > Technology > > > http://community.qnx.com/sf/go/post68865 > > > > > > > > > > > _______________________________________________ > > > > Technology > > http://community.qnx.com/sf/go/post68893 > > > > > > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post68936 >

Patrik Lahti 2010-09-29T13:26:01Z Vineet Garg http://community.qnx.com/sf/go/post68936 2010-09-29T03:46:31Z 2010-09-29T03:46:31Z

hi patrik in my case system is not allowing to set mtu of parent interface to more than 1500 bytes thus leading to problems as even in article pointed to by you. To be compatible with other IEEE 802.1Q devices, the *vlan* interface sup- ports a 1500 byte MTU, which means that the parent interface will have to handle packets that are 4 bytes larger than the original Ethernet stan- dard Is this behavior dependent on underlying network driver or is a property of operating system? I have devn-ixp2351 as network driver in my case. Since article provides a list of network drivers that support increased mtu size, does it mean that ifconfig sends a devctl to network driver to check if given mtu value is supported or not? In that case I can modify my network driver to accept even higher mtu. On Wed, Sep 29, 2010 at 1:18 AM, Patrik Lahti <community-noreply@qnx.com>wrote: > This is expected and not unique to QNX. > > The 802.1Q encapsulation requires four more bytes which are then not > available for payload (IP or whatever). > > To change the MTU of the VLAN interface I believe you'll have to set the > parent interface's MTU to be bigger. > > See e.g. http://netbsd.gw.com/cgi-bin/man-cgi?vlan+4 > > /P > > On 10-09-28 02:17 PM, Vineet Garg wrote: > > Hi > > > > I noticed that VLAN interface derives its mtu attribute from the parent > > interface (say en0) but uses a value that is 4 less than that of parent > > interface. > > So, if mtu for en0 is 1500 > > vlanX on en0 will have mtu 1496. > > > > Also, stack does not allow user to set the mtu value at vlanX to be more > > than 1496 so that difference of 4 byte always stays. Neither does stack > > allow mtu of en0 to be more than 1500. > > > > This causes issues when an IP peer with MTU set to 1500 sends fragmented > > packets to this interface vlanX. > > > > Theoratically, I do not understand the reasoning for having this > > difference of 4 bytes. MTU at IP layer (1500 for ethernet) is IP header > > + IP payload. It should make no difference to stack if the size of > > Ethernet header is 14 bytes or 18 bytes as that should not be part of > > MTU anyways. > > > > Please help in understanding this behavior of QNX stack and also any > > workaround that is possible to use MTU size of 1500 on a VLAN interface. > > > > Regards > > VG > > > > > > > > _______________________________________________ > > > > Technology > > http://community.qnx.com/sf/go/post68865 > > > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post68893 > >

Vineet Garg 2010-09-29T03:46:31Z Patrik Lahti http://community.qnx.com/sf/go/post68893 2010-09-28T19:48:38Z 2010-09-28T19:48:38Z

This is expected and not unique to QNX. The 802.1Q encapsulation requires four more bytes which are then not available for payload (IP or whatever). To change the MTU of the VLAN interface I believe you'll have to set the parent interface's MTU to be bigger. See e.g. http://netbsd.gw.com/cgi-bin/man-cgi?vlan+4 /P On 10-09-28 02:17 PM, Vineet Garg wrote: > Hi > > I noticed that VLAN interface derives its mtu attribute from the parent > interface (say en0) but uses a value that is 4 less than that of parent > interface. > So, if mtu for en0 is 1500 > vlanX on en0 will have mtu 1496. > > Also, stack does not allow user to set the mtu value at vlanX to be more > than 1496 so that difference of 4 byte always stays. Neither does stack > allow mtu of en0 to be more than 1500. > > This causes issues when an IP peer with MTU set to 1500 sends fragmented > packets to this interface vlanX. > > Theoratically, I do not understand the reasoning for having this > difference of 4 bytes. MTU at IP layer (1500 for ethernet) is IP header > + IP payload. It should make no difference to stack if the size of > Ethernet header is 14 bytes or 18 bytes as that should not be part of > MTU anyways. > > Please help in understanding this behavior of QNX stack and also any > workaround that is possible to use MTU size of 1500 on a VLAN interface. > > Regards > VG > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post68865 >

Patrik Lahti 2010-09-28T19:48:38Z Vineet Garg http://community.qnx.com/sf/go/post68865 2010-09-28T18:17:31Z 2010-09-28T18:17:31Z

Hi I noticed that VLAN interface derives its mtu attribute from the parent interface (say en0) but uses a value that is 4 less than that of parent interface. So, if mtu for en0 is 1500 vlanX on en0 will have mtu 1496. Also, stack does not allow user to set the mtu value at vlanX to be more than 1496 so that difference of 4 byte always stays. Neither does stack allow mtu of en0 to be more than 1500. This causes issues when an IP peer with MTU set to 1500 sends fragmented packets to this interface vlanX. Theoratically, I do not understand the reasoning for having this difference of 4 bytes. MTU at IP layer (1500 for ethernet) is IP header + IP payload. It should make no difference to stack if the size of Ethernet header is 14 bytes or 18 bytes as that should not be part of MTU anyways. Please help in understanding this behavior of QNX stack and also any workaround that is possible to use MTU size of 1500 on a VLAN interface. Regards VG

Vineet Garg 2010-09-28T18:17:31Z Vineet Garg http://community.qnx.com/sf/go/post68857 2010-09-28T18:03:25Z 2010-09-28T18:03:25Z

Hi Sean Fixed the leak that I was facing, however for future dev can you please let me know the way to find out if the select()/poll() memory leak fix in io-net is present in OS version that I am using. Regards VG > On Tue, Aug 31, 2010 at 11:27:14PM -0400, Vineet Garg wrote: > > Hi > > > > This is an old thread, but i'll like to know if this problem was resolved. > > > > I am facing a memory leak where "pidin mem | grep io-net " shows continuous > increase in memory utilization over a period of time. We are running qnx 6.3.0 > and io-net. > > > > Any idea if this could be linked to an already known issue on io-net? > > > > Looking for help badly on this. > > See the top of this thread. One leak was plugged > in select() / poll() handling on multiple sockets. > > Regards, > > -seanb

Vineet Garg 2010-09-28T18:03:25Z Vineet Garg http://community.qnx.com/sf/go/post68856 2010-09-28T18:00:38Z 2010-09-28T18:00:38Z

Thanks Andrew & Sean for replying. I have been a little late in this update but I eventually found a leak in ethernet driver (proprietary driver feeding stack from a resource manager) in case packets coming from stack had more than 8 buffers in the chain. That brings me to question about why stack uses different number of buffer for packets of different sizes. Is that because io-net has a buffer pool of small size and it uses a number of them to create complete packet?

Vineet Garg 2010-09-28T18:00:38Z Nadeem Hasan http://community.qnx.com/sf/go/post65990 2010-09-03T20:22:03Z 2010-09-03T20:22:03Z

Hi, I am trying to install netperf on QNX 6.5.0 [Momentics IDE version 4.7.0]. I have extracted netperf-2.4.5 to an SD card that I plug into my target HW. I mount the SD, so that the netperf folder is visible and as per the installation notes from netperf I do the following for installing netperf: 1. cd netperf-2.4.5 2. ./configure ./netperf-2.4.5/configure[557]: sed: cannot execute - No such file or directory ./netperf-2.4.5/configure[1466]: sed: cannot execute - No such file or directory configure: error: cannot run /bin/sh ./netperf-2.4.5/config.sub ./netperf-2.4.5/configure: sed: cannot execute - No such file or directory ./netperf-2.4.5/configure: sort: cannot execute - No such file or directory ./netperf-2.4.5/configure: sed: cannot execute - No such file or directory ./netperf-2.4.5/configure: sort: cannot execute - No such file or directory and I get the above mentioned errors. I could not see a 'sed' or 'sort' executable under C:\QNX650\target\qnx6\armle\bin on my system. Can someone please point out what the issue is here and how can I resolve it? Nadeem.

Nadeem Hasan 2010-09-03T20:22:03Z Sean Boudreau http://community.qnx.com/sf/go/post65529 2010-09-01T18:10:57Z 2010-09-01T18:10:57Z

On Tue, Aug 31, 2010 at 11:27:14PM -0400, Vineet Garg wrote: > Hi > > This is an old thread, but i'll like to know if this problem was resolved. > > I am facing a memory leak where "pidin mem | grep io-net " shows continuous increase in memory utilization over a period of time. We are running qnx 6.3.0 and io-net. > > Any idea if this could be linked to an already known issue on io-net? > > Looking for help badly on this. See the top of this thread. One leak was plugged in select() / poll() handling on multiple sockets. Regards, -seanb

Sean Boudreau 2010-09-01T18:10:57Z Andrew Boyd(deleted) http://community.qnx.com/sf/go/post65365 2010-09-01T03:58:25Z 2010-09-01T03:58:25Z

99% of the time, this is caused by the driver leaking packets in a race condition somewhere. What driver are you using? -- aboyd ________________________________ From: Vineet Garg [mailto:community-noreply@qnx.com] Sent: Tue 8/31/2010 8:27 PM To: technology-networking Subject: Re: RE: io-net memory leak Hi This is an old thread, but i'll like to know if this problem was resolved. I am facing a memory leak where "pidin mem | grep io-net " shows continuous increase in memory utilization over a period of time. We are running qnx 6.3.0 and io-net. Any idea if this could be linked to an already known issue on io-net? Looking for help badly on this. Regards Vineet _______________________________________________ Technology http://community.qnx.com/sf/go/post65363

Andrew Boyd(deleted) 2010-09-01T03:58:25Z Vineet Garg http://community.qnx.com/sf/go/post65363 2010-09-01T03:27:13Z 2010-09-01T03:27:13Z

Hi This is an old thread, but i'll like to know if this problem was resolved. I am facing a memory leak where "pidin mem | grep io-net " shows continuous increase in memory utilization over a period of time. We are running qnx 6.3.0 and io-net. Any idea if this could be linked to an already known issue on io-net? Looking for help badly on this. Regards Vineet

Vineet Garg 2010-09-01T03:27:13Z Dan Laffoon http://community.qnx.com/sf/go/post63636 2010-08-19T20:11:44Z 2010-08-19T20:11:44Z

Hello, We are running io-pkt in QNX 6.5.0. We have some questions about priority levels on receive operation, and the handoff between the driver level and the TCP stack. We are specifying elevated interface-specific priorities at the driver command-line options. When the driver is done servicing the hardware at this elevated priority (on a receive event), and the thread becomes the TCP stack thread, does the TCP stack operation continue at the same priority as the driver? If so, is there any way to lower the thread priority when it becomes the TCP stack so that it can be pre-empted if more packets come in to the hardware? We have a requirement for a critical path from the hardware to a network filter to handle time-critical packets, and thus need guaranteed response to receive events in hardware. Thanks, Dan Laffoon

Dan Laffoon 2010-08-19T20:11:44Z Vineet Garg http://community.qnx.com/sf/go/post63283 2010-08-17T17:46:16Z 2010-08-17T17:46:16Z

Hi Need to get your opinion about a general concept about using IP routing over serial/ppp interfaces. Is it ok to configure an entry in routing table as follows: Serial1 (1.1.1.1/24) ---------ppp--------------Serial2(2.2.2.2/24) ---IP----3.3.3.3/24 So at host having serial1: Route towards 3.3.3.3/24 using next hop as 2.2.2.2 Normally this is not allowed since next hop IP address needs to be in same subnet. However, do you think that subnet concept is meaningless in case of serial interface because it is not broadcast medium. Regards VG

Vineet Garg 2010-08-17T17:46:16Z Fernando Gonzalez http://community.qnx.com/sf/go/post62982 2010-08-13T19:09:40Z 2010-08-13T19:09:40Z

Does QNX support the capability an unnumbered IP interface on an Ethernet port. We found already this page: http://community.qnx.com/sf/go/wiki3072?nav=1 It says "it is not currently supported". But the page does not have a date and any reference to the word "current". To which release does "current" refer to? Are there any plans to support this on a future release? Thanks, -Fernando Gonzalez

Fernando Gonzalez 2010-08-13T19:09:40Z Gordon Molek http://community.qnx.com/sf/go/post61541 2010-08-04T13:18:24Z 2010-08-04T13:18:24Z

I have tried following the instructions on the foundry for building the networking source to no avail, using the DOS command window method and through the Momentics IDE. Can the networking source be complied without first compiling the os source? Does hide-gnu.mk need to be run for the networking source, or just for the os source? If so, does it take a DOS-style path (e.g., E:/core_networking)? Should the INSTALL_ROOT_nto line of qconf-override.mk use a DOS-style path (e.g., E:/core_networking/stage)? Does the QCONF_OVERRIDE environment variable need a DOS-style path (e.g., "set QCONF_OVERRIDE=E:/core_networking/qconf-override.mk")? When attempting to build the OS, when I run "make OSLIST=nto hinstall" I get errors of the form: /usr/bin/cp: cannot stat 'e:/QNX641/host/win32/x86/usr/cygdrive/e/qnx/trunk/lib/c/public/x86/string.h': No such file or directory Do I need to run "make OSLIST=nto hinstall" to build the networking source, or go straight to "make CPULIST=arm install"? -----Original Message----- From: Patrik Lahti [mailto:community-noreply@qnx.com] Sent: Thursday, July 29, 2010 3:03 PM To: technology-networking Subject: Re: TTLS failure No it's not part of 6.5. It's on trunk only. So you need to get the latests source code from SVN. /P On 10-07-29 03:03 PM, Gordon Molek wrote: > The updated supplicant is not part of 6.5? We just tried building wpa_supplicant with 6.5 (and EAP-FAST enabled) and we get similar linkage failures. > > -----Original Message----- > From: Patrik Lahti [mailto:community-noreply@qnx.com] > Sent: Friday, July 02, 2010 11:52 AM > To: technology-networking > Subject: Re: TTLS failure > > Hi Gordon, > > Good news, we've actually got openssl 1.0.0 in trunk. And EAP-FAST is in > wpa_supplicant trunk too now, but untested so far due other priorities. > It would be great if you can try it out! > > Please let me know if you have success or any problems with EAP-FAST. > > Cheers& Good luck! > /P > > On 10-06-29 01:04 PM, Gordon Molek wrote: >> Thanks for the quick response. >> >>> I assume you're talking about EAP-TTLS in the context of wpa_supplicant? >> >> Yes, I should have been more specific. >> >>> What version of QNX are you using? >> >> 6.4.1 On a related note, OpenSSL 0.9.8g doesn't appear to support EAP-FAST (there seems to be a patch for 0.9.8i) are there plans to pick up support for EAP-FAST? >> >>>> TLS: Certificate verification failed, error 9 (certificate is not yet valid) >>> depth 1 for '/DC=test/DC=ctc-zebra/CN= >>> >>> This indicates to me that the certificate is deemed to yet not valid. >>> Maybe the time on your target is not set correctly? Or the certificate >>> was created with validity time in the future? >> >> Ah! I hadn't even thought of that! Yes, my target was using the default date of 1970. Setting the date and then running wpa_supplicant gets me past that failure. We don't complete authentication yet, but I need to do more digging. >> >>>> Does anyone have TTLS working? >>> >>> Yes, I think I've used EAP-TTLS although not recently though... and >>> probably not with a self-signed certificate. Please check the documentation. >> >> By "documentation" are you referring to the QNX, wpa_supplicant or OpenSSL documentation? >> >> Again, thanks for the quick response. >> >> >> >> _______________________________________________ >> >> Technology >> http://community.qnx.com/sf/go/post58100 >> > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post58341 > > > > - CONFIDENTIAL- > > This email and any files transmitted with it are confidential, and may also be legally privileged. If you are not the intended recipient, you may not review, use, copy, or distribute this message. If you receive this email in error, please notify the sender immediately by reply email and then delete this email. > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post61097 > _______________________________________________ Technology http://community.qnx.com/sf/go/post61108

Gordon Molek 2010-08-04T13:18:24Z Patrik Lahti http://community.qnx.com/sf/go/post61108 2010-07-29T20:02:31Z 2010-07-29T20:02:31Z

No it's not part of 6.5. It's on trunk only. So you need to get the latests source code from SVN. /P On 10-07-29 03:03 PM, Gordon Molek wrote: > The updated supplicant is not part of 6.5? We just tried building wpa_supplicant with 6.5 (and EAP-FAST enabled) and we get similar linkage failures. > > -----Original Message----- > From: Patrik Lahti [mailto:community-noreply@qnx.com] > Sent: Friday, July 02, 2010 11:52 AM > To: technology-networking > Subject: Re: TTLS failure > > Hi Gordon, > > Good news, we've actually got openssl 1.0.0 in trunk. And EAP-FAST is in > wpa_supplicant trunk too now, but untested so far due other priorities. > It would be great if you can try it out! > > Please let me know if you have success or any problems with EAP-FAST. > > Cheers& Good luck! > /P > > On 10-06-29 01:04 PM, Gordon Molek wrote: >> Thanks for the quick response. >> >>> I assume you're talking about EAP-TTLS in the context of wpa_supplicant? >> >> Yes, I should have been more specific. >> >>> What version of QNX are you using? >> >> 6.4.1 On a related note, OpenSSL 0.9.8g doesn't appear to support EAP-FAST (there seems to be a patch for 0.9.8i) are there plans to pick up support for EAP-FAST? >> >>>> TLS: Certificate verification failed, error 9 (certificate is not yet valid) >>> depth 1 for '/DC=test/DC=ctc-zebra/CN= >>> >>> This indicates to me that the certificate is deemed to yet not valid. >>> Maybe the time on your target is not set correctly? Or the certificate >>> was created with validity time in the future? >> >> Ah! I hadn't even thought of that! Yes, my target was using the default date of 1970. Setting the date and then running wpa_supplicant gets me past that failure. We don't complete authentication yet, but I need to do more digging. >> >>>> Does anyone have TTLS working? >>> >>> Yes, I think I've used EAP-TTLS although not recently though... and >>> probably not with a self-signed certificate. Please check the documentation. >> >> By "documentation" are you referring to the QNX, wpa_supplicant or OpenSSL documentation? >> >> Again, thanks for the quick response. >> >> >> >> _______________________________________________ >> >> Technology >> http://community.qnx.com/sf/go/post58100 >> > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post58341 > > > > - CONFIDENTIAL- > > This email and any files transmitted with it are confidential, and may also be legally privileged. If you are not the intended recipient, you may not review, use, copy, or distribute this message. If you receive this email in error, please notify the sender immediately by reply email and then delete this email. > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post61097 >

Patrik Lahti 2010-07-29T20:02:31Z Sean Boudreau http://community.qnx.com/sf/go/post61102 2010-07-29T19:39:16Z 2010-07-29T19:39:16Z

On Thu, Jul 29, 2010 at 03:03:10PM -0400, Gordon Molek wrote: > The updated supplicant is not part of 6.5? We just tried building wpa_supplicant with 6.5 (and EAP-FAST enabled) and we get similar linkage failures. No, not 6.5. The updated openssl and supplicant are on the foundry. Regards, -seanb

Sean Boudreau 2010-07-29T19:39:16Z Gordon Molek http://community.qnx.com/sf/go/post61097 2010-07-29T19:03:09Z 2010-07-29T19:03:09Z

The updated supplicant is not part of 6.5? We just tried building wpa_supplicant with 6.5 (and EAP-FAST enabled) and we get similar linkage failures. -----Original Message----- From: Patrik Lahti [mailto:community-noreply@qnx.com] Sent: Friday, July 02, 2010 11:52 AM To: technology-networking Subject: Re: TTLS failure Hi Gordon, Good news, we've actually got openssl 1.0.0 in trunk. And EAP-FAST is in wpa_supplicant trunk too now, but untested so far due other priorities. It would be great if you can try it out! Please let me know if you have success or any problems with EAP-FAST. Cheers & Good luck! /P On 10-06-29 01:04 PM, Gordon Molek wrote: > Thanks for the quick response. > >> I assume you're talking about EAP-TTLS in the context of wpa_supplicant? > > Yes, I should have been more specific. > >> What version of QNX are you using? > > 6.4.1 On a related note, OpenSSL 0.9.8g doesn't appear to support EAP-FAST (there seems to be a patch for 0.9.8i) are there plans to pick up support for EAP-FAST? > >>> TLS: Certificate verification failed, error 9 (certificate is not yet valid) >> depth 1 for '/DC=test/DC=ctc-zebra/CN= >> >> This indicates to me that the certificate is deemed to yet not valid. >> Maybe the time on your target is not set correctly? Or the certificate >> was created with validity time in the future? > > Ah! I hadn't even thought of that! Yes, my target was using the default date of 1970. Setting the date and then running wpa_supplicant gets me past that failure. We don't complete authentication yet, but I need to do more digging. > >>> Does anyone have TTLS working? >> >> Yes, I think I've used EAP-TTLS although not recently though... and >> probably not with a self-signed certificate. Please check the documentation. > > By "documentation" are you referring to the QNX, wpa_supplicant or OpenSSL documentation? > > Again, thanks for the quick response. > > > > _______________________________________________ > > Technology > http://community.qnx.com/sf/go/post58100 > _______________________________________________ Technology http://community.qnx.com/sf/go/post58341 - CONFIDENTIAL- This email and any files transmitted with it are confidential, and may also be legally privileged. If you are not the intended recipient, you may not review, use, copy, or distribute this message. If you receive this email in error, please notify the sender immediately by reply email and then delete this email.

Gordon Molek 2010-07-29T19:03:09Z Mitchell Schoenbrun http://community.qnx.com/sf/go/post60684 2010-07-26T23:33:11Z 2010-07-26T23:33:11Z

# sloginfo Time Sev Major Minor Args Jul 26 15:12:07 3 14 0 Threads exhausted. See "threads_max" option Now why don't I think of this sort of thing more often. That was the problem. I increased threads_max and the problem went away. Thanks, Mitchell

Mitchell Schoenbrun 2010-07-26T23:33:11Z Sean Boudreau http://community.qnx.com/sf/go/post60680 2010-07-26T22:44:10Z 2010-07-26T22:44:10Z

Is there anything in the sloginfo on 6.4? -seanb -----Original Message----- From: Mitchell Schoenbrun [mailto:community-noreply@qnx.com] Sent: Mon 7/26/2010 5:41 PM To: technology-networking Subject: Re: TCP/IP questions I now have a more clear picture of the connection problem. If I run a server and try to attach 100 clients, it locks up. If I run a server with 90 clients, it works fine. If I then start a 2nd server on another port and try to start clients, about 10 start up before everything locks up. After killing all the processes and waiting for the connections to time out, all seems back to normal. This suggests a built in limitation in io-net or io-pkg (I've tried both using 6.3.2 and 6.4) or the tcpip protocol module. I looked in the docs and could not find any mentioned limitation nor any parameter to increase the number of connections. This is not currently holding anything up, however my customer is very concerned about this as a roadblock to future expansion of the system we are developing. I would appreciate hearing whether there is any known reason for this behavior. Thank you _______________________________________________ Technology http://community.qnx.com/sf/go/post60666

Sean Boudreau 2010-07-26T22:44:10Z Mitchell Schoenbrun http://community.qnx.com/sf/go/post60666 2010-07-26T21:41:47Z 2010-07-26T21:41:47Z

I now have a more clear picture of the connection problem. If I run a server and try to attach 100 clients, it locks up. If I run a server with 90 clients, it works fine. If I then start a 2nd server on another port and try to start clients, about 10 start up before everything locks up. After killing all the processes and waiting for the connections to time out, all seems back to normal. This suggests a built in limitation in io-net or io-pkg (I've tried both using 6.3.2 and 6.4) or the tcpip protocol module. I looked in the docs and could not find any mentioned limitation nor any parameter to increase the number of connections. This is not currently holding anything up, however my customer is very concerned about this as a roadblock to future expansion of the system we are developing. I would appreciate hearing whether there is any known reason for this behavior. Thank you

Mitchell Schoenbrun 2010-07-26T21:41:47Z