|
William Hoey(deleted)
02/24/2015 1:27 PM
post113369
|
With some assistance from this forum (many thanks) I have been able to port my network driver to run under io-pkt.
I am able to ping the hardware with varying packet sizes, however I am having some trouble getting qconn to work.
The packets reach the hardware, if print the packet received it matches the wireshark (excluding the ethernet header)
capture and netstat -s reports that the packet has been received, however no response is generated. When I run pidin the
qconn process is started:
I was wondering if I was missing a configuration step and what steps I could take to determine why the stack does not
generate a response.
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192
input: 0 packets, 0 bytes
output: 0 packets, 0 bytes
inet 127.0.0.1 netmask 0xff000000
fr0: flags=88d3<UP,BROADCAST,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1500
address: 57:20:48:4f:45:59
media: Ethernet 10baseT full-duplex (<unknown subtype> full-duplex)
input: 17 packets, 1150 bytes, 17 multicasts
output: 6 packets, 412 bytes
inet 192.168.1.130 -> 192.168.7.255 netmask 0xfffff800 broadcast 192.168.7.255
# netstat -s
tcp:
0 packets sent
0 data packets (0 bytes)
0 data packets (0 bytes) retransmitted
0 ack-only packets (0 delayed)
0 URG only packets
0 window probe packets
0 window update packets
0 control packets
0 send attempts resulted in self-quench
78 packets received
0 acks (for 0 bytes)
0 duplicate acks
0 acks for unsent data
0 packets (0 bytes) received in-sequence
0 completely duplicate packets (0 bytes)
0 old duplicate packets
0 packets with some dup. data (0 bytes duped)
0 out-of-order packets (0 bytes)
0 packets (0 bytes) of data after window
0 window probes
0 window update packets
0 packets received after close
0 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
0 connection requests
0 connection accepts
0 connections established (including accepts)
0 connections closed (including 0 drops)
0 embryonic connections dropped
0 delayed frees of tcpcb
0 segments updated rtt (of 0 attempts)
0 retransmit timeouts
0 connections dropped by rexmit timeout
0 persist timeouts (resulting in 0 dropped connections)
0 keepalive timeouts
0 keepalive probes sent
0 connections dropped by keepalive
0 correct ACK header predictions
0 correct data packet header predictions
0 PCB hash misses
0 dropped due to no socket
0 connections drained due to memory shortage
0 PMTUD blackholes detected
0 bad connection attempts
0 SYN cache entries added
0 hash collisions
0 completed
0 aborted (no space to build PCB)
0 timed out
0 dropped due to overflow
0 dropped due to bucket overflow
0 dropped due to RST
0 dropped due to ICMP unreachable
0 delayed free of SYN cache entries
0 SYN,ACKs retransmitted
0 duplicate SYNs received for entries already in the cache
0 SYNs dropped (no route or no space)
0 packets with bad signature
0 packets with good signature
0 sucessful ECN handshakes
0 packets with ECN CE bit
0 packets ECN ECT(0) bit
udp:
0 datagrams received
...
View Full Message
|
|
|
|
|
|
Sean Boudreau(deleted)
02/24/2015 1:31 PM
post113370
|
On Tue, Feb 24, 2015 at 01:27:18PM -0500, William Hoey wrote:
> With some assistance from this forum (many thanks) I have been able to port my network driver to run under io-pkt.
>
> I am able to ping the hardware with varying packet sizes, however I am having some trouble getting qconn to work.
>
> The packets reach the hardware, if print the packet received it matches the wireshark (excluding the ethernet header)
capture and netstat -s reports that the packet has been received, however no response is generated. When I run pidin the
qconn process is started:
>
> I was wondering if I was missing a configuration step and what steps I could take to determine why the stack does not
generate a response.
>
> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192
> input: 0 packets, 0 bytes
> output: 0 packets, 0 bytes
> inet 127.0.0.1 netmask 0xff000000
> fr0: flags=88d3<UP,BROADCAST,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1500
> address: 57:20:48:4f:45:59
> media: Ethernet 10baseT full-duplex (<unknown subtype> full-duplex)
> input: 17 packets, 1150 bytes, 17 multicasts
17 multicast looks funny. tcp will silently
drop packets that have m->m_flags & (M_BCAST|M_MCAST)
|
|
|
|
|
|
William Hoey(deleted)
02/24/2015 1:51 PM
post113371
|
Mmmm
All packets received appear to increase the mutlicast count reported ifconfig -v.
I order to work around the IP link between the host and the target not supporting ARP I add the following to every MAC
header to every packet before passing it to the stack:
{0x57, 0x20, 0x48, 0x4F, 0x45, 0x59,0x00, 0x11, 0x93, 0x15, 0x52, 0xc0, 0x08, 0x00};
I also add the following arp and route entries:
arp -s 192.168.1.54 00:11:93:15:52:c0 fr0
arp -s 192.168.0.6 00:11:93:15:52:d0 fr0
route add -net 10.14.0 -netmask 255.255.255.0 192.168.0.6
route add -net 10.17.176 -netmask 255.255.255.0 192.168.0.6
I also config the target to use a 255.255.248.0 subnet, could that be the cause of the problem.
|
|
|
|
|
|
Sean Boudreau(deleted)
02/24/2015 2:19 PM
post113372
|
On Tue, Feb 24, 2015 at 01:51:31PM -0500, William Hoey wrote:
> Mmmm
>
> All packets received appear to increase the mutlicast count reported ifconfig -v.
>
> I order to work around the IP link between the host and the target not supporting ARP I add the following to every MAC
header to every packet before passing it to the stack:
>
> {0x57, 0x20, 0x48, 0x4F, 0x45, 0x59,0x00, 0x11, 0x93, 0x15, 0x52, 0xc0, 0x08, 0x00};
So the first oxtet of the destination address is 0x57
#define ETHER_IS_MULTICAST(addr) (*(addr) & 0x01)
>
> I also add the following arp and route entries:
>
> arp -s 192.168.1.54 00:11:93:15:52:c0 fr0
> arp -s 192.168.0.6 00:11:93:15:52:d0 fr0
> route add -net 10.14.0 -netmask 255.255.255.0 192.168.0.6
> route add -net 10.17.176 -netmask 255.255.255.0 192.168.0.6
>
> I also config the target to use a 255.255.248.0 subnet, could that be the cause of the problem.
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post113371
> To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
|
|
|
|
|
|
William Hoey(deleted)
02/24/2015 2:36 PM
post113373
|
Very many thanks, a bad choice of hard coded Ethernet Header.
It would have taken a while to spot that (particularly as the IP stack that has been running on the target incorrectly
lets me away with that seen hard coded Ethernet Header)
Both qconn and telnet are now working.
:-)
|
|
|
|
|
|
