PingApp with IPv6

[Jonas Hartwig]

Hi,

I set up a IPv6 Network which contains a router, nodeA and nodeB. When
I configure PingApp
*.nodeA.pingApp.interval = 100ms
**.pingApp.startTime = 5s (so Neighbourhood Discovery is done)
*.nodeA.pingApp.destAddr = "nodeB"
do I always the error that the destination address is not specified.
What do I miss?

regards

[Christi...@dlr.de]

Hi,

I assume the error occurs at time t=5s.

Did you check whether nodeB has succesfully configured a *global* Ipv6 address until t=5?

Cheers

> --
> You received this message because you are subscribed to the Google Groups
> "omnetpp" group.
> To post to this group, send email to omn...@googlegroups.com.
> To unsubscribe from this group, send email to
> omnetpp+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/omnetpp?hl=en.

[Jonas Hartwig]

i tried to figure out where to find this info... but i dindt :(

[Jonas Hartwig]

I figured out i forgot the FlatNetworkConfigurator6... now i have the
problem that the nodes can ping themselves directly... if connected,
but not via the router... the ping message gets encapsulated in an NS-
message, goes to the router, no response, no forwarding...
output looks like this:
** Event #353 T=5.1 net.nodeA.pingApp (PingApp, id=8), on selfmsg
`sendPing' (cMessage, id=0)
Sending ping #1
** Event #354 T=5.1 net.nodeA.networkLayer6.icmpv6 (ICMPv6, id=22),
on `ping1' (PingPayload, id=148)
** Event #355 T=5.1 net.nodeA.networkLayer6.ipv6 (IPv6, id=21), on
`ping1' (ICMPv6EchoRequestMsg, id=149)
fragmentation not implemented yet
Routing datagram `ping1' with dest=aaaa:2::aaa:ff:fe00:2: next hop for
aaaa:2::aaa:ff:fe00:2 is aaaa:2::aaa:ff:fe00:2, interface lrwpan
no link-layer address for next hop yet, passing datagram to Neighbour
Discovery module
** Event #356 T=5.1 net.nodeA.networkLayer6.neighbourDiscovery
(IPv6NeighbourDiscovery, id=24), on `ping1' (IPv6Datagram, id=150)
Packet (IPv6Datagram)ping1 arrived from IPv6 module.
Determining Next Hop
Find out if supplied dest addr is on-link or off-link.
Dest is on-link, next-hop addr is same as dest addr.
Next Hop Address is: aaaa:2::aaa:ff:fe00:2 on interface: 101
Reachability State is INCOMPLETE.Address Resolution already initiated.

something is wrong :(

[Jonas Hartwig]

The routingtable6 gets not filled properly, as is can see.
Suggestions?
regards

[Christi...@dlr.de]

Hi,

This is normal behaviour.
The router does not yet have a NC entry for that destination address. So it will multicast a NS to all its nodes. Node B should reply with a NA to the router.
The router will then forward the ping to Node B.

However, I would strongly advise you to take one of the existing examples and extend it to fit your needs. With this approach, these problems would not have occurred...

Regards

[Jonas Hartwig]

I did as you suggested. I took the example from INET (ipv6bulk) and
exchanged just the interfaces...
Same result, they do ND and when the PingApp starts (client1 is
supposed to ping client 3) after 5 sec i get the result that client 1
sends NS again to the router without any response:
Sending ping #0
** Event #651 T=5 NetIPv6over802154.client1.networkLayer.icmpv6
(ICMPv6, id=24), on `ping0' (PingPayload, id=296)
** Event #652 T=5 NetIPv6over802154.client1.networkLayer.ipv6 (IPv6,
id=23), on `ping0' (ICMPv6EchoRequestMsg, id=297)
fragmentation not implemented yet
Routing datagram `ping0' with dest=aaaa:4::aaa:ff:fe00:2: next hop for
aaaa:4::aaa:ff:fe00:2 is aaaa:4::aaa:ff:fe00:2, interface lrwpan

no link-layer address for next hop yet, passing datagram to Neighbour
Discovery module

** Event #653 T=5
NetIPv6over802154.client1.networkLayer.neighbourDiscovery
(IPv6NeighbourDiscovery, id=26), on `ping0' (IPv6Datagram, id=298)
Packet (IPv6Datagram)ping0 arrived from IPv6 module.

Determining Next Hop
Find out if supplied dest addr is on-link or off-link.
Dest is on-link, next-hop addr is same as dest addr.

Next Hop Address is: aaaa:4::aaa:ff:fe00:2 on interface: 101
No Entry exists in the Neighbour Cache.
Creating an INCOMPLETE entry in the neighbour cache.
Initiating Address Resolution for:aaaa:4::aaa:ff:fe00:2 on Interface:
101
Preparing to send NS to solicited-node multicast group
on the next hop interface
Add packet to entry's queue until Address Resolution is complete.
** Event #654 T=5 NetIPv6over802154.client1.networkLayer.ipv6 (IPv6,
id=23), on `NSpacket' (IPv6NeighbourSolicitation, id=299)
fragmentation not implemented yet
** Event #655 T=5 NetIPv6over802154.client1.bridge (MixnetBridge,
id=17), on `NSpacket' (IPv6Datagram, id=301)
NSpacket
** Event #656 T=5 NetIPv6over802154.client1.lrwpan.mac (CSMA802154,
id=28), on `NSpacket' (IPv6Datagram, id=301)
** Event #657 T=5 NetIPv6over802154.client1.lrwpan.mac (CSMA802154,
id=28), on selfmsg `timer-backoff' (cMessage, id=4)
** Event #658 T=5 NetIPv6over802154.client1.lrwpan.mac (CSMA802154,
id=28), on `{Radio switching over}' (cMessage, id=303)
** Event #659 T=5 NetIPv6over802154.client1.battery (SimpleBattery,
id=20), on selfmsg `auto-update' (cMessage, id=8)
** Event #660 T=5 NetIPv6over802154.client2.battery (SimpleBattery,
id=39), on selfmsg `auto-update' (cMessage, id=16)
** Event #661 T=5 NetIPv6over802154.client3.battery (SimpleBattery,
id=58), on selfmsg `auto-update' (cMessage, id=24)
** Event #662 T=5 NetIPv6over802154.server.battery (SimpleBattery,
id=77), on selfmsg `auto-update' (cMessage, id=32)
** Event #663 T=5 NetIPv6over802154.router.battery (SimpleBattery,
id=93), on selfmsg `auto-update' (cMessage, id=40)
** Event #664 T=5.00192 NetIPv6over802154.client1.lrwpan.mac
(CSMA802154, id=28), on selfmsg `timer-cca' (cMessage, id=5)
[Host 0] - PhyLayer(Decider): Creating RSSI map.
** Event #665 T=5.002112 NetIPv6over802154.client1.lrwpan.phy
(PhyLayerBattery, id=27), on selfmsg `{radio switching
over}' (cMessage, id=2)
** Event #666 T=5.002112 NetIPv6over802154.client1.lrwpan.mac
(CSMA802154, id=28), on `{Radio switching over}' (cMessage, id=305)
** Event #667 T=5.002112 NetIPv6over802154.client1.lrwpan.phy
(PhyLayerBattery, id=27), on `NSpacket' (MacPkt, id=304)
client1[0]::PhyLayerBattery: AirFrame encapsulated, length: 440
client1[0]::PhyLayerBattery: sendToChannel: sending to gates
** Event #668 T=5.002112 NetIPv6over802154.router.lrwpan.phy
(PhyLayerBattery, id=100), on `NSpacket' (AirFrame, id=306)
router[0]::PhyLayerBattery: Received new AirFrame (AirFrame)NSpacket
from channel.
PhyLayer(SimplePathlossModel): sqrdistance is: 35125
PhyLayer(SimplePathlossModel): wavelength is: 0.124914
PhyLayer(SimplePathlossModel): distance factor is: 1.31692e-008
PhyLayer(SimplePathlossModel): Signal contains frequency dimension: no
[Host 0] - PhyLayer(Decider): Processing AirFrame...
router[0]::PhyLayerBattery: Handed AirFrame with ID 13 to Decider.
Next handling in 0.000192s.
** Event #669 T=5.002304 NetIPv6over802154.router.lrwpan.phy
(PhyLayerBattery, id=100), on selfmsg `NSpacket' (AirFrame, id=306)
[Host 0] - PhyLayer(Decider): Processing AirFrame...
[Host 0] - PhyLayer(Decider): Creating RSSI map excluding AirFrame
with id 13
router[0]::PhyLayerBattery: Handed AirFrame with ID 13 to Decider.
Next handling in 0.001568s.
** Event #670 T=5.002304 NetIPv6over802154.router.lrwpan.mac
(CSMA802154, id=101), on `start_rx' (cMessage, id=307)
Invalid control message type (type=NOTHING) : name=start_rx
modulesrc=NetIPv6over802154.router.lrwpan.phy.
** Event #671 T=5.003872 NetIPv6over802154.client1.lrwpan.phy
(PhyLayerBattery, id=27), on selfmsg `{transmission over}' (cMessage,
id=3)
** Event #672 T=5.003872 NetIPv6over802154.client1.lrwpan.mac
(CSMA802154, id=28), on `{Transmission over}' (cMessage, id=308)
** Event #673 T=5.003872 NetIPv6over802154.router.lrwpan.phy
(PhyLayerBattery, id=100), on selfmsg `NSpacket' (AirFrame, id=306)
[Host 0] - PhyLayer(Decider): Processing AirFrame...
[Host 0] - PhyLayer(Decider): Creating RSSI map excluding AirFrame
with id 13
[Host 0] - PhyLayer(Decider): Creating RSSI map.
[Host 0] - PhyLayer(Decider): Adding mapping of Airframe with ID 13.
Starts at 5.002112 and ends at 5.003872
router[0]::PhyLayerBattery: Decapsulating MacPacket from Airframe with
ID 13 and sending it up to MAC.
router[0]::PhyLayerBattery: End of Airframe with ID 13.
** Event #674 T=5.003872 NetIPv6over802154.router.lrwpan.mac
(CSMA802154, id=101), on `NSpacket' (MacPkt, id=304)
** Event #675 T=5.003872 NetIPv6over802154.router.bridge
(MixnetBridge, id=90), on `NSpacket' (IPv6Datagram, id=301)
** Event #676 T=5.003872 NetIPv6over802154.router.networkLayer.ipv6
(IPv6, id=96), on `NSpacket' (IPv6Datagram, id=301)
destination address ff02::1:ff00:2 is multicast, doing multicast
routing
multicast dest address is link-local (or smaller) scope

I dont know whats wrong. any suggestions?

On 22 Jul., 15:40, Jonas Hartwig <nemut...@googlemail.com> wrote:
> Hi,
>
> thats a good advise. Ill try that today and post results if the
> routing works then...
>
> regards

[Jonas Hartwig]

The interesting part is that i can ping a wired node via the router if
its not connected over the same interface. how do i configure my
network that the router forwards also the wireless packages?

regards

> ...
>
> Erfahren Sie mehr »

[suneth namal]

EX:

*.nodeA.pingApp.destAddr = "aaaa:31:2:0:aaa:ff:fe00:9"

configure the nodeA and nodeB in .ini file too. 

try this out...

neighborhood discovery can be maintained with 

**.neighbourDiscovery.minIntervalBetweenRAs = 1 s

**.neighbourDiscovery.maxIntervalBetweenRAs = 3 s

Namal

--
You received this message because you are subscribed to the Google Groups "omnetpp" group.
To post to this group, send email to omn...@googlegroups.com.
To unsubscribe from this group, send email to omnetpp+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/omnetpp?hl=en.

--
Suneth Namal

[Jonas Hartwig]

Thx for your help. But I think the problem is more that they
communicate over the same media because its wireless. when i connect
all nodes via ethernet it works fine. But because the nodes are out of
range, they send NS because they search for neighbours. these they
dont find cause its out of range and the router does not forward the
request. The router should just read the NS and flood it again, read
the answere and flood this again too. then the same with the ping and
answere...

or am i wrong?

On 22 Jul., 17:37, suneth namal <sune...@gmail.com> wrote:
> EX:
>
> *.nodeA.pingApp.destAddr = "aaaa:31:2:0:aaa:ff:fe00:9"
> configure the nodeA and nodeB in .ini file too.
> try this out...
>
> neighborhood discovery can be maintained with
> **.neighbourDiscovery.minIntervalBetweenRAs = 1 s
> **.neighbourDiscovery.maxIntervalBetweenRAs = 3 s
>
> Namal
>

[News]

The Problem is that the flatnetwork configurator, assigns addresses all of one subnet. It is not aware that there is a router. So your node thinks that all other nodes are on its link and therefor sends ns to the neighbor solicited mc address. But no one answers, because these messages are link local scope.

Jonas Hartwig <nemu...@googlemail.com> schrieb:

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

[Jonas Hartwig]

Yeah, and how can I work around that? thers no way, is there?

regards

On 22 Jul., 19:02, News <grub...@googlemail.com> wrote:
> The Problem is that the flatnetwork configurator, assigns addresses all of one subnet. It is not aware that there is a router. So your node thinks that all other nodes are on its link and therefor sends ns to the neighbor solicited mc address. But no one answers, because these messages are link local scope.
>

> Jonas Hartwig <nemut...@googlemail.com> schrieb:

[suneth namal]

There is a high probability happening what you are saying. I also have face the same problem you explain above. I think you can conform this after testing it with UDP or TCP

check changing the location of the mobile.

and change the **.AP.wlan.radio.channelNumber = x # x =0-5 and try for different channel numbers too

if you chack it for UDP:

**.mobilehiphost.numUdpApps = 1

**.mobilehiphost.udpAppType = "UDPEchoStream"

**.mobilehiphost.udpApp[0].port = 2000

# 15 kbps :256B packet 0.13333 sec interval

**.mobilehiphost.udpApp[0].waitInterval = 0.133333 s

**.mobilehiphost.udpApp[0].packetLength = 256 B

**.mobilehiphost.udpApp[0].destPort = 2001

**.mobilehiphost.udpApp[0].startTime = 21 s

**.mobilehiphost.udpApp[0].destAddress = "2001:0db8:85a3:0000:0000:8a2e:0370:0253"

**.srv.numUdpApps = 1

**.srv.udpAppType = "UDPEchoApp"

**.srv.udpApp[0].localPort = 2001

**.srv.udpApp[0].destPort = 2000

**.srv.udpApp[0].messageLength = 0

**.srv.udpApp[0].messageFreq = 1 s

**.srv.udpApp[0].dest_addresses = ""

or for TCP ===========================================

**.mobilehiphost.numTcpApps = 1

**.mobilehiphost.tcpAppType = "TCPSinkApp"

**.mobilehiphost.tcpApp[0].address = "2001:0db8:85a3:0000:0000:8a2e:0370:0254" 

**.mobilehiphost.tcpApp[0].port = 1000

**.srv.numTcpApps = 1

**.srv.tcpAppType = "TCPSessionApp"

**.srv.tcpApp[0].port = 1001

**.srv.tcpApp[0].active = true

**.srv.tcpApp[0].address = "2001:0db8:85a3:0000:0000:8a2e:0370:0253"

**.srv.tcpApp[0].connectAddress = "2001:0db8:85a3:0000:0000:8a2e:0370:0254"

**.srv.tcpApp[0].connectPort = 1000

**.srv.tcpApp[0].tOpen = 15 s

**.srv.tcpApp[0].tSend = 20 s

**.srv.tcpApp[0].tClose = 120 s

**.srv.tcpApp[0].sendBytes = 100000000 B

**.srv.tcpApp[0].sendScript = ""

# tcp settings.

**.tcp.mss = 1024

**.tcp.advertisedWindow = 14336  # 14*mss

**.tcp.sendQueueClass = "TCPMsgBasedSendQueue"

**.tcp.receiveQueueClass = "TCPMsgBasedRcvQueue"

**.tcp.tcpAlgorithmClass = "TCPReno"

**.tcp.recordStats = false

Once you check this out for sure you will know what happens.

GD luck

Namal

[Amjed]

Hi Jonas

hope you fine, I have a typical scenario for implementing  IPv6 Network which contains a router, nodeA and nodeB to apply IPv6 in IPv4 tunnel (encapsulation),, may you advise me how can I implement it ????

Many Thanks.

[Mohammadreza sahebi]

[Narimane Elhilali]

hello ,

Did you configure  this encapsulation  (IPv6 in IPv4 tunnel )